[Roll] draft-ietf-roll-unaware-leaves (WAS: AD Review of draft-ietf-roll-efficient-npdao-16)

[Alvaro Retana <[e-mail]>]

Just for clarity.

The changes proposed here are for draft-ietf-roll-unaware-leaves
(not draft-ietf-roll-efficient-npdao).  I changed the subject to reflect
that.

Alvaro.

On October 30, 2019 at 6:37:15 AM, Pascal Thubert (pthubert) (
[e-mail]) wrote:

Dear all :



There is a need in the RUL draft to carry a 6LoWPAN ND status inside a RPL
status so we can avoid duplicating DAR/DAC and DAO/DAO-ACK through the
network. This also allows async communication down the DODAG through DCO
(efficient NPDAO).



Alvaro pointed out that mapping one  status in the other as proposed so far
was not too clean. The change proposed herein addresses this concern. The
change would be adding another control bit in the RPL status and
formalizing the format as follows:



7.  Updated RPL Status



   The RPL Status is defined in section 6.5.1. of [RFC6550] for use in

   the DAO-Ack message and values are assigned as follows:



                  +---------+---------------------------+

                  | Range   | Meaning                   |

                  +=========+===========================+

                  | 0       | RFC 6550                  |

                  +---------+---------------------------+

                  | 1-127   | Not an outright rejection |

                  +---------+---------------------------+

                  | 128-255 | Rejection                 |

                  +---------+---------------------------+



                      Table 1: RPL Status per RFC 6550



   This specification extends the scope of the RPL status to be used in

   RPL DCO messages.  Furthermore, this specification enables to carry

   the status values defined for use in the IPv6 ND Extended Address

   Registration Option (EARO) and listed in table 1 of [RFC8505].  Only

   EARO status values in the range 0-63 can be transported.



   The resulting RPL status is as follows:



                        0 1 2 3 4 5 6 7

                      +-+-+-+-+-+-+-+-+

                       |E|A|  Value    |

                       +-+-+-+-+-+-+-+-+



                        Figure 2: RPL status Format



   RPL Status subfields:



   E:  1-bit flag.  Set to indicate a rejection.  When not set, a value

      of 0 indicates success and other values indicate an non-outright-

      rejection as per RFC 6550.



   A:  1-bit flag.  Indicates the type of the status value.



   Status Value:  6-bit unsigned integer.  If the 'A' flag is set this

      field transports a status value defined for IPv6 ND EARO.  When

      the 'A' flag is reset, the status value is defined in a RPL

      extension



   When building a DCO message upon an IPv6 ND NA or DAC message, the

   root MUST place the ARO status unchanged in a mapped DCO with the 'A'

   bit set.  Conversely the 6LR MUST place the ARO status unchanged in

   the NA(EARO) that is built upon a DCO with the 'A' bit set.



Comments welcome (and urgent!). Unless I see opposition I plan to publish
before cutoff so we can discuss it at IETF 106.



All the best;



Pascal



*From:* Alvaro Retana <[e-mail]>
*Sent:* mardi 29 octobre 2019 23:10
*To:* Pascal Thubert (pthubert) <[e-mail]>;
[e-mail]
*Cc:* [e-mail]; roll <[e-mail]>; Peter van der Stok <
[e-mail]>
*Subject:* RE: AD Review of draft-ietf-roll-efficient-npdao-16



Hi!



I’m fine with the changes proposed to draft-ietf-roll-efficient-npdao.



I want to see the WG reach consensus on the changes related
to draft-ietf-roll-unaware-leaves.



Thanks!



Alvaro.



On October 29, 2019 at 5:52:13 AM, Pascal Thubert (pthubert) (
[e-mail]) wrote:

 If you agree with the proposed line above I'll make editions and come back
to you for more comments and/or approval.