Subject: Re: DRAFT: Request for guidance about the flow label

From: Tina TSOU <[email-masked]>
Date: Wed, 05 May 2010 17:18:31 +0800

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

---

From: Fred Baker <[email-masked]>
Date: Wed, 5 May 2010 10:15:33 -0700

On May 5, 2010, at 2:18 AM, Tina TSOU wrote:

> [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.]

Yes, one could do that. It looks more and more like MPLS as you get there. Why not just use MPLS if that's what you're trying to achieve?

http://www.ipinc.net/IPv4.GIF

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 May 2010 11:13:08 +1200

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

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:
> ----- Original Message ----- From: Shane Amante
> To: Rémi Després
> 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.
> 
>>>> In my understanding, restoring domain-entrance FL-values at domain
>>>> exit should be a "MUST" for any domain-specific use:
>>>
>>> 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.
>>
> 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).
> 
> 
>> (Any computation of FLs based on 5-tuples in intermediate routers
>> would be well beyond what an asic can do.)
> 
> 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.
> 
> Header for restoral? When the exit router receives the packet, it uses
> the previous option to replace the existing one to implement restoral.]
> 
> 
> I completely agree that this is a challenging problem; however, I see a
> few ways of potentially dealing with it:
> 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

---

From: Tina TSOU <[email-masked]>
Date: Fri, 07 May 2010 11:53:14 +0800

Brian,
Agreed.
Let's wait and see what the choice the WG will make.

B. R.
Tina
----- Original Message ----- 
From: "Brian E Carpenter" <[email-masked]>
To: "Tina TSOU" <[email-masked]>
Cc: "Shane Amante" <[email-masked]>; "6man" <[email-masked]>
Sent: Thursday, May 06, 2010 7:13 AM
Subject: Re: Request for guidance about the flow label

Tina,

Regards
   Brian Carpenter

---

From: Tina TSOU <[email-masked]>
Date: Fri, 07 May 2010 11:59:21 +0800

Hi Fred,
If we select the approach 2 in draft-carpenter-6man-flow-update-03, the 
issue we talked below (either restoral or MPLS) would be solved.

B. R.
Tina
----- Original Message ----- 
From: "Fred Baker" <[email-masked]>
To: "Tina TSOU" <[email-masked]>
Cc: "Brian E Carpenter" <[email-masked]>; "Shane Amante" 
<[email-masked]>; "6man" <[email-masked]>
Sent: Thursday, May 06, 2010 1:15 AM
Subject: Re: DRAFT: Request for guidance about the flow label

> previous option to replace the existing one to implement restoral.]

Yes, one could do that. It looks more and more like MPLS as you get there. 
Why not just use MPLS if that's what you're trying to achieve?