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

[Michael Richardson <[e-mail]>]

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) <[e-mail]> 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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-