Pascal, Thanks for this and your previous message. I would need to think very carefully whether this proposal would really have been strictly compatible with RFC 3697 - it actually depends on how the agreement to use these semantics imposed on the flow label is made (what is called 'flow state establishment' in the RFC). I see more weaknesses in 3697 each time I look at it :-(
More below... On 2010-08-09 22:17, Pascal Thubert (pthubert) wrote: > 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. So I understand that ROLL would definitely need the ability to define explicit semantics on the label. Would it also need the label to be mutable? > > 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. > A first question to the group could be whether 12 mutable bits are > enough for the sensible usages envisioned so far? To me it seems that 12 bits could contain enough randomness to drive a load balancing mechanism, but there's no need for those bits to be mutable that I can see. On the other hand, 12 bits seems very small for any kind of nonce or for a flow identification scheme, so it seems that draft-blake and draft-donley would be knocked out. Brian > >> -----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 --------------------------------------------------------------------
