Re: [RRG] RRG process clarification

[Scott Brim <swb@employees.org>]

On 5/2/08 12:47 PM, Tony Li allegedly wrote:
> It should be noted that some folks come at things with an alternate
> branching structure:
>
> 	- Map-n-encap
> 	- Translation
> 	- Transport

I would go with this conceptual framework, but not call it "transport",
since that can be confusing.  The point is that the solution is in the
endpoints (i.e. transport layer) not in the network.  Perhaps just say
"endpoint-based".


On 5/2/08 9:37 PM, Brian E Carpenter allegedly wrote:
> > IMHO, SHIM6 lives directly in the translation camp.  It is very much NAT in
> > the host.
>
> No, it's fundamentally different in that the packet delivered to the upper
> layer at the far end is identical to the packet sent by the upper layer.
> It's vital to distinuguish reversible mutation of the packet from irreversible
> mutation. 

Agreed.  That's why translation is different from encapsulation.
However ...

> So I would put shim6 and map-and-encap together; they are
> isomorphic viewed from the upper layer.

They deliver the same result from the point of view of the application,
but do so with very different requirements and placement of functions
and complexity.  I'm still in favor of "map/encap", "translation", and
"endpoint-based".


On 5/2/08 10:33 PM, Joel M. Halpern allegedly wrote:
> Actually, the way I look at it, both encaps and rewrite (map-and-encaps 
> and translation) have the property that the information of interest to 
> the upper layers is carried and preserved.  

But to get to that level, where they are the same, you have to get above
transport, and up there every proposal so far is essentially the same.
The information of interest to the upper layers is carried and
preserved.  So that doesn't distinguish things.

> The biggest difference I see
> (and I tend to think it is architectural, although there are those who 
> see it differently) is that by having the upper layers ignore part of 
> the packet, we can use that part for the mapping result, avoiding the 
> need for encapsulation.

Having lower layers ignore parts of the existing header just changes
the boundaries of what is semantically meaningful to them.  So far the
functions, and relationships between functions, have not changed, so I
would say that's not a significant architectural change.  However,
the fact that you add the new function is significant.  However
(again), That function can be added independent of whether it uses a
piece of an existing header or not.

Whether extra addressing information is placed in extra encapsulating
headers or is added to existing headers doesn't feel like a huge
difference either, since in either case the e2e information is still
preserved and can be extracted.  But if the e2e information can NOT be
extracted -- if I am an endpoint and I see someone changing all my
headers between me and my friend -- that feels like a significant
architectural change.

Scott

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