Re: [pim] Rtgdir last call review of draft-ietf-pim-drlb-13

Ben Niven-Jenkins <> Tue, 07 January 2020 21:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 745D51200A3; Tue, 7 Jan 2020 13:51:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yuQ-zVmvFNFm; Tue, 7 Jan 2020 13:51:49 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EA9E1120025; Tue, 7 Jan 2020 13:51:48 -0800 (PST)
Received: from [] (helo=[]) by with esmtpa (Exim 4.92.3) (envelope-from <>) id 1iowlM-0001RD-Fe; Tue, 07 Jan 2020 21:51:47 +0000
From: Ben Niven-Jenkins <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9A03F69C-B8D4-49C3-AAB2-3DD435F794BF"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
Date: Tue, 07 Jan 2020 16:51:41 -0500
In-Reply-To: <>
To: Stig Venaas <>
References: <> <>
X-Mailer: Apple Mail (2.3608.
X-Mailcore-Auth: 9600544
X-Mailcore-Domain: 172912
X-KLMS-Rule-ID: 1
X-KLMS-Message-Action: clean
X-KLMS-AntiSpam-Status: not scanned, license restriction
X-KLMS-AntiPhishing: not scanned, license restriction
X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version, bases: 2020/01/07 05:09:00 #11232087
X-KLMS-AntiVirus-Status: Clean, skipped
Archived-At: <>
Subject: Re: [pim] Rtgdir last call review of draft-ietf-pim-drlb-13
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Jan 2020 21:51:54 -0000

Hi Stig,

Closing the loop on this…your responses answer all my questions, I have no issues with the document now, which I see has been approved for publication :-)

Apologies for the delay in my response…holiday season and all that.


> On 11 Dec 2019, at 18:06, Stig Venaas <> wrote:
> Hi
> Thanks a lot for the good review with a lot of comments. I believe
> I've addressed them in the new version. Please see inline for further
> comments.
> On Tue, Nov 5, 2019 at 7:59 AM Ben Niven-Jenkins via Datatracker
> < <>> wrote:
>> 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
>> 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.
> Thanks.
>> 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.
> Fixed.
>> 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?
> It is not clear that we will define other algorithms. If we do, I
> think it might be sufficient that the administrator manually
> configures the candidates with the preferred algorithm. We may come up
> with an election scheme later once we have additional algorithms
> though.
>> 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.
> In pim we only use each option at most once in the hello, but I've
> added a comment saying at most once.
>> 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
>> 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.”
> I've tried to clarify this now. I added that it is recommended that
> first time I mention a sorted list. Also changed RECOMMENDED to
> recommended, as things will work just fine either way. I also added
> text explaining why it is a good idea to sort them.
>> 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?
> Good catch.
>> 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”?
> There are PIM register messages. It is a specific message type. I added "PIM".
> Thanks,
> Stig