[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] What do we have consensus on?
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
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
>> |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
>> 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
>> 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.
>> to unsubscribe send a message to email@example.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 firstname.lastname@example.org 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 email@example.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