Subject: Re: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 22 Aug 2014 12:56:13 +0000

Hello Brian:

The question of a liaison was discussed at both IEC and ISA100, and they were very positive about the idea. We can certainly make that happen.
I doubt that there is value in analyzing finely ISA100.11a that is mostly cast in stone now. We made the analysis at the time and concluded that it was conforming RFC 3697, and we know now that it does not conform RFC 6437.
We could still participate to the work on the backbone router but the rules in RFC 6437 will not be acceptable there for the exact same reasons that they are not acceptable in a RPL domain, and the Laurent+Carsten proposal will not change that a iota.

The most constructive would be (IMHO):
- adopt the proposed change to the 6MAN rules separately from the proposed use in RPL and 
- extend the rights that we are asking for a RPL domain to an ISA100 subnetwork as well so as to make ISA100 compliant again
- update 6284 to position ISA100.11a/IEC62734 vs. both RFCs and the 6MAN RPL flow label work (split or not) as Ines suggested
- go to WCI and enforce the application of the new RFC so that packets outgoing the ISA100 subnetwork are made compliant to RFC 6437 (by the backbone router).

Would we agree on this path? 

Pascal

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: mardi 19 août 2014 22:32
> To: Pascal Thubert (pthubert)
> Cc: Michael Richardson; Philip Levis; Routing Over Low power and Lossy
> networks; Ines Robles; 6man WG; [email-masked] WG
> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
> 
> Hi Pascal,
> 
> If we're really going to discuss this, we need the IAB to establish liaison and
> get the right to let us all see the specification. I'm not going to spend my
> time speculating about a secret document. However, the bit you quote:
> "FlowLabel: The lower order 16 bits of the FlowLabel shall be set to
> ContractID. The higher order 4 bits shall be all zeros."
> certainly seems to violate RFC 6437. Whether it violated the somewhat
> confused situation left by RFC 2460 and RFC 3697 is less clear. I have no
> recollection of anybody from ISA or IEC talking to the IETF about this issue.
> 
> Regards
>    Brian
> 
> On 19/08/2014 00:51, Pascal Thubert (pthubert) wrote:
> > Hello Brian:
> >
> > I do not think that you can freely download the specification. You
> > probably need membership first. The links exist from the Wikipedia
> > page but they are broken. Same goes for the IEC version which is IEC
> > 62734, but if you have access to the IEC then the current work is here
> > http://www.iec.ch/cgi-bin/restricted/getfile.pl/65C_735ea_CDV.pdf?dir=
> > 65C&format=pdf&type=_CDV&file=735ea.pdf
> >
> > Quotes:
> >
> > "The ContractID is associated with a particular D-route. This may be used
> when a particular graph or source D-route is intended to provide a defined
> level of service"
> >
> > "FlowLabel: The lower order 16 bits of the FlowLabel shall be set to
> ContractID. The higher order 4 bits shall be all zeros. This field shall only be
> present if octets 3 through 5 are present, as indicated by LOWPAN_IPHC
> encoding."
> >
> > Note that the 6TiSCH architecture echoes this design, and a d-route is very
> similar to a 6TiSCH track.
> >
> > For the sake of history and to my best knowledge, ISA100.11a was the first
> industrial standard to adopt IPv6 for process control applications (control
> loops and monitoring).
> > It is effectively enabling IP in the control network, which is an historical
> step toward the IT/OT convergence, that is the Industrial equivalent of voice
> and video convergence over IP.
> >
> > And also to my best knowledge and conforming RFC 3697, ISA100.11a does
> not mute the Flow Label inside the network, as Michael points out. Only
> when the additional backbone Router functionality is defined does the
> problem of rewriting come into play at the Backbone Router (same position
> as RPL root). For all I know this work is taking place at the Wireless
> Compliance Institute, WCI, but I do not have the latest.
> >
> > Cheers,
> >
> > Pascal
> >
> >
> >> -----Original Message-----
> >> From: Brian E Carpenter [mailto:[email-masked]]
> >> Sent: samedi 16 août 2014 03:13
> >> To: Pascal Thubert (pthubert)
> >> Cc: Philip Levis; Routing Over Low power and Lossy networks; Ines
> >> Robles; 6man WG; [email-masked] WG
> >> Subject: Re: [Roll] [6lo] WGLC for
> >> draft-thubert-6man-flow-label-for-rpl-03
> >>
> >> On 15/08/2014 20:51, Pascal Thubert (pthubert) wrote:
> >>> Hello Brian
> >>>
> >>> I do not think that ISA10011.a violates RFC 3697. What exactly made
> >>> you
> >> believe so?
> >>
> >> I was over-interpreting what you wrote, I guess. It's true that 3697
> >> was rather vague about what it called "flow state establishment
> >> methods" and permitted both sequential and pseudo-random flow label
> >> values. Is the ISA10011.a on line somewhere?
> >>
> >>> For all I know ISA100 does everything by the book. Note that ISA100
> >>> does
> >> not update a non zero FL on the fly since it is not set by a source
> >> outside the LLN if that is your concern.
> >>> OTOH It may violate RFC 6437 in that the flow is not a random but a
> >>> value
> >> attributed by a PCE called system manager (along rules in section 4).
> >> As things stand, we'd certainly want the backbone router at LLN
> >> egress to rewrite the FL in packets towards the Internet with a
> >> randomized per flow value.
> >>> It will violate RFC 6437 because if the flow label is set by a
> >>> router in the
> >> Internet - or an updated source that complies to 6437-, the backbone
> >> router at LLN Ingress will rewrite it.
> >>> Both issues are addressed in my draft for a RPL domain. An RFC will
> >>> also
> >> hint a revision of the backbone router that it should rewrite the FL
> >> on outgoing packets.
> >>> What do you think?
> >> I think that Phil's last message frames the question to 6man
> >> correctly, so I will respond to him...
> >>
> >> Regards
> >>     Brian
> >>> Pascal
> >>>
> >>>> Le 14 août 2014 à 22:18, "Brian E Carpenter"
> >> <[email-masked]> a écrit :
> >>>>> On 14/08/2014 22:28, Pascal Thubert (pthubert) wrote:
> >>>>> We can live with this Brian,
> >>>>>
> >>>>> but then I can we add at least an ISA100.11a network? ISA100.11a
> >>>>> was
> >> designed in 2007/8, adopted IPv6 and 6LoWPAN, and uses the IPv6 flow
> >> label to indicate which flow a packet belongs to.
> >>>> I have no idea what ISA100.11a is or which organisation developed
> >>>> it, but it sounds like a violation of the flow label standard at
> >>>> that time (RFC 3697). If I'd known about it, we would probably have
> >>>> included it in the menagerie of RFC 6294.
> >>>>
> >>>> There's not much the IETF can do about other organisations that
> >>>> misuse our standards, although indeed we sometimes need to
> document
> >>>> such cases.
> >>>>
> >>>>   Brian
> >>>>
> >>>>
> >>>> In more details, devices are provisioned with per-flow behavior
> >>>> (including
> >> routing) and settings in what is called a contract.
> >>>> The contractID is carried in the IPv6 flow label.
> >>>>> If so should we name ISA100 specifically or use a more vague
> >>>>> description
> >> like a "RPL or similar LLN domain"
> >>>>> We'll note that resetting an flow label that comes from the
> >>>>> Internet is a generic need is that flow label was set according to
> >>>>> 6437, cannot be trusted to be untempered with,
> >>>>>
> >>>>> Cheers,
> >>>>>
> >>>>> Pascal
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E
> >>>>>> Carpenter
> >>>>>> Sent: mercredi 13 août 2014 22:53
> >>>>>> To: Philip Levis
> >>>>>> Cc: Routing Over Low power and Lossy networks; Ines Robles; 6man
> >>>>>> WG; [email-masked] WG
> >>>>>> Subject: Re: [Roll] [6lo] WGLC for
> >>>>>> draft-thubert-6man-flow-label-for-rpl-03
> >>>>>>
> >>>>>>> On 14/08/2014 07:07, Philip Levis wrote:
> >>>>>>> On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert)
> >>>>>> <[email-masked]> wrote:
> >>>>>>>> If this draft is not adopted, the flow label from LLN will
> >>>>>>>> probably stay all
> >>>>>> zeroes as it is today and the goal of 6437 will not be achieved.
> >>>>>>> Pascal, I'm trying to reconcile your claim that the goal of 6437
> >>>>>>> is to allow enclosed networks to use the flow label with Brian's
> >>>>>>> statement
> >>>>>>>
> >>>>>>>> Actually that's why I don't want to see a formal update to
> >>>>>>>> 6437, because the only rational update would be to allow any
> >>>>>>>> closed domain to invent its own usage. We had that argument at
> >>>>>>>> length during the development of 6437, and decided against it.
> >>>>>>> Phil
> >>>>>> Right. I'm drawing a very subtle line between (a) stating an
> >>>>>> exception to 6437 for this particular usage and (b) opening the
> >>>>>> door to other usages. Since 6man clearly didn't want (b) during
> >>>>>> the development of
> >>>>>> 6437 I think we do need to limit ourselves to (a).
> >>>>>>
> >>>>>>    Brian
> >>>>>>
> >>>>>> -----------------------------------------------------------------
> >>>>>> --
> >>>>>> - IETF IPv6 working group mailing list [email-masked]
> >>>>>> Administrative
> >>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>>>>> -----------------------------------------------------------------
> >>>>>> --
> >>>>>> -
> >

---

From: Ines Robles <[email-masked]>
Date: Fri, 22 Aug 2014 18:44:17 +0300

Hello,

Thank you all for your comments during this WGLC. Our conclusion is that we did
not see consensus for the draft. We need please more participation on that.
(We think that most of the people are on vacations).

So, we leave this thread open, and we are going to have another WGLC during
september.

Thank you very much in advance,

Kind Regards,

Michael & Ines.

2014-08-22 15:56 GMT+03:00 Pascal Thubert (pthubert) <[email-masked]>:

> Hello Brian:
>
> The question of a liaison was discussed at both IEC and ISA100, and they
> were very positive about the idea. We can certainly make that happen.
> I doubt that there is value in analyzing finely ISA100.11a that is mostly
> cast in stone now. We made the analysis at the time and concluded that it
> was conforming RFC 3697, and we know now that it does not conform RFC 6437.
> We could still participate to the work on the backbone router but the
> rules in RFC 6437 will not be acceptable there for the exact same reasons
> that they are not acceptable in a RPL domain, and the Laurent+Carsten
> proposal will not change that a iota.
>
> - extend the rights that we are asking for a RPL domain to an ISA100
> subnetwork as well so as to make ISA100 compliant again
> - update 6284 to position ISA100.11a/IEC62734 vs. both RFCs and the 6MAN
> RPL flow label work (split or not) as Ines suggested
> - go to WCI and enforce the application of the new RFC so that packets
> outgoing the ISA100 subnetwork are made compliant to RFC 6437 (by the
> backbone router).
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 23 Aug 2014 15:07:40 +1200

Hi Pascal,

> The question of a liaison was discussed at both IEC and ISA100, and they were very positive about the idea. We can certainly make that happen.

That's something that you would need to raise with the IAB. I imagine there
are quite a few IEC documents that are relevant to the IETF; given that
we have a long history of liaison with ITU and ISO, it's actually a bit
surprising we have never set it up with IEC. Anyway, that's above my
current pay grade in the IETF ;-).

> - adopt the proposed change to the 6MAN rules separately from the proposed use in RPL and 

The problem is that something like this was in the draft that became RFC 6437,
and was removed after a very negative reaction from 6MAN.

Quoting from a slide shown to 6MAN in November 2010:

"A network domain MUST NOT forward packets outside the
domain whose flow labels are other than zero or pseudorandom.
[Backstop rule for sites that break other rules.]
o New compared to RFC 3697."

This made it into draft-ietf-6man-flow-update-00 and then
draft-ietf-6man-flow-3697bis-00, but was removed from
draft-ietf-6man-flow-3697bis-01 because the WG simply didn't
want it.

The text "However, any node that sets flow label values
according to a stateful scheme MUST ensure that packets conform to
Section 3 of the present specification if they are sent outside the
network domain using the stateful scheme." was present in the -01
draft but was removed at WG request in -04.

So there was an extremely clear 6MAN consensus against this in 2010/11.
We were explicitly asked to remove the notion of domains with their
own rules.

   Brian

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 25 Aug 2014 16:30:53 +0000

I understand, Brian:

It makes sense to propose a generic rule and try it on the real world. But it is not surprising that such a bold approach fails to be universal when confronted to the real world.
To be very clear on the need for 6MAN to take our responsibilities, I added text to clarify that 6437 as of today is dramatically counterproductive for the development of IPv6 in LLNs.

Otherwise, I updated http://www.ietf.org/id/draft-thubert-6man-flow-label-for-rpl-05.txt along with your recommendations as follows:

- removed the updated: till we get consensus on having it, but following Phil's recommendation, I isolated the 6437 updates in section 5.  Updated Rules
- removed the text on the application to the RPL option. The rules that are needed whatever the decision is later in LLN WGs as of how the RPL option is compressed, yet leaving all possibilities open. This allows 6MAN to make an independent decision.
- indicated that a constrained LLN domain is an exception to the generalness of 6437 where energy-saving is another compelling reason to allow the modification of a non-zero flow label.
- extended the applicability to ISA100.11a networks as an effort from the IETF to keep that standard compliant with IPv6 as well as similar LLNs since the issue with 6437 is generic to all constrained LLN.

Cheers,

Pascal

> Sent: samedi 23 août 2014 05:08
> are quite a few IEC documents that are relevant to the IETF; given that we
> have a long history of liaison with ITU and ISO, it's actually a bit surprising
> we have never set it up with IEC. Anyway, that's above my current pay grade
> in the IETF ;-).
> 
> > I doubt that there is value in analyzing finely ISA100.11a that is mostly cast
> in stone now. We made the analysis at the time and concluded that it was
> conforming RFC 3697, and we know now that it does not conform RFC 6437.
> > We could still participate to the work on the backbone router but the rules
> in RFC 6437 will not be acceptable there for the exact same reasons that
> they are not acceptable in a RPL domain, and the Laurent+Carsten proposal
> will not change that a iota.
> >
> The problem is that something like this was in the draft that became RFC
> 6437, and was removed after a very negative reaction from 6MAN.
> 
> "A network domain MUST NOT forward packets outside the domain whose
> flow labels are other than zero or pseudorandom.
> [Backstop rule for sites that break other rules.] o New compared to RFC
> 3697."
> 
> This made it into draft-ietf-6man-flow-update-00 and then draft-ietf-6man-
> flow-3697bis-00, but was removed from
> draft-ietf-6man-flow-3697bis-01 because the WG simply didn't want it.
> 
> The text "However, any node that sets flow label values according to a
> stateful scheme MUST ensure that packets conform to Section 3 of the
> present specification if they are sent outside the network domain using the
> stateful scheme." was present in the -01 draft but was removed at WG
> request in -04.
> 
> We were explicitly asked to remove the notion of domains with their own
> rules.
> 
>    Brian
> 
> > - update 6284 to position ISA100.11a/IEC62734 vs. both RFCs and the
> > 6MAN RPL flow label work (split or not) as Ines suggested
> >> Cc: Michael Richardson; Philip Levis; Routing Over Low power and
> >> Lossy networks; Ines Robles; 6man WG; [email-masked] WG
> >> If we're really going to discuss this, we need the IAB to establish
> >> liaison and get the right to let us all see the specification. I'm
> >> not going to spend my time speculating about a secret document.
> However, the bit you quote:
> >> confused situation left by RFC 2460 and RFC 3697 is less clear. I
> >> have no recollection of anybody from ISA or IEC talking to the IETF about
> this issue.
> >>
> >> Regards
> >>    Brian
> >>
> >>> http://www.iec.ch/cgi-bin/restricted/getfile.pl/65C_735ea_CDV.pdf?di
> >>> r= 65C&format=pdf&type=_CDV&file=735ea.pdf
> >>>
> >>> Quotes:
> >>>
> >> when a particular graph or source D-route is intended to provide a
> >> defined level of service"
> >> ContractID. The higher order 4 bits shall be all zeros. This field
> >> shall only be present if octets 3 through 5 are present, as indicated
> >> by LOWPAN_IPHC encoding."
> >> industrial standard to adopt IPv6 for process control applications
> >> (control loops and monitoring).
> >> step toward the IT/OT convergence, that is the Industrial equivalent
> >> of voice and video convergence over IP.
> >> not mute the Flow Label inside the network, as Michael points out.
> >> Only when the additional backbone Router functionality is defined
> >> does the problem of rewriting come into play at the Backbone Router
> >> (same position as RPL root). For all I know this work is taking place
> >> at the Wireless Compliance Institute, WCI, but I do not have the latest.
> >>> Cheers,
> >>>
> >>> Pascal
> >>>
> >>>
> >>>>> I do not think that ISA10011.a violates RFC 3697. What exactly
> >>>>> made you
> >>>> believe so?
> >>>>
> >>>> I was over-interpreting what you wrote, I guess. It's true that
> >>>> 3697 was rather vague about what it called "flow state
> >>>> establishment methods" and permitted both sequential and
> >>>> pseudo-random flow label values. Is the ISA10011.a on line
> somewhere?
> >>>>
> >>>>> For all I know ISA100 does everything by the book. Note that
> >>>>> ISA100 does
> >>>>> OTOH It may violate RFC 6437 in that the flow is not a random but
> >>>>> a value
> >>>> Internet - or an updated source that complies to 6437-, the
> >>>> backbone router at LLN Ingress will rewrite it.
> >>>>> Both issues are addressed in my draft for a RPL domain. An RFC
> >>>>> will also
> >>>> hint a revision of the backbone router that it should rewrite the
> >>>> FL on outgoing packets.
> >>>>> What do you think?
> >>>> designed in 2007/8, adopted IPv6 and 6LoWPAN, and uses the IPv6
> >>>> flow label to indicate which flow a packet belongs to.
> >>>>>> that time (RFC 3697). If I'd known about it, we would probably
> >>>>>> have included it in the menagerie of RFC 6294.
> >>>>>>
> >>>>>>> Internet is a generic need is that flow label was set according
> >>>>>>> to 6437, cannot be trusted to be untempered with,
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>>
> >>>>>>> Pascal
> >>>>>>>
> >>>>>>>
> >>>>>>>> Cc: Routing Over Low power and Lossy networks; Ines Robles;
> >>>>>>>> 6man WG; [email-masked] WG
> >>>>>>>>> Pascal, I'm trying to reconcile your claim that the goal of
> >>>>>>>>> 6437 is to allow enclosed networks to use the flow label with
> >>>>>>>>> Brian's statement
> >>>>>>>>>
> >>>>>>>>>> closed domain to invent its own usage. We had that argument
> >>>>>>>>>> at length during the development of 6437, and decided against
> it.
> >>>>>>>>> Phil

---

From: Richard Kelsey <[email-masked]>
Date: Tue, 26 Aug 2014 20:02:28 +0000

> From: Pascal Thubert (pthubert) [[email-masked]]
> Sent: Monday, August 25, 2014 12:30 PM
> 
> I understand, Brian:
>
> It makes sense to propose a generic rule and try it on the real
> world. But it is not surprising that such a bold approach fails to
> be universal when confronted to the real world.  To be very clear on
> the need for 6MAN to take our responsibilities, I added text to
> clarify that 6437 as of today is dramatically counterproductive for
> the development of IPv6 in LLNs.

Pascal,

Hold on a second.  First of all, not everyone doing IPv6 in LLNs
is using RPL.  Second of all, not everyone using RPL in LLNs is
particularly hindered by the overhead of using RFC 6553.  And finally,
Carsten's suggested 6lo encoding of the RPL Option arguably has
better properties than using the flow label and is definitely not
"dramatically" worse.

Personally, I think using the flow label in this way is a very bad
idea.  The games that are played within an LLN to make IPv6 work there
need to be invisible to the rest of the Internet.  Universal rules
are what its all about.

                               -Richard Kelsey

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 26 Aug 2014 20:18:55 +0000

Richard:

Maybe you should read the draft.

I removed all references to my proposal of how to use the Flow label for RPL.

What the 6MAN draft is now asking is only the right to manipulate a flow label in the LLN, RPL or not RPL, be it only to reset it to zero so as to elide it.

The Idea to propose a 6lowpan compression is actually from Laurent and I was the first on the ML to support it.

Cheers,
Pascal

Le 26 août 2014 à 22:04, "Richard Kelsey" <[email-masked]> a écrit :

> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo