[Last-Call] Rtgdir last call review of draft-ietf-pim-drlb-13

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Reviewer: Ben Niven-Jenkins
Review result: Has Issues

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Document: draft-ietf-pim-drlb-13.txt
Reviewer: Ben Niven-Jenkins
Review Date: 5th November 2019
IETF LC End Date: 7th November 2019
Intended Status: Standards Track

Summary: I have some minor concerns about this document that I think should be
resolved before publication.

Comments: The document is well written and easy to understand.

Major Issues: No major issues found.

Minor Issues:

1) Section 4.1 says:

“To become a GDR Candidate, a router must have the same DR priority and run the
same GDR election Hash Algorithm as the DR on the LAN.”

and

“Furthermore, assume router R1 wins the PIM DR election, R1 and R2 run the same
Hash Algorithm for GDR election, while R3 runs a different one.”

I think it would be clearer if you said “support”/“supports” (or maybe
“advertise”/“advertises”) rather than “run”/“runs”. As I think what you are
trying to say is if a router has the same DR priority as the DR it is only a
GDR candidate if it also supports the same hash algorithm as advertised by the
DR.

2) In section 5.3.1 the PIM DR Load Balancing Capability (DRLB-Cap) Hello
Option only contains a single value for Hash Algorithm. How is transition
between different hash algorithm expected to be achieved?

Does a router that supports multiple hash algorithms include multiple DRLB-Cap
Hello Options each containing a different hash algorithm and the DR selects the
hash algorithm it prefers (or is configured to use)?

If so, then it might be worth explicitly mentioning that in the document.

3) Section 5.3 says “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.”

Section 5.3.2 says “All addresses MUST be in the same address family as the PIM
Hello IP header.  It is RECOMMENDED that the addresses are sorted in descending
order.”

Section 5.3 implies (without explicitly stating it) that GDR Candidate
addresses MUST be sorted, but section 5.3.2 states that sorting is only
RECOMMENDED.

Maybe remove any possibility of ambiguity by rewording Section 5.3 to something
like “The DRLB-List Hello Option consists of three Hash Masks as defined above
and also a list of GDR Candidate addresses on the LAN. It is RECOMMENDED that
the GDR Candidate addresses are sorted in descending order.”

Nits:

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

Do you mean “applies to PIM-SM DRs”? Otherwise who is the “they” referring to
in that sentence?

Section 3 says “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.”

Do you mean “registration” instead of “registers”?

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux