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 [EMAIL PROTECTED] 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 PROTECTED] 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 PROTECTED] 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
