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

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

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



> -----Original Message-----
> From: Michael Richardson <[e-mail]>
> Sent: lundi 16 mars 2020 19:44
> To: Pascal Thubert (pthubert) <[e-mail]>; [e-mail]
> Subject: Re: New Version Notification for draft-ietf-roll-unaware-leaves-11.txt
> 
> 
> 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 =-
> 
>