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

[Samita Chakrabarti <[e-mail]>]

Hi Pascal:

For RPL compression context, option-2 is  the best choice.

Can you clarify a bit on the following text in section  3.2?

“Finally, the specification indicates that Fragments Headers must
   always preceed Routing header.

   As a result, the 11111111 pattern could be considered a delimiminator
   between a portion of the frame that is formatted per [RFC4944] on the
   left, and a portion from which the space for Mesh Header, Fragment
   Header and NALP can be reused, on the right.  This specification
   would reuse the Mesh Header or the NALP as discuused above, so the
   text in this specification is not impacted.”

Q1 – Why do you want to put Routing header behind Fragment header?  Should not the routing header be looked at next hop ?

NALP means not-a-lowpan header --  are you trying to say it’s RPL Routing header instead of lowpan header(IPV6+payload)?

It will be a good idea if your draft draws an example of  sequence of headers.

For example in RFC4944:
      +-----------+-------------+--------------+------------+---------+
      | Frag Type | Frag Header | HC1 Dispatch | HC1 Header | Payload |
      +-----------+-------------+--------------+------------+---------+




Finally,  we are going to discuss in the WG about the design of next set of ESC-style bytes; Johnathan’s ideas were good and Johnathan will be also involved in the discussion for the definition of common ‘Dispatch Extension Tag’.

Are you going to use Mesh header to route the compressed RPL packet ?

Thanks,
-Samita



From: Pascal Thubert (pthubert) [mailto:[e-mail]]
Sent: Thursday, July 23, 2015 5:23 AM
To: Samita Chakrabarti; Jonathan Hui
Cc: [e-mail]
Subject: RE: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt

Dear all:

It seems that we are finding a way which is workable and acceptable to all parties to extend 6LoWPAN with a TLV format. Not my favorite, I really think that Jonathan has the best proposal on the table. But if this is the one thing that can make a consensus, I’ll gladly go for it.

The method is described in more details as option 2 In section 3.2 of the 6LoRH draft https://www.ietf.org/id/draft-thubert-6lo-routing-dispatch-05.txt

If the group agrees with the chairs on this approach, I can rapidly republish the draft cleaning up the leftovers of the other options so we can move forward with 6lo compression work that RPL is expecting from us. That would be really welcome for the next ETSI plugtest.

Let us confirm at the WG today and on this list.

If/when that is behind us, my question to the WG will be whether folks want:
1) to split the doc in 2 to separate the TLV proper in a short document, or
2) if it is OK to keep the draft in one piece as it is today, using the first values of the type for RPL packet artifacts

The former 1) leads to a quicker delivery of the TLV alone, so other work can safely start using it.

The latter 2) is a quicker path for RPL compression since we do not need to advance 2 documents; it also has the advantage to illustrate why we suggest to have the type and the length structured the way they are. Rather to advance a format with no example usage.

What do people think?

Pascal

From: Samita Chakrabarti [mailto:[e-mail]]
Sent: mercredi 22 juillet 2015 23:43
To: Pascal Thubert (pthubert); Jonathan Hui
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 Pascal,

We discussed it in person. But for clarification purpose, I am responding to this email.

See in-line.

From: Pascal Thubert (pthubert) [mailto:[e-mail]]
Sent: Thursday, July 09, 2015 5:00 AM
To: Jonathan Hui; 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

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.
[SC>]  At the meeting(July 20th), we have discussed ITU-T code-space assignment and possible solutions at length and WG response was taken with hum and email of the quorum and liaison statement text was shared.


We have proposed to use the current ESC sequence (01 000000) for ITU-T and for other possible organization specific usage(TBD). But only allocate code-space for which we have specs (G.9903 and G.9905).

We are going to define a new ESC byte or will call that ‘Dispatch Extention Tag” or something similar to allow the WG to define a TLV structure and use it for different purpose – one of that could be link-specific. Though we need to be careful and see we don’t waste codespace in anticipation.

We can definitely start looking into 6loRH draft as a starting point for the new ‘Dispatch Extension Tag(DET)”…

Cheers,
-Samita


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]] 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