Hi Pascal, More comments below. Le 10 août 2010 à 16:24, Pascal Thubert (pthubert) a écrit :
> Salut Rémi, > > Please see below: > > Pascal > >> -----Original Message----- >> From: Rémi Després [mailto:remi.desp...@free.fr] >> Sent: Monday, August 09, 2010 1:50 PM >> To: Pascal Thubert (pthubert) >> Cc: 6man 6man; Michael Richardson; r...@ietf.org; Carsten Bormann >> Subject: Re: Flow Label: 12 bits mutable and 8 bits immutable >> >> >> Le 9 août 2010 à 12:17, Pascal Thubert (pthubert) a écrit : >> >>> Hi Michael: >>> >>> With http://tools.ietf.org/html/draft-ietf-roll-rpl-07#section-7.2 I >>> tried to stay within the lines of RFC 3697 as you also defend in your >>> mail. >>> >>> I think the question we have now is not whether that proposal is >>> lawful but whether the new law being defined at 6MAN would prevent it >>> in the future. >>> If the updated rules allow, then I'll be glad to work on an FL-based >>> alternate to the IPinIP/HbH. >>> >>> It appeared at the 6MAN WG meeting that 12 bits mutable was exactly >>> what the core network was asking for to do its load balancing. >> >> Would you have more details on WHY it would be "exactly" what was needed >> (???) ? > > [Pascal] That does not come from me. I asked at the mike during the WG > meeting, and the answer that was given was that for the purpose of a load > balancing hash in the SP network, 11 or 12 bits would be enough. What is clear, though, is that a hash of 11-12 bits has a higher probability of collisions than a hash on 20 bits. If hashes become permitted (which simplifies support of FLs for load balancing), it is then clear that 20 is better than 12. >>> A first question to the group could be whether 12 mutable bits are >>> enough for the sensible usages envisioned so far? >> >> I'd rather see the first question as being "Are there some improvements of >> RFC >> 3697 that would make it practicable?". >> >> If yes, improving this RFC rather than deprecating it after 6+ years of >> standard- >> track existence would IMHO be better for IPv6 credibility (and IMHO for that >> of >> IETF in general). >> >> The two improvements that seem to make sense (see various exchanged mails) >> are: >> - permit stateless support (with flow-ID hashes in place of flow-based >> stateful >> processing) >> - permit intermediate nodes to set FLs when source hosts haven't done it >> (still >> as shorthands for flow ISs made available in IPv6 first headers). >> > [Pascal] We agree here. The point if that there might be enough room for > both, depending on what we are doing. > Note that for the latter, the discussion was also that it is not obvious at > the egress of the network to reset the FL to zero in order to enable the next > AS to reuse it. RFC 3697 isn't concerned with ASes, and doesn't need to be. The proposal is only that, where load balancing is performed, 0 FLs MAY be replaced by meaningful values for this purpose. A FL, once set to a non 0 value, never needs to be reset. > So the conclusion was rather to use the bits is a DSCP fashion. I am not sure what is meant by used in a DSCP fashion (some DSCP actual uses seem to me rather complex). In any case, using FLs ONLY as FLs (essentially RFC 3697, but completed to be more practicable), is IMHO the most reasonable approach to improve the situation in a reasonable timeframe. I understand that 20 unused bits in IP headers is bound to arouse envy, but adding a new role to FLs, with the original role becoming less efficient rather than more efficient, is IMHO a wrong approach. Cheers, RD > > Pascal >>> >>> >>>> -----Original Message----- >>>> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf >>> Of >>>> Michael Richardson >>>> Sent: Wednesday, August 04, 2010 4:05 AM >>>> To: r...@ietf.org; Carsten Bormann >>>> Cc: Pascal Thubert (pthubert); ipv6@ietf.org >>>> Subject: Re: Flow Label: 12 bits mutable and 8 bits immutable >>>> >>>> >>>> {there is a thread which started on r...@ietf.org, and ipv6@ietf.org, >>> and then >>>> seemed to have dropped r...@ietf.org. I'm not on ipv6@ietf.org, so >>> there likely >>>> are message there I've missed} >>>> >>>> okay, so I've read Carsen's opinion. >>>> I read RFC 3697 (which I didn't know about). >>>> >>>> draft-hu-flow-label-cases-00 is a very good read. I pull out >>> something from >>>> section 4 (Discussion); >>>> >>>> The other choice, for designers who wish to use the flow label to >>>> control switching or QoS directly, is to bypass the rules within a >>>> given domain (a set of cooperating nodes) in a way that nodes >>> outside >>>> the domain cannot detect. In this case, any deviation from >>> [RFC3697] >>>> has no possible effect outside the domain in question. >>>> >>>> I don't know where this subject line is from: 12 bits/8bits. >>>> Is there a draft that explains that idea that I've missed? >>>> >>>> My claim is that ROLL's RPL is a set of cooperating nodes. >>>> >>>> But, it's better than that --- it's a set of routers which are tuned >>> to support >>>> specific applications, and the applications want in this case to be >>> given >>>> information like, "what flow label" to use. RPL's RPLinstanceID has >>> all the >>>> properties required of a flow label (or, rather, it has no >>> requirements presently, >>>> and therefore can have the flow label requirements imposed upon it, >>>> specifically: >>>> 2. "Nodes MUST NOT assume any mathematical or other properties of >>>> the Flow Label" >>>> ) >>>> >>>> The non-mutability of the label isn't a problem either --- the >>> applications *AT >>>> EACH END*, even if one end of the application is several AS's away (a >>> very >>>> unusual case for 95% of RPL's target use), that application still >>> needs to know >>>> something about what label to use. >>>> >>>> There are three cases to consider: >>>> a) traffic between two RPL nodes >>>> b) traffic exiting an RPL >>>> c) traffic entering an RPL >>>> >>>> case (a) -- is the "set of cooperating nodes", and therefore is no >>> problem. >>>> >>>> case (b) -- the flow label is set to get through the RPL/LLN, and out >>> to >>>> the network, and the flow label has done it's job, and >>>> the RPL/LLN network could care less what happens to the >>> flow >>>> label at that point. The rest of the network might have >>> a >>>> problem (i.e. a bug) when RPL networks start sending >>>> non-zero flow labels, but that's the rest of the >>> network's >>>> problem. >>>> >>>> case (c) - flow labels of zero are not a problem. There is either a >>>> default RPLinstanceID to use (and traffic flows, perhaps not >>>> optimally), or there isn't (and ICMP Host unreachable >>> occurs). >>>> >>>> - non-zero flow labels which do not map to an RPLinstanceID, >>>> are simply considered zero, see above. >>>> - non-zero flow labels which map to RPLinstanceIDs are used. >>>> *If* it is a problem for outsiders to invoke that LLN's >>>> DODAG, then there are bigger issues, which the flow label >>> can neither >>>> help nor hinder --- the flowlabel is not a magic security >>> cookie. >>>> A firewall may still be required. >>>> >>>> The only real problem I can see is when a packet needs to do (b) and >>>> (c). e.g. use label A to exit LLN alpha, and label B to enter LLN >>> beta. >>>> >>>> I don't have a solution to this. Some have suggested IPIP tunnels, >>> which sound >>>> nice in theory, but in practice do not work in the wilderness found >>> behind the >>>> walls of walled gardens. >>>> >>>> -- >>>> ] He who is tired of Weird Al is tired of life! | >>> firewalls [ >>>> ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net >>>> architect[ >>>> ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ >>> |device >>>> driver[ >>>> Kyoto Plus: watch the video >>>> <http://www.youtube.com/watch?v=kzx1ycLXQSE> >>>> then sign the petition. >>>> >>>> >>>> >>>> >>>> -------------------------------------------------------------------- >>>> 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 --------------------------------------------------------------------
