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

Stig Venaas <> Wed, 11 December 2019 23:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E9BF120898 for <>; Wed, 11 Dec 2019 15:06:26 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eFwGdvNo_YCB for <>; Wed, 11 Dec 2019 15:06:24 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6605D120899 for <>; Wed, 11 Dec 2019 15:06:22 -0800 (PST)
Received: by with SMTP id i6so93340edr.5 for <>; Wed, 11 Dec 2019 15:06:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ab0XeQJPLROQG5DlvvVPhAd1O+iWym1QnU8COWg+82E=; b=TGi74+w+vnsueFP7qV+jRbhcxqfvvMg+9ku1L8H7wGLXvFAmGzwjUZkUj/F8PJXJ8j f3KCDF8yjrkaC7En3VRNVcBlQehAUUJf55fYdhoBvx7VW0AmHD8cO0BLbZQfBTxyMxaG cB1iXxqJF9UlihS+4gQodpblXND4Wx6HvdIziTolnGDoXWA2X+5cOlkDjZbS38lnrFin TkE/MQS+6vh2RdLx3ek+47DAKiTUSRGNjCPBi92S2s7SLZ37PJR8SD4GBWna5XcoOk14 tscG+vEQsNKppyYZ3ZHo5RHbiipcfWCag3gur1I0ai6TFRD5puI01NCsAuiut3/PlOuT rd4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ab0XeQJPLROQG5DlvvVPhAd1O+iWym1QnU8COWg+82E=; b=cfT5EOvKDhzp/c98To+JKi/79czlODS0ORuieaxpIaWzxJBm/YhPE5xMyaivNf1l+s rchaJkLEM4uZCb1aFGm9tr+I/rWbuFgVi4KFK9tuK2pz/1DQtschMtPTzTF81v7YNn7D LcO/P7KK3xt/PMO+UDfWQxpBablIYcd4vW08x0NJed00SsxDKCaOA3QjYHD0oETcAEww 7Wi7zLsKm+MkfJ67f8efvgNXTDTl9lbLUcXQKAMBIO7d7pbtnrlo5ZiNikgnjOuDtqWE y7bxJRTAncy06S67cxPqgOiKEL9J7WOJyH+aE8BJdwMdn49/bZPXybX0GhaktijfdHFV zsxA==
X-Gm-Message-State: APjAAAXgjxFeHi0t0Yzt0MYm2EOwt9I+eGrj3TzUj+8QpaEq4MVsfRtR 9yrbkj+u8mJhdxvAPhji7bonEqdheT4GMmP/UU0yWQ==
X-Google-Smtp-Source: APXvYqxPKhBo+xfAsrxTIloP4ivDbMiwnriIhalxDerjSCyuOsAtbj2R16gyaMsTV5yGa+VCY8cVN8jKbpfFVYIPkdM=
X-Received: by 2002:a17:906:aad0:: with SMTP id kt16mr6139942ejb.223.1576105580837; Wed, 11 Dec 2019 15:06:20 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Stig Venaas <>
Date: Wed, 11 Dec 2019 15:06:10 -0800
Message-ID: <>
To: Ben Niven-Jenkins <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Wed, 11 Dec 2019 23:06:29 -0000


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

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.


> 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?

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

> 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".