Re: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt

[Samita Chakrabarti <[e-mail]>]

Hi Robert,

Please see in-line. Thank you very much for your comments.

From: [e-mail] [mailto:[e-mail]] On Behalf Of Robert Cragie
Sent: Friday, July 10, 2015 4:36 AM
To: Pascal Thubert (pthubert)
Cc: Jonathan Hui; Samita Chakrabarti; Thierry LYS ([e-mail]); [e-mail]
Subject: Re: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt

Comments on the draft
=====================

"The ESC byte [01 000000] is modified in RFC 6282[RFC6282] and [RFC4944] first introduces this dispatch header type for extension of dispatch bytes for different usage of 6lowpan applications."

I am not sure what "for different usage of 6lowpan applications" means. I would have thought "for future definition" would be more appropriate. Whatever follows the ESC byte is not defined in RFC 4944 or RFC 6282, or else there would be no need for it.
[SC>] We can change to “future definition” is that is agreeable by most.

"For example, a dispatch header type (ex: LOWPAN_HC1, MESH etc.) might need some special handling of each packet for classification."

I am not sure what this actually means and doesn't really add any value. The rest of the document defines what the intention is regarding the byte subsequent to ESC and there shouldn't be any assumptions about how that will be used.
[SC>] At the time of writing, from the existing documents, the usage  of ESC bytes was not clear to me. The examples of special handling was an idea to see if it was a justified usecase. The purpose of the document is also to provide a guideline of usages of ESC bytes. I am wondering about a usecase, where a 6lo-device wants to send a 6lowpan packet + device information or network information that might be used for routing or end-node communication as we add more functionality using 6lowpan. Or it could be some security related information being present in the ESC bytes… If we don’t know the example usecases, how can we guide others to define new additional sequence bytes? Now that we have opportunities to define ESC bytes usage, perhaps we can add some new thoughts…  that was the thinking behind that sentence.

"Note that section 5.1 in RFC4944 indicates that the Extension Type field may contain additional dispatch values (larger than 63)."

The value in RFC 4944 is 127, which IIRC was agreed on the mailing list to be wrong (a hangover from earlier drafts) and should be 63. This should be clarified here.
[SC>] Possible. Though, I am not sure if this is the right document for clarification of that Errata in RFC4944. But we can take an opportunity to explain. I am open to it. Will need to discuss with co-authors.

Minor nit: Put a space between term and abbreviation, e.g. "Extension Type(ET)" -> "Extension Type (ET)"
[SC>] OK.

Open issues: It is not possible for a legacy device to simply ignore the ESC byte. To some extent, it depends where the ESC byte appears in the stream. As Jonathan points out, if it occurs as payload of another header it is just part of opaque data. However, if encountered during processing, the packet should be discarded.
[SC>] This is definitely a safe option.

Figure 3: 32-254 Unassigned. I think this needs to be stronger and say "reserved", which requires any use of these values to be sanctioned by IETF/IANA. To be honest, the use of ESC is reserved in IANA and G3-PLC should not have just gone and used those values without consulting IETF/IANA.
[SC>] We need to revisit the IANA bits/values based on the discussions on this list. I understand your concern and the point is taken.

Thanks,
-Samita

Cherry-picking on some of the other comments
============================================

>> (JH) RFC 4944 and RFC 6282 does not define any behavior when encountering an ESC header (or any 6lowpan header) it does not understand.
> (CB) Exactly -- there is no ignorable range yet.

<RCC>No, but it is defined as a reserved field. On that basis, there should be some defined behaviour for reserved fields. I am not aware of a RFC which generally states what to do in this case but the normal behaviour is to discard the packet. The elective form can only work if the processing has sufficient knowledge of the meta format, e.g. TLV, where it may not be able to interpret the payload but can skip over. In this case, we are simply specifying Extension Type so, on that basis, if a device sees [ESC,<ET>], it cannot infer anything about subsequent bytes so really has to discard the packet.</RCC>

> (JH) I think we need to be clear about different "legacy" implementations. There's legacy implementations that don't understand any ESC headers (those that only used the 6lowpan headers defined in RFCs as of today).

<RCC>See previous comment (use of ESC is reserved).</RCC>

> (JH) There's legacy implementations that makeup their own use of ESC headers (G3-PLC).

<RCC>The uncoordinated use by G3-PLC is indeed unfortunate and of course it is possible that others have also used ESC in the same way. My main concern is that the use of the reserved ESC field is counter to expected practice. On this basis, one could even argue that the allocation should be ignored and state that the ITU should have coordinated with IETF/IANA regarding the use of this field.</RCC>

> (JH) And then there's the "legacy" implementations that will understand the new ESC header encoding, but may not understand some subset of the headers defined within that ESC header encoding.

<RCC>That's not "legacy" IMHO - "legacy" applies to all devices which exist prior to the publication of this standard. If we tighten up the meaning of "reserved" then it should be clear what the behaviour is. Going forward, this will mean that updates to the specification (using currently reserved values) will at least be able to unequivocally state what a "legacy" device relative to the update will do.</RCC>

>> (SC) Could ESC bytes occur multiple times? [ in practice, we want to minimize the header bits- that’s the purpose of 6lowpan, so I assume, we don’t want to add a very long set of sequences]
> (JH) That's really up to how we define ESC headers, but I think it would be a mistake not to allow ESC headers to occur multiple times.

<RCC>I think that is OK providing we still have the concept of a "switch" type of dispatch, as described in Section 3.2 of draft-thubert-6lo-routing-dispatch-04. This concept is different from ESC in that it switches the dispatch code space on encountering the switch byte.</RCC>

Robert


On 9 July 2015 at 12:59, Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>> wrote:
100% agreement with Jonathan.

I think that granting 6LoWPAN formats after the fact without a chance to discuss what goes where in that grant is a mistake that create the wrong type of precedent.

What if another group also escaped its own stuff and used the same codes and comes tomorrow asking us the same range? Or any range? Why them and not us?

We are pretty much in the mirror situation as the desire to reuse the MH space for 6LoRH. This becomes a problem of relation between not just 2 but an unknown number of other standardization bodies. At the end of the day, this is the core reason why there are some rules, and the reason why we are reconsidering the 6LoRH not to overlap with MH.

A few remarks:


-        6LoRH has built-in a signal that a header can be ignored. That’s a lesson we learnt from IPv6 Option Type identifiers encoding. When the header can be ignored, the size to skip is provided in octets.

-        One option (option 2) for encoding 6LoRH is a form of escape. But we realized that the values being escaped (and thus reused modulo 256) are for dispatches that are at the head of the packet. So rather than having to escape every single occurrence of a 6LoRH, the proposal is to delineate the segment of the packet where 4944 is no more used and 6LoRH start applying. IOW we virtually escape all the rest of the packet, so we can reuse the space (modulo 256) the space used by NALP, MH and Fragments before the demarcation.

-        6LoRH has a TLV structure and has room to receive the namespace required by G3-PLC.


Cheers,

Pascal




Cheers,

Pascal

From: 6lo [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Jonathan Hui
Sent: mercredi 8 juillet 2015 22:48
To: Samita Chakrabarti
Cc: Thierry LYS ([e-mail]<mailto:[e-mail]>); [e-mail]<mailto:[e-mail]>
Subject: Re: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt

Hi Samita,

See below:

On Wed, Jul 8, 2015 at 11:17 AM, Samita Chakrabarti <[e-mail]<mailto:[e-mail]>> wrote:

From: Jonathan Hui [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Tuesday, July 07, 2015 11:16 PM
To: Samita Chakrabarti
Cc: [e-mail]<mailto:[e-mail]>; Thierry LYS ([e-mail]<mailto:[e-mail]>)
Subject: Re: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt

If a legacy implementation does not understand the ESC header, the device cannot simply skip the ESC header and continue processing what follows.  So I'm not sure how an existing implementation can just ignore the ESC header.
[SC>] Yes, you’re right. It is limited to <dispatch><ESC> case.  I am still not sure how useful that is for the node that does not understand the ESC bytes. For sequence <dispatch><ESC><another-dispatch> will not work—Gabe and I discussed that.
The question we probably need to answer – what would be the use-cases in different scenarios?

I think we need to be clear about different "legacy" implementations.  There's legacy implementations that don't understand any ESC headers (those that only used the 6lowpan headers defined in RFCs as of today).  There's legacy implementations that makeup their own use of ESC headers (G3-PLC).  And then there's the "legacy" implementations that will understand the new ESC header encoding, but may not understand some subset of the headers defined within that ESC header encoding.

If history is any indication, we can't possibly foresee all important use cases that may come up in the future.

What was the original intention of having ESC bytes?  Could ESC byte be considered as 6lowpan extension header? [ like IPv6 extension headers? ]

As Carsten stated, the original intention was to give us an out in the case that all of the existing dispatch values were used up.

Could ESC bytes occur multiple times? [ in practice, we want to minimize the header bits- that’s the purpose of 6lowpan, so I assume, we don’t want to add a very long set of sequences]

That's really up to how we define ESC headers, but I think it would be a mistake not to allow ESC headers to occur multiple times.

Another question: It is possible that one implementation can only understand a set of ESC bytes but not other sets. Should it drop the packet? The problem is that without knowing ESC type, the receiver cannot know how many bytes to skip. It’s too late now to introduce TLV structure in ESC first byte. We can define TLV after first byte, but in either case we are stuck because of G.9903, I guess.

Again, that's really depends on whether or not we define a class of headers that can be ignored.  Personally, I do think 6lowpan could benefit from a class of ignorable headers.

As I mentioned above, we can't possibly foresee all important use cases that may come up in the future.  So having an ignorable range of 6lowpan headers is something we should certainly consider.  IEEE 802.15.4 originally started down a path of optimizing every bit, only to realize that it was too restrictive, and resulted in IEEE 802.15.4e-2012 Information Elements (IEs).  Those IEs are now used in a number of ways to extend the base IEEE 802.15.4 header.  IEEE 802.15.4e-2012 even introduces an IE that carries the MAC payload such that new footers can also be defined.  Basically, most everything outside the base header can now be encapsulated by IEs.

As Carsten mentioned, whether or not additional headers are encoded within the ESC range is a separate consideration.  But if such additional headers are encoded within the ESC range, then it is of interest to this draft.

Finally, I'll reiterate that I think we should think carefully about simply giving a whole swath of the ESC namespace to G3-PLC.  One possibility is to have an encoding that can carry something like an OUI, allowing third parties to define whatever they want without any further coordination with the IETF.  IEEE 802.15.4e-2012 IEs have a form that can carry OUIs.

--
Jonathan Hui


_______________________________________________
6lo mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/6lo