Re: [pim] Rtgdir last call review of draft-ietf-pim-drlb-13
Ben Niven-Jenkins <ben@niven-jenkins.co.uk> Tue, 07 January 2020 21:51 UTC
Return-Path: <ben@niven-jenkins.co.uk>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745D51200A3; Tue, 7 Jan 2020 13:51:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuQ-zVmvFNFm; Tue, 7 Jan 2020 13:51:49 -0800 (PST)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA9E1120025; Tue, 7 Jan 2020 13:51:48 -0800 (PST)
Received: from [135.245.42.235] (helo=[10.195.76.194]) by smtp03.mailcore.me with esmtpa (Exim 4.92.3) (envelope-from <ben@niven-jenkins.co.uk>) id 1iowlM-0001RD-Fe; Tue, 07 Jan 2020 21:51:47 +0000
From: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
Message-Id: <5F7FB54A-2455-46DD-B035-16F083E1A239@niven-jenkins.co.uk>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9A03F69C-B8D4-49C3-AAB2-3DD435F794BF"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Date: Tue, 07 Jan 2020 16:51:41 -0500
In-Reply-To: <CAHANBtLZxwj5DDaHNz4e+NismVzpJ5SoLSyHr-X_BX2mAP=Q4Q@mail.gmail.com>
Cc: rtg-dir@ietf.org, last-call@ietf.org, pim@ietf.org, draft-ietf-pim-drlb.all@ietf.org
To: Stig Venaas <stig@venaas.com>
References: <157296956286.4449.7260081919501488270@ietfa.amsl.com> <CAHANBtLZxwj5DDaHNz4e+NismVzpJ5SoLSyHr-X_BX2mAP=Q4Q@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
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 8.0.1.721, bases: 2020/01/07 05:09:00 #11232087
X-KLMS-AntiVirus-Status: Clean, skipped
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/1xesc_3NwX71r10bLY6NAtzF6U8>
Subject: Re: [pim] Rtgdir last call review of draft-ietf-pim-drlb-13
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=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. Regards Ben > On 11 Dec 2019, at 18:06, Stig Venaas <stig@venaas.com> 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 > <noreply@ietf.org <mailto:noreply@ietf.org>> 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 >> 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. > > 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 >> 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.” > > 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
- [pim] Rtgdir last call review of draft-ietf-pim-d… Ben Niven-Jenkins via Datatracker
- Re: [pim] Rtgdir last call review of draft-ietf-p… Stig Venaas
- Re: [pim] Rtgdir last call review of draft-ietf-p… Ben Niven-Jenkins