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

[Stig Venaas <[e-mail]>]

Hi

Thanks for a lot of good comments. I've addressed all of them I
believe, except in 5.6 where I feel we still need to keep some of the
previous details.

You made this comment: I'm not sure how processing can be done "if the
option was not announced".
It is important to do processing when a hello is received and the
option is no longer present. I tried to maybe make it clearer by
adding a sentence at the beginning of 5.6:
   This section discusses processing of the DRLB-List Hello Option,
   including the case where it was received in the previous hello,
   but not in the current hello.

Is that good enough? Otherwise, I guess I could change it to
processing of Hello messages, and talk about how they are processed
depending on whether the option is present etc.

Please let me know what you think of revision 12. It should be close
to what you want...

Thanks,
Stig

On Fri, Oct 18, 2019 at 11:36 AM Alvaro Retana <[e-mail]> wrote:
>
> 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.