[6lo] Re: John Scudder's No Objection on draft-ietf-6lo-multicast-registration-18: (with COMMENT)

[Pascal Thubert <[e-mail]>]

Hello John

Many thanks for your in depth review!

Please see below

Le mer. 1 mai 2024 à 01:52, John Scudder via Datatracker <[e-mail]>
a écrit :

> John Scudder has entered the following ballot position for
> draft-ietf-6lo-multicast-registration-18: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-6lo-multicast-registration/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks for this document. I enjoyed reading it, although some of it was
> fairly
> heavy going. I have several comments I hope may be helpful to you.
>
> ### Section 1, please expand DIO
>
>                             The mode is signaled in the Mode of
>    Operation (MoP) field in the DIO messages and applies to the whole
>    RPL Instance.
>

done


>
> You do define DIO in your glossary, but since it comes later in the
> document, I
> suggest you expand it here anyway. (Also, you use mixed case for "MoP"
> here but
> mostly all-upper "MOP" elsewhere.)
>
> ### Section 1, please expand ULP
>
>    is up to the ULP to cope with both situations.
>
>
done


> Please expand/define.
>
> ### Section 2.3, MOP
>
> You use the acronym "MOP" in quite a few places. Consider adding it to your
> glossary.
>
>
done


> ### Section 3, conserves
>
>    As opposed to unicast addresses, there might be multiple
>    registrations from multiple parties for the same address.  The router
>    conserves one registration per party per multicast or anycast
>    address, but injects the route into the routing protocol only once
>    for each address, asynchronously to the registration.
>
> I don't find the meaning of the second sentence very clear, in particular,
> I
> don't think the verb "conserves" is common in this context. I guess what
> you
> mean is something like "retains" or "stores"?
>
>
I like retains, sorry for my French and thanks


> ### Section 3, please define DMB
>
> Figure 1 has "DMB link". DMB isn't defined anywhere in the document.
>
>
Added glossary and clarified text text with a ref in section 3:

before
"
    Broadcasting is typically unreliable in LLNs (no ack) and
  forces a listener to remain awake, so is generally discouraged.
  The expectation is thus that in either mode, the 6LRs deliver the
  multicast packets as individual unicast MAC frames to each of the 6LNs
  that subscribed to the multicast address.

"

after
"
   LLN links are typically Direct MAC Broadcast (DMB) (more in
   [I-D.ietf-6man-ipv6-over-wireless]) with no emulation to increase
   range (over multiple radio hops) or reliability.  In such links,
   broadcasting is unreliable and asynchronous transmissions force a
   listener to remain awake, so asynchronous broadcasting is generally
   inefficient.  The expectation is thus that whenever possible, the
   6LRs deliver the multicast packets as individual unicast MAC frames
   to each of the 6LNs that subscribed to the multicast address.  On the
   other hand, in a network where nodes do not sleep, asynchronous
   broadcasting may still help recovering faster when state is lost.
"




> ### Section 3, Figure 1
>
> Figure 1 is *relatively* self-explanatory and I found it useful to look at.
> However, it was a little strange that it's not mentioned in the prose at
> all.
>
>


   Figure 1 depicts the registration of an anycast or a multicast
   address.  As shown, the 6LBR receives and accepts multiple Extended
   DAR messages for the same address, and the address being registered
   by multiple nodes is not treated as a duplication.



> ### Section 3, EVPN isn't a routing protocol
>
>                                         or redistributed in a full-
>    fledged routing protocol such as EVPN
>
> EVPN isn't a routing protocol per se. It's a "solution", specifically a
> "BGP
> MPLS-based solution" per [RFC7432 Section 1]. A minimal fix might be to
> change
> the quoted text to "or redistributed in a full-fledged routing protocol
> such as
> might be done in EVPN".
>
>
done


> ### Section 3, nit, "has"
>
>                           The device mobility can be gracefully
>    supported as long has the routers can exchange and make sense of the
>    sequence counter in the TID field of the EARO.
>
> "has" should be "as"
>
> done

### Section 3, "as for"
>
> I found this sentence quite hard to follow:
>
>                As for the unicast address registration, the subscription
>    to anycast and multicast addresses is agnostic to the routing
>    protocol in which this information may be redistributed, though
>    protocol extensions would be needed in the protocol when multicast
>    services are not available.
>
> After reading it a few times, I think your intent is captured if we change
> "as
> for" to "as with"? That is to say, you're saying that anycast and multicast
> follow the same pattern as unicast does?
>

Yes. The registration is over IPv6 ND and that does not depend on the IGP
beyond the router (it is agnostic, I mean, independent)
Proposed new text:

"
   As with the unicast address registration, the
   subscription to anycast and multicast addresses between a node and
   its router(s) is agnostic (meaning, independent, unaware of) to the
   routing protocol in which this information may be redistributed or
   aggregated by the router to other routers, though protocol extensions
   would be needed in the protocol when multicast services are not
   available.
"


>
> ### Section 3, "therein"
>
> Did you mean "herein"?
>
>    This specification also Extends [RFC6550] and [RFC9010] in the case
>    of a route-over multilink subnet based on the RPL routing protocol,
>    to add multicast ingress replication in Non-Storing Mode and anycast
>    support in both Storing and Non-Storing modes.  A 6LR that implements
>    the RPL extensions specified therein MUST also implement [RFC9010].
>                                 ^^^^^^^
>
> yep


> ### Section 6.1, toggling between 1 and 2 descendants
>
>    A RPL router maintains a remaining Path Lifetime for each DAO that it
>    receives for a multicast target, and sends its own DAO for that
>    target with the longest remaining lifetime across its listening
>    children.  If the router has only one descendant listening, it
>    propagates the TID and ROVR as received.  Conversely, if the router
>    merges multiple advertisements (including possibly one for self as a
>    listener), the router uses its own ROVR and TID values.
>
> If I understand this correctly, it implies that in the situation where you
> go
> from one descendent to two, or from two to one, you have to withdraw the
> old
> TID and ROVR and announce new ones. This seems to me to be worth a sentence
> spelling it out.
>
>
proposed addition:
"
                         This
   implies a possible transition of ROVR and TID values when the number
   of listening children changes from one to more or back to one, which
   should not be considered as an error or a change of ownership by the
   parents above.
"


> Also, it has the potential to be kind of chatty in the edge case, but I'm
> not
> saying anything needs to be done about that, necessarily.
>

The transition does not create a new DAO, but the next DAO will be with the
ROVR / TID change. Note that we still have to define ROV in RPL networks.
I hope we do that before the WG closes, the ROVR field was in part intended
for that purpose.




>
> ### Section 7.2, s/DAC/DAR/
>
>    Section 4 of [RFC6775] provides the same format for DAR and DAC
>    messages but the status field is only used in DAC message and has to
>    set to zero in DAC messages.
>
> Should be "set to zero in DAR messages", right? (Also, "in DAC messages",
> plural.)
>
>
both done, great catch!


> ### Section 7.3, only unicast addresses
>
>    [RFC8505] specifies the following behaviours:
>
> ...
>
>    *  Only unicast addresses can be registered.
>
> ...
>
>    This specification adds the following behavior:
>
> You're not just adding new behaviors, right, you're also revising old
> ones? In
> particular, the restriction I've quoted no longer holds. It's probably
> clear
> enough from context what you're trying to say, which is why this isn't a
> DISCUSS, but it seems worth trying to be more precise if we can figure out
> how.
> One way, which is inelegant but has the merit of being straightforward,
> would
> be something like,
>
> NEW:
>    [RFC8505] specifies that only unicast addresses can be registered.
>    This specification removes that restriction and adds procedures for
>    registering multicast and anycast addresses.
>

To be clear, RFC 8505 does not say that non-unicast cannot be registered,
it does not provide an explicit restriction. It only says how unicast
addresses are registered and says nothing about other addresses. This was
my meaning writing that "only IPv6 addresses can be registered". The other
ones cannot because how to do that is unspecified.
Moreover, requirements Req2-x (see annex B2) is not covered by RFC 8505 but
show that the registration of multicast addresses was intended in a future
spec. So your proposed wording above misinterprets my words, and my words
must be rewritten.

What if I change the first bullet to "The registration method is specified
only for unicast addresses" ?

Then I can change:
before
"
   This specification adds the following behavior:
"
after:
"
This specification Amends une above behavior and Extends it with the
following behavior:
 "



> ### Section 7.3, lollipops and other confectionary
>
> In a couple of places in this section you reference lollipops. I don't
> know if
> I would find this term defined if I went to one of the underlying
> specifications, but it sure isn't defined here, and it's not a standard
> enough
> term of art to use it without defining it, IMO.
>

This is all specified in RFC 6550 (RPL) section 7.2, which RFC 8505 section
5.2 points at.
The text is reused as is by reference. RPL points at Perlman83 which is the
original lollipop description by Radia.
proposed addition at the end of this sentence;
"
     The TID field in the multicast NA(EARO) is the one associated to
      the Target and follows the same rules as the TID in the NS(EARO)
      for the same Target, see section 5.2 of [RFC8505], which points at
      section 7.2 of [RFC6550] for the lollipop mechanism used in the
      TID operation.
"


>
> ### Section 7.3, ???
>
> I wasn't able to understand this paragraph:
>
>       The multicast NA(EARO) SHOULD be resent enough times for the TID
>       to be issued with the value of 255 so the next NA(EARO) after the
>       initial series is outside the lollipop and not confused with a
>       reboot.  A 6LN that has recently processed the multicast NA(EARO)
>       indicating "Registration Refresh Request" ignores the next
>       multicast NA(EARO) with the same status and a newer TID received
>       within the duration of the initial series.
>
> Maybe it would be sufficiently clear to the intended audience of this
> document,
> but I thought I should flag it.
>
>
It was rewritten for a parallel comment, please revisit. You need to know
that the straight part starts somewhere above 128, then the counter wraps
once after 255 and then after 127.
So about 128 is the straight part of the lollipop and below 128 is the loop
(circular or sweet part of the lollipop). This is all in RFC 6550 section 7.



> ### Section 7.3, the other way around
>
>                                         If the value of the P-Field is
>       not consistent with the Registered Address, e.g., the Registered
>       Address is a multicast address (section 2.4 of [RFC4291]) and the
>       P-Field indicates a value that is not 1, or the other way around,
>       then the message, NS(EARO) or EDAR, MUST be dropped, and the
>       receiving node MAY either reply with a status of 12 "Invalid
>       Registration" or remain silent.
>
> As written this is ambiguous, I think because you are trying to construct
> a new
> example case by substitution, but the referent of "the other way around" is
> itself ambiguous. I think what you mean is, in the e.g.,
>
> - the Registered Address is a multicast address and the
>   P-Field indicates a value that is not 1, or
> - the Registered Address is not a multicast address and the
>   P-Field indicates a value that is 1.
>
> Is that right? If so, I suggest spelling it out for clarity. Also, do you
> really mean "e.g.", that is to say, is this only an example, and there
> might be
> other "not consistent" cases you expect an implementation to cover, but you
> don't want to exhaustively list them? If it is just an example, an even
> simpler
> fix would be to just get rid of "or the other way around", since you're not
> attempting to be exhaustive anyway.
>

I agree.
"

   *  Registration for multicast and anycast addresses is now supported.
      The P-Field is added to the EARO to signal when the registered
      address is anycast or multicast.  If the value of the P-Field is
      not consistent with the Registered Address, that is if

      -  the Registered Address is a multicast address (section 2.4 of
         [RFC4291]) and the P-Field indicates a value that is not 1, or

      -  the Registered Address is not a multicast address and the
         P-Field indicates a value that is 1.

      then the message, NS(EARO) or EDAR, MUST be dropped, and the
      receiving node MAY either reply with a status of 12 "Invalid
      Registration" or remain silent.
"


>
> ### Section 7.3, all-nodes link-scope
>
>    *  The 6LN MUST also subscribe all the IPv6 multicast addresses that
>       it listens to but the all-nodes link-scope multicast address
>       ff02::1 [RFC4291] which is implicitly registered, and it MUST set
>       the P-Field to 1 in the EARO for those addresses.
>
> That doesn't make sense as written, or at best is ambiguous. Would it be
> correct to rewrite it as,
>
>
what about
"
      The 6LN MUST also subscribe all the IPv6 multicast addresses that
      it listens to, and it MUST set the P-Field to 1 in the EARO for
      those addresses.  The one exception is the all-nodes link-scope
      multicast address ff02::1 [RFC4291] which is implicitly registered
      by all nodes, meaning that all nodes are expected to accept
      messages sent to ff02::1 but are not expected to register it.
"


> NEW:
>    *  The 6LN MUST also subscribe all the IPv6 multicast addresses that
>       it listens to, other than the all-nodes link-scope multicast address
>       ff02::1 [RFC4291] which is implicitly registered, and it MUST set
>       the P-Field to 1 in the EARO for those addresses.
>
> (replaced "but" with ", other than")
>
> Also, in many places where you use "subscribe", I feel like you should use
> "subscribe to", but I expect the RFC Editor will fix this if they agree
> with me
> so I'm not calling the cases out.
>
> ### Section 7.3, SLLAO? LMAO!
>
> But seriously, please gloss it or expand it in line.
>

done


>
>    *  The 6LR MUST also consider that all the nodes that registered an
>       address to it (as known by the SLLAO) also registered to the all
>       nodes link-scope multicast address ff02::1 [RFC4291].
>
> ### Section 8, only unicast routes
>
>    *  The 6LR injects only unicast routes in RPL
>
> Similar point to my previous "Section 7.3, only unicast addresses".
>
>
"*
The 6LR has no specified procedure to inject multicast and anycast routes
in RPL
"


> ### Section 8, nodes or node?
>
> In this,
>
>    *  Upon receiving a packet directed to a unicast address for which it
>       has an active registration, the 6LR delivers the packet as a
>       unicast layer-2 frame to the LLA the nodes that registered the
>       unicast address.
>
> do you mean,
>
>    *  Upon receiving a packet directed to a unicast address for which it
>       has an active registration, the 6LR delivers the packet as a
>       unicast layer-2 frame to the LLA of the node that registered the
>       unicast address.
>
> That is, node singular and not nodes plural, plus added a needed "of".
>

 yep, done


> ### Section 9, addresses used to source traffic
>
>                                              Also, anycast and multicast
>    addresses are not used to source traffic.
>
> Surely not? An anycast address is just a unicast address with delusions of
> grandeur. It's both legal and expected for it to sometimes appear as the
> SA.


OK I removed that sentence since the restriction against using IPv6 anycast
addresses as source addresses was removed in Section 2.6 of RFC 4291. To
your point, it's still a very weird thing to do, see
https://datatracker.ietf.org/doc/html/rfc7094#section-3.3

>
> I
> think the rest of the section can stand alone without this statement, so
> one
> fix would be to just delete it. Or, fix it. Or explain to me why it doesn't
> need to be fixed.
>

The point is if a stack knows an address is anycast but it does not know
whether the app expects a response, it better not hand it as SA to the app,
because the app may never see the response.
responding to an anycast is usually done with a unicast to continue the
conversation. But then as you point out that sentence does not bring much
value here.


>
> ### Section 10, nit, ordering of field descriptions
>
> It would be nice if the fields were described in the order in which they
> occur
> in the diagram.
>
>
done


> ### Section 10, 2-exponent
>
> IMO "2-exponent" is a little terse/slangy. "Exponent to the base 2",
> perhaps.
>
>
done


> ### Section 10, prepositions are so annoying
>
> "2 at the power of" should be "2 to the power of".
>
>
: )


> ### Section 10, Epoch
>
>                                                    The receiver derives
>    the boot time of the sender as the current Epoch minus the sender's
>    Consistent Uptime.
>
> Don't you mean, "the current time"? If you do mean
> https://en.wikipedia.org/wiki/Epoch_(computing), please say more.
>
>
changed to time


> ### Section 10, state must be reassessed
>
>    If the boot time of the sender is updated to a newer time, any state
>    that was installed in the sender MUST be reassessed and reinstalled
>    if it is missing but still needed.
>
> I think I get what you're telling me to do here, but I also think you're
> asking
> the reader to do too much work and in particular, to exercise their
> creativity
> and imagination, always dangerous. I think what you're saying is, that if I
> receive a message that tells me the sender has updated their boot time, I
> (who
> is not the sender!) have to reassess state, and resend it if I think the
> sender
> has lost it.
>

proposed:

"

   If the boot time of the sender is updated to a newer time, any state
   that the receiver installed in the sender before the reboot is
   probably lost.  The receiver MUST reassess all the state it installed
   in the server (e.g., any registration) and reinstall if it is still
   needed.

"

>
> (Also in that same paragraph you have a "the the".)
>
> gone by now, thanks Dirk!


> ### Section 10, s/if/of/
>
> I think "The value if the uptime" is supposed to be "The value of the
> uptime",
> right?
>
> sure


> ### Section 10, can you be more prescriptive?
>
>    Any change in the value of the NSSI from a node is an indication that
>    the node updated some state and that the needful state should be
>    reinstalled, e.g., addresses that where formed based on an RA with a
>    previous NSSI should be reassessed, and the registration state
>    updated in the peer.
>
> Once again I'm a little concerned that you're inviting the reader to
> exercise
> creativity and imagination. If this is what the WG decided is both
> appropriate
> and sufficient, I won't stand in the way, but I did think I should point
> it out.
>
> The applicability is very generic. We need this in RPL too, and the
receiver may need to poll the sender to ask the values of different states
that are not necessarily present in all DIOs.


"
   As long as the NSSI remains constant, the cross-dependent state (such
   as addresses in a host that depend on a prefix in a router) can
   remain stable, meaning less checks in the receiver.  Any change in
   the value of the NSSI is an indication that the sender updated some
   state and that the dependent state in the receiver should be
   reassessed, e.g., addresses that were formed based on an RA with a
   previous NSSI should be checked, or new addresses may be formed and
   registered.
"





> ### Section 11, s/and//
>
> Should
>
>    *  The RPL routers that support the mixed mode and are configured to
>       operate in in accordance with the desired operation in the
>       network.
>
> instead be
>
>    *  The RPL routers that support the mixed mode are configured to
>       operate in accordance with the desired operation in the
>       network.
>
> (Deleted "and", and also fixed "in in".). If that isn't the right fix, can
> you
> please explain further?
>
>
All good, thanks :)


> ### Section 12, not prescribed
>
>    RPL network, since the nodes that do not really need to speak RPL, or
>    are not trusted enough to inject RPL messages, can be prescribed from
>    doing so, which bars a number of attacks Vectors from within RPL.
>
> I guess you probably meant "proscribed"? But I would suggest using
> "forbidden",
> "prevented", etc, instead. If you did mean "prescribed", please help me
> understand.
>
>
that's it, forbidden. Before this spec, all nodes in a RPL network needed
to speak RPL, even hosts that would sit at the edge like washing machines,
and that was a huge attack vector against the whole network.
with https://datatracker.ietf.org/doc/draft-ietf-6lo-prefix-registration/
we'll also allow prefix injection in the RPL network without opening the
doors to the RPL domain.



> ### Section 12, ROV
>
>    multicast subscription inside the RPL network.  This is a first step
>    to enable Route Ownership Validation (ROV) in RPL using the ROVR
>
> I devoutly hope that the abbreviation ROV isn't already well-established
> for
> this use, because it's a potentially a problematic collision with (BGP,
> RPKI)
> Route Origin Validation (ROV) which is already in wide use. Come to think
> of
> it, I don't know what Route Ownership Validation is... but maybe you
> actually
> did mean Route Origin Validation, in which case make that edit and also it
> would probably be appropriate to add an informative reference to RFC 6811.
> (In
> looking back at RFC 6811, I was reminded that we foolishly titled it
> "Prefix
> Origin Validation" even though the technology is universally referred to as
> ROV. Ah well.)
>
>



> ### Section 15, thanking Mx Ellipsis
>
>    The Editor wishes to thank ...  and Esko Dijk for their useful WGLC
>    reviews and proposed changes.
>




>
> Did you really mean to thank Mx Ellipsis?
>

That was a place holder for other reviewers who never came :) It's gone
now...

Many thanks John! I published -19 with your diffs and others that came at
the same time :)
https://author-tools.ietf.org/iddiff?url1=draft-ietf-6lo-multicast-registration-18&url2=draft-ietf-6lo-multicast-registration-19&difftype=--html

all the best;

Pascal



-- 
Pascal