PIM Designated Router Load Balancing
Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
Benjamin Kaduk 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).
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)
Alvaro Retana Yes
Deborah Brungard No Objection
Alissa Cooper No Objection
Roman Danyliw No Objection
I support Ben Kaduk's DISCUSS position.
Suresh Krishnan No Objection
Warren Kumari No Objection
Thank you for this document -- I found it easy to read and helpful. I'd note that the document has 6 authors instead of the "recommended" 5 -- I don't care, just noting it. Also, please see the OpsDir review ( https://datatracker.ietf.org/doc/review-ietf-pim-drlb-13-opsdir-lc-clarke-2019-10-30/ ) for some useful editorial fixes.
Mirja Kühlewind No Objection
Please have a look at the TSV-ART review, there is an editorial suggestion that might be worth considering (and thanks Michael for the TSV-ART review!).
Barry Leiba No Objection
Some very minor comments: Please expand “PIM-SM” on first use in both the Abstract and the Introduction. This allows the forwarding of multicast packets to be restricted only to segments leading to receivers who have indicated their interest in multicast groups using either IGMP or MLD. Nit: Let’s not personify our devices: please change “who” to “that”. However, if there was a way that allowed multiple routers to forward to the LAN for different groups, failure of one of the Nit: “if there were a way”, subjunctive mood with a conditional. — Section 3 — The extension specified in this document applies to PIM-SM when they act as last hop routers (there are directly connected receivers). I can’t find the antecedent to “they”; what is it? It looks like it’s “PIM-SM”, but that’s not something that can be “they”, is it? Maybe you mean to say “PIM-SM routers”? — Section 4 — 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. “Hash Algorithm” might do well to include a forward reference to Section 5.1.
Alexey Melnikov No Objection
Adam Roach No Objection
Please consider formatting IPv6 address as per the recommendations in RFC 5952, and section 4.3 of that document (https://tools.ietf.org/html/rfc5952#section-4.3) in particular.
Martin Vigoureux No Objection
Éric Vyncke No Objection
Thank you for the work put into this document. The short document is easy to read. I have one COMMENT and one NIT below, feel free to ignore them. Regards, -éric == COMMENT == -- Section 5.1 -- Some more explanations about "These default values are likely acceptable" would be welcome. == NIT == -- Section 1 -- s/ on behalf of any local members/on behalf of all local members/ ?