Re: Request for guidance about the flow label

[Tina TSOU <[e-mail]>]

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" <[e-mail]>
To: "Tina TSOU" <[e-mail]>
Cc: "Shane Amante" <[e-mail]>; "6man" <[e-mail]>
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