Re: [Roll] AD Review of draft-ietf-roll-efficient-npdao-16

["Pascal Thubert (pthubert)" <[e-mail]>]

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]<mailto:[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.