Subject: [Roll] Published draft-ietf-roll-unaware-leaves-03

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 2 Sep 2019 06:36:32 +0000

Dear all :

We just published 03 of the RUL draft. This version incorporates a number of major changes that we discussed at the meeting and on this ML since:

  *   Modified DAO to add the ROVR. After discussion with Rahul, we clarified that this could only be optional, because of 1) backward compatibility and 2) amount of state in the intermediate nodes in storing mode.
  *   Use the DCO to clear a rejected registration/refresh. If the 6LBR detects a duplication or a movement and returns a negative starus to the Root,  The Root can use an asynchronous DCO to the 6LR, which turns it in a NA(EARO, Status). The draft now adds the IANA registry of Status values that was missing in RFC 6550, and maps the 6LoWPAN Status Values in RPL.
  *   Modified RPL to indicate that Non-Storing signaling MUST be used for External routes signaled by the 'E' flag in the transit option. This will happen even in storing Mode. The reason is to be able to tunnel to the 6LR (that appears as in the Transit option) in order to get rid of RPL artifacts and RFC 8138 compression before the packet is forwarded externally.
  *   We did a number of smaller corrections, like clarified the language on what is a leaf, RUL, RAL (aligned with useofrplinfo) and introduced RAN (as either a RAL or a RPL router).
  *   Michael is now a co-author

Please consider this and let us know your thoughts.

What's left to be done:

  *   Signal whether the ROVR in DAO should be used in capability/config options (dependency on the discussion between Michael and Rahul on the MOP draft)
  *   Signal the capability by the root to proxy the EDAR in behalf of the 6LR. Should we use the MOP draft or make it protocol independent with 6CIO so any routing protocol could be used to proxy?
  *   Interaction with the 6BBR. Based on the discussion with Michael, I separated that flow, so in 03 it disappeared. The goal is to have another section on that.
  *   ?

Other discussion: the new RUL also updates

  *   Impact on useofrplinfo: the change that the (E flag) => (non-storing signaling + tunnel to the 6LR)
  *   Impact on DCO draft: change reserved into Status field

Since those specs are not published yet, we could piggy-back the changes there but that means taking the drafts off the RFC editor's hands.

All the best;

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Mon, 02 Sep 2019 10:59:50 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > *   Modified RPL to indicate that Non-Storing signaling MUST be used
    > for External routes signaled by the 'E' flag in the transit
    > option. This will happen even in storing Mode. The reason is to be able
    > to tunnel to the 6LR (that appears as in the Transit option) in order
    > to get rid of RPL artifacts and RFC 8138 compression before the packet
    > is forwarded externally.

This is quite an interesting thing to do, and I think that it brings us
another step step closer to some kind of hybrid storing/non-storing mode.
DAO-projection is obviously the other step.

Many in the WG might not know, but at one point the WG thought that storing and
non-storing operation would be local choices, but it turned out not to work
that way.

    > *   Signal the capability by the root to proxy the EDAR in behalf of
    > the 6LR. Should we use the MOP draft or make it protocol independent
    > with 6CIO so any routing protocol could be used to proxy?

I think we should use the root-announced (non-negotiated) capability.

    > *   Impact on useofrplinfo: the change that the (E flag) =>
    > (non-storing signaling + tunnel to the 6LR)

...

    > Since those specs are not published yet, we could piggy-back the
    > changes there but that means taking the drafts off the RFC editor's
    > hands.

I think that the useofrplinfo change affects only two (maybe) four of the 24
cases, and the case remains where we have an IPv6 Host only.
So I think it is better to Updates: useofrplinfo.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 2 Sep 2019 15:19:14 +0000

Hello Michael 

Please see below 

> Le 2 sept. 2019 à 17:01, Michael Richardson <[email-masked]> a écrit :
> 
> 

Indeed 

My early implementation would have partial storing mode state and inject record route in the packet going up when the previous hop for the packet wouldn’t match the next hop in the root. 

> I think we should use the root-announced (non-negotiated) capability.

Works for me

> ....

Would you take the pen for this and the root capability? I’m looking at the mop draft in parallel 

All the best,

Pascal 

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Michael Richardson <[email-masked]>
Date: Mon, 02 Sep 2019 13:31:18 -0400

> the mop draft in parallel

To clarify:
My job is to document a capability (using mopex mechanism), in the
unaware-leaves document so that the root can announce that it can
process/proxy the EDAR.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 3 Sep 2019 09:18:21 +0000

If we decide to keep useofrplinfo on its current track and shape then this doc will update it.
I'd like you to write the update section, similar to that for RFC 6550 or RFC 8505.
Peter indicated that we should block useofrplinfo to update it. What do you think?

We also need a way for the root to declare that it can proxy DAO into EDAR. That could be a bit in the 6CIO (RFC 7400, already used a lot in RFC 8505) or a RPL specific thingy. You seemed to prefer RPL specific. Then it would be a capability from the root to all.
As a corollary we need to express whether the ROVR in DAO is used in the network. It is designed to be backwards compatible. Arguably some nodes could do it an others not, so we have to signal whether the root says nothing (legacy), SHOULD use it, or MUST use it else go away.
Note that RFC 6551 has already thought about those things:

P8:

   o  'C' flag.  When set, this indicates that the Routing Metric/
      Constraint object refers to a routing constraint.  When cleared,
      the routing object refers to a routing metric.

   o  'O' flag: The 'O' flag is used exclusively for routing constraints
      ('C' flag is set).  When set, this indicates that the constraint
      specified in the body of the object is optional.  When cleared,
      the constraint is mandatory.  If the 'C' flag is zero, the 'O'
      flag MUST be set to zero on transmission and ignored on reception.

P11:

3.1.  Node State and Attribute Object

   The Node State and Attribute (NSA) object is used to provide
   information on node characteristics.

All the best,

Pascal

> -----Original Message-----
> From: Roll <[email-masked]> On Behalf Of Michael Richardson
> Sent: lundi 2 septembre 2019 19:31
> To: Routing Over Low power and Lossy networks <[email-masked]>
> Subject: Re: [Roll] Published draft-ietf-roll-unaware-leaves-03
> 
>