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

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

Hello Michael, 

Now going through your questions below:

> -----Original Message-----
> From: Michael Richardson <[e-mail]>
> Sent: lundi 16 mars 2020 19:44
> 
> 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.

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!

> 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.

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


> 
> 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 really like to keep the abstract short.


> 
> 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 do but we can remove/change if not appropriate

> 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.

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

> 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.

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


> 
> 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.

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:
>    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.

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....


>    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.

Kept it, though a bit on the obvious side


> 
>    (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)
> 

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

> 
> ...
>    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 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.

> 
>    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.
> 

Good

> 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)

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

> 
> 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.

Yes, I like your proposal

> 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"?

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


> 
>    *  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"

Cool


> 
> >   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.

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


> 
> >   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.

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.


> 
> >   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?

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).
"

> 
> 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.

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'm not sure that the reverse direction provides anything useful. Opinions?

I though it did, but OK without it.

> 
> 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.
 

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
> multicast.

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 RFC6550 would have been something I would have removed for
> 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.


> 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)

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
> to clone myself.

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