From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <CAHANBtLQL9R_qVciqyDTGtJHdW+gicXgX4JtCyeeV2okN-fgyQ@mail.gmail.com>
References: <CAMMESszYeVa9_2EMQjNCUP-8PzK3g_Zbv0cQ5vi7nA8j4Kp9Fw@mail.gmail.com>
 <CAHANBtLQL9R_qVciqyDTGtJHdW+gicXgX4JtCyeeV2okN-fgyQ@mail.gmail.com>
MIME-Version: 1.0
Date: Fri, 18 Oct 2019 11:36:01 -0700
Message-ID: <CAMMESsyzw7We7xvHkWjEBrTSsXRQdAWZ4P853zqrB1S7LOgeBw@mail.gmail.com>
To: Stig Venaas <stig@venaas.com>
Cc: pim-chairs@ietf.org, draft-ietf-pim-drlb@ietf.org, 
 Mike McBride <mmcbride7@gmail.com>, pim@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/jmnAu-EIa2nDIE-SoLu87BBSYkA>
Subject: Re: [pim] AD Review of draft-ietf-pim-drlb-10 (now -11)
Precedence: list

On October 11, 2019 at 5:58:54 PM, Stig Venaas
(stig@venaas.com(mailto:stig@venaas.com)) wrote:

Stig:

Hi!

> I've posted a version 11 which I think addresses your comments. Please
> see my comments inline though.

I think we=E2=80=99re 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=E2=80=99ll 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. =C2=A0Terminology
...
196	 =C2=A0 o =C2=A0GDR: Group Designated Router. =C2=A0For each multicast =
flow, either a
197	 =C2=A0 =C2=A0 =C2=A0(*,G) for Any-Source Multicast (ASM), or an (S,G) =
for Source-
198	 =C2=A0 =C2=A0 =C2=A0Specific Multicast (SSM) [RFC4607], a hash algorit=
hm (described
199	 =C2=A0 =C2=A0 =C2=A0below) is used to select one of the routers as a G=
DR. =C2=A0The GDR is
200	 =C2=A0 =C2=A0 =C2=A0responsible for initiating the forwarding tree bui=
lding process
201	 =C2=A0 =C2=A0 =C2=A0for the corresponding multicast flow.

s/hash algorithm/Hash Algorithm/g =C2=A0To be consistent with the name of t=
he field.


...
220	4. =C2=A0Functional Overview
...
237	 =C2=A0 For each multicast flow, that is, (*,G) for ASM and (S,G) for S=
SM, a
238	 =C2=A0 hash algorithm is used to select one of the routers to be the G=
DR. =C2=A0A
239	 =C2=A0 new DR Load Balancing Capability (DRLB-Cap) PIM Hello Option, w=
hich
240	 =C2=A0 contains hash algorithm type, is announced by routers on interf=
aces
241	 =C2=A0 where this specification is enabled. =C2=A0Routers with the new=
 DRLB-Cap
242	 =C2=A0 Option advertised in their PIM Hello, using the same GDR electi=
on
243	 =C2=A0 hash algorithm and the same DR priority as the PIM DR, are cons=
idered
244	 =C2=A0 as GDR Candidates.

[minor] There are still places where text like "this specification is
enabled" exists. =C2=A0I'm suggesting changes...as mentioned before, it is
not necessarily bad/wrong...

NEW>
=C2=A0 =C2=A0For each multicast flow, that is, (*,G) for ASM and (S,G) for =
SSM, a hash
=C2=A0 =C2=A0algorithm is used to select one of the routers to be the GDR. =
=C2=A0The new DR
=C2=A0 =C2=A0Load Balancing Capability (DRLB-Cap) PIM Hello Option is used =
to announce
=C2=A0 =C2=A0the hash algorithm type. =C2=A0Routers with the new DRLB-Cap O=
ption advertised in
=C2=A0 =C2=A0their PIM Hello, using the same GDR election hash algorithm an=
d the same DR
=C2=A0 =C2=A0priority as the PIM DR, are considered as GDR Candidates.



...
280	5.1. =C2=A0Hash Mask and Hash Algorithm

282	 =C2=A0 A Hash Mask is used to extract a number of bits from the
283	 =C2=A0 corresponding IP address field (32 for IPv4, 128 for IPv6) and
284	 =C2=A0 calculate a hash value. =C2=A0A hash value is used to select a =
GDR from
285	 =C2=A0 GDR Candidates advertised by PIM DR. =C2=A0For example, 0.0.255=
.0 defines
286	 =C2=A0 a Hash Mask for an IPv4 address that masks the first, the secon=
d, and
287	 =C2=A0 the fourth octets. =C2=A0Hash masks allow for certain flows to =
always be
288	 =C2=A0 forwarded by the same GDR, since the hash values are the same. =
=C2=A0For
289	 =C2=A0 instance the mask 0.0.255.0 means that only the third octet wil=
l be
290	 =C2=A0 considered when hashing.

NEW>
=C2=A0 =C2=A0A Hash Mask is used to extract a number of bits from the corre=
sponding IP
=C2=A0 =C2=A0address field (32 for IPv4, 128 for IPv6) and calculate a hash=
 value. =C2=A0A
=C2=A0 =C2=A0hash value is used to select a GDR from GDR Candidates adverti=
sed by the PIM
=C2=A0 =C2=A0DR, allowing for certain flows to always be forwarded by the s=
ame GDR, if
=C2=A0 =C2=A0the hash values are the same. =C2=A0For example, 0.0.255.0 def=
ines a Hash Mask
=C2=A0 =C2=A0for an IPv4 address that masks the first, the second, and the =
fourth octets,
=C2=A0 =C2=A0which means that only the third octet will be considered when =
hashing.


...
336	 =C2=A0 If different hash algorithms are advertised among the routers o=
n a
337	 =C2=A0 LAN, only the outers advertising the same hash algorithm as the=
 DR
338	 =C2=A0 (as well as having the same DR priority as the DR) are eligible=
 for
339	 =C2=A0 GDR election.

[nit] s/the outers/the routers


...
386	5.2.1. =C2=A0Modulo Hash Algorithm Example

[nit] An IPv6 example would be nice.


...
425	5.3. =C2=A0PIM Hello Options

427	 =C2=A0 When a PIM router sends a PIM Hello on an interface with this
428	 =C2=A0 specification enabled, it includes a new option, called "Load
429	 =C2=A0 Balancing Capability (DRLB-Cap)".

[] NEW>
=C2=A0 =C2=A0All PIM routers include a new option, called "Load Balancing C=
apability
=C2=A0 =C2=A0(DRLB-Cap)" in their PIM Hellos.


...
460	5.3.2. =C2=A0PIM DR Load Balancing List (DRLB-List) Hello Option

462	 =C2=A0 =C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
463	 =C2=A0 =C2=A0 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	 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+
465	 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Type =3D 35 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 Length =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
466	 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+
467	 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Group Mask =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
468	 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+
469	 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Source Mask =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
470	 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+
471	 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RP Mask =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0|
472	 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+
473	 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0GDR Candidate Address(es) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
474	 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+
...
495	 =C2=A0 =C2=A0 =C2=A0GDR Address (32/128 bits): Address(es) of GDR Cand=
idate(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	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 All addresses MUST be in the same address =
family as the PIM
498	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hello IP header. =C2=A0It is RECOMMENDED t=
hat the addresses are
499	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sorted in descending order.

[major] What should a receiver do if the addresses or masks don't
match the IP header? =C2=A0Ignore the option?

501	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If the "Interface ID" option, as specified=
 in [RFC6395], is
502	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 present in a GDR Candidate's PIM Hello mes=
sage, and the "Router
503	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ID" portion is non-zero:

[minor] rfc6395 uses "Router Identifier" (and not "Router ID").


...
520	5.4. =C2=A0PIM DR Operation

522	 =C2=A0 The DR election process is still the same as defined in [RFC776=
1]. =C2=A0A
523	 =C2=A0 DR that has this specification enabled on an interface advertis=
es the
524	 =C2=A0 new DRLB-List Hello Option, which contains mask values from use=
r
525	 =C2=A0 configuration (or default values), followed by a list of GDR
526	 =C2=A0 Candidate Addresses. =C2=A0It is RECOMMENDED that the list is s=
orted, from
527	 =C2=A0 the highest value to the lowest value. =C2=A0The reason for sor=
ting the
528	 =C2=A0 list is to make the behavior deterministic, regardless of the o=
rder
529	 =C2=A0 the DR learns of new candidates. =C2=A0Note that same as non-DR=
 routers,
530	 =C2=A0 the DR also advertises DRLB-Cap Hello Option to indicate its
531	 =C2=A0 capability of supporting this specification and the type of its=
 GDR
532	 =C2=A0 election hash algorithm.

[] NEW>
=C2=A0 =C2=A0The DR election process is still the same as defined in [RFC77=
61]. =C2=A0The DR
=C2=A0 =C2=A0advertises the new DRLB-List Hello Option, which contains mask=
 values from
=C2=A0 =C2=A0user configuration (or default values), followed by a list of =
GDR Candidate
=C2=A0 =C2=A0Addresses. =C2=A0It is RECOMMENDED that the list be sorted, fr=
om the highest
=C2=A0 =C2=A0value to the lowest value. =C2=A0The reason for sorting the li=
st is to make the
=C2=A0 =C2=A0behavior deterministic, regardless of the order in which the D=
R learns of
=C2=A0 =C2=A0new candidates. =C2=A0Note that, as non-DR routers, the DR als=
o advertises the
=C2=A0 =C2=A0DRLB-Cap Hello Option to indicate its ability to support the n=
ew
=C2=A0 =C2=A0functionality and the type of GDR election Hash Algorithm.

534	 =C2=A0 If a PIM DR receives a neighbor DRLB-Cap Hello Option, which co=
ntains
535	 =C2=A0 the same hash algorithm as the DR, and the neighbor has the sam=
e DR
536	 =C2=A0 priority as the DR, PIM DR SHOULD consider the neighbor as a GD=
R
537	 =C2=A0 Candidate and insert the GDR Candidate' Address into the list o=
f the
538	 =C2=A0 DRLB-List Option. =C2=A0However, the DR may have policies limit=
ing which
539	 =C2=A0 GDR Candidates, or the number of GDR Candidates to include. =C2=
=A0The DR
540	 =C2=A0 would normally include itself in the list of GDR Candidates.

[major] "The DR would normally include itself in the list of GDR
Candidates." =C2=A0Why is this statement not Normative? =C2=A0What are the
conditions under which the DR would not include itself?

542	 =C2=A0 If a PIM neighbor included in the list expires, stops announcin=
g the
543	 =C2=A0 DRLB-Cap Hello Option, changes DR priority, changes hash algori=
thm or
544	 =C2=A0 otherwise becomes ineligibile as a candidate, the DR should
545	 =C2=A0 immediately send a triggered hello with a new list in the DRLB-=
List
546	 =C2=A0 option, excluding the neighbor.

[nit] s/ineligibile/ineligible

[major] s/should immediately/SHOULD immediately =C2=A0 Is there any reason
to not make this statement Normative...specially if the alternative
action (below) is?

548	 =C2=A0 If a new router becomes eligible as a candidate, there is no ur=
gency
549	 =C2=A0 in sending out an updated list. =C2=A0An updated list SHOULD be=
 included
550	 =C2=A0 in the next hello.

552	5.5. =C2=A0PIM GDR Candidate Operation

554	 =C2=A0 When an IGMP/MLD report is received, without this specification=
, only
555	 =C2=A0 the PIM DR will handle the join and potentially run into the is=
sues
556	 =C2=A0 described earlier. =C2=A0Using this specification, a hash algor=
ithm is
557	 =C2=A0 used by the GDR Candidates to determine which router is going t=
o be
558	 =C2=A0 responsible for building forwarding trees on behalf of the host=
.

[]NEW>
=C2=A0 =C2=A0When an IGMP/MLD report is received, a Hash Algorithm is used =
by the GDR
=C2=A0 =C2=A0Candidates to determine which router is going to be responsibl=
e for building
=C2=A0 =C2=A0forwarding trees on behalf of the host.

560	 =C2=A0 If this specification is enabled on an interface, the router MU=
ST
561	 =C2=A0 include the DRLB-Cap Hello Option in all PIM Hello messages sen=
t on
562	 =C2=A0 that interface. =C2=A0Note that the presence of the DRLB-Cap Op=
tion in PIM
563	 =C2=A0 Hello does not guarantee that this router would be considered a=
s a
564	 =C2=A0 GDR candidate. =C2=A0Once DR election is done, the DRLB-List He=
llo Option
565	 =C2=A0 would be received from the current PIM DR on the link which wou=
ld
566	 =C2=A0 contain a list of GDRs Candidates selected by the PIM DR.

[]NEW>
=C2=A0 =C2=A0The router MUST include the DRLB-Cap Hello Option in all PIM H=
ello messages
=C2=A0 =C2=A0sent on the interface. =C2=A0Note that the presence of the DRL=
B-Cap Option in the
=C2=A0 =C2=A0PIM Hello does not guarantee that the router will be considere=
d as a GDR
=C2=A0 =C2=A0candidate. =C2=A0Once the DR election is done, the DRLB-List H=
ello Option is
=C2=A0 =C2=A0received from the current PIM DR containing a list of the sele=
cted GDRs
=C2=A0 =C2=A0Candidates.

568	 =C2=A0 A router only acts as a GDR Candidate if it is included in the =
GDR
569	 =C2=A0 Candidate list of the DRLB-List Hello Option. =C2=A0See next se=
ction for
570	 =C2=A0 details.

572	5.6. =C2=A0DRLB-List Hello Option Processing

574	 =C2=A0 This section discusses processing of the DRLB-List Hello Option=
. =C2=A0All
575	 =C2=A0 routers MUST ignore the DRLB-List Hello Option if it is receive=
d from
576	 =C2=A0 a PIM router which is not the DR. =C2=A0The option MUST only be=
 processed
577	 =C2=A0 by routers that are announcing the DRLB-Cap Option. =C2=A0Also,=
 the
578	 =C2=A0 algorithm announced in the DRLB-Cap Option, MUST be the same as=
 what
579	 =C2=A0 was announced by the DR. =C2=A0All GDR Candidates MUST use the =
Hash Masks
580	 =C2=A0 advertised in the Option, even if they differ from those the
581	 =C2=A0 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." =C2=A0This sentence seems to say
that the algorithms MUST be the same...in order to process the
DRLB-List Hello Option. =C2=A0IOW, if the GDR didn't advertise the same
algorithm as the DR, then it won't process the list. =C2=A0That has been
stressed in several places...

OLD>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The option MUST=
 only be processed
=C2=A0 =C2=A0by routers that are announcing the DRLB-Cap Option. =C2=A0Also=
, the
=C2=A0 =C2=A0algorithm announced in the DRLB-Cap Option, MUST be the same a=
s what
=C2=A0 =C2=A0was announced by the DR.

NEW>
=C2=A0 =C2=A0The option MUST only be processed by routers that announce the=
 DRLB-Cap
=C2=A0 =C2=A0Option, and if the Hash Algorithm announced by the DR is the s=
ame as the
=C2=A0 =C2=A0local announcement.


[major] What if the receiver's address is listed in the DRLB-List, but
the advertised hash algorithms don't match? =C2=A0Even 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	 =C2=A0 A router stores the latest option contents that was announced, =
if
584	 =C2=A0 any, and deletes the previous contents. =C2=A0The router MUST a=
lso compare
585	 =C2=A0 the new contents with any previous contents, and if there are a=
ny
586	 =C2=A0 changes, continue processing as below. =C2=A0Note that if the o=
ption does
587	 =C2=A0 not pass the above checks, the below processing MUST be done as=
 if
588	 =C2=A0 the option was not announced.

590	 =C2=A0 If the contents of the DRLB-List Option, the masks or the candi=
date
591	 =C2=A0 list, differs from the previously saved copy, it is received fo=
r the
592	 =C2=A0 first time, or it is no longer being received or accepted, the =
option
593	 =C2=A0 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". =C2=A0In
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>
=C2=A0 =C2=A0A router MUST keep track of the state of its local address in =
the received
=C2=A0 =C2=A0GDR Candidate Address(es) field, and of whether it is a GDR fo=
r group, or
=C2=A0 =C2=A0source and group pair if SSM, and take the appropriate action =
as described
=C2=A0 =C2=A0below. =C2=A0The DR MUST also process its own DRLB-List Hello =
Option.


595	 =C2=A0 1. =C2=A0If the router was not included in the previous GDR lis=
t, or there
596	 =C2=A0 =C2=A0 =C2=A0 was no previous GDR list, but it is included in t=
he new GDR list,
597	 =C2=A0 =C2=A0 =C2=A0 the router MUST for each of the groups, or source=
 and group pairs
598	 =C2=A0 =C2=A0 =C2=A0 if the group is in SSM mode, with local receiver =
interest, run
599	 =C2=A0 =C2=A0 =C2=A0 the hash algorithm to determine which of them it =
is the GDR for.

601	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If it is not the GDR for a group, or=
 source and group pair if
602	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SSM, no processing is required.

604	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If it is hashed as the GDR, it needs=
 to build a multicast
605	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0forwarding tree.

607	 =C2=A0 2. =C2=A0If the router was included in the previous GDR list, a=
nd still is
608	 =C2=A0 =C2=A0 =C2=A0 included in the new GDR list: The router MUST for=
 each of the
609	 =C2=A0 =C2=A0 =C2=A0 groups, or source and group pairs if the group is=
 in SSM mode,
610	 =C2=A0 =C2=A0 =C2=A0 with local receiver interest, run the hash algori=
thm to determine
611	 =C2=A0 =C2=A0 =C2=A0 which of them it is the GDR for.

613	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If it was the GDR for a group, or so=
urce and group pair if
614	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SSM, and the new hash result chose i=
t as the GDR, then no
615	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0processing is required.

617	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If it was the GDR for a group, or so=
urce and group pair if
618	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SSM, earlier and now it is no longer=
 the GDR, then it sets the
619	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0assert metric preference to maximum =
(0x7FFFFFFF) and the
620	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0assert metric to one less than maxim=
um (0xFFFFFFFE), as
621	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0explained in [Section 5.7].

623	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If it was not the GDR for a group, o=
r source and group pair if
624	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SSM, earlier, and the new hash does =
not make it GDR, then no
625	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0processing is required.

627	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If it was not the GDR for an earlier=
 group, or source and
628	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0group pair if SSM, and now becomes t=
he GDR, it starts building
629	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0multicast forwarding tree for this f=
low.

631	 =C2=A0 3. =C2=A0If the router was included in the previous GDR list, b=
ut is not
632	 =C2=A0 =C2=A0 =C2=A0 included in the new GDR list, or there is no new =
GDR list: The
633	 =C2=A0 =C2=A0 =C2=A0 router MUST for each of the groups, or source and=
 group pairs if
634	 =C2=A0 =C2=A0 =C2=A0 the group is in SSM mode, with local receiver int=
erest do as
635	 =C2=A0 =C2=A0 =C2=A0 follows.

637	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If it was the GDR for a group, or so=
urce and group pair if
638	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SSM, it sets the assert metric prefe=
rence to maximum
639	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(0x7FFFFFFF) and the assert metric t=
o one less than maximum
640	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(0xFFFFFFFE), as explained in [Secti=
on 5.7].

642	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If it was not the GDR, then no proce=
ssing is required.


[]NEW>
=C2=A0 =C2=A01. =C2=A0If the local router is included in the GDR Candidate =
Address(es) field,
=C2=A0 =C2=A0 =C2=A0 =C2=A0for each of the groups, or source and group pair=
s if the group is in SSM
=C2=A0 =C2=A0 =C2=A0 =C2=A0mode, with local receiver interest, the router M=
UST run the Hash
=C2=A0 =C2=A0 =C2=A0 =C2=A0Algorithm to determine which of them it is the G=
DR for.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If there is no change in the GDR status,=
 then no further action is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 required.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If the router becomes the new GDR, then =
a multicast forwarding tree
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MUST be built [RFC7761].

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If the router is no longer the GDR, then=
 it uses an Assert as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 explained in Section 5.7.

=C2=A0 =C2=A02. =C2=A0If the local router is not included in the GDR Candid=
ate Address(es)
=C2=A0 =C2=A0 =C2=A0 =C2=A0field, or if the DRLB-List Hello Option is no lo=
nger included in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0DR's Hello, or if the DR's Neighbor Liveness Tim=
er expires [RFC7761],
=C2=A0 =C2=A0 =C2=A0 =C2=A0for each of the groups, or source and group pair=
s if the group is in SSM
=C2=A0 =C2=A0 =C2=A0 =C2=A0mode, with local receiver interest, for which th=
e router is the GDR, it
=C2=A0 =C2=A0 =C2=A0 =C2=A0uses an Assert as explained in Section 5.7.


644	5.7. =C2=A0PIM Assert Modification

646	 =C2=A0 GDR changes may occur due to configuration change, due to GDR
647	 =C2=A0 candidates going down, and also new routers coming up and becom=
ing
648	 =C2=A0 GDR candidates. =C2=A0This may occur while flows are being forw=
arded. =C2=A0If
649	 =C2=A0 the GDR for an active flow changes, there is likely to be some
650	 =C2=A0 disruption, such as packet loss or duplicates. =C2=A0By using a=
sserts,
651	 =C2=A0 packet loss is minimized, while allowing a small amount of
652	 =C2=A0 duplicates.

[minor] s/assert/Assert/g

654	 =C2=A0 When a router stops acting as the GDR for a group, or source an=
d
655	 =C2=A0 group pair if SSM, it MUST set the assert metric preference to
656	 =C2=A0 maximum (0x7FFFFFFF) and the assert metric to one less than max=
imum
657	 =C2=A0 (0xFFFFFFFE). =C2=A0This was also mentioned in the previous sec=
tion. =C2=A0That
658	 =C2=A0 is, whenever it sends or receives an assert for the group, it m=
ust
659	 =C2=A0 use these values as the metric preference and metric rather tha=
n the
660	 =C2=A0 values provided by routing. =C2=A0This is similar to what is do=
ne for
661	 =C2=A0 AssertCancel Messages in [RFC7761], except that the metric valu=
e here
662	 =C2=A0 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	 =C2=A0 Using the above example, for G1, assume R1 and R3 agree on the =
new
682	 =C2=A0 GDR, which is R3. =C2=A0With the new assert behavior, R1 sets i=
ts assert
683	 =C2=A0 metric to the near maximum value discussed above. =C2=A0That wi=
ll make R3,
684	 =C2=A0 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>
=C2=A0 =C2=A0For G1, using the functionality described in this document, R1=
 and R3
=C2=A0 =C2=A0determine the new GDR, which is R3. =C2=A0With the modified As=
sert behavior, R1
=C2=A0 =C2=A0sets its Assert metric to the near maximum value discussed abo=
ve. =C2=A0That will
=C2=A0 =C2=A0make R3, which has normal metric in its Assert as the Assert w=
inner.

686	 =C2=A0 For G2, assume it takes a slightly longer time for R2 to find o=
ut
687	 =C2=A0 that R3 is the new GDR and still considers itself being the GDR=
 while
688	 =C2=A0 R3 already has assumed the role of GDR. =C2=A0Since both R2 and=
 R3 think
689	 =C2=A0 they are GDRs, they further compare their metric and IP address=
es.
690	 =C2=A0 If R3 has the better routing metric, or the same metric but a b=
etter
691	 =C2=A0 tie-breaker, the result will be consistent during GDR selection=
. =C2=A0If
692	 =C2=A0 unfortunately, R2 has the better metric or the same metric but =
a
693	 =C2=A0 better tie-breaker, R2 will become the Assert winner and contin=
ues to
694	 =C2=A0 forward traffic. =C2=A0Shortly after when R2 finds out that it =
is no
695	 =C2=A0 longer the GDR, R2 will change to using the near maximum assert
696	 =C2=A0 metric. =C2=A0Next time R2 sends an assert message, it will los=
e the
697	 =C2=A0 assert and stop forwarding. =C2=A0As assert winner, R2 would se=
nd periodic
698	 =C2=A0 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. =C2=A0Backward Compatibility

702	 =C2=A0 In the case of a hybrid Ethernet shared LAN (where some PIM rou=
ters
703	 =C2=A0 enable the specification defined in this document, and some do =
not).

705	 =C2=A0 o =C2=A0If a router which does not support this specification b=
ecomes the
706	 =C2=A0 =C2=A0 =C2=A0DR on the LAN, then it is the only router acting a=
s a DR, and
707	 =C2=A0 =C2=A0 =C2=A0there will be no load-balancing.

709	 =C2=A0 o =C2=A0If a router which does not support this specification b=
ecomes a
710	 =C2=A0 =C2=A0 =C2=A0non-DR on link, then it acts as non-DR defined in =
[RFC7761], and
711	 =C2=A0 =C2=A0 =C2=A0it will not take part in any load-balancing. =C2=
=A0Load-balancing may
712	 =C2=A0 =C2=A0 =C2=A0still happen.

[]NEW>
=C2=A0 =C2=A0In the case of a hybrid Ethernet shared LAN (where some PIM ro=
uters support
=C2=A0 =C2=A0the functionality defined in this document, and some do not);

=C2=A0 =C2=A0o =C2=A0If the DR does not support the new functionality, then=
 there will be no
=C2=A0 =C2=A0load-balancing.

=C2=A0 =C2=A0o =C2=A0If non-DR routers do not support the new functionality=
, they will not be
=C2=A0 =C2=A0considered as Candidate GDRs and it will not take part in an
=C2=A0 =C2=A0load-balancing. =C2=A0Load-balancing may still happen on the l=
ink.


714	6. =C2=A0Manageability Considerations

[minor] s/Manageability/Operational

716	 =C2=A0 An administrator needs to consider what the total bandwidth
717	 =C2=A0 requirements are and find a set of routers that together has en=
ough
718	 =C2=A0 total capacity, while making sure that each of the router can h=
andle
719	 =C2=A0 its part, assuming that the traffic is distributed roughly equa=
lly
720	 =C2=A0 among the routers. =C2=A0Ideally, one should also have enough b=
andwidth to
721	 =C2=A0 handle the case where at least one router fails. =C2=A0Ideally =
all the
722	 =C2=A0 routers should have reachability to the sources, and RPs if
723	 =C2=A0 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. =C2=A0Informative References
...
844	 =C2=A0 [RFC8126] =C2=A0Cotton, M., Leiba, B., and T. Narten, "Guidelin=
es for
845	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Writing an IANA Consid=
erations Section in RFCs", BCP 26,
846	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 8126, DOI 10.17487=
/RFC8126, June 2017,
847	 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.rfc-edito=
r.org/info/rfc8126>.

[major] This reference must be normative.