Re: [RRG] What do we have consensus on?

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

Dave,

If you look for a "top-level branch" we will never find
a view that everyone agrees with. Let's just say that this
is one important axis or facet, and there are others of
similar importance. Viewed that way, I agree with Tony's
summary.

   Brian

On 2008-06-20 00:31, David R Oran wrote:
> 
> On Jun 19, 2008, at 1:41 AM, Tony Li wrote:
> 
>>
>> |through a phone chat with Tony, I finally got what's the above tried
>> |to say.
>> |It's all due to from which angle one looks at the picture.
>> |
>> |I take the view of scaling routing by provider-aggregatable prefixes:
>> |for a multihomed site, both SHIM6 and Handley proposal take the
>> |multiple provider-based addresses all the way *into* each host.  As
>> |far as routing scalability is concerned, it makes no difference
>> |whether these multiple PA addresses stop at a shim layer, or go to
>> |transport layer (of course it can make a big difference as far as
>> |transport functions are concerned).
>> |This is top-level branch#1 in my earlier msg
>> |http://psg.com/lists/rrg/2008/msg01220.html
>> |
>> |Tony's above msg took the view from transport layer and *looking
>> |downward*: SHIM6 has this notion of EID, and the actual IP packets
>> |*may* be sent using IP addresses that are different from EID, hence
>> |"this is a translation" view, i.e. a translation from an "EID" to an
>> |"IP address".
>> |(to be more precise, SHIM6's notion, as I understand it, is really a
>> |binding of a set of IP addresses to one transport session, so anyone
>> |in the set can be used. But lets not argue this semantic detail).
>>
>>
>> Agreed.  So if we look at things from the network side looking in, we
>> have
>> the classes where:
>>
>> - Locators propagate all the way to the host
>> - Locators are terminated at the site border
>>
>> From the feedback that we got from the SHIM6 discussion, there really
>> aren't
>> enough tools today to deal with the case where locators propagate to the
>> host.  This isn't to say that it couldn't be fixed, just that there's an
>> (engineering?) issue to be dealt with.
>>
>> Do we agree with this separation?  And is it useful?
>>
> While I agree with the separation as a conceptually useful distinction,
> for me it isn't really the "top-level branch" in the architectural tree
> because one could always put a map-n-encap module in the routing layer
> of each host and then there would be three host-oriented approaches:
> - topologically-aggregatable addresses and EIDs inside the routing layer
> of the host. Only EIDs visible to transport
> - topologically-aggregatable addresses mapped to/from an EID in a shim
> layer between routing and transport layers of the host. Only EIDs
> visible to transport
> - topologically-aggregatable addresses directly managed by the transport
> layer of the host
> 
> Others will of course see this differently, but for me the top level
> branch is in fact whether the solution *requires* code and state in the
> hosts, or conversely can be done by routers with the hosts totally
> oblivious. A consequence of this branching is that if you require new
> code in the hosts, you can exploit state in the hosts, which has
> benefits which have been articulated many times on this list.
> 
> In the taxonomy above, only the first approach shields the hosts from
> the mapping/translation/whatever. That's pretty fundamental in my book.
> 
> DaveO.
> 
>> Tony
>>
>>
>> -- 
>> 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
> 
> 
> -- 
> 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
> 

--
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