Re: [RRG] RRG process clarification

[Jari Arkko <jari.arkko@piuha.net>]

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