Re: [Roll] [6lo] New routing dispatch and RPL

[Gabriel Montenegro <[e-mail]>]

Thanks for your response, Pascal.

Yes, I think any other discussion points left (I see some are agreeable already to you) we can sort out after adoption. I’ll issue the call now.

From: Pascal Thubert (pthubert) [mailto:[e-mail]]
Sent: Thursday, November 12, 2015 7:41
To: Gabriel Montenegro <[e-mail]>; Robert Cragie <[e-mail]>
Cc: [e-mail]; Routing Over Low power and Lossy networks <[e-mail]>; Ines Robles <[e-mail]>
Subject: RE: [6lo] [Roll] New routing dispatch and RPL

Hello Gabriel:

Bottom line: I followed your suggestions and posted 07.

Exception left for later: the term elective that comes from Robert and the General Header proposal that is too wide to my taste, I wish to stick to routing and forwarding operations.

Can we sort that out after adoption?

Take care;

Pascal

1.  Introduction

...

   This specification extends 6LoWPAN [RFC4944] and in particular reuses
   the Mesh Header formats that are defined for the Mesh-under use cases
   so as to carry routing information for Route-over use cases.  The
   specification includes the formats necessary for RPL and is
   extensible for additional formats.

gab> reuse Mesh Header??? This does not agree with all our discussions since IETF 93, nor does it reflect what this doc proposes. In any page other than 0, one can say it reuses Mesh Header, sure, but it also reuses every other page 0 dispatch (except the Paging Dispatch itself). So mentioning Mesh Header as being reused while strictly speaking a true statement is misleading. Suggest removing that, as it is clear from subsequent text what is going on..

PT>> sure; will remove inadequate mentions to mesh header

Also, suggest using "Paging Dispatch" for the overall mechanism and for the name of this draft.

PT>> done. But then, should I split in 2 drafts, one for the "Paging Dispatch" and one for the 6LoRH?

The capability to compress RPL artifacts is only part of page 1 (not even the entire page 1, as you include the BIER example already).

PT>>  True, added this:
“

The 6LoRH uses on a 1/4th of the Dispatch space in Page 1, and this
specification only uses a limited portion of the TLV space in
the 6LoRH to encode RPL artifacts. It is expected that in the
future, other specification with extend the 6LoRH for other features
  related to packet routing and forwarding in 6LoWPAN networks.
“

2.  Terminology
...

3.  Updating RFC 4944

...

                            0
                            0 1 2 3 4 5 6 7
                           +-+-+-+-+-+-+-+-+
                           |1|1|1|1|Page Nb|
                           +-+-+-+-+-+-+-+-+

                          Figure 2: Page encoding

gab> Suggest calling this the Paging Dispatch, which includes the Page encoding in its least significant 4 bits.

...

3.1.  New Page1 Dispatch

   This draft defines a new Page1 Dispatch with a Dispatch Value of
   11110001 that indicates a context switch in the 6LoWPAN parser to a
   Page 1.

gab> s/Page1/Page 1/

Done. Now reads throughout like “Page 1 Paging Dispatch”

   The Dispatch bits defined in Page 0 by [RFC4944] are free to be
   reused in Page 1.


gab> True, but it is truer to say this not only of Page 1 but all non-zero pages.


PT >>

“
The Dispatch bits defined in Page 0 by {{RFC4944}} are free to be reused in the next
  Pages, 1 to 15.
“


3.2.  New Routing Header Dispatch (6LoRH)

...

   The 6LoRH is expressed in a 6loWPAN packet as a Type-Length-Value
   (TLV) field, which is extensible for future uses.  The proposed BIER
   bitmap encoding in Section 9 is an example of extension.

gab> If this is applicable to other applications, perhaps Routing Header is a misnomer. Heck, it already is usable for BIER. Perhaps General Header?

PT >> I’d like to keep it for routing and forwarding operations, things done by routers that can be removed before the last router passes the packet to a host. BIER is still routing.
Would you prefer 6LoRFH to avoid confusion with RH in IP?

   Section 5.1 of the [RFC4944] specification defines various Dispatch
   Types and Headers, and in particular a Mesh Header that corresponds
   to a bit pattern 10xxxxxx (in Page 0).

   This specification uses the same bit pattern 10xxxxxx in Page 1 for
   the canonical form of 6LoRH Dispatch that is detailed in Section 5

gab> Mentioning Mesh Header is misleading as this value in page 1 has no relationship whatsoever to it. It is a fresh start for all dispatch values.

PT >> It is. But this section is about the surcompression mechanism that projects all Pages into one.
As long as the projection does not create overlap, there is no need to do any remapping.
This text is saying that there will generally not be an overlap. But the section is not necessary for the spec and I removed it to simplify adoption.


3.3.  Sur-Compression Mechanisms

gab> "Sur-compression" ? Is that a word? Did you mean “Sub-compression”? Or, from the text, link-specific compression?

PT>> I removed the whole section. That’s really for Jonathan to draft and I was hinting that it will work fine for 6LoRH when he does.
I meant compression of compression, unsure how to express that in English though sur or super came to my mind as the natural way.

...

5.  6LoWPAN Routing Header General Format

gab> suggest: s/Routing Header General Format/General Header Format/

PT >> Hum, I keep that one for discussion due to the above

   In its canonical form, the 6LoRH reuses in Page 1 the Dispatch Value
   Bit Pattern of 10xxxxxx that is defined in Page 0 for the Mesh Header
   in [RFC4944].

gab> I would avoid constantly mentioning what it represents in Page 0, as it is not relevant. In a page system, these values have no pre-established meaning, and mentioning the previous value in page 0 can actually be more misleading than helpful.

PT >> sure, done. That was repeated text. All fixed.

   The Dispatch Value Bit Pattern is split in two forms of 6LoRH:

      Elective (6LoRHE) that may skipped if not understood

      Critical (6LoRHC) that may not be ignored

5.1.  Elective Format

gab> Perhaps "Optional", "Ignorable", "Skippable" instead of “Elective”?

PT>> that’s Robert, and I trust is native speaking. Robert?

...

9.  The BIER 6LoRH

gab> This BIER header could be done later separately. BIER may not need to be in this document. Probably better not to have it and focus on what needs to happen quickly and is better understood at this point. Anything else that is not as well understood might cause further delays. However, this document lays out the foundation for future extensions (including BIER if it makes sense) as well as define some extensions (for the RPL artifacts).

PT>> removed


From: 6lo [mailto:[e-mail]] On Behalf Of Ines Robles
Sent: Wednesday, November 4, 2015 17:20
To: Routing Over Low power and Lossy networks <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [6lo] [Roll] New routing dispatch and RPL

+1

It is good to have a method  to compress RPL Option.

I think you are asking for adoption, not last-call?

Let'see how it can be used for the different uses cases, specifically the ones that fails

Thanks Pascal for this work


2015-09-16 12:33 GMT+03:00 Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>:
Dear all:

We packed pretty much all we got from the meeting(s) in Prague into https://tools.ietf.org/html/draft-thubert-6lo-routing-dispatch-06<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-thubert-6lo-routing-dispatch-06&data=01%7c01%7cGabriel.Montenegro%40microsoft.com%7ccd411b1f40934414f5cb08d2e57f4dba%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2fXkJnPJ6DP6U4vZpCdlXr4RLJ%2bfxcC4bIt69V8NWfoA%3d>
Do you see some consequent change we need to make before we ask for last call?

Cheers,

Pascal


_______________________________________________
Roll mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/roll<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2froll&data=01%7c01%7cGabriel.Montenegro%40microsoft.com%7ccd411b1f40934414f5cb08d2e57f4dba%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=lVj4ymM4uHnGZsEYC5jAZlDeLbhmwbqsQsZDhZhXXF0%3d>