Le 30 juil. 2010 à 14:42, Pascal Thubert (pthubert) a écrit : > 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. Full agreement on this point. What about this combination (not documented yet, it seems) - Hosts that send non 0 FLs, MUST do it with a value that: . is common to all packets of their flow . generally is different from one flow to another - non 0 FLs MUST be preserved e2e. - 0 FLs may be changed anywhere, but with the same constraints as in hosts. In addition, - A flow is specified by its 5-tuple, if it exists, or its 3-tuple otherwise. - The FL value assigned to a flow MAY be EITHER: . a hash of the flow identification (simple because stateless), OR . a pseudo random number (more complex because stateful, but providing an utmost privacy protection The choice between hash or randomness is made where the FL is set. Other nodes don't need to know what has been chosen. Regards, RD PS, I added to the list Tony Hain with whom we discussed FL issues in Maastricht. > I'll try to post a small draft soon. > > Pascal > > >> -----Original Message----- >> From: Mohacsi Janos [mailto:moha...@niif.hu] >> Sent: Thursday, July 29, 2010 3:28 PM >> To: Pascal Thubert (pthubert) >> Cc: Aleksi Suhonen; ipv6@ietf.org; m...@sandelman.ca >> Subject: RE: Flow Label: 12 bits mutable and 8 bits immutable >> >> 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 >> >> On Thu, 29 Jul 2010, Pascal Thubert (pthubert) wrote: >> >>> 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 >>> -------------------------------------------------------------------- >>> > -------------------------------------------------------------------- > 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 --------------------------------------------------------------------
