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. A first question to the group could be whether 12 mutable bits are enough for the sensible usages envisioned so far? Pascal > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Michael Richardson > Sent: Wednesday, August 04, 2010 4:05 AM > To: [email protected]; Carsten Bormann > Cc: Pascal Thubert (pthubert); [email protected] > Subject: Re: Flow Label: 12 bits mutable and 8 bits immutable > > > {there is a thread which started on [email protected], and [email protected], and then > seemed to have dropped [email protected]. I'm not on [email protected], 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[ > ] [email protected] 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 > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
