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 (???) ? > 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). Regards, 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 --------------------------------------------------------------------
