[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    (IPng 3112) re: GSE+
From:       Ray Hunter <Ray.Hunter () mpn ! cp ! philips ! com>
Date:       1997-02-27 13:03:48
[Download RAW message or body]

After having read the proposal and the comments I'd like to add
my 1 Guilder's worth to the meeting by email.


I am convinced that the approach shown in GSE can be made to work today,
and provides a great opportunity for the future.

I am not convinced that GSE as it stands today is ready for rubber stamping.

Equally, GSE+ attempts to be a long term solution.



I do think that _temporarily_ encoding AS numbers in the ESD
will solve a number of problems, and enable early deployment
without significant hardship later. AS numbers are after all only
0-4095 at the moment, which is only 12 bits ;-)

I present a summary of the issues with GSE as I see them, and how using AS
numbers would be a _quick_fix_in_the_interim_.

I make no claims about encoding AS numbers in the ESD as a long term solution.

There is nothing fundamentally new in this proposal
(unless you haven't read GSE+ ;-).



Meanwhile, we can debate long term solutions over a longer term.
I'd hate for nothing to come out of this IETF meeting.


Routing Goop Determination at Start-up
--------------------------------------
problem raised several times on the list.

There is no specific protocol to tie location to ESD.
Many other protocols have similar items as an explicit service
(e.g. Novell SAP's for virtual server LAN's, Apple ZIP+NBP)

The proposed solution is to use DNS to redistribute a routing goop.

Paul Ferguson raises the question of whether this is a change in use
of DNS, and whether we are now confusing name resolution and routing.

I tend to agree that it is confusing (see next section below).


AS number change very infrequently, and could be made in to
DNS records with a minimum of fuss. They can have a very long TTL.

They can be linked to both an inverse tree, in the style of in-addr.arpa,
and linked to forward resolution domain names, such as company.com.


Routing Goop Variance at Site Re-homing may break routing
----------------------------------------------------------
problem raised by Paul Ferguson.

I am presuming that a routing goop is assigned per
_entry_point_ of an AS. If this is wrong, then flame me.

Routing changes at AS boundaries may break TCP sessions, because
this will also change the routing goop seen by the remote host
in the source address of packets.

This implies that goop records can only have a short TTL,
and that load on DNS will increase.

Otherwise a goop may change when BGP moves, and the application won't know.
Either the application has to time out the TCP session, and start a new
session, or the back-up routers have change their re-writing to take
over the old goop. This only covers the case where an AS has multi-homing
for pure long term back up purposes.

To me, this now implies DNS also has to be dynamically updated when a
routing goop changes. Otherwise new sessions to a site cannot be started.

In my view this _is_ a significant change on the routing/DNS relationship.


AS numbers do not change when a site re-routes via another provider,
so sessions will survive.

Today's routing policies are written in terms of AS numbers.
They will be equally valid for IPV6 during initial roll out.

ESD not long enough to be globally unique
-----------------------------------------
Mike himself raised this issue.

Mike believes he has fixed this in the move from 8+8 to GSE.

I do not see any reason to disagree.

AS numbers today are unique, so any scheme based on a pre-fix AS number
together with ANY address scheme that guarantees site uniqueness will provide
globally unique addresses.

Routing Goop Variance at site re-homing may Break Weak Security
---------------------------------------------------------------
comment by Robert Elz <kre@munnari.OZ.AU>

Weak security is weak security.

Many of these problems stem from the lack of an explicit session
layer in the IP view of the world. The fixes all talk in terms of
session type activies, but it is still a change to TCP or the application.


AS numbers are invariant, so there is no issue with them changing.

Furthermore ISP's can implement today's packet based security filters
based on an a simple prefix filter of the remote AS. There is no
need to get all excited about 10000 ESD's on the other end of the link.



Routing Goop Variance Breaks Applications that use Embedded Address
-------------------------------------------------------------------
raised by Richard Draves <richdr@microsoft.com> 

Embedded address application exist.

Remember the first FDDI to Ethernet or Ethernet to Token Ring bridges. yuk!

AS numbers are invariant and so can be embedded.


hope this can be taken on board.

best regards,
Ray Hunter
on contract to Origin
Building VA-130,
Postbus 218,
5600MD Eindhoven,
The Netherlands.
email: Ray.Hunter@mpn.cp.philips.com
email: Ray.Hunter@globis.net
www:   http://www.globis.net/~rhunter
phone: +31 40 2787988



------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com/pub/ipng
IPng Home Page:          	      http://playground.sun.com/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com

[prev in list] [next in list] [prev in thread] [next in thread]