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

From: Ines Robles <[email-masked]>
Date: Thu, 5 Nov 2015 03:20:18 +0200

+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) <[email-masked]>:

> 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
>
> Do you see some consequent change we need to make before we ask for last
> call?
>
>
>
> Cheers,
>
>
>
> Pascal
>
>
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>
>

---

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 11 Nov 2015 06:41:03 +0000

First of all, thanks for this work to Pascal and authors. It’s looking very good. I do have some questions/comments.

I intersperse them below with “gab>” within relevant parts of the document (most of it is elided):

Thanks,

Gabriel

...

Abstract

   This specification introduces a new context switch mechanism for
   6LoWPAN compression, expressed in terms of Pages.  A new 6LoWPAN
   dispatch type is proposed in a new Page 1 for use in 6LoWPAN Route-
   Over topologies, that initially covers the needs of RPL (RFC6550)
   data packets compression.  This specification defines a method to
   compress RPL Option (RFC6553) information and Routing Header type 3
   (RFC6554), an efficient IP-in-IP technique and is extensible for more
   applications.

gab> Very nice expression of the scope.

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

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

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).

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/

   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.

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?

   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.

3.3.  Sur-Compression Mechanisms

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

...

5.  6LoWPAN Routing Header General Format

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

   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.

   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”?

...

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).

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

+1

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

2015-09-16 12:33 GMT+03:00 Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>:
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
[email-masked]<mailto:[email-masked]>
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>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 12 Nov 2015 15:40:57 +0000

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

...

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

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

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

...

3.1.  New Page1 Dispatch

gab> s/Page1/Page 1/

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

PT >>

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

...

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?

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.

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.

...

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

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

5.1.  Elective Format

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

...

9.  The BIER 6LoRH

PT>> removed

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

+1

Cheers,

Pascal

---

From: Gabriel Montenegro <[email-masked]>
Date: Tue, 17 Nov 2015 20:06:24 +0000

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:[email-masked]]
Sent: Thursday, November 12, 2015 7:41
To: Gabriel Montenegro <[email-masked]>; Robert Cragie <[email-masked]>
Cc: [email-masked]; Routing Over Low power and Lossy networks <[email-masked]>; Ines Robles <[email-masked]>
Subject: RE: [6lo] [Roll] New routing dispatch and RPL

Hello Gabriel:

Take care;

Pascal

1.  Introduction

...

PT>>  True, added this:
“

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

...

3.1.  New Page1 Dispatch

gab> s/Page1/Page 1/

PT >>

“

...

...

5.1.  Elective Format

...

9.  The BIER 6LoRH

PT>> removed

+1

Cheers,

Pascal