Re: [Roll] suggested addition to draft-ietf-roll-efficient-npdao

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

Hum;

The term “status” may be abused, but it practice it means more than a state. It is more like a return code.
RUL uses the “Status values” from 6LoWPAN ND and transports them on DCO.
E.g., the backbone router uses “removed” to indicate that another BBR now owns the address.
In a 6TiSCH network that would mean in another RPL DODAG, so the address in this DODAG needs to be cleaned up. DCO is the way to do that. So the expectation is a DCO with a status code ‘removed’ as well.
The 6lo chairs asked me to remove text on RPL from the BBR so the above is still nuspecified, we’ll do that once the BBR has shipped.

If you look at the values in RUL right now they are exactly the sort of thing you’re talking about; current IANA section of RUL has the following:

    +---------+--------------------------------------+----------------+
    |  Value  |               Meaning                | Defining Spec  |
    +---------+--------------------------------------+----------------+
    |    0    |        Unqualified acceptance        |    RFC6550     |
    |         |                                      |                |
    |  1-127  |      Reserved for Warning Codes      |    RFC6550     |
    |         |                                      |                |
    |   128   |          Duplicate Address           |    This RFC    |
    |         |                                      |                |
    |   129   |            Out of Storage            |    This RFC    |
    |         |                                      |                |
    |   130   |                Moved                 |    This RFC    |
    |         |                                      |                |
    |   131   |               Removed                |    This RFC    |
    |         |                                      |                |
    |   132   |         Validation Requested         |    This RFC    |
    |         |                                      |                |
    |   133   |       Duplicate Source Address       |    This RFC    |
    |         |                                      |                |
    |   134   |        Invalid Source Address        |    This RFC    |
    |         |                                      |                |
    |   135   |   Address topologically incorrect    |    This RFC    |
    |         |                                      |                |
    |   136   |       6LBR Registry saturated        |    This RFC    |
    |         |                                      |                |
    |   137   |          Validation Failed           |    This RFC    |
    |         |                                      |                |
    | 138-192 | Reserved for 6LoWPAN ND code mapping |    This RFC    |
    |         |                                      |                |
    | 193-255 |  Reserved for other Rejection Codes  |    RFC6550     |
    +---------+--------------------------------------+----------------+

All the best,

Pascal

From: Roll <[e-mail]> On Behalf Of Rahul Arvind Jadhav
Sent: vendredi 30 août 2019 10:31
To: Routing Over Low power and Lossy networks <[e-mail]>; [e-mail]
Subject: Re: [Roll] suggested addition to draft-ietf-roll-efficient-npdao


Minimal changes to NPDAO is to change the name “reserved” of the field in the drawing and add text saying same status field as in RPL DAO ACK.

If we really want new status values we may also add them in NPDAO and I’ll adapt RUL. But there is no absolute need to create the registry in NPDAO.
[RJ] The status field values of DAO-ACK/DCO-ACK are not what we require to be sent in DCO… What we want is a Reason field and not a Status field in the DCO.. Hence I believe that there are changes required for IANA. We can take a shortcut and keep the field same as Status, but it seems like a hack to me.

Le 30 août 2019 à 09:30, Peter van der Stok <[e-mail]<mailto:[e-mail]>> a écrit :
Hi Authors,

It is a bit late to change the approved draft.
It is in IANA editing; and you could write to IANA to apologize for a late addition and see how far they are in the process.
BUT, worse,  how much text is needed to explain this addition?

Adding text to an approved document sounds like opening a can of worms to me.

Peter

Rahul Arvind Jadhav schreef op 2019-08-30 09:03:
The DCO could be initiated for regular route invalidation due to path changes or because of management decision. The status code can help understand the reason for initiating the DCO. I like the idea of this.

However, I don’t know, procedurally, what it means to changing the draft at this stage.

The changes to draft would include new IANA considerations for the status field.

From: Roll [mailto:[e-mail]] On Behalf Of Pascal Thubert (pthubert)
Sent: 30 August 2019 14:43
To: Routing Over Low power and Lossy networks <[e-mail]<mailto:[e-mail]>>
Subject: [Roll] suggested addition to draft-ietf-roll-efficient-npdao

Dear all ;

I know it’s late but I’d suggest an addition to draft-ietf-roll-efficient-npdao. There’s a reserved field in the DCO.
My suggestion is to use it to transport RPL DAO-ACK status values as defined in RFC 6550. This way we can signal the reason of the DCO to the node.
This will become significant with the RPL-unaware leaves draft, so we can rebuild a NA(EARO) with a non-zero status based on a DCO.

Else the RUL draft will have to update efficient NP DAO, which does not look as good.

Any objection to this?

Pascal

   0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | RPLInstanceID |K|D|   Flags   |   Reserved    | DCOSequence   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                            DODAGID(optional)                  +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Option(s)...
     +-+-+-+-+-+-+-+-+


_______________________________________________
Roll mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/roll