Re: [pim] AD Review of draft-ietf-pim-drlb-10 (now -11)

[Alvaro Retana <[e-mail]>]

On October 11, 2019 at 5:58:54 PM, Stig Venaas
([e-mail](mailto:[e-mail])) wrote:

Stig:

Hi!

> I've posted a version 11 which I think addresses your comments. Please
> see my comments inline though.

I think we’re on the right track. :-)

I put below comments from reviewing -11. In there I have several
editorial suggestions to clarify and simplify, and some major issues.


> Dear WG, there are a ton of changes, so please have a look at this
> latest version and see if you have any concerns.

I’ll wait for an updated version, or a week, whichever comes later, to
give the WG a chance to digest the changes.


Also, please address the questions on the list after the publication of -11 [1].


Thanks!


Alvaro.


[1] https://mailarchive.ietf.org/arch/msg/pim/8BTQtPw4QqQPPY6zbv5NMJF0dyI



[Line numbers form idnits.]

...
183	2.  Terminology
...
196	   o  GDR: Group Designated Router.  For each multicast flow, either a
197	      (*,G) for Any-Source Multicast (ASM), or an (S,G) for Source-
198	      Specific Multicast (SSM) [RFC4607], a hash algorithm (described
199	      below) is used to select one of the routers as a GDR.  The GDR is
200	      responsible for initiating the forwarding tree building process
201	      for the corresponding multicast flow.

s/hash algorithm/Hash Algorithm/g  To be consistent with the name of the field.


...
220	4.  Functional Overview
...
237	   For each multicast flow, that is, (*,G) for ASM and (S,G) for SSM, a
238	   hash algorithm is used to select one of the routers to be the GDR.  A
239	   new DR Load Balancing Capability (DRLB-Cap) PIM Hello Option, which
240	   contains hash algorithm type, is announced by routers on interfaces
241	   where this specification is enabled.  Routers with the new DRLB-Cap
242	   Option advertised in their PIM Hello, using the same GDR election
243	   hash algorithm and the same DR priority as the PIM DR, are considered
244	   as GDR Candidates.

[minor] There are still places where text like "this specification is
enabled" exists.  I'm suggesting changes...as mentioned before, it is
not necessarily bad/wrong...

NEW>
   For each multicast flow, that is, (*,G) for ASM and (S,G) for SSM, a hash
   algorithm is used to select one of the routers to be the GDR.  The new DR
   Load Balancing Capability (DRLB-Cap) PIM Hello Option is used to announce
   the hash algorithm type.  Routers with the new DRLB-Cap Option advertised in
   their PIM Hello, using the same GDR election hash algorithm and the same DR
   priority as the PIM DR, are considered as GDR Candidates.



...
280	5.1.  Hash Mask and Hash Algorithm

282	   A Hash Mask is used to extract a number of bits from the
283	   corresponding IP address field (32 for IPv4, 128 for IPv6) and
284	   calculate a hash value.  A hash value is used to select a GDR from
285	   GDR Candidates advertised by PIM DR.  For example, 0.0.255.0 defines
286	   a Hash Mask for an IPv4 address that masks the first, the second, and
287	   the fourth octets.  Hash masks allow for certain flows to always be
288	   forwarded by the same GDR, since the hash values are the same.  For
289	   instance the mask 0.0.255.0 means that only the third octet will be
290	   considered when hashing.

NEW>
   A Hash Mask is used to extract a number of bits from the corresponding IP
   address field (32 for IPv4, 128 for IPv6) and calculate a hash value.  A
   hash value is used to select a GDR from GDR Candidates advertised by the PIM
   DR, allowing for certain flows to always be forwarded by the same GDR, if
   the hash values are the same.  For example, 0.0.255.0 defines a Hash Mask
   for an IPv4 address that masks the first, the second, and the fourth octets,
   which means that only the third octet will be considered when hashing.


...
336	   If different hash algorithms are advertised among the routers on a
337	   LAN, only the outers advertising the same hash algorithm as the DR
338	   (as well as having the same DR priority as the DR) are eligible for
339	   GDR election.

[nit] s/the outers/the routers


...
386	5.2.1.  Modulo Hash Algorithm Example

[nit] An IPv6 example would be nice.


...
425	5.3.  PIM Hello Options

427	   When a PIM router sends a PIM Hello on an interface with this
428	   specification enabled, it includes a new option, called "Load
429	   Balancing Capability (DRLB-Cap)".

[] NEW>
   All PIM routers include a new option, called "Load Balancing Capability
   (DRLB-Cap)" in their PIM Hellos.


...
460	5.3.2.  PIM DR Load Balancing List (DRLB-List) Hello Option

462	     0                   1                   2                   3
463	     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
464	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
465	     |           Type = 35           |         Length                |
466	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
467	     |                          Group Mask                           |
468	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
469	     |                          Source Mask                          |
470	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
471	     |                            RP Mask                            |
472	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
473	     |                    GDR Candidate Address(es)                  |
474	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
495	      GDR Address (32/128 bits): Address(es) of GDR Candidate(s)

[minor] s/GDR Address (32/128 bits): Address(es) of GDR
Candidate(s)/GDR Candidate Address(es) (32/128 bits): List of GDR
Candidate(s)

497	         All addresses MUST be in the same address family as the PIM
498	         Hello IP header.  It is RECOMMENDED that the addresses are
499	         sorted in descending order.

[major] What should a receiver do if the addresses or masks don't
match the IP header?  Ignore the option?

501	         If the "Interface ID" option, as specified in [RFC6395], is
502	         present in a GDR Candidate's PIM Hello message, and the "Router
503	         ID" portion is non-zero:

[minor] rfc6395 uses "Router Identifier" (and not "Router ID").


...
520	5.4.  PIM DR Operation

522	   The DR election process is still the same as defined in [RFC7761].  A
523	   DR that has this specification enabled on an interface advertises the
524	   new DRLB-List Hello Option, which contains mask values from user
525	   configuration (or default values), followed by a list of GDR
526	   Candidate Addresses.  It is RECOMMENDED that the list is sorted, from
527	   the highest value to the lowest value.  The reason for sorting the
528	   list is to make the behavior deterministic, regardless of the order
529	   the DR learns of new candidates.  Note that same as non-DR routers,
530	   the DR also advertises DRLB-Cap Hello Option to indicate its
531	   capability of supporting this specification and the type of its GDR
532	   election hash algorithm.

[] NEW>
   The DR election process is still the same as defined in [RFC7761].  The DR
   advertises the new DRLB-List Hello Option, which contains mask values from
   user configuration (or default values), followed by a list of GDR Candidate
   Addresses.  It is RECOMMENDED that the list be sorted, from the highest
   value to the lowest value.  The reason for sorting the list is to make the
   behavior deterministic, regardless of 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.

534	   If a PIM DR receives a neighbor DRLB-Cap Hello Option, which contains
535	   the same hash algorithm as the DR, and the neighbor has the same DR
536	   priority as the DR, PIM DR SHOULD consider the neighbor as a GDR
537	   Candidate and insert the GDR Candidate' Address into the list of the
538	   DRLB-List Option.  However, the DR may have policies limiting which
539	   GDR Candidates, or the number of GDR Candidates to include.  The DR
540	   would normally include itself in the list of GDR Candidates.

[major] "The DR would normally include itself in the list of GDR
Candidates."  Why is this statement not Normative?  What are the
conditions under which the DR would not include itself?

542	   If a PIM neighbor included in the list expires, stops announcing the
543	   DRLB-Cap Hello Option, changes DR priority, changes hash algorithm or
544	   otherwise becomes ineligibile as a candidate, the DR should
545	   immediately send a triggered hello with a new list in the DRLB-List
546	   option, excluding the neighbor.

[nit] s/ineligibile/ineligible

[major] s/should immediately/SHOULD immediately   Is there any reason
to not make this statement Normative...specially if the alternative
action (below) is?

548	   If a new router becomes eligible as a candidate, there is no urgency
549	   in sending out an updated list.  An updated list SHOULD be included
550	   in the next hello.

552	5.5.  PIM GDR Candidate Operation

554	   When an IGMP/MLD report is received, without this specification, only
555	   the PIM DR will handle the join and potentially run into the issues
556	   described earlier.  Using this specification, a hash algorithm is
557	   used by the GDR Candidates to determine which router is going to be
558	   responsible for building forwarding trees on behalf of the host.

[]NEW>
   When an IGMP/MLD report is received, a Hash Algorithm is used by the GDR
   Candidates to determine which router is going to be responsible for building
   forwarding trees on behalf of the host.

560	   If this specification is enabled on an interface, the router MUST
561	   include the DRLB-Cap Hello Option in all PIM Hello messages sent on
562	   that interface.  Note that the presence of the DRLB-Cap Option in PIM
563	   Hello does not guarantee that this router would be considered as a
564	   GDR candidate.  Once DR election is done, the DRLB-List Hello Option
565	   would be received from the current PIM DR on the link which would
566	   contain a list of GDRs Candidates selected by the PIM DR.

[]NEW>
   The router MUST include the DRLB-Cap Hello Option in all PIM Hello messages
   sent on the interface.  Note that the presence of the DRLB-Cap Option in the
   PIM Hello does not guarantee that the router will be considered as a GDR
   candidate.  Once the DR election is done, the DRLB-List Hello Option is
   received from the current PIM DR containing a list of the selected GDRs
   Candidates.

568	   A router only acts as a GDR Candidate if it is included in the GDR
569	   Candidate list of the DRLB-List Hello Option.  See next section for
570	   details.

572	5.6.  DRLB-List Hello Option Processing

574	   This section discusses processing of the DRLB-List Hello Option.  All
575	   routers MUST ignore the DRLB-List Hello Option if it is received from
576	   a PIM router which is not the DR.  The option MUST only be processed
577	   by routers that are announcing the DRLB-Cap Option.  Also, the
578	   algorithm announced in the DRLB-Cap Option, MUST be the same as what
579	   was announced by the DR.  All GDR Candidates MUST use the Hash Masks
580	   advertised in the Option, even if they differ from those the
581	   candidate was configured with.

[major] "Also, the algorithm announced in the DRLB-Cap Option, MUST be
the same as what was announced by the DR."  This sentence seems to say
that the algorithms MUST be the same...in order to process the
DRLB-List Hello Option.  IOW, if the GDR didn't advertise the same
algorithm as the DR, then it won't process the list.  That has been
stressed in several places...

OLD>
                                      The option MUST only be processed
   by routers that are announcing the DRLB-Cap Option.  Also, the
   algorithm announced in the DRLB-Cap Option, MUST be the same as what
   was announced by the DR.

NEW>
   The option MUST only be processed by routers that announce the DRLB-Cap
   Option, and if the Hash Algorithm announced by the DR is the same as the
   local announcement.


[major] What if the receiver's address is listed in the DRLB-List, but
the advertised hash algorithms don't match?  Even though it is
specified in several places that the hash algorithms must be the same,
there's a possibility (bug, attack) that the algorithms don't match.
If a Candidate GDR that didn't advertise the same algorithm as the DR
is in the list, then some flows may end up orphaned.

I don't think that this effect (orphaned flows) is fully covered in
the Security section...


583	   A router stores the latest option contents that was announced, if
584	   any, and deletes the previous contents.  The router MUST also compare
585	   the new contents with any previous contents, and if there are any
586	   changes, continue processing as below.  Note that if the option does
587	   not pass the above checks, the below processing MUST be done as if
588	   the option was not announced.

590	   If the contents of the DRLB-List Option, the masks or the candidate
591	   list, differs from the previously saved copy, it is received for the
592	   first time, or it is no longer being received or accepted, the option
593	   MUST be processed as below.

[] I'm not sure how processing can be done "if the option was not
announced", or if it is "no longer being received or accepted".  In
general, there seem to be 3 cases (as mentioned below): the GDR is new
to the list, it is still in a list, or it is not listed anymore.

Also, instructions for the DR (it creates the list, but doesn't
receive the Option) are missing.

NEW>
   A router MUST keep track of the state of its local address in the received
   GDR Candidate Address(es) field, and of whether it is a GDR for group, or
   source and group pair if SSM, and take the appropriate action as described
   below.  The DR MUST also process its own DRLB-List Hello Option.


595	   1.  If the router was not included in the previous GDR list, or there
596	       was no previous GDR list, but it is included in the new GDR list,
597	       the router MUST for each of the groups, or source and group pairs
598	       if the group is in SSM mode, with local receiver interest, run
599	       the hash algorithm to determine which of them it is the GDR for.

601	          If it is not the GDR for a group, or source and group pair if
602	          SSM, no processing is required.

604	          If it is hashed as the GDR, it needs to build a multicast
605	          forwarding tree.

607	   2.  If the router was included in the previous GDR list, and still is
608	       included in the new GDR list: The router MUST for each of the
609	       groups, or source and group pairs if the group is in SSM mode,
610	       with local receiver interest, run the hash algorithm to determine
611	       which of them it is the GDR for.

613	          If it was the GDR for a group, or source and group pair if
614	          SSM, and the new hash result chose it as the GDR, then no
615	          processing is required.

617	          If it was the GDR for a group, or source and group pair if
618	          SSM, earlier and now it is no longer the GDR, then it sets the
619	          assert metric preference to maximum (0x7FFFFFFF) and the
620	          assert metric to one less than maximum (0xFFFFFFFE), as
621	          explained in [Section 5.7].

623	          If it was not the GDR for a group, or source and group pair if
624	          SSM, earlier, and the new hash does not make it GDR, then no
625	          processing is required.

627	          If it was not the GDR for an earlier group, or source and
628	          group pair if SSM, and now becomes the GDR, it starts building
629	          multicast forwarding tree for this flow.

631	   3.  If the router was included in the previous GDR list, but is not
632	       included in the new GDR list, or there is no new GDR list: The
633	       router MUST for each of the groups, or source and group pairs if
634	       the group is in SSM mode, with local receiver interest do as
635	       follows.

637	          If it was the GDR for a group, or source and group pair if
638	          SSM, it sets the assert metric preference to maximum
639	          (0x7FFFFFFF) and the assert metric to one less than maximum
640	          (0xFFFFFFFE), as explained in [Section 5.7].

642	          If it was not the GDR, then no processing is required.


[]NEW>
   1.  If the local router is included in the GDR Candidate Address(es) field,
       for each of the groups, or source and group pairs if the group is in SSM
       mode, with local receiver interest, the router MUST run the Hash
       Algorithm to determine which of them it is the GDR for.

          If there is no change in the GDR status, then no further action is
          required.

          If the router becomes the new GDR, then a multicast forwarding tree
          MUST be built [RFC7761].

          If the router is no longer the GDR, then it uses an Assert as
          explained in Section 5.7.

   2.  If the local router is not included in the GDR Candidate Address(es)
       field, or if the DRLB-List Hello Option is no longer included in the
       DR's Hello, or if the DR's Neighbor Liveness Timer expires [RFC7761],
       for each of the groups, or source and group pairs if the group is in SSM
       mode, with local receiver interest, for which the router is the GDR, it
       uses an Assert as explained in Section 5.7.


644	5.7.  PIM Assert Modification

646	   GDR changes may occur due to configuration change, due to GDR
647	   candidates going down, and also new routers coming up and becoming
648	   GDR candidates.  This may occur while flows are being forwarded.  If
649	   the GDR for an active flow changes, there is likely to be some
650	   disruption, such as packet loss or duplicates.  By using asserts,
651	   packet loss is minimized, while allowing a small amount of
652	   duplicates.

[minor] s/assert/Assert/g

654	   When a router stops acting as the GDR for a group, or source and
655	   group pair if SSM, it MUST set the assert metric preference to
656	   maximum (0x7FFFFFFF) and the assert metric to one less than maximum
657	   (0xFFFFFFFE).  This was also mentioned in the previous section.  That
658	   is, whenever it sends or receives an assert for the group, it must
659	   use these values as the metric preference and metric rather than the
660	   values provided by routing.  This is similar to what is done for
661	   AssertCancel Messages in [RFC7761], except that the metric value here
662	   is one less.

[nit] s/This was also mentioned in the previous section./

[minor] s/values provided by routing./values provided by the unicast
routing protocol.

[nit] I would take out the last sentence.


...
681	   Using the above example, for G1, assume R1 and R3 agree on the new
682	   GDR, which is R3.  With the new assert behavior, R1 sets its assert
683	   metric to the near maximum value discussed above.  That will make R3,
684	   which has normal metric in its Assert as the Assert winner.

[minor] We don't have to "assume R1 and R3 agree", that's what this
document is for! :-)

NEW>
   For G1, using the functionality described in this document, R1 and R3
   determine the new GDR, which is R3.  With the modified Assert behavior, R1
   sets its Assert metric to the near maximum value discussed above.  That will
   make R3, which has normal metric in its Assert as the Assert winner.

686	   For G2, assume it takes a slightly longer time for R2 to find out
687	   that R3 is the new GDR and still considers itself being the GDR while
688	   R3 already has assumed the role of GDR.  Since both R2 and R3 think
689	   they are GDRs, they further compare their metric and IP addresses.
690	   If R3 has the better routing metric, or the same metric but a better
691	   tie-breaker, the result will be consistent during GDR selection.  If
692	   unfortunately, R2 has the better metric or the same metric but a
693	   better tie-breaker, R2 will become the Assert winner and continues to
694	   forward traffic.  Shortly after when R2 finds out that it is no
695	   longer the GDR, R2 will change to using the near maximum assert
696	   metric.  Next time R2 sends an assert message, it will lose the
697	   assert and stop forwarding.  As assert winner, R2 would send periodic
698	   assert messages per [RFC7761].

[nit] I don't like this second part of the example because it now
opens questions about why did R2 not receive a Hello...etc.. Up to you
if you want to keep it.

700	5.8.  Backward Compatibility

702	   In the case of a hybrid Ethernet shared LAN (where some PIM routers
703	   enable the specification defined in this document, and some do not).

705	   o  If a router which does not support this specification becomes the
706	      DR on the LAN, then it is the only router acting as a DR, and
707	      there will be no load-balancing.

709	   o  If a router which does not support this specification becomes a
710	      non-DR on link, then it acts as non-DR defined in [RFC7761], and
711	      it will not take part in any load-balancing.  Load-balancing may
712	      still happen.

[]NEW>
   In the case of a hybrid Ethernet shared LAN (where some PIM routers support
   the functionality defined in this document, and some do not);

   o  If the DR does not support the new functionality, then there will be no
   load-balancing.

   o  If non-DR routers do not support the new functionality, they will not be
   considered as Candidate GDRs and it will not take part in an
   load-balancing.  Load-balancing may still happen on the link.


714	6.  Manageability Considerations

[minor] s/Manageability/Operational

716	   An administrator needs to consider what the total bandwidth
717	   requirements are and find a set of routers that together has enough
718	   total capacity, while making sure that each of the router can handle
719	   its part, assuming that the traffic is distributed roughly equally
720	   among the routers.  Ideally, one should also have enough bandwidth to
721	   handle the case where at least one router fails.  Ideally all the
722	   routers should have reachability to the sources, and RPs if
723	   applicable, that is not via the LAN.

[nit] s/each of the router/each of the routers

[minor] s/Ideally all the routers should have reachability/All routers
should have reachability


...
822	10.2.  Informative References
...
844	   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
845	              Writing an IANA Considerations Section in RFCs", BCP 26,
846	              RFC 8126, DOI 10.17487/RFC8126, June 2017,
847	              <https://www.rfc-editor.org/info/rfc8126>.

[major] This reference must be normative.