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

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

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

> -----Original Message-----
> From: Pascal Thubert (pthubert)
> Sent: mardi 17 mars 2020 12:27
> To: 'Michael Richardson' <[e-mail]>ca>; [e-mail]
> Subject: RE: New Version Notification for draft-ietf-roll-unaware-leaves-11.txt
> 
> 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