Re: [pim] pim-dr-improvement wglc

Greg Mirsky <> Sun, 13 January 2019 03:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 61F6B128CE4 for <>; Sat, 12 Jan 2019 19:59:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4kIL77bdC_0L for <>; Sat, 12 Jan 2019 19:59:25 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A083D124D68 for <>; Sat, 12 Jan 2019 19:59:24 -0800 (PST)
Received: by with SMTP id i26so13451860lfc.0 for <>; Sat, 12 Jan 2019 19:59:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jhgH2n9qT3AxCLUNq9k7+Ntz8btPAdwzIPpm89fv7/E=; b=Di35JKKaC81SB97FsAYnD9D7ytxMcoEgqgNst0zjS5a6TooUS7SAvyUjh7vDLBDCab unW6m1W4KkyOttXsG1E5NOQXmSnnW5X9Gwwf93X9oaowDcB2Q26W9L7J57M2lEOn/ob8 kEAeTNjWKKajOQxO+7gfdqWQT7fgtYstZEB3TvQSFeEJKGmZDfPLlPY6L12Zw4FDUC49 9h+Ay8yDjvOvn91KOyaklguXz+iRJepmr1SYnme89MW4atPd6x1u2zMTq1ZgFM5ND2mJ G80i1ByvRgleM8lAn3a/z1AgQkoesFbcI7Rf4cP7A5UCoXYmKBsIdZw9kErCZQ9l+Pm9 C8YQ==
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; bh=jhgH2n9qT3AxCLUNq9k7+Ntz8btPAdwzIPpm89fv7/E=; b=hH5faRxvyrlxQdLHrXJqeViqdkd1Dy0CwVx7CTpOViZManHMz9HRhdUxEFRFre+2Wr ieiSFVJH+q69OgUzaNvbnwmSxGMfoDAESkdGv/e9d/Yz3TCCY81pJiNhfxpipRBVUJMH MYpq4w8PEEazi2re9IFLBGQWO+4a1HBlYfEcOP2BrvCt6348MDWsKwQ9zgcmaDMatWp9 76L9ErZianK95lhV4GxYgXHRolcvfa1eoN7T/Vxf+dXUQZZLTXAhsoPDjl1tNef+IzeQ BFz99klwv2DZpYcvRRxpaaX8ae1+OloD2nHxB60zuULjDcYXcQa/JpU4YMWFjxEM/UsR QLbw==
X-Gm-Message-State: AJcUukeD7TXzwAUc3tHlNdyFKMAqrYGX2fptHLJtRr9QsF2hFVI9QIlP 04LqBEU9wVXp8yODDiV3nM5jgCJl3MuAm2Qq14M=
X-Google-Smtp-Source: ALg8bN7tWVyLbX3coKp3SaKvpbpmgxvI7/z38bgPSIDO8fH+kBtBQF1ajv7Qq6MK2ajkeFptmO5ydODdD72nP2SJ7TE=
X-Received: by 2002:a19:c014:: with SMTP id q20mr10302727lff.16.1547351962252; Sat, 12 Jan 2019 19:59:22 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Sat, 12 Jan 2019 19:59:10 -0800
Message-ID: <>
To: Michael McBride <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="0000000000000d81ad057f4ef429"
Archived-At: <>
Subject: Re: [pim] pim-dr-improvement wglc
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: Sun, 13 Jan 2019 03:59:28 -0000

Dear Authors, Chairs, et. al,
I've read the draft and support its publication. Below please find my
comments and editorial nits:

   - Abstract
      - expand PIM on the first reference
      - s/extension/an extension/
      - s/stability/the stability/
      - s/PIM protocol/the PIM protocol/
      - Introduction
      - s/adjust/adjusted/
      - s/new comers/newcomers/ or s/new comers/new nodes/
   - Terminology:
      - Consider adding sub-section Keywords with normative references to
      RFC 2119 and RFC 8174.

2.2.  Keywords

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   - s/A BDR/a BDR/
      - I think that more expansions to the acronyms used are needed
   - section 3.1
      - s/TBD/TBD1/ (I assume that OptionType for DR is different from
      OptionType value for BDR)
      - s/is support/supports/*4
   - section 3.2
      - s/TBD/TBD2/
      - s/is support/supports/*4
      - section 4
      - s/avoid/avoids/
      - RE: "new comers" as for Introduction
      - s/address of router/address of the router/
      - s/be simplify/simplify/
      - s/. The router/, then the/
      - s/import/and import/
   - section 4.2
      - s/according/according to/
      - s/DR election definition/DR election defined/
      - s/one which have/one which has/
      - section 4.3
      - s/the router send/the router sends/
      - s/according/ according to/
   - section 4.4
      - s/as following/as follows/
      - s/are larger/is greater than 0x0/is non-zero/
      - s/BDS in message/BDR in the message/
      - s/algorithm/the algorithm/
      - s/as DR. and/as DR, and/
   - section 4.5

Perhaps some re-wording and nits fixes as follows:
If all the routers on a shared-media LAN have started working at the same
time, then the election result of DR is same as defined in [RFC7761].  And
all the routers will elect a BDR which is next best to DR.  The routers in
the network will store the DR and BDR.  The hello messages sent by all the
routers are the same with the value of DR and BDR are all set.
When a new router activated on the shared-media LAN and received hello
messages from other routers with the value of DR is already set. The new
router will not change the current DR even if it is superior to the current
DR.  If the new router is superior to current BDR, the new router will
replace the current BDR.

   When the routers receive a hello message from a new router, the routers
will compare the new router and all the other routers on the LAN.  If the
new router is superior to the current BDR, the new router will be new BDR.
Then the old BDR will send the Prune message to upstream routers.

   As a result, the BDR is the one which has the highest priority except
for DR.  Once the DR is elected, the DR will not change until it fails or
manually adjusted.  After the DR and BDR are elected, the routers in the
network will store the address of DR and BDR.

   - section 4.6
      - s/same/the same/
      - s/downstream router/a downstream router/
   - section 6

Perhaps the following will be acceptable:
If there are two or more routers which are responsible for multicast flow
forwarding on a shared-media LAN, and the multicast services are sensitive
to the lost of multicast packets, the functions of DR and BDR, defined in
this document, SHOULD be deployed.

   - IANA Considerations

I think that there are two OptionTypes, for DR address and BDR address,
that should be assigned. Would you agree?

   - Section 9
      - s/their/his/


On Tue, Jan 8, 2019 at 10:29 AM Michael McBride <>

> Happy New Year!
> Today begins a two week wglc for draft-ietf-pim-dr-improvement-06. In
> Bangkok, 4 people indicated that they had read the draft and each agreed
> it’s ready for wglc. Let’s please read the draft one more time and confirm,
> on this list, that it’s ready to be sent to iesg.
> thanks,
> mike
> _______________________________________________
> pim mailing list