Subject: Re: [Roll] [6tisch] Support of flow label to carry the RPL information in data packets

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 2 May 2014 16:54:20 +0000

Thanks a bunch for this Brian;

I'll submit a revision addressing your points. Please see inline:

> > Considering the support we have at 6TiSCH and ROLL for the work, I
> published draft-thubert-6man-flow-label-for-rpl-00.txt to the 6MAN WG.
> > The main discussion is probably to confirm whether our proposed use of
> the flow label inside the RPL domain is compatible with the goals that are
> achieved by RFC6437. Let us continue the discussion there from now on.
> 
> The proposal really does three things:
> 
> 1. Asserts (implicitly) that a ROLL domain is really, truly, absolutely separated
> from the Internet at layer 3 except for traffic through its root node (acting as
> a border router).
> 
> I think that needs to be stated very explicitly as a fundamental requirement
> for this spec to be acceptable.
> 
[PT] This assumption is there today, since RPL expects to build stub networks with a default route towards the root. I agree it makes sense to provisionally add words to indicate a treatment for packets leaving the RPL domain regardless of the exit point in case a weird deployment would inject traffic into the internet from a leaf. 
>
> 2. It recommends that the root rewrites the flow label on outbound packets
> according to the provisions in RFC 6437.
> The slight deviation from RFC 6437 purism there is that it treats the existing
> flow label on the packets as if it was zero.
> 
[PT] yes

> 3. It requires that the root rewrites the flow label on inbound packets even if
> they are already set to non-zero.
> That is indeed a violation of RFC 6437. But it is a violation we have already
> accepted in another case: "for compelling operational security reasons".
> What's lost? The ability for nodes inside the ROLL domain to perform flow-
> label based load balancing for such inbound packets. I think it's for ROLL and
> 6TISCH to say whether that loss matters.
 
[PT] Roll and 6TiSCH are copied; the draft has circulated as a ROLL draft for quite a while without an objection on that matter.
We are not deprecating the other method, but we are proposing an alternate method. I results that we'll have to decide how an implementation knows which method to use.

> In my opinion, we shouldn't be religious about this as long as point 1 is
> guaranteed. I don't see any risks to the generic use of the flow label.
> 

> I think the language around the relationship with RFC 6437 is a bit defensive
> at the moment and could probably be a bit simpler and clearer. ("The
> following exceptions to the rules in [RFC6437] are made:..."). I'd have a
> preference for doing that without a formal update to 6437, because it's only
> RPL implementors who need to change anything.

[PT] Can I change that text to describe the behavior proposed by the draft inside the RPL domain as the way the rules in 6437 are interpreted?

Cheers,

Pascal
> >
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Xavier Vilajosana
> > Sent: jeudi 17 avril 2014 10:00
> > To: Ines Robles
> > Cc: Pascal Thubert (pthubert); [email-masked]; roll
> > Subject: Re: [6tisch] [Roll] Support of flow label to carry the RPL
> > information in data packets
> >
> > +1 I think this is more than needed. In addition RFC 6282 defines how
> header compression needs to be handled together with extension headers. I
> think this is not clear and leads to confusions (afecting already some
> wireshark dissectors). The use of flow label will solve several problems at
> once.
> >
> > X.
> >
> >
> >
> > 2014-04-16 22:44 GMT+02:00 Ines Robles
> <[email-masked]<mailto:[email-masked]
> >>:
> > +1
> >
> > Ines
> >
> > 2014-04-15 21:19 GMT-03:00 Qin Wang
> <[email-masked]<mailto:[email-masked]>>:
> > +1
> >
> > Qin
> > On Wednesday, April 16, 2014 1:47 AM, Prof. Diego Dujovne
> <[email-masked]<mailto:[email-masked]>> wrote:
> > +1 !
> >
> > 2014-04-15 12:25 GMT-03:00 Tom Phinney
> <[email-masked]<mailto:[email-masked]>>:
> > +1 for sure. The flow label has always been the preferable method for me,
> and I suspect for others with knowledge of how it is used in ISA100.11a.
> > ===
> >
> > On 2014.04.15 07<tel:2014.04.15%2007>:25, Pascal Thubert (pthubert)
> wrote:
> > Dear all:
> >
> > As some of you remember, the RPL specification has changed over time
> WRT to the location of the information that RPL places in the data packets.
> We started with the flow label but these were the days when what became
> RFC 6437 was being defined at 6MAN, so we shied away and defined the
> HbH technique that is now specified as RFC 6553.
> >
> > We’ll note that the RPL option defined in RFC 6553 takes 6 octets, and with
> the HbH hdr we end up with 8 extra octets. An extra IP-in-IP encapsulation is
> required on top of that unless both endpoints are in the same RPL domain.
> All this overhead may be acceptable when power is available and the PHY
> allows for larger frames, but in traditional battery-operated 15.4 with ~ 80
> bytes usable per frame, my experience from integrating 6LoWPAN HC with
> ISA100.11a says that all these extra bytes will be on the way of the 6TiSCH
> adoption.
> >
> > Still, both RFC 6550 and RFC 6552 are designed to allow for an alternate
> technique and in particular for the use of the flow label, as is elaborated in
> http://tools.ietf.org/html/draft-thubert-roll-flow-label-02 . Using the flow
> label reduces the cost of the RPL information dramatically, down to a level
> that is probably acceptable for the target SDOs.
> >
> > So my plan for now is to move the flow label draft to 6MAN and prepare
> for a hot season, and I’m looking for support from both 6TiSCH and ROLL to
> back me up from the start.  Yes, you can help!
> >
> > Please +1 if you agree we need this work to happen, and/or provide any
> suggestion.
> >
> > Cheers,
> >
> > Pascal
> >
> >
> > _______________________________________________
> >
> > 6tisch mailing list
> >
> > [email-masked]<mailto:[email-masked]>
> >
> > https://www.ietf.org/mailman/listinfo/6tisch
> >
> >
> > _______________________________________________
> > 6tisch mailing list
> > [email-masked]<mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/6tisch
> >
> >
> >
> > --
> > DIEGO DUJOVNE
> > Académico Escuela de Ingeniería en Informática y Telecomunicaciones
> > Facultad de Ingeniería UDP
> > www.ingenieria.udp.cl<http://www.ingenieria.udp.cl/>
> > (56 2) 676 8125<tel:%2856%202%29%20676%208125>
> >
> > _______________________________________________
> > 6tisch mailing list
> > [email-masked]<mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/6tisch
> >
> >
> > _______________________________________________
> > Roll mailing list
> > [email-masked]<mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/roll
> >
> >
> > _______________________________________________
> > 6tisch mailing list
> > [email-masked]<mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/6tisch
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 03 May 2014 08:22:47 +1200

Hi Pascal,

Just responding to your question:

On 03/05/2014 04:54, Pascal Thubert (pthubert) wrote:
...
> [PT] Can I change that text to describe the behavior proposed by the draft inside the RPL domain as the way the rules in 6437 are interpreted?

Well, I don't think personally that you need to be shy about saying
that within an RPL domain, the rules are in fact slightly changed instead
of being interpreted. The main thing is to be completely clear.

    Brian