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