[pim] Benjamin Kaduk's Discuss on draft-ietf-pim-drlb-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-pim-drlb-13: Discuss

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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pim-drlb/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I think we need greater clarity on whether the list of GDR candidate
addresses is sorted or not (i.e., whether it is required for protocol
operation), as indicated by the rtgdir reviewer.
Specifically, Section 5.3 is clear in the descriptive text that the list
is sorted (as if a recipient might rely on that behavior), but Section
5.3.2 and Section 5.4 only have it as RECOMMENDED.  Given my
understanding of the protocol, it seems that all routers need to receive
the DRLB-List in order to perform the GDR selection algorithm, in which
case the extra information about the addresses being sorted would not be
useful for the calculation.  That would actually suggest that we do not
need RFC 2119 keywords here, and could just say (as we do in Section
5.4) that it's recommended for the DR to use a deterministic procedure,
such as sorting.

I also think the text should be more clear in Section 5.3.2 about the
use of the Router Identifier as the "GDR Candidate Address".  I believe
(but am not certain) that the intended behavior is that the elected DR
use all the PIM Hellos it has received (from candidate GDRs) to assemble
the list of candidate "addresses", but instead of using the actual IP
addresses it uses the Router Identifier construction described here when
assembling the "GDR Candidate Address(es)" field.  The current text
leaves unsaid what entity is performing this operation and how the PIM
Hello+Router Identifier corresponds to an entry in the list of
addresses.  Furtheremore, for the IPv6 case, it seems like this
substitution procedure interacts very poorly with the masking procedure
when the network includes a mix of routers that do/don't send a Router
ID (as it may not be possible to set a 32-bit contiguous mask that
captures the varying parts of IPv6 router addresses and the space
reserved here for "Router ID").

I'm concerned about hash algorithm agility (in the vein of BCP 201,
though since this is not a cryptographic hash that BCP does not strictly
speaking apply), as the rtg-dir review noted.  Specifically, each router
has to commit in its Hello to a single hash algorithm, so transitioning
to a new algorithm will require accepting reduced functionality during
the transition period (a reduced list of potential GDR candidates),
which is contrary to the goals of algorithm negotiation espoused in BCP
201.  Is this not a significant concern for this use case?  I see that
Section 6 attempts to disclaim discussion of algorithm migration, but I
am not yet convinced that it is appropriate to do so.

Please also remove from Section 5.7 the stale statement referring to the
previous section (see COMMENT).


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the Backward Compatibility section; it's great to see that
covered explicitly!

Per the rtg-dir review, please clarify that each router advertises at
most one Hash Algorithm at any given time (or how a multi-algorithm
scenario would work).

Limiting the GDR candidates to those with the same (highest) priority as
the PIM DR seems like it will in practice encourage having multiple
routers advertise the same priority value (if that is not already the
case).  Are there any operational considerations or risks in having to
use the IP-address tie-breaker more often for the non-GDR-capable
routers?

Section 1

Interesting to 1-index the routers but 0-index the links in Figure 2.

Section 3

   The extension specified in this document applies to PIM-SM when they
   act as last hop routers (there are directly connected receivers).  It

nit: this sentence makes more sense when I insert the word "routers"
after "PIM-SM".

   does not alter the behavior of a PIM DR, or any other routers, on the
   first hop network (directly connected sources).  This is because the
   source tree is built using the IP address of the sender, not the IP
   address of the PIM DR that sends the registers towards the RP.  The
   load balancing between first hop routers can be achieved naturally if
   an IGP provides equal cost multiple paths (which it usually does in
   practice).  Also distributing the load to do registering does not
   justify the additional complexity required to support it.

In this last sentence, does "registering" refer to setting up the sender
or the registration of receivers from DR to RP?

Section 4

   In order to share forwarding load among last hop routers, besides the
   normal PIM DR election, the GDR is also elected on the multi-access
   LAN.  There is only one PIM DR on the multi-access LAN, but there
   might be multiple GDR Candidates.

nit: this reads as if there is only a single GDR per LAN the same way
that there is only one PIM DR.  But my understanding is that the GDR is
per-group, so perhaps a wording tweak is in order, even given the
exposition in the following paragraph.

   A Hash Algorithm based on the announced Source, Group, or RP masks
   allows one GDR to be assigned to a corresponding multicast state.
   And that GDR is responsible for initiating the creation of the
   multicast forwarding tree for multicast traffic.

nit: s/And that/That/

Section 5.1

Do we expect the hash masks to be a contiguous set of bits (i.e., not
0xf0f0f0f0)?

   The DRLB-List Hello Option contains a list of GDR Candidates.  The
   first one listed has ordinal number 0, the second listed ordinal
   number 1, and the last one has ordinal number N - 1 if there are N
   candidates listed.  The hash value computed will be the ordinal
   number of the GDR Candidate that is acting as GDR.

nit: I suggest "acting as GDR for the flow in question".

I would also consider having some lead-in text to introduce the purpose
of the bulleted list that follows, perhaps something like "the input to
be hashed is determined according to the following procedure:".

Section 5.2

I suspect that the "keeping only the last 32 bits of the result" step
could result in pathological behavior for certain IPv6 addressing
schemes; this risk should be discussed in the security considerations
(or the limitation removed).  Presumably any hash algorithm more
complicated than modulo would not need this step of trimming down to 32
bits, too?

Please define (e.g., by reference to a specific version of the C
language) the notation used for these calculations.  (I note that the
algorithm applied to IPv6 addresses would require a 128-bit unsigned
integer type.)

Section 5.3

   All PIM routers include a new option, called "Load Balancing
   Capability (DRLB-Cap)" in their PIM Hello messages.

nit: I suggest a minor rewording to """PIM routers include a new option,
called "Load Balancing Capability (DRLB-Cap)" in their PIM Hello
messages, to indicate support for this specification""".  (With the
current text the reader is responsible for scoping the "All PIM routers"
to "ones that implement this specificiation.)

   Besides this DRLB-Cap Hello Option, the elected PIM DR also includes
   a new "DR Load Balancing List (DRLB-List) Hello Option".  The DRLB-
   List Hello Option consists of three Hash Masks as defined above and
   also a sorted list of GDR Candidate addresses on the LAN.

Would you mind pointing me at the part of RFC 7761 that describes the
procedure/delay used by a router to determine that it is the DR (and
thus, when it should start sending DRLB-List)?  It's not entirely clear
that we'd need to include that reference in this document, but I'd like
to sate my curiousity.

Section 5.3.1

      Hash Algorithm: Hash Algorithm type. 0 for the Modulo algorithm
      defined in this document.

Maybe mention the registry again here?

Section 5.3.2

         This DRLB-List Hello Option MUST only be advertised by the
         elected PIM DR.  It MUST be ignored if received from a non-DR.
         The option MUST also be ignored if the hash masks are not the
         correct number of bits, or GDR Candidate addresses are in the
         wrong address family.

I'm not sure that any of the cases listed in the last sentence are
reliably detectable.

Section 5.4

   the order in which the DR learns of new candidates.  Note that, as
   non-DR routers, the DR also advertises the DRLB-Cap Hello Option to
   indicate its ability to support the new functionality and the type of
   GDR election Hash Algorithm.

nits: "as for non-DR routers", "the type of GDR election Hash Algorithm
it uses"

Section 5.6

The requirement in step 1 to run the Hash Algorithm for all groups with
local receiver interest seems to imply that all GDR candidates must
track and store local receiver interest for all groups, as opposed to
without this extension where only the DR strictly needs to do so.  I
imagine that generally all/most routers will be tracking this
information, though, so in practice this will not be an additional
operational burden [that would need to be documented].  But this is not
my area of expertise, so please correct me if I'm wrong!

Section 5.7

   When a router stops acting as the GDR for a group, or source and
   group pair if SSM, it MUST set the Assert metric preference to
   maximum (0x7FFFFFFF) and the Assert metric to one less than maximum
   (0xFFFFFFFE).  This was also mentioned in the previous section.  That

This was not mentioned in the previous section.

Section 6

   An administrator needs to consider what the total bandwidth
   requirements are and find a set of routers that together has enough
   total capacity, while making sure that each of the routers can handle
   its part, assuming that the traffic is distributed roughly equally
   among the routers.  Ideally, one should also have enough bandwidth to

In a scenario where an attacker can create groups or control how some
amount of traffic is split across groups, this assumption of roughly
equal distribution will not hold.  Please discuss this in the security
considerations.

   The default masks will use the entire group addresses, and source
   addresses if SSM, as part of the hash.  An administrator may set

(side note: of course, the only hash algorithm currently defined will
only use the last 32 bits of IPv6 addresses)