On Apr 15, 2010, at 05:52, Brian E Carpenter wrote:
>> the flow-label MUST or, at
>> least, SHOULD be reset to 0 upon /leaving/ that domain,
>> otherwise the next domain may (or, will?) misinterpret the
>> meaning of the incoming "locally-defined" flow-label. The
>
> I'm personally quite attracted by this. It does further damage
> to the sacred principle that the flow label is immutable,
> but maybe that is the inevitable result anyway.
It may be useful to discuss this in the context of a more general question:
How does a domain stash temporary information (meaningful only in that domain)
into an IPv6 packet, with the intention of removing it again at domain egress?
See also:
"RPL Option for Carrying RPL Information in Data-Plane Datagrams",
Jonathan Hui, JP Vasseur, 10-Mar-10, <draft-hui-6man-rpl-option-00.txt>
The RPL protocol requires data-plane datagrams to carry RPL routing
information that is processed by RPL routers when forwarding those
datagrams. This document describes the RPL option for use within a
RPL domain.
This work was originally trying to use the flow label in a similar way, and has
moved to proposing to insert a hop-hy-hop option. Note that hop-by-hop options
*inserted* on the way destroy AH, so in this case they *must* be removed at
egress (including at final delivery; and the fun part about "removing" is then
how to reconstitute any padding in the original hbh option, if there was one).
I'm not saying the flow label does not pose an attractive nuisance for
addressing some of these problems.
But if it is already taken in a packet (by the sending host or by an
encapsulating domain), how does the domain derive the benefit?
We can either stipulate that everyone (end-to-end, encapsulating domain) please
use it in a similar way (i.e., 5-tuple), or we can provide for a way to stash
it on ingress and reconstruct it on egress (the only way that would be useful
for RPL, as its use would not be about the 5-tuple). None of this makes me
particularly happy right now.
(I'm not even saying the flow label work *must* consider this problem. It just
appears it's getting awfully close to it.)
Gruesse, Carsten
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
