Subject: Flow Label: 12 bits mutable and 8 bits immutable

From: Tina TSOU <[email-masked]>
Date: Wed, 28 Jul 2010 12:24:11 +0200

I like the proposal from Pascal Thurbert in today's meeting.
I believe that It's more acceptable for the majority of the different  
camps.

B. R.
Tina
http://tinatsou.weebly.com/contact.html

---

From: Bob Hinden <[email-masked]>
Date: Wed, 28 Jul 2010 14:27:50 +0200

Tina,

On Jul 28, 2010, at 12:24 PM, Tina TSOU wrote:

> I believe that It's more acceptable for the majority of the different camps.

One of the problems with this idea is that it makes the sub-fields to small to be useful.  

Bob

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Tina TSOU <[email-masked]>
Date: Wed, 28 Jul 2010 14:36:14 +0200

Bob,
I understood. But this is one of the best compromises so far.

B. R.
Tina

---

From: Aleksi Suhonen <[email-masked]>
Date: Wed, 28 Jul 2010 18:01:18 +0300

Hi,

> I believe that It's more acceptable for the majority of the different

I hated it. :-(

I feel that changing the structure of the IPv6 header like that at this 
stage is too late. And I feel the change is bigger than people think it is.

Some earlier discussion has suggested that if the label is "0", then 
it's mutable and otherwise it's immutable. And if an operator does 
change it, they should reset it on egress, and maybe hijack some other 
bit in the header (e.g. from DSCP?) to signal that the flow label has 
been fiddled with. This bit should of course also be reset at the same 
time as the label is reset.

--
	Aleksi Suhonen

---

From: Tina TSOU <[email-masked]>
Date: Wed, 28 Jul 2010 17:57:05 +0200

Comments in line.

B. R.
Tina

On Jul 28, 2010, at 5:01 PM, Aleksi Suhonen wrote:

> I feel that changing the structure of the IPv6 header like that at  
> this stage is too late. And I feel the change is bigger than people  
> think it is.
>
> it's mutable and otherwise it's immutable.
It's also fine, if people could agree on it. I'm fine with both  
proposals, as long as both mutable and immutable are possible.
> And if an operator does change it, they should reset it on egress,  
> and maybe hijack some other bit in the header (e.g. from DSCP?) to  
> signal that the flow label has been fiddled with. This bit should of  
> course also be reset at the same time as the label is reset.
>
> --
> 	Aleksi Suhonen

---

From: "George, Wes E IV [NTK]" <[email-masked]>
Date: Wed, 28 Jul 2010 15:55:44 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tina TSOU
Sent: Wednesday, July 28, 2010 11:57 AM
To: Aleksi Suhonen
Cc: [email-masked]
Subject: Re: Flow Label: 12 bits mutable and 8 bits immutable

> course also be reset at the same time as the label is reset.

[[WEG]] I refer you to Bert Manfredi's message http://www.ietf.org/mail-archive/web/ipv6/current/msg12042.html. The lack of a checksum is why I'm generally resistant to the idea of preserving immutability of this field in all or in part - while the RFC says it must be, in practical application, a single bit error ruins that assumption. There's no way to be sure that it's immutable within an AS, let alone across multiple ASes, so any implementation that relies on the intermediate networks not touching it (or worse, an implementation that "fiddles" with it and then somehow resets it to the original value on egress) is doomed to failure.

Wes George

This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: Tina TSOU <[email-masked]>
Date: Thu, 29 Jul 2010 10:41:37 +0200

B. R.
Tina

On Jul 28, 2010, at 10:55 PM, George, Wes E IV [NTK] wrote:

> [[WEG]] I refer you to Bert Manfredi's message http://www.ietf.org/mail-archive/web/ipv6/current/msg12042.html 
> . The lack of a checksum is why I'm generally resistant to the idea  
> of preserving immutability of this field in all or in part - while  
> the RFC says it must be, in practical application, a single bit  
> error ruins that assumption. There's no way to be sure that it's  
> immutable within an AS, let alone across multiple ASes, so any  
> implementation that relies on the intermediate networks not touching  
> it (or worse, an implementation that "fiddles" with it and then  
> somehow resets it to the original value on egress) is doomed to  
> failure.
So you mean either we solve the issue of checksum, or we rather select  
to let the flow label mutable completely?
>
> Wes George
>
> This e-mail may contain Sprint Nextel Company proprietary  
> information intended for the sole use of the recipient(s). Any use  
> by others is prohibited. If you are not the intended recipient,  
> please contact the sender and delete all copies of the message.
>

---

From: David Malone <[email-masked]>
Date: Thu, 29 Jul 2010 10:07:02 +0100

On Wed, Jul 28, 2010 at 03:55:44PM -0500, George, Wes E IV [NTK] wrote:
> [[WEG]] I refer you to Bert Manfredi's message
> http://www.ietf.org/mail-archive/web/ipv6/current/msg12042.html.
> The lack of a checksum is why I'm generally resistant to the idea
> error ruins that assumption.

I guess it depends on the application. If the checksum failed, the
packet would be tossed. If the result of the flow label being
corrupted is that the packet is tossed, then the application is
still OK. For example, this would be OK for the transport nonce
application, or using the flow label to find the right layer 3 queue
(if it goes to the wrong queue, there will be no corresponding layer
3 flow, so the packet will be tossed).

> There's no way to be sure that it's

Note, you can check if people are changing it using traceroute, by
comparing the values in the quotation in the ICMPv6 packet. The
idea is similar to this:

	http://www.wand.net.nz/~mluckie/pubs/icmp-pam07.pdf

Last time I checked (which was a couple of years ago), I couldn't
find anyone who was messing with the flow label in-flight. I still
have the code, so I could check what today's network is doing, if
anyone is interested.

	David.

---

From: Mark Smith <[email-masked]>
Date: Thu, 29 Jul 2010 19:08:48 +0930

Hi Wes,

On Wed, 28 Jul 2010 15:55:44 -0500

> [[WEG]] I refer you to Bert Manfredi's message http://www.ietf.org/mail-archive/web/ipv6/current/msg12042.html. The lack of a checksum is why I'm generally resistant to the idea of preserving immut…

That's why I think it could be termed a "best effort field".

Links or routers that are corrupting packets within your network/AS are
generally recognised fairly quickly and fixed fairly quickly, because
packet corruption is unlikely to be limited to just the flow label
field - it'll be impacting payloads, address fields etc. as well.

So it seems to me, that within an network/AS, where traffic
transport quality is usually better controlled, it could have 'best
effort' acceptable uses. If best effort isn't good enough for specific
applications, then you wouldn't use it. In those applications it may
still be useful as a 'hint' or other use field. As an example, within
your network/AS, you might use the flow field to hold a checksum,
instead of carrying it in the payload. There may be a variety of
applications where the quality of the local network/AS goes some way to
making up for it's lack of end-to-end immutability and protection, such
that the risks of using it don't outweigh the benefits gained.

Thinking about the term "end-to-end" a bit further, the
unstated assumption and context is "end-to-end (across the Internet)".
That's the correct thing to protect against, because it is also the
worst case, with the most risks. However, if the scope of
"end-to-end" is reduced, e.g. "end-to-end (across a single network/AS)",
the protections may not need to be as strict, allowing for other
acceptable uses of this field.

Regards,
Mark.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 29 Jul 2010 14:13:31 +0200

Hi Aleksi:

I think that the premise in the discussion was that the network egress
is incapable of restoring zero. 

This taken into account we observe that:

- there is a clear and documented need for the network to tag the
packet. This happens for load balancing reasons, but also for routing
reasons, when multiple topologies can be used (eg multihoming, RPL
etc...)
- 12 mutable bits is seen as enough. We had a proposed usage in RPL that
needed just that as well. RPL ended up with the Hop by Hop mainly
because the use of flow label was too largely undefined to feel safe
using it, with the side effects that you know of, like IP in IP.

- flow label is the only field that an application can use to place an
abstract tag in the packet in order to dialog with the network. Removing
that capability seems really short sighted.
- 8 bits have been enough for a considerable amount of functionality in
the past. For the one I have in mind - application aware tagging, it is
enough.

What can I say? We are asked to choose between 2 evils when a simple
trade off exists...

Pascal

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Aleksi Suhonen
> Sent: Wednesday, July 28, 2010 5:01 PM
> To: [email-masked]
this stage is too
> late. And I feel the change is bigger than people think it is.
> 
it's mutable
> and otherwise it's immutable. And if an operator does change it, they
should
> reset it on egress, and maybe hijack some other bit in the header
(e.g. from
> DSCP?) to signal that the flow label has been fiddled with. This bit
should of

---

From: Mohacsi Janos <[email-masked]>
Date: Thu, 29 Jul 2010 15:27:53 +0200 (CEST)

Dear All,
 	splitting this field not so obvious:
- API should be changed - or at least truncate the existing flow field to 
8 bit.

- applications relying on 20 bits flow bits should be sought and fixed. I 
believe they assumed the flow field is immutable

Although I dont see the motivation for the flow field to be mutable.

Janos Mohacsi
Head of HBONE+ project
Network Engineer, Deputy Director of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882

---

From: Michael Richardson <[email-masked]>
Date: Thu, 29 Jul 2010 09:11:16 -0400

I see the CC to [email-masked], and none to [email-masked]. 
I'm not on [email-masked], so I imagine I'll get moderated.

>>>>> "Pascal" == Pascal Thubert <(pthubert)" <[email-masked]>> writes:
    Pascal> I think that the premise in the discussion was that the
    Pascal> network egress is incapable of restoring zero. 

Are you saying that the network egress can remove hop-by-hops, but it
can't restore zero to the flow label?

    Pascal> - flow label is the only field that an application can use
    Pascal> to place an abstract tag in the packet in order to dialog
    Pascal> with the network. Removing 
    Pascal> that capability seems really short sighted.

My opinion, again, is that we are doing EXACTLY this.
RPL is providing a number of RPLinstanceID's, selectable by flow-label
to the application, and the application is selecting one.

(Unknown flow-labels naturally need to go into some default RPLinstance ID)

If the ROLL WG does not feel conformtable with the above, then I think we
need to go ask some grandfathers of IPv6... What's the FLOW LABEL FOR
then?   

I think our usage of flow label is completely within the pervue of what
was intended.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 29 Jul 2010 18:58:11 +0200

On Jul 29, 2010, at 15:11, Michael Richardson wrote:

> What's the FLOW LABEL FOR then?

Wrong question, at least if taken the way you meant to ask it.

Let me try to give an answer to the question "why is it there" from the view of a somewhat cynical protocol designer and see who of the original players would like to oppose my analysis.

The flow label is an unused space of 20 (was: 28) bits in the IPv6 header.  It is there to round the size of this header up to a multiple of 8 bytes.

However, marking all these 20 bits as reserved appears to have caused too much cognitive dissonance to the IPv6 designers (or they feared such dissonance during reception of their proposal; I wasn't there).

Instead, the 20 bits were given an ostensible purpose to remove that cognitive dissonance.

Since intserv, a technology that is about flows, was modern just at the time when IPv6 was finally nailed down, the spare bits were given an ostensible purpose in the area of distinguishing flows.

Intserv never took really off, and it was too difficult to make the flow label idea useful in a mixed v4/v6 world, so that assignment was never specified out well enough to make it concrete.
Instead, in order to keep it usable for its ostensible purpose, we managed to accumulate various prohibitions on its proper use that appear to have made sure it is not used at all.

In effect, the flow label is still a collection of reserved bits in the IPv6 header.

I'm not saying this development is bad or even that the players that caused this development acted in a devious way.  It is a relatively rational result of the cognitive and political processes that govern protocol design in a consensus environment.  We can learn a lot for future protocol designs from examining these kinds of cases from the past.

Now my contribution to the discussion.

Since the cognitive dissonance of 20 unused bits per packet is no longer likely to damage IPv6, we might now want to recognize the flow label as what it is.  20 bits that are waiting for a purpose. With the nice property that they can be changed in the network without upsetting checksums/integrity checks.

Allocating all of them right now at once, early in the lifetime of the protocol, doesn't strike me as particularly prudent.  Being able to use them as a short MPLS label, as was envisioned in RPL, might be a good experimental use, if this does not mean they get lost for any and all future use in the general Internet.  A policy of MBZ, overwrite at will on ingress, clear at egress, might be good enough to enable that experimental use.

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 29 Jul 2010 18:58:11 +0200

Gruesse, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Jul 2010 09:35:01 +1200

On 2010-07-30 01:11, Michael Richardson wrote:
...
> need to go ask some grandfathers of IPv6... What's the FLOW LABEL FOR

That's the problem. It was never determined. That's why RFC 3697 had such
limited goals.

The introduction to draft-hu-flow-label-cases-00 gives a short summary
of the history.

> I think our usage of flow label is completely within the pervue of what

Can you summarise that use for those of us who don't follow ROLL,
and indicate how it plays with the rules in RFC 3697?

Thanks
     Brian

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 30 Jul 2010 14:42:21 +0200

Hi Mohacsi:

> - applications relying on 20 bits flow bits should be sought and
fixed. I believe
> they assumed the flow field is immutable

That was the second point I made at the mike. We'll have to have a
deprecation path if we change anything. We faced that with RH0, we faced
that with site local. The sooner that happens the less it will hurt.

Let's face it, the current status is that we have 20 bits in every
header that are mostly wasted. Providing rules restricts the freedom of
what we could have done with those bits, but at least they become
useful. I'll try to post a small draft soon.

Pascal

> From: Mohacsi Janos [mailto:[email-masked]]
> Sent: Thursday, July 29, 2010 3:28 PM
> To: Pascal Thubert (pthubert)
> Cc: Aleksi Suhonen; [email-masked]; [email-masked]
> Subject: RE: Flow Label: 12 bits mutable and 8 bits immutable
> 
> Dear All,
> - applications relying on 20 bits flow bits should be sought and
fixed. I believe
> they assumed the flow field is immutable
> 
>

---

From: "George, Wes E IV [NTK]" <[email-masked]>
Date: Fri, 30 Jul 2010 11:17:19 -0500

-----Original Message-----
From: Mark Smith [mailto:[email-masked]]
Sent: Thursday, July 29, 2010 5:39 AM
To: George, Wes E IV [NTK]
Cc: Tina TSOU; Aleksi Suhonen; [email-masked]
Subject: Re: Flow Label: 12 bits mutable and 8 bits immutable

Hi Wes,

[[WEG]] Agree

[[WEG]] also true, but keep in mind that most networks operate based on an acceptable percentage of errors, and a couple of bits corrupted in a non-checksummed field (that therefore doesn't result in the packet being dropped) every couple billion packets would be within that margin of error. I'm simply pointing out that there are issues beyond purposeful rewriting of the packets that can cause the field to be changed, meaning 3697's "MUST" assertion is misleading to someone wanting to implement a use for flow label, because unless they also implement a way to verify the data, they won't know if it's been changed.

effort' acceptable uses.

 ...

[[WEG]] No disagreement, but the current RFC language doesn't give us that flexibility. This debate has been about 2 things - first, "we can't use flow label for something like draft-carpenter-flow-ecmp because 3697 says it has to be immutable" and second, this new proposal of splitting the flow into a part that is immutable and a part that is mutable. I think that your comments support the concept of using flow label locally and updating 3697 to remove the absolute requirement of immutability from end to end, and if so, then flow-ecmp could be one of a number of possible uses. The main question is whether or not any of the existing applications would break if we make this change, and whether that breakage would also be triggered by corruption of the field or whether it's just because the hosts are assuming that the data will be largely intact (not overwritten).

Thanks
Wes George

---

From: "George, Wes E IV [NTK]" <[email-masked]>
Date: Fri, 30 Jul 2010 11:29:41 -0500

-----Original Message-----
From: Tina TSOU [mailto:[email-masked]]
Sent: Thursday, July 29, 2010 4:42 AM
To: George, Wes E IV [NTK]
Cc: Aleksi Suhonen; [email-masked]
Subject: Re: Flow Label: 12 bits mutable and 8 bits immutable

So you mean either we solve the issue of checksum, or we rather select
to let the flow label mutable completely?
[[WEG]] Well, I don't think that it's necessarily either-or. I was simply making the point that immutability as defined in 3697 is not completely possible and that implementations using flow label should at a minimum assume that they need a method to validate the data. My personal opinion is that this means that the current immutability requirement should not be blocking if we have a better idea of a way to use the flow label that would violate that, but we need to understand how ROLL is using the flow label before we determine if that's actually possible without breaking their stuff.

Thanks
Wes George

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 31 Jul 2010 08:46:06 +1200

Just on one point:

On 2010-07-31 04:17, George, Wes E IV [NTK] wrote:
...
> "we can't use flow label for something like draft-carpenter-flow-ecmp because 3697 says it has to be immutable"

But that is a completely false argument. The model described in
that draft is 100% consistent with an immutable flow label. In fact
there is nothing in 3697 that prevents ECMP, LAG or the model in
draft-donley-softwire-dslite-flowlabel

The usage models I know of that violate 3697 are documented in
draft-hu-flow-label-cases.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 31 Jul 2010 08:49:18 +1200

Pascal,

On 2010-07-31 00:42, Pascal Thubert (pthubert) wrote:
...
> that with site local. The sooner that happens the less it will hurt.

I think the deprecation issue is very minor. The usage of the flow label
today is essentially nil and I don't think there would be any
operational impact if we chose to change the rules. I agree it should
be done clearly and sooner rather than later.

    Brian