[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] Long term clean-slate only for the RRG?



> From owner-rrg@psg.com  Wed Jul  2 11:15:43 2008
> Date: Wed, 02 Jul 2008 12:10:46 -0400
> From: Scott Brim <swb@employees.org>
> To: Noel Chiappa <jnc@mercury.lcs.mit.edu>
> CC: rrg@psg.com
> Subject: Re: [RRG] Long term clean-slate only for the RRG?
>
> On 7/2/08 11:59 AM, Noel Chiappa allegedly wrote:
> >     > From: Peter Sherbin <pesherb@yahoo.com>
> > 
> >     >> As has been remarked before, routing and addressing are fundamentally
> >     >> inseparable...
> > 
> >     > It seems right but what is the basis for that statement? Does anyone
> >     > has a mathematical formula that proves it?
> > 
> > Addresses (routing-names) are the data that path-selection (routing) works
> > on. As such, they are inherently inseparable.
>
> I have trouble seeing them as tightly bound.  Routing is mechanisms for 
> passing around information in support of path discovery and selection. 
> The information is about routing-names but the form of those names has 
> only limited influence on the information about those names that needs 
> to be transferred, and even less on the mechanisms by which it is 
> transferred or used.  ??

Here we go with the terminology problem -- specifically the multiple,
overlaid, meanings attached to the symbol "address".   <sigh>


'Routing' is _not_ bound to the 'identifiers' used to specify destination
objects.

"Routing" _is_ inextricably bound to a location-specifying attribute of
the object which the 'identifier' _names_.

In present-day IP routing object label called the "IP Address" is used 
both as the identifier, and as the location-specifying attribute.

_Internal_ routing within a single network is closely, if not inextricably,
bound to the unique label that specifies the object's location on the
network -- thhe "IP address".

*External* routing is not so constrained.  One can use _any_ attribute of
the object that is sufficient to uniquely identify the specific network
to which it is connected.  One could easily build an '_external_ routing 
protocol/technology' that uses "AS numbers" as the 'where to go' specifiers. 
Use currently-existing routing technology _within_ an AS, but for traffic 
_leaving_ the AS -- and the obvious place to implement this is _at_ the AS 
border -- look up the "destination AS" for the destination 'address' and 
forward to the "next-hop AS" for that destination AS. 

Implementation details: One could (a) record the  source/dest AS in a new 
'transit packet' header, and use that, now embedded, "locator" information 
for all subsequent routing until the packet is delivered to the destination 
AS -- where the transit header would be stripped, and the 'local' routing 
protocol then used to reach the actual destination location.  *OR*, one could 
(b) do the 'destination location to servicing AS' lookup at each router, to 
get the destination AS, and select the 'next AS' based on that.  Approach (b) 
would appear to be prohibitively expensive, based solely on a very superficial 
look.  Approach (a) is little different in cost from any existing tunnelling
and/or encapsulation methodology, and should be workable and feasible.
This is, functionally, a map-and-encapsulate, using the AS no. as the locator.






--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg