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. > 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 ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
