Brian,
Agreed.
Let's wait and see what the choice the WG will make.
B. R.
Tina
http://tinatsou.weebly.com/contact.html
----- Original Message -----
From: "Brian E Carpenter" <[email protected]>
To: "Tina TSOU" <[email protected]>
Cc: "Shane Amante" <[email protected]>; "6man" <[email protected]>
Sent: Thursday, May 06, 2010 7:13 AM
Subject: Re: Request for guidance about the flow label
Tina,
[Tina: How about keeping the previous flow label in the option of IPv6
Header for restoral? When the exit router receives the packet, it uses the
previous option to replace the existing one to implement restoral.]
This was discussed at one time by the authors of draft-chakravorty-6lsa,
but like any other proposed new header content, it would meet a lot
of opposition. Right now my feeling is that we should make a clear
decision to keep the flow label strictly immutable, or to change the
rule and make it mutable, but avoid all the complexity of any mixed
approach. Complexity in packet headers is a really bad idea.
I hope there'll be a revised draft in a few days that makes this
choice clear.
Regards
Brian Carpenter
On 2010-05-05 21:18, Tina TSOU wrote:
Hi,
Comments in line.
B. R.
Tina
http://tinatsou.weebly.com/contact.html
----- Original Message ----- From: Shane Amante
To: Rémi Després
Cc: 6man ; Brian E Carpenter
Sent: Friday, April 23, 2010 3:30 AM
Subject: Re: DRAFT: Request for guidance about the flow label
Remi,
I think we may be in agreement that domain-specific uses of the
flow-label are problematic for the reason you illustrate below? Namely,
that once one domain sets it to something that is not known to be a 3-
or 5-tuple of the IPv6 header, then you lose the ability to use that
flow-label for, say, calculating a load-balancing hash for LAG and ECMP
paths. See below for more.
On Apr 22, 2010, at 10:50 MDT, Rémi Després wrote:
Le 22 avr. 2010 à 17:31, Shane Amante a écrit :
Brian, Remi,
On Apr 22, 2010, at 06:50 MDT, Rémi Després wrote:
Le 22 avr. 2010 à 04:56, Brian E Carpenter a écrit :
I think we need to simplify the change proposed in
draft-carpenter-6man-flow-update-02 even more after the recent
discussions, while maintaining the proposed duality
(RFC 3697-like
use still possible, but locally-defined use also possible for those
who
want it).
In my understanding, restoring domain-entrance FL-values at domain
exit should be a "MUST" for any domain-specific use:
I'm concerned with Remi's above proposal about restoring FL-values at
domain exit.
IMHO, instead of restoring FL-values at domain exit, it is /much/
more simple to declare that Flow-Label values are _mutable_ when a
packet crosses over from one administratively defined domain to the
next. I doubt any existing, already deployed high-speed network
equipment (routers) would support any scheme to "restore"
domain-specific FL-values from entrance to exit of a domain --
although, I haven't conducted a thorough investigation with them;
rather, I'm basing this on knowledge of the forwarding architecture
of various, **already deployed** (and, will keep getting deployed)
platforms whose ASIC's are extremely limited, to say the least.
Would these deployment use domain-specific computations of flow labels?
Since I'm not a proponent of domain-specific, "special-use" flow-labels,
that's a question I can't answer, particularly given each
domain-specific proposal likely has various amounts of computational
complexity. (I'll save my comments on 'draft-hu-flow-label-cases' for a
separate e-mail).
If yes, have you more information on what they do?
(Any computation of FLs based on 5-tuples in intermediate routers
would be well beyond what an asic can do.)
How would we expect to implement restoral of domain-specific flow-labels
upon entrance or exit of a administratively-defined domain, (hopefully
in a _stateless_ manner)? I'm not sure if this has already been
discussed, but the only thing I've come up with is that upon entrance to
a domain, the ingress PE would have to "push" the existing IPv6
flow-label into a new, to-be-defined IPv6 Extension Header for transport
across the domain. Then, at exit from the administrative domain, the
egress PE would have to be able to "pop" the Extension Header containing
the old IPv6 flow-label and put it back into the outermost IPv6
flow-label field. That's: a) likely difficult/impossible to do in
existing HW; b) creates more challenges for routers in dealing with,
possibly, unknown Extension Headers; and, c) challenging operationally,
particularly if we were to require operators to turn this behavior
on/off at each border interface to their network.
[Tina: How about keeping the previous flow label in the option of IPv6
Header for restoral? When the exit router receives the packet, it uses
the previous option to replace the existing one to implement restoral.]
The main reason I see to restore FLs is that, if a domain replaces a
"good" FL coming from upstream (host generated and 5-tuple based ), by
another that isn't 5-tuple based, routers that are further downstream
won't be able to use the "good" FL for their load sharing.
I completely agree that this is a challenging problem; however, I see a
few ways of potentially dealing with it:
a) Restoral of domain-specific flow-label values, (your proposal), at
egress from an administratively defined domain -- which I find might be
impractical to implement; or,
b) Declare that the flow-label is _mutable_ by each administrative
domain. Therefore, I _MAY_ not trust an incoming IPv6 flow-label from
another administrative domain. However, in thinking about this a bit
more, this has problems of it's own, namely: a) the dependency of
intermediate routers to (re)calculate a "good" flow-label based off the
3- or 5-tuple in the IPv6 header (possible, but not guaranteed); and, b)
it could unintentionally overwrite "good" flow-labels, particularly
those of inter-domain IP-in-IPv6 tunnels (cf:
draft-carpenter-flow-ecmp), where the outer IPv6 header may have a
"good" flow-label based on the inner IP header's 5-tuple -- which is bad.
c) Declare the flow-label is _immutable_ and must be set by all hosts
and must only contain a 3- or 5-tuple hash of the appropriate IPv6
headers. Further use cases for the flow-label would be restricted.
IMHO, this would be by far the easiest from an implementation and
operational point-of-view, however this is unlikely to appeal to
proponents of domain-specific special-uses of flow-labels, unfortunately.
FWIW, related to the last point, (and as I'm sure you're well aware of),
I'd also add that we're well beyond the alpha and beta stages of IPv6
deployment and well into mad deployment phase of IPv6 to mitigate IPv4
address exhaustion. Therefore, if a legitimate use of flow-labels has
not been found in the last 15 years of IPv6 development, it's time to
move on and use the flow-label for something useful and practical in
production networks, (i.e.: a hash of the 3- or 5-tuple of L3 + L4
headers for LAG + ECMP load-balancing).
-shane
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
