Hi Remi: > It looks like you insist on destroying FL compatibility with what it has been > specified for.
What was it defined for, indeed? The story starts in the mid-90s and is contiguous with the early Ypsilon work on flow switching. It's quite natural that at that time, the concept of flow was integrated in the IPv6 header, in a same fashion that byte alignment in enforced in the headers since that was also a concern of the day. While IPv6 adopted the wait-and-see position, flow switching evolved into tag switching and then MPLS. From an IPv6 perspective, what can we see after all this waiting? That the real value of the tag has nothing to do with the initial MP (IPv4 has been hegemonic ever since) or the LS (IP routing in silicon has rendered the performance discussion obsolete more than ten years ago). The real value that we can clearly observe today appeared with the applications to VPN and TE. IOW, the value of the tag derives from the capability in the router to select a path that's not the one the main RIB would have indicated. Modern networks need VPN, TE and MTR capabilities and MPLS bloomed in a niche that IPv4, with no mean to do this tagging, could simply not start to address. What does that tell us? Probably that the use of the flow label as a tag to influence the routing of the packet (eg a VRF index) is not so far from the initial intent but simply its natural evolution. Clearly, tags are employed in the core in such a way that a simple 20 bit field in the header can never suffice to emulate. But OTOH, at the edge of the network, it is still possible to place a tag in the flow label that will be mapped into a MPLS label at the border. This is quite naturally the route-over version of the mapping of a 1Q tag into a label that we commonly do today. Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Rémi Després [mailto:[email protected]] > Sent: Tuesday, September 21, 2010 5:10 PM > To: Pascal Thubert (pthubert) > Cc: JP Vasseur; IPv6 WG; ROLL WG > Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable > > > Le 21 sept. 2010 à 16:49, Pascal Thubert (pthubert) a écrit : > > > It is. > > > > But the real world tells us that various MTUs over various paths is > problematic. > > Isn't this independent from RPL, and from whatever MTU one applies locally? > > Actually, this is a nice feature of IPv6 that every network under an > administrative control has to make sure it supports 1280 + whatever headers > are needed to traverse. > Hosts, except for on-link neighbors, should better send with a 1280 MTU. > (This constraint will disappear when PMTUD becomes reliable, but it may take > quite a while.) > > > In particular it creates states in the hosts which can be subject to > > attacks. > Middle box happen to defeat PMTUD. > > > > Encapsulation for insertion will probably hit the router performance > > unless there's special silicon for that operation, > > The change of size only appears at the border between RPL and ordinary IP, > right? > > > which current routers obviously do not have. Etc... > > Etc. Etc. > It looks like you insist on destroying FL compatibility with what it has been > specified for. > > IMHO, working on RPL solutions without interfering with FLs has a better > chance to permit consensus, both for RPL and for FLs. > > RD > > > > Pascal > > > > > >> -----Original Message----- > >> From: Rémi Després [mailto:[email protected]] > >> Sent: Tuesday, September 21, 2010 2:28 PM > >> To: Pascal Thubert (pthubert) > >> Cc: JP Vasseur; IPv6 WG; ROLL WG > >> Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable > >> > >> > >> Le 21 sept. 2010 à 14:08, Pascal Thubert (pthubert) a écrit : > >> > >>> Hi Rémi: > >>> > >>> It would not. > >>> > >>> We'll be very glad that 6LoWPAN compresses RPL optimally. But RPL > >>> being > >> layer 2 agnostic cannot depend on 6LoWPAN. > >>> Header and IP in IP insertion is problematic on any network, > >> > >> Couldn't the additional header start with e.g. a 0xF so that it can > >> be distinguished from an IPvX header. > >> (These 4 bits, plus the 20 that would be sufficient if FLs were to be > >> used, would make a nice 3 octets.) It would then be layer-2 agnostic. > >> > >>> be it for the MTU issues only. > >> > >> Why? > >> Isn't each traversed link authorized to have its link MTU? > >> > >> Cheers, > >> RD > >>> > >>> The FL for RPL discussion illustrates that there can be multiple > >>> valuable > >> usages of the field by the network. > >>> It mostly shows that tying the usage to local balancing only is > >>> probably short > >> sighted. > >>> > >>> Cheers, > >>> > >>> Pascal > >>> > >>>> -----Original Message----- > >>>> From: [email protected] [mailto:[email protected]] On > >>>> Behalf Of Rémi Després > >>>> Sent: Saturday, September 18, 2010 4:53 PM > >>>> To: JP Vasseur > >>>> Cc: IPv6 WG; ROLL WG > >>>> Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits > >>>> immutable > >>>> > >>>> > >>>> Le 18 sept. 2010 à 02:22, JP Vasseur a écrit : > >>>>> On Sep 15, 2010, at 8:51 AM, Carsten Bormann wrote: > >>>>> ... > >>>>>> > >>>>>> However, it would be pretty easy to put something in 6lowpan to > >>>>>> carry those > >>>> 3 bytes. > >>>>>> (Consider it an advanced form of header compression for the > >>>>>> 48-byte IP-in-IP thing, if you don't like the sub-IP thinking.) > >>>>>> Consult > >>>> http://tools.ietf.org/html/draft-bormann-6lowpan-ext-hdr-00 for a > >>>> sample base design. > >>>>>> Such a simple extension may actually be a preferable way to carry > >>>>>> ROLL in > >>>> 6lowpan. > >>>>> > >>>>> "preferable" in which sense ? > >>>> > >>>> At least, IMHO, in that it eliminates the motivation to interfere > >>>> with the current discussion on improving flow-label utilization. > >>>> > >>>> Regards, > >>>> RD > >>>> > >>>> > >>>> _______________________________________________ > >>>> Roll mailing list > >>>> [email protected] > >>>> https://www.ietf.org/mailman/listinfo/roll > >> > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
