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 > -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > Aleksi Suhonen > Sent: Wednesday, July 28, 2010 5:01 PM > To: ipv6@ietf.org > Subject: Re: Flow Label: 12 bits mutable and 8 bits immutable > > Hi, > > On 07/28/10 13:24, Tina TSOU wrote: > > 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. > > 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 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
