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

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

Dear all

More on the proposal below:

The proposal is to place more details in the RPL status in the RUL draft and make it a normative ref to efficient NPDAO. 

Changes in the efficient NPDAO draft:
====================

- Make the RUL draft a normative reference

- new description of the status:
"
   RPL Status: As defined in [RFC6550] and updated in
   [I-D.ietf-roll-unaware-leaves].  The root or common parent that
   generates a DCO is authoritative for setting the status information
   and the information is unchanged as propagated down the DODAG.  This
   document does not specify a differentiated action based on the RPL
   status.
"



Changes in the RUL draft:
====================

- In 4.  Updating RFC 6550, add:

"
   The RPL Status defined in section 6.5.1. of [RFC6550] for use in the
   DAO-Ack message is extended to be used in the DCO messages
   [EFFICIENT-NPDAO] as well.  Furthermore, this specification enables
   to use a RPL status to transport the IPv6 ND status defined for use
   in the EARO, more in Section 7.
"

- Create a section 7 as:

"
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
       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |E|A|  Value    |
      +-+-+-+-+-+-+-+-+

   RPL Status subfields:

   E:  1-bit flag.  Set to indicate a rejection.  When not set, A value
      of 0 indicates success.  Other values are non-rejection as per RFC
      6550.

   A:  1-bit flag.  Set to indicate the type of the status value.

   Value:  6-bit unsigned integer.  If the 'E' flag is set this field
      transports a status value defined for IPv6 ND EARO.  When the 'E'
      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.

"

- Remove section 12.2 since we do not create new status values, we now transport the ARO status as defined by ND.

- Instead, create the missing registries that RFC 6550 did not as
"

13.2.  New Subregistry for the RPL Non-Rejection Status values

   This specification creates a new subregistry for the RPL Non-
   Rejection Status values for use in RPL DAO-ACK and RCO Messages,
   under the ICMPv6 parameters registry.

   *  Possible values are 6-bit unsigned integers (0..63).

   *  Registration procedure is "Standards Action" [RFC8126].

   *  Initial allocation is as indicated in Table 2:

            +-------+------------------------+---------------+
            | Value | Meaning                | Defining Spec |
            +=======+========================+===============+
            | 0     | Unqualified acceptance | RFC 6550      |
            +-------+------------------------+---------------+

            Table 2: Status values of the RPL DAO-ACK Message

13.3.  New Subregistry for the RPL Rejection Status values

   This specification creates a new subregistry for the RPL Non-
   Rejection Status values for use in RPL DAO-ACK and RCO Messages,
   under the ICMPv6 parameters registry.

   *  Possible values are 6-bit unsigned integers (0..63).

   *  Registration procedure is "Standards Action" [RFC8126].

   *  There is no initial allocation
"


Fire at will!

Pascal
> -----Original Message-----
> From: Pascal Thubert (pthubert)
> Sent: mardi 29 octobre 2019 10:52
> To: 'Alvaro Retana' <[e-mail]>; draft-ietf-roll-efficient-
> [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
> 
> .
> > >
> > > It cannot be a convergence because RPL had rules in
> > > https://tools.ietf.org/html/rfc6550#section-6.5.1 whereby the status
> > > below
> > > 128 are warning.
> > > That provision was not really used so far to my best knowledge. So
> > > we could drop it. We chose not to so far. Could be done though if
> > > that's your recommendation.
> >
> > I think that would be a lot clearer...but that is a decision that the
> > WG needs to make.
> >
> >
> 
> 
> Maybe we could restructure the RPL Status with the first 2 bits becoming
> significant as opposed to the first bit only.
> 
> Today:
> 
> Bit 0 set  => error
> Bits 1->7 => status code
> 
> Proposed change:
> 
> Bit 0 set  => means error ( 0 is warning or OK) Bit 1 set  => transporting ARO
> status (refers to RFC 8505 and updates for definition off the next status) Bits
> 2->7 => status code | ARO status depending on bit 1
> 
> >
> > > > (2) draft-ietf-roll-unaware-leaves doesn't update the allocation
> > > > guidelines from rfc6550 (§6.5.1) for the Status, which then lands
> > > > "moved" in the "Rejection" range. IOW, the meaning is changed, but
> > > > the original meaning of the DAO-ACK Status is not updated...
> > > >
> > > > [We are not reviewing draft-ietf-roll-unaware-leaves here, so some
> > > > of these comments can be saved for later. ;-)]
> > >
> > > I see: we need to indicate that we update/extend the semantics of a
> > > the DAO-ACK status.
> > > Should that be indicated in npdao draft or in unaware leaves, where
> > > the IANA is done for all?
> >
> > If the IANA update is to be done in draft-ietf-roll-unaware-leaves,
> > then there (that is part of the reason for the Normative dependence below).
> 
> 
> I'm good with that. Considering the stage of this doc, I'd rather not change it
> too much and do the above in the RUL draft.
> We can complete the RUL draft quite quickly now,  and ship this useofrplinfo
> and RUL together.
> 
> >
> > > > Needless to say, I don't like this approach.
> >
> > To be clear, what I don't like is the fact that message that seem to
> > be intended for different things (ND, DAO-ACK, DCO) share the same
> > status information...and that it is not consistently corresponding
> > (the same values don't mean the same things...)....so while
> > homogenizing is a good thing, we seem to (currently) only go half way.
> >
> 
> This is really helpful, Alvaro.
> I read the whole answer once before starting to answer and the proposal
> above is what I found to meet this and the below.
> 
> 
> > > We are specifying it right now in Efficient-NPDAO. RFC 8505 was
> > > forward looking to that respect. It had to indicate the ND status
> > > for that case and that status is "moved".
> > > - It means the guys was down there but is no more. Which is exactly
> > > the topic of NPDAA, cleanup a downwards path that leads to a
> > > location from which the target has moved away.
> > > - But it could not discuss how RPL translates it back and forth. The
> > > generic spec for that is unaware-leaves. DCO is a special case of
> > > RC/status that matches "moved" in RFC 8505.
> >
> > Ok...so this piece is also dependent on
> > draft-ietf-roll-unaware-leaves.  I expect then clear pointers from
> > draft-ietf-roll- efficient-npdao to it.
> >
> >
> 
> Certainly
> 
> 
> > > The meaning we wanted to convey is that when propagating down the
> > > DCO, the status from the parent MUST be repeated unchanged to the
> children.
> >
> > Yes, I understand.
> >
> > My question is from the Normative point of view.  The rfc2119 keywords
> > "MUST only be used where it is actually required for interoperation".
> > If informative, then we don't need "MUST NOT"...but if there is a
> > behavior expectation (or as you wrote above: "be turned into ND again
> > and in those cases the meaning must be conveyed unmodified"), then the
> > required behavior should be able to be verified somehow...and,
> > ideally, the specification should include an indication of what the
> > behavior should be if the mandatory action is not met.  We can of
> > course trust that nodes will follow the specification and will not change the
> contents of the status...
> >
> > So..I would like to see a couple of things:
> >
> > (1) A clear indication of whether specific behavior is expected (you
> > have mentioned it twice in this thread, but the document doesn't
> > reflect that) or not based on the status.
> 
> Will do
> 
> >
> > (2) Text (maybe in the security considerations) pointing out the
> > effect of, changing the value in-flight, and how (if possible) to mitigate it.
> 
> Same here. Note that I do not have a mitigation in mind right now.
> 
> 
> >
> >
> > > Suggestion to reword from the perspective of the intermediate router.
> > >
> > > > (2) If only values > 128 are expected, then what should a receiver
> > > > do if a value < 128 is received? Should the DCO not be propagated
> further?
> > >
> > > Yes, the DCO should be propagated and as done today, it causes the
> > > destruction of the path regardless of the value of the status, even
> > > a warning <128.
> > > Should we change that so a warning is propagated but the route is
> > > conserved or something? There is no known usage of that today, does
> > > that protect the future better?
> >
> > Going back to the text, which reads: "Only Rejection Codes (values of
> > 128 and above) are expected in a DCO."  Also, going back to your
> > statements above about specific behavior resulting from the status
> > value.  I just want to make sure the specification is clear related to
> > what should be done; if any value is ok, then the text is, at minimum
> > not clear...if the behavior depends on the value, then there's an effect if the
> value is not that is expected...
> >
> 
> That text goes away if you agree with the proposal of the additional bit in the
> RPL status. The new text would say that "the ARO status MUST be placed
> unchanged by the root" in the mapped DCO with the bit ARO set. Conversely
> that the "6LR MUST place the mapped ARO status in the NA(ARO) that is built
> upon the DCO".
> 
> RPL already has text like "
>                   The root of a DODAG is
>    authoritative for setting that information and the information is
>    unchanged as propagated down the DODAG.
> "
> 
> We can emulate that form for the DCO, say that "The root or common parent
> that generates a DCO is authoritative for setting the status information and
> the information is unchanged as propagated down the DODAG. " The
> transported ARO status is just a case of that. We'd also say that "this spec
> does not specify a differentiated action based on the status."
> 
> 
> >
> > I hope we're making progress.  If not, we might want to think about
> > speaking live. :-)
> 
> We are. If you agree with the proposed line above I'll make editions and come
> back to you for more comments and/or approval.
> 
> This is all very much appreciated, Alvaro.
> 
> Pascal