Subject: Re: [6lo] Fwd: [Technical Errata Reported] RFC4944 (4359)

From: Jonathan Hui <[email-masked]>
Date: Fri, 29 May 2015 17:59:18 -0700

I believe the Erratum under discussion is correct and should be marked as
Verified.

The original intent of "Dispatch value" was:
1) To refer to the Dispatch field in the Dispatch Header - note the
capitalization in "Allows support for Dispatch values larger than 127."
2) To identify a namespace that *excludes* the Mesh Addressing and
Fragmentation headers.

The original draft text (draft-ietf-6lowpan-format-07) was less ambiguous
about the original intent.  Referring to that draft:

1) The draft separated the concept of "Header Type" from "Dispatch Value".
The draft defined Header Types: Dispatch, Mesh Delivery, and Fragmentation,
and Dispatch Values: NALP, IPv6, LOWPAN_HC1, LOWPAN_BC0, and ESC.  The
draft also includes the following text that indicates the Mesh Addressing
and Fragmentation headers are not included in the dispatch value namespace:

   The definition of headers, other than mesh addressing and
   fragmentation, in LoWPAN consists of the dispatch value, the
   definition of the header fields that follow

Note that the text above still lives in RFC 4944.

2) The bit pattern figure was titled "Dispatch Type Bit Pattern", not
"Dispatch Value Bit Pattern", with the intent that the table only included
the initial allocations within the Dispatch Header and did *not* include
any mention of Mesh Delivery and Fragmentation headers.

--
Jonathan Hui

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 30 May 2015 08:46:15 +0200

It is true that the RFC is not internally consistent here -- some
counterexamples to the ones you give here are Figure 2 and the text
   NALP:  Specifies that the following bits are not a part of the LoWPAN
      encapsulation, and any LoWPAN node that encounters a dispatch
      value of 00xxxxxx shall discard the packet

Nor is it consistent with the actual usage of the term "dispatch value"
in the literature, as can be seen e.g. in
http://solomon.ipv6.club.tw/Course/ProtocolEngineering/archrock-6lowpan-tutorial.pdf
or the 6LoWPAN book.

Also, there is no mandate that ESC-based dispatch values can only be
used for things other than mesh addressing and fragmentation.  There is
also no intention that the values 0 to 63 following ESC have the same
meaning as the dispatch values 01 000000 to 01 111111.

Expanding the confusing use of the term "dispatch value" just for the
six-bit field in 01 xxxxxx would be wrong.

Grüße, Carsten

Jonathan Hui wrote:
> I believe the Erratum under discussion is correct and should be marked
> as Verified.
> 
> The original draft text (draft-ietf-6lowpan-format-07) was less
> ambiguous about the original intent.  Referring to that draft:
> 
> 1) The draft separated the concept of "Header Type" from "Dispatch
> Value".  The draft defined Header Types: Dispatch, Mesh Delivery, and
> Fragmentation, and Dispatch Values: NALP, IPv6, LOWPAN_HC1, LOWPAN_BC0,
> and ESC.  The draft also includes the following text that indicates the
> Mesh Addressing and Fragmentation headers are not included in the
> dispatch value namespace:
> 
> "Dispatch Value Bit Pattern", with the intent that the table only
> included the initial allocations within the Dispatch Header and did
> *not* include any mention of Mesh Delivery and Fragmentation headers.
> 
> --
> Jonathan Hui
> 
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: Jonathan Hui <[email-masked]>
Date: Sat, 30 May 2015 00:51:55 -0700

> http://solomon.ipv6.club.tw/Course/ProtocolEngineering/archrock-6lowpan-tutorial.pdf

Unfortunately, the RFC also does not carry forward the original intent of
the value "127".  All of the counterexamples you gave appear in the RFC (or
as a result of the RFC) and not in draft-ietf-6lowpan-format-07.

> meaning as the dispatch values 01 000000 to 01 111111.

You are correct that the intent was not to preclude things that have to do
with mesh addressing and fragmentation.  But I can say that the intent was
the "Mesh Addressing Type and Header" and "Fragmentation Type and Header"
were not included in the "Dispatch Type and Header".  As mentioned
previously, the original version of Figure 2 did not include the Mesh
Addressing and Fragmentation header bit patterns.  To Kerry's point, the
original table included 128 entries, *not* 256 entries.

> six-bit field in 01 xxxxxx would be wrong.

If you look at draft-ietf-6lowpan-format-07, the term "dispatch value" was
only used in reference to the Dispatch Type and Header.  The update to
draft-ietf-6lowpan-format-08 is where the confusing use of "dispatch value"
started to appear.  draft-ietf-6lowpan-format-07 actually used the 7-bit
dispatch value of 0 to support NALP.  However, there was concern about
consuming too many bits for NALP.  So in draft-ietf-6lowpan-format-08, we
updated NALP to only take one additional bit.  That lead to having 00xxxxxx
for NALP and 01xxxxxx for Dispatch.  Unfortunately, the edits that were
made were quick and dirty.  In retrospect, we should have create a fourth
"Type and Header" for NALP, in addition to Dispatch, Mesh Addressing, and
Fragmentation.  Doing so would have removed any discussion of NALP from the
"Dispatch Type and Header" section as well as the "Bit Pattern" table.

But putting aside the discussion on the original intent of the value "127"
and taking a step back, the high-level intent was to support
arbitrary-length bit patterns for identifying 6LoWPAN headers.  It may be
that removing any reference to a maximum "dispatch value" offered within
the first 8 bits is the best path forward, as Kerry has suggested.

--
Jonathan Hui

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 30 May 2015 14:02:16 +0200

Jonathan Hui wrote:
> But putting aside the discussion on the original intent of the value
> "127" and taking a step back, the high-level intent was to support
> arbitrary-length bit patterns for identifying 6LoWPAN headers.  It may
> be that removing any reference to a maximum "dispatch value" offered
> within the first 8 bits is the best path forward, as Kerry has suggested.

+1

Grüße, Carsten

---

From: Kerry Lynn <[email-masked]>
Date: Sat, 30 May 2015 08:35:11 -0400

On Sat, May 30, 2015 at 3:51 AM, Jonathan Hui <[email-masked]> wrote:

<snip>

Jonathan,

Thanks for the historical background.  I think it will inform the
discussion on how to fix
the section going forward.

> No argument here.  I think it's the best that can be done to improve the
section with a
one-sentence change.

Kerry

---

From: Robert Cragie <[email-masked]>
Date: Sat, 30 May 2015 15:19:47 +0100

I think the text is almost right, however I think "larger than 63" is no
longer appropriate due to the initial 0b01 bit combination. "larger than
127" worked as it implied the most significant bit could be 1. If the
original intent is to be preserved, the following text would make more
sense to me:

ESC:  Specifies that the following header is a single 8-bit field for the
Dispatch value.  It allows support for more than 64 Dispatch values.

Alternatively, Kerry's more relaxed text would also work.

Robert