Re: [pim] AD Review of draft-ietf-pim-dr-improvement-09 Tue, 16 June 2020 00:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0399F3A0F36; Mon, 15 Jun 2020 17:51:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L30n5_zwlrJm; Mon, 15 Jun 2020 17:51:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BAC933A0F31; Mon, 15 Jun 2020 17:51:12 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTPS id E2310F21D19C954BDE8E; Tue, 16 Jun 2020 08:51:10 +0800 (CST)
Received: from ([]) by with SMTP id 05G0p9a7076373; Tue, 16 Jun 2020 08:51:09 +0800 (GMT-8) (envelope-from
Received: from mapi (njxapp01[null]) by mapi (Zmail) with MAPI id mid203; Tue, 16 Jun 2020 08:51:08 +0800 (CST)
Date: Tue, 16 Jun 2020 08:51:08 +0800 (CST)
X-Zmail-TransId: 2af95ee8177c93a20a55
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <>
Mime-Version: 1.0
From: <>
To: <>
Cc: <>, <>, <>
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: 05G0p9a7076373
Archived-At: <>
Subject: Re: [pim] =?utf-8?q?AD_Review_of_draft-ietf-pim-dr-improvement-09?=
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, 16 Jun 2020 00:51:15 -0000

Hi Alvaro,

Thank you very much for your detailed review!

And thank you for your guidance for the modification!

We will have a discussion about the modification and modify the draft as soon as possible. :-)

(Sorry I cut some details because the mail scale limitation.)

Best regards,



发件人:AlvaroRetana <>
收件人 <>rg>;
抄送人 <>; <>rg>;
日 期 :2020年06月16日 05:45
主 题 :[pim] AD Review of draft-ietf-pim-dr-improvement-09

Dear authors:

Hi!  I hope everyone is safe and healthy.

I (finally!) finished my review of this document.  Thank you for the
effort so far.

I think that this document is not ready and needs significant work to
move forward.  There are many parts that are repetitive and redundant.
Also, there would be a lot of benefit from an English-language
edit/review.  I tried to cover many of the points in my comments, but
probably left some out...

Before getting into the details, I have a couple of points I want to
highlight up here:

(1) How does this document interact with rfc8775 (PIM DR Load Balancing)?
    Should be BDR always be a GDR?  Can a BDR not be a GDR?  rfc8775 is not
    even mentioned.

(2) As far as I can see draft-mankamana-pim-bdr has not been adopted yet.
    Assuming that is the plan, how would the two mechanisms interact?  Given
    that draft-mankamana-pim-bdr doesn't add options, and §5 says that if no
    options are received then the routers MUST use rfc7761, how does a router
    implementing this specification tell the difference?

    I realize that some of these questions may be better directed at
    draft-mankamana-pim-bdr, but because the WG agreed that a statement
    relating the two should be included in this document [1], then I'm
    asking now.  I would really like to understand what the WG expects.

(3) The Shepherd writeup [2] says that there is an implementation and
    deployment of this specification.  *But* the IANA Considerations section
    lists the code points as TBD.  What's the status of the implementation?
    Are there specific code points that should be suggested to IANA?  An
    rfc7942-type section would be useful to justify specific code points, if

(4) The election algorithm (§4.2) is a word-by-word copy from rfc2328!  It is
    good to reuse technology, but in this case (1) the description is out of
    context, and (2) the election function from rfc7761 would make a much
    better (and familiar) base for the description (and, as far as I can
    tell, should yield the same result).  Please update the description.

I expect a significant change in the structure of the document to move forward.





[Line numbers from idnits.]

pim mailing list