Subject: Re: [Roll] New Version Notification for draft-ietf-roll-unaware-leaves-11.txt

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 13 Mar 2020 12:46:18 +0000

Dear Rollers:

After Rahul's questions yesterday I reworked the text in section 6.2: 
This update is an attempt to clarify the text on RPL packets forwarding from and to RULs, as well as backward compatibility and the use of non-storing mode signaling.

Dear Chairs: I believe that the known issues are now solved and the doc is ready for WGLC. Could we please launch it now?

Cheers;

Pascal

> -----Original Message-----
> From: [email-masked] <[email-masked]>
> Sent: vendredi 13 mars 2020 13:35
> To: Michael C. Richardson <[email-masked]>; Michael Richardson
> <[email-masked]>; Pascal Thubert (pthubert) <[email-masked]>
> Subject: New Version Notification for draft-ietf-roll-unaware-leaves-11.txt
> 
> 
> A new version of I-D, draft-ietf-roll-unaware-leaves-11.txt
> has been successfully submitted by Pascal Thubert and posted to the IETF
> repository.
> 
> Name:		draft-ietf-roll-unaware-leaves
> Revision:	11
> Title:		Routing for RPL Leaves
> Document date:	2020-03-13
> Group:		roll
> Pages:		32
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-roll-unaware-leaves-
> 11.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-11
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-roll-unaware-
> leaves
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-11
> 
> Abstract:
>    This specification extends RFC6550 and RFC8505 to provide unicast and
>    multicast routing services in a RPL domain to 6LNs that are plain
>    Hosts and do not participate to RPL, and enables the RPL Root to
>    proxy the EDAR/EDAC flow on behalf of the RULs and RANs in its DODAG.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 16 Mar 2020 14:43:43 -0400

Following up publically, as an author re-read from the beginning.

Pascal has carried this document very far since it was started last summer,
and I've been rather out of the loop due to other commitments.
My intense thanks to Pascal for this.

My changes are at:
   https://github.com/roll-wg/roll-unaware-leaves/pull/1

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > Actually Michael it would be real great if you could reread unaware
    > leaves. I asked the chairs to make the last call. I believe it’s ready
    > now and as you know it blocks cluster c310.

Yeah, I know.
I wish we had used markdown :-)

1) I notice the Abstract is a single complex sentence.
   I think we should split it up somehow.
   I will think on this after reading it all through.

2) I have a bunch of typos/missing words that I'll commit directly to github.

3) Should we say:

   A RUL is a plain <xref target="RFC8504" /> Host that needs a
   RPL-Aware Router to obtain routing services over the RPL network.

that is, insert RFC8504 here?
Or should we actually say RFC8504/RFC8505, because we depend upon EARO?
I'd like to get Carsten to review this actually, as we are really updating
what it means to be a "Host" on a constrained network.

How can we split this up into three sentences:
   This specification leverages the Address Registration mechanism
   defined in 6LoWPAN ND to enable a RUL as a 6LoWPAN Node (6LN) to
   interface with a RPL-Aware Router as a 6LoWPAN Router (6LR) to
   request that the 6LR injects the relevant routing information for the
   Registered Address in the RPL domain on its behalf.

I think that this paragraph (3.2.1) should get turned into part of the abstract:

   This document specifies how the "R" flag is used in the context of
   RPL.  A 6LN is a RUL that requires reachability services for an IPv6
   address iff it sets the "R" flag in the EARO used to register the
   address to a RPL router.  Conversely, this document specifies the
   behavior of a RPL Router acting as 6LR depending on the setting of
   the "R" flag in the EARO.  The RPL Router generates a DAO message for
   the Registered Address upon an NS(EARO) iff the "R" flag is set.

I wonder if the word "Conversely," is needed.
Maybe:
   A 6LN is a RUL that requires reachability services for an IPv6
   address. It sets the "R" flag in the EARO in order to register the
   address to a RPL router.  This is described in RFC8505.

   This document specifies the behavior of a RPL Router that processes
   EARO messages that have the the "R" flag set in the EARO.

Not sure if this is abstract content, but I like the above.
You really like the word "Conversely" :-)

I am concerned that there is so much repeating of 8505, that this will
confuse some reviewers.  I guess we do Update 8505, but maybe we should hit
them a bit harder on the head that they need to understand it first.

section 4: I keep wondering if we haven't created a new Storing-Mode MOP here,
        that should get a new MOP value (or mopex) value.
        But, I see that 6.3.1. contains the compromise text we worked out at IETF106.

let me think: a storing root that does not set the P bit (because it does not
    support this functionality) will cause 6LR that support this to not
    support RUL processing, and not support RULs.
    Should such 6LRs also essentially not do RAs in that context?
    Does this also enable RFC8505/EARO processing?

I find section 4 really dense, and I wonder if it wouldn't be better to move
sections 4 and 5 later in the document, so that we are referring back.
I'm not sure here.

section 6.1:
   In order to obtain routing services from a 6LR, a RUL MUST implement
   [RFC8505] and set the "R" flag in the EARO option.  The RUL MUST NOT
   request routing services from a 6LR unless the 6LR originates RA
   messages with a CIO that has the L, P and E flags are all set as
   discussed in Section 3.3.1.

-> I think that rather than have MUST NOT, which I think does not lead to
   good interop failure results, I suggest we write:

   A RUL that receives a CIO from a potential (6LR) router that has the L, P and E
   flags set, SHOULD set the "R" flag in the EARO in order to request routing
   services from that 6LR.
   A RUL that has multiple potential routers SHOULD prefer the router that
   can provide the desired routing services.
   If there are no available routers, the connection of the RUL fails.

   (XXX- Can the RUL use the EARO process in the absence of L/P/E to signal
   the error?  I think that deployment of 8505 without this document is a
   very small window, so this won't work in general)

...
   The RUL MUST register to all the 6LRs from which it requests routing
   services.

section 6.2:
   A 6LR that is upgraded to act as a border router for external routes
   advertises them using Non-Storing Mode DAO messages that are unicast
   directly to the Root, even if the DODAG is operated in Storing Mode.

yes, but it should only request them from routers which support R, right?

   The RPL data packets always carry a Hop-by-Hop Header to transport a
   RPL Packet Information (RPI) [RFC6550].  So unless the RUL originates
   its packets with an RPI, the 6LR needs to tunnel them to the Root to
   add the RPI.  As a rule of a thumb and except {FOR} the very special case
   above, the packets from and to a RUL are always encapsulated using an
   IP-in-IP tunnel between the Root and the 6LR that serves the RUL.

I think that this should reference [UseOfRPLinfo] section 7.1.4,
section 7.2.3, 7.2.4, 7.3.3, 7.3.4, 8.1.3, 8.1.4, 8.2.3, 8.2.4, 8.3.3 and
8.3.4.

section 9.1:
   In a same fashion, if an additional routing protocol is deployed on a
   same network, that additional routing protocol may need to handle the
   keep alive procedure for the addresses that it serves.

I believe that this might scare our routing colleagues into thinking that we
intend to deploy things in parallel on LLNs.  Do we need to say this at all?
(I understand that you are just expressing an outward requirement on anyone
that wants to do this.  Maybe we can put this in a section of it's own so
that someone can point to it in the future?   Quite reasonable, someone could
attach a non-constrained wired network on the edge of an LLN, and run OSPFv3
or something there.  But there would be no overlap with the LLN)

section 9.1.1, I think that the column that says "6LN" should say "RUL" instead.
        Yes, 6LN is not wrong, but I think it's not helpful.

Do we need to say something about LLNs which do not have a 6LBR?
Or is this degenerate case self-evident?

section 9.2.1: "By the 6LN" -> "By the RPL unaware 6LN"?

   *  The 6LN can register to more than one 6LR at the same time.  In
      that case, it MUST use the same value of TID for all of the
      parallel Address Registrations.

I'd like to motivate this statement, I think it should reference RFC8505
section 5.2.  Just so that no part of this process is "new"

>   Even without support for RPL, a RUL may be aware of opaque values to be
>   provided to the routing protocol. If the RUL has a knowledge of the RPL

I just looked to see if we return RPLInstanceID in CoJP, and we don't :-(
Someone could write a document in RPL to add that.

>   A RUL that places an
>   RPI in a data packet MUST indicate the RPLInstanceID that corresponds
>   to the RPL Instance the packet should be injected into.  All the
>   flags and the Rank field are set to zero as specified by section 11.2
>   of [RFC6550].

It has never been clear to me how much security isolation RPLInstanceID
should have.  Is it as strong as 802.1Q VLAN tags?  Or is much softer, just a
bit more interesting than IPv6 Flow?  If it's intended to be as strong as
VLAN tags, then there is an admission control control that the 6LR must do.

>   Extended Duplicate Address
>   messages with the 6LBR is avoided if the RPL Root has indicated that
>   it proxies for it.

I'm misplaced how the RPL root has indicated this.  Is it in the DAO-ACK?

9.2.2:
>   *  RPL Non-Storing Mode is used, and the 6LR indicates one of its
>      global or unique-local IPv6 unicast addresses as the Parent
>      Address in the associated RPL Transit Information Option (TIO).

I think that this is an instruction that RPL Non-Storing mode is TO BE used,
(not a conditional sentence).   I suggest we number these points so that
implementers can argue about them better, and make them all more declarative.
There is a commented out sentence in the XML, which I think we can remove.

I understand the use of "iff" throughout, but I'm not sure others will notice
it as other than a typo of "if".  I turned the next paragraph into a numbered
point, but maybe the trailing ';' now does not work.
I'm not sure that the reverse direction provides anything useful. Opinions?

Should the rest of the If/In case be changed to a section on 6LR processing
of DAO-ACK, and a section on processing of DCO?    Right now processing is
described by each role.  I'm for that, but I think we should split it up as
well by message.

Is section 12 RFC6550 multicast actually implemented by anyone?
Given MPL, I didn't think you needed both, but maybe I don't understand multicast.
Section 12 RFC6550 would have been something I would have removed for
6550bis, so I wonder if we should be doing anything with it.

section 12.3, I think that instead of reducing the size of the Flags field, I
suggest that we say that we are allocating 4 bits of the Flag field as the
ROVRsize. (I found it really confusing to figure out btw)

----
I wish I had time to implement this in unstrung and the Linux kernel. :-(
I need to clone myself.

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 17 Mar 2020 10:40:20 +0000

Hello Michael

I picked your changes, moved stuff around, but one really does not parse:

old
   <xref target='RFC8505'/> and set the "R" flag in the EARO option.
   The RUL MUST NOT request routing services from a 6LR unless
   the 6LR originates RA messages with a CIO that has the L, P and E
   flags are all set as discussed in <xref target='R7400'/>.

new
   <xref target='RFC8505'/>. Such a RUL that receives a CIO from a potential
   (6LR) router that has the L, P and E flags set, SHOULD set the "R" flag in
   the EARO in order to request routing services from that 6LR.
   and set the "R" flag in the EARO option.
   This is detailed in in <xref target='R7400'/>

The whole text becomes strange

"

   In order to obtain routing services from a 6LR, a RUL MUST implement
   [RFC8505].  Such a RUL that receives a CIO from a potential (6LR)
   router that has the L, P and E flags set, SHOULD set the "R" flag in
   the EARO in order to request routing services from that 6LR.  and set
   the "R" flag in the EARO option.  This is detailed in in
   Section 3.3.1 A RUL that has multiple potential routers SHOULD prefer
   the router that can provide the desired routing services.  If there
   are no available routers, the connection of the RUL fails.

"

I suggest to rephrase to 
"

   In order to obtain routing services from a 6LR, a RUL MUST implement
   [RFC8505] and set the "R" flag in the EARO.  The RUL SHOULD support
   [AP-ND] and use it to protect the ownership of its addresses.  The
   RUL MUST NOT request routing services from a 6LR that does not
   originate RA messages with a CIO that has the L, P and E flags set as
   discussed in Section 3.3.1.

   A RUL that has multiple potential routers MUST prefer those that
   provide routing services.  The RUL MUST register to all the 6LRs from
   which it desires routing services.  If there are no available
   routers, the connection of the RUL fails.  The Address Registrations
   SHOULD be performed in a rapid sequence, using the exact same EARO
   for a same Address.  Gaps between the Address Registrations will
   invalidate some of the routes till the Address Registration finally
   shows on those routes as well.
"

Can you please review the published-12 to see if the resulting diffs are appropriate?

https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-12 (note that looking at the diffs I found 2 typos that I fixed in github).

All the best

Pascal

> From: Michael Richardson <[email-masked]>
> Sent: lundi 16 mars 2020 19:44
> To: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]
> Subject: Re: New Version Notification for draft-ietf-roll-unaware-leaves-11.txt
> 
> 
> Pascal has carried this document very far since it was started last summer, and
> I've been rather out of the loop due to other commitments.
> I'd like to get Carsten to review this actually, as we are really updating what it
> means to be a "Host" on a constrained network.
> 
> I am concerned that there is so much repeating of 8505, that this will confuse
> some reviewers.  I guess we do Update 8505, but maybe we should hit them a
> bit harder on the head that they need to understand it first.
> 
> -> I think that rather than have MUST NOT, which I think does not lead
> -> to
> I think that this should reference [UseOfRPLinfo] section 7.1.4, section 7.2.3,
> 7.2.4, 7.3.3, 7.3.4, 8.1.3, 8.1.4, 8.2.3, 8.2.4, 8.3.3 and 8.3.4.
> 
> section 9.1:
> attach a non-constrained wired network on the edge of an LLN, and run
> OSPFv3 or something there.  But there would be no overlap with the LLN)
> 
> I'd like to motivate this statement, I think it should reference RFC8505 section
> 5.2.  Just so that no part of this process is "new"
> 
> should have.  Is it as strong as 802.1Q VLAN tags?  Or is much softer, just a bit
> more interesting than IPv6 Flow?  If it's intended to be as strong as VLAN tags,
> then there is an admission control control that the 6LR must do.
> 
> I understand the use of "iff" throughout, but I'm not sure others will notice it
> as other than a typo of "if".  I turned the next paragraph into a numbered
> described by each role.  I'm for that, but I think we should split it up as well by
> message.
> 
> section 12.3, I think that instead of reducing the size of the Flags field, I suggest
> that we say that we are allocating 4 bits of the Flag field as the ROVRsize. (I
> found it really confusing to figure out btw)
> 
> ----
> I wish I had time to implement this in unstrung and the Linux kernel. :-( I need
> to clone myself.
> 
> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works  -
> = IPv6 IoT consulting =-
> 
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 17 Mar 2020 11:27:57 +0000

Hello Michael, 

>    I will think on this after reading it all through.

Yes, I use your proposed change, keps the split, and moved one sentence down.

> 2) I have a bunch of typos/missing words that I'll commit directly to github.

Thanks!

> means to be a "Host" on a constrained network.

For 8505, the next sentence does it. I like your suggestion to add the reference and changed "plain host" to "IPv6 host".

>    the Registered Address upon an NS(EARO) iff the "R" flag is set.

I really like to keep the abstract short.

> You really like the word "Conversely" :-)

I do but we can remove/change if not appropriate

> bit harder on the head that they need to understand it first.

This is really the RPL counterpart of RFC 8505, and we need to show the matching operation each time it occurs.

>         But, I see that 6.3.1. contains the compromise text we worked out at

Rahul discussed a real new MOP in a parallel thread. Interesting stuff...

> sections 4 and 5 later in the document, so that we are referring back.

That would be really difficult. Section 4 is a collection of pointers to the next sections as an introduction of what comes next.

>    flags set, SHOULD set the "R" flag in the EARO in order to request routing

Well, that's only if the 6LR wants to use that guy. And you're reversing the meaning. I tried to say that a router can be used for this spec iff its sets all the bits. I read your text as saying that if a router sets the bits then  the RUL SHOULD use it....

>    If there are no available routers, the connection of the RUL fails.

Kept it, though a bit on the obvious side

>    very small window, so this won't work in general)

Yes. A RUL can register to many routers, to get a DODAG back. It may in parallel register to routers that to not have the bits set, so it can talk to them. But it will not get routing services and the "R" flag will not be set in the NS and NA 's EARO

> yes, but it should only request them from routers which support R, right?

The external route is a general term, and the route can be learnt in many ways. E.g. redistribute an IGP. 
You're correct that it means the 'R' is in the case of a RUL learned via 6LoWPAN ND.

> 7.2.4, 7.3.3, 7.3.4, 8.1.3, 8.1.4, 8.2.3, 8.2.4, 8.3.3 and 8.3.4.

Good

> OSPFv3 or something there.  But there would be no overlap with the LLN)

Yes, that would be a complicated network... I believe the text is needed, but if you like we could move to appendix or something.

>         Yes, 6LN is not wrong, but I think it's not helpful.

Yes, I like your proposal

> section 9.2.1: "By the 6LN" -> "By the RPL unaware 6LN"?

Anything as long as 9.2.1 and 9.2.2 are homogeneous...

> 5.2.  Just so that no part of this process is "new"

Cool

> Someone could write a document in RPL to add that.

Do you think we should do it here? It's doable...

> then there is an admission control control that the 6LR must do.

Could be made as strong. I mean a vlan is only as strong as the switches make it. You'd need different keys per instance since we use the same radio interfaces.

> I'm misplaced how the RPL root has indicated this.  Is it in the DAO-ACK?

See section 4, we could have a reference
"

   RPL defines a configuration option that is registered to IANA in
   section 20.14. of [RFC6550].  This specification defines a new flag
   "Root Proxies EDAR/EDAC" (P) that is encoded in one of the reserved
   control bits in the option.  The new flag is set to indicate that the
   Root performs the proxy operation and that all nodes in the network
   must refrain from renewing the 6LBR state directly.  The bit position
   of the "P" flag is indicated in Section 12.2.
"

Maybe we can say

"
  message, but the exchange of keep-alive Extended Duplicate Address
   messages with the 6LBR is avoided if the RPL Root has indicated that
   it proxies for it using the "P" flag in the RPL configuration option
   (see Section 4).
"

> There is a commented out sentence in the XML, which I think we can remove.

Cool. We should do the same in 9.2.1 and 9.2.3 then, no?

> 
> I understand the use of "iff" throughout, but I'm not sure others will notice it as
> other than a typo of "if".  I turned the next paragraph into a numbered point,
> but maybe the trailing ';' now does not work.

I though it did, but OK without it.

> described by each role.  I'm for that, but I think we should split it up as well by

If needed... 

> Is section 12 RFC6550 multicast actually implemented by anyone?

We have use for it.

> Given MPL, I didn't think you needed both, but maybe I don't understand

MPL is out of scope here. IMHO it's a more of a broadcast than a multicast. In ny fashion I do not see it as a replacement to RPL but as another protocol that can co-exist with RPL though both can live separately.

> 6550bis, so I wonder if we should be doing anything with it.

I have to disagree with that. Just like I disagree with other people about removing storing mode.

> ROVRsize. (I found it really confusing to figure out btw)

Happy to reword but we are not allocating 4 flags, we are reusing the footprint.

> I wish I had time to implement this in unstrung and the Linux kernel. :-( I need

That would be an interesting world : )

I published -12 with your changes and already picked some of the proposals above in the github.
Please have a look and let me know when you do think we want more.

Many thanks again Michael!

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 17 Mar 2020 14:38:16 +0000

Hello again Michael

I applied a number of your recommendations and published 13.
I hope that the remainder of the discussion can be addressed during WGLC, if any.
Please see   https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-13 
 
Take care

Pascal

> From: Pascal Thubert (pthubert)
> Sent: mardi 17 mars 2020 12:27
> To: 'Michael Richardson' <[email-masked]>; [email-masked]
> Subject: RE: New Version Notification for draft-ietf-roll-unaware-leaves-11.txt
> 
> Hello Michael,
> 
> > I'd like to get Carsten to review this actually, as we are really
> > updating what it means to be a "Host" on a constrained network.
> 
> > confuse some reviewers.  I guess we do Update 8505, but maybe we
> > should hit them a bit harder on the head that they need to understand it first.
> 
> > I find section 4 really dense, and I wonder if it wouldn't be better
> > to move sections 4 and 5 later in the document, so that we are referring
> back.
> > I'm not sure here.
> 
> That would be really difficult. Section 4 is a collection of pointers to the next
> sections as an introduction of what comes next.
> 
> >
> > section 6.1:
> Well, that's only if the 6LR wants to use that guy. And you're reversing the
> meaning. I tried to say that a router can be used for this spec iff its sets all the
> bits. I read your text as saying that if a router sets the bits then  the RUL
> SHOULD use it....
> 
> 
> Yes. A RUL can register to many routers, to get a DODAG back. It may in
> parallel register to routers that to not have the bits set, so it can talk to them.
> But it will not get routing services and the "R" flag will not be set in the NS and
> NA 's EARO
> 
> >
> > ...
> > section 7.2.3, 7.2.4, 7.3.3, 7.3.4, 8.1.3, 8.1.4, 8.2.3, 8.2.4, 8.3.3 and 8.3.4.
> >
> 
> Good
> 
> > section 9.1:
> > I believe that this might scare our routing colleagues into thinking
> > that we intend to deploy things in parallel on LLNs.  Do we need to say this at
> all?
> > (I understand that you are just expressing an outward requirement on
> > anyone that wants to do this.  Maybe we can put this in a section of it's own
> so
> Yes, that would be a complicated network... I believe the text is needed, but if
> you like we could move to appendix or something.
> 
> >
> > I'd like to motivate this statement, I think it should reference
> > RFC8505 section 5.2.  Just so that no part of this process is "new"
> 
> Cool
> 
> 
> >
> > I just looked to see if we return RPLInstanceID in CoJP, and we don't
> > :-( Someone could write a document in RPL to add that.
> 
> > It has never been clear to me how much security isolation
> > RPLInstanceID should have.  Is it as strong as 802.1Q VLAN tags?  Or
> > is much softer, just a bit more interesting than IPv6 Flow?  If it's
> > intended to be as strong as VLAN tags, then there is an admission control
> control that the 6LR must do.
> 
> Could be made as strong. I mean a vlan is only as strong as the switches make
> it. You'd need different keys per instance since we use the same radio
> interfaces.
> 
> 
> >
> See section 4, we could have a reference "
> 
> > I understand the use of "iff" throughout, but I'm not sure others will
> > notice it as other than a typo of "if".  I turned the next paragraph
> > into a numbered point, but maybe the trailing ';' now does not work.
> > described by each role.  I'm for that, but I think we should split it
> > up as well by message.
> 
> 
> If needed...
> 
> 
> MPL is out of scope here. IMHO it's a more of a broadcast than a multicast. In
> ny fashion I do not see it as a replacement to RPL but as another protocol that
> can co-exist with RPL though both can live separately.
> 
> > section 12.3, I think that instead of reducing the size of the Flags
> > field, I suggest that we say that we are allocating 4 bits of the Flag
> > field as the ROVRsize. (I found it really confusing to figure out btw)
> 
> > I wish I had time to implement this in unstrung and the Linux kernel.
> > :-( I need to clone myself.
>