Lixia, Dave, >>>> It should be noted that some folks come at things with an alternate >>>> branching structure: >>>> >>>> - Map-n-encap >>>> - Translation >>>> - Transport >>> >>> Where would you put SHIM6 in the above? >>> (I wasn't clear whether it belongs to transport, as the shim layer >>> is between IP and transport; while the proposal from Mark lies >>> entirely on transport) >>> >> The network/transport boundary is inside hosts and is emphemeral. The >> salient questions, at least to me, are: >> >> a) which bits on the wire are interpreted/set by hosts only versus >> which bits on the wire are interpreted/set/modified by routers only, >> versus which are interpreted/set/modified by both >> b) whether only the router hardware/software needs to modified, only >> the host hardware/software below the application interfaces needs to >> be modified, or if both need to modified >> c) if the scheme is undetectable by application code, detectable but >> not in any useful/harmful way by applicaiton code, or if application >> code is affected. > > an excellent set of questions. > it seems that the 3 branches above can be expressed by the answers to > the above questions.
Yes. A possibly important subcase of c is what kind of addresses are exposed to applications. Some of the proposals on the table expose non-routable identifiers, some don't. This affects how referrals work, whether applications need to use ice-like mechanisms when talking to each other, etc. Jari -- 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
