Re: [pim] pim-dr-improvement wglc

Stig Venaas <stig@venaas.com> Mon, 28 January 2019 17:33 UTC

Return-Path: <stig@venaas.com>
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 E07631310BF for <pim@ietfa.amsl.com>; Mon, 28 Jan 2019 09:33:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.041
X-Spam-Level:
X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=venaas-com.20150623.gappssmtp.com
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 61M1qfyu2rbE for <pim@ietfa.amsl.com>; Mon, 28 Jan 2019 09:33:16 -0800 (PST)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0768E1310BE for <pim@ietf.org>; Mon, 28 Jan 2019 09:33:16 -0800 (PST)
Received: by mail-ed1-x52f.google.com with SMTP id o10so13667856edt.13 for <pim@ietf.org>; Mon, 28 Jan 2019 09:33:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=i8d5Tfv+Qcy4FZtm4n+4Bho18T2MMS0cCN/zzCHNlgY=; b=wLWXGYn4e0Fko9Ib1OZ7+At05uqA2Cw/OkSO3+7otGkZwued03FsEIQ0SrO/FT2fUt t46WdAKDLSvR2bnRsD4Z3nw6Gqkh9NIHP8a2iglhdAxp2JPQVsxRiJS6T4Hubrk4bOE1 euWRY8Kz5jE9ikNlQearBYAdmjuDEsYEK/b+fNA/Pq3pex7W7X4K5nHgwNajNBnXqVP4 z5qj323CLJTV+S31pwUpedfbt3QTIrMx2Af5xQJSSk5oYjPdc/nRARIF6V+igK+6umYk 02kWLuhA6LT/KBfksHxgp6tKY7h1huNQI4/qBQMsprOVn96Ds/PpbUYYECdjeUxSTWbp lNLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=i8d5Tfv+Qcy4FZtm4n+4Bho18T2MMS0cCN/zzCHNlgY=; b=ET4kBdoeOn7jgvOai4zWx4K94AYSh2HQKfm1DkdGpUXNc6mgxvy0eLZ5hI0WCS0rsf ZW67PJ6dtSsKOJpE9uJWZFct5CEC37fpC4X0w0qAOKuq7HN74f90mpYMjANCHjau7kfy t0lUWTvxW7+q8FyDJc1Hp1z3F1Yxvw5QD4B03T4iBIQVdNlkgUo0PZUIfzup7w4XD9pQ /NiM/Kk8UG5V+gDW1IAnZyZhXJz2knYpw18KPH5UNJ1d4bsxBKM+cijgWpuFd2jlWsLO JmDgocJgnEZMxcNd413PCsfWHiQ1g5Zxka/3SJredQauW26BCTY0z631BriZjdYV4eLl W+GQ==
X-Gm-Message-State: AJcUukdRDOXGpUyG40Nti6+NbuUZeV1Vl+O+SoZBv40VigDuDiPIs3+P ez1MlTTGoRpQpnZKYvrS81Zem9/GBRIP6BidgMOgK9Zi
X-Google-Smtp-Source: ALg8bN46mq+EvE0VB5/D4p5gkh1M1idrM3KKFgQSBC+fGykV0VJ3vhL4aCPOb+3XCqW2zhOPPTd6c8pOSF/XTkzpnhI=
X-Received: by 2002:a50:8d12:: with SMTP id s18mr22938019eds.32.1548696794387; Mon, 28 Jan 2019 09:33:14 -0800 (PST)
MIME-Version: 1.0
References: <8CCB28152EA2E14A96BBEDC15823481A1CE66B26@sjceml521-mbs.china.huawei.com> <201901261209412860801@zte.com.cn>
In-Reply-To: <201901261209412860801@zte.com.cn>
From: Stig Venaas <stig@venaas.com>
Date: Mon, 28 Jan 2019 09:33:03 -0800
Message-ID: <CAHANBtKGVVtkpgd+oNKST35wzLLRvcp=LBbzN1_z46vWc-hNyQ@mail.gmail.com>
To: "zhang.zheng" <zhang.zheng@zte.com.cn>
Cc: Michael McBride <Michael.McBride@huawei.com>, Greg Mirsky <gregimirsky@gmail.com>, "Holland, Jake" <jholland@akamai.com>, pim@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/KpST2CFEL9Ww7vOQPPez7mUqe9A>
Subject: Re: [pim] pim-dr-improvement wglc
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: Mon, 28 Jan 2019 17:33:19 -0000

I'll have another look myself. I only mentioned the more high level
concerns I had in my previous email. But it might all be good. Let me
see.

Stig

On Fri, Jan 25, 2019 at 8:09 PM <zhang.zheng@zte.com.cn> wrote:
>
> Hi Mike,
>
> All the comments from Greg and Jake have been addressed except for if the pseudocode should be provided. My concern is that it may not be the must because most of the parts is the same. But more suggestions about it are welcomed.
> A spelling nit will be fixed in next version.
>
> Thanks,
> Sandy
>
>
>
> 发自我的zMail
>
> 原始邮件
> 发件人:MichaelMcBride<Michael.McBride@huawei.com>
> 收件人:张征00007940;gregimirsky<gregimirsky@gmail.com>;jholland<jholland@akamai.com>;stig<stig@venaas.com>;
> 抄送人:pim<pim@ietf.org>;
> 日期:2019-01-26 07:27:07
> 主题:RE: [pim] pim-dr-improvement wglc
>
> Does this latest version address all of the comments from Greg and Jake? If so we will forward it on.
>
>
>
> Thanks
>
> mike
>
>
>
> From: pim [mailto:pim-bounces@ietf.org] On Behalf Of zhang.zheng@zte.com.cn
> Sent: Thursday, January 17, 2019 1:09 AM
> To: gregimirsky@gmail.com; jholland@akamai.com; stig@venaas.com
> Cc: pim@ietf.org
> Subject: Re: [pim] pim-dr-improvement wglc
>
>
>
> Hi Greg, Jake, Stig,
>
>
>
> Thank you very much for your careful review and suggestion!
>
> A new version of this draft has been submitted.
>
> The nits you mentioned are fixed. And I add more description in Compatibility section and Security Considerations section.
>
> Appreciate for your more view!
>
>
>
> PS. It seems like the previous email has been held for some reasons, so I resend this email. Sorry for the duplicate emails.
>
>
>
> Best regards,
>
> Sandy
>
>
>
> 原始邮件
>
> 发件人:StigVenaas <stig@venaas.com>
>
> 收件人:Holland, Jake <jholland@akamai.com>;
>
> 抄送人:pim@ietf.org <pim@ietf.org>;
>
> 日 期 :2019年01月16日 01:11
>
> 主 题 :Re: [pim] pim-dr-improvement wglc
>
> Hi
>
> I overall agree with the other reviewers' comments. One high level
> concern I think needs to be addressed in the draft is how to detect
> that other neighbors support the mechanism, and how to behave if not
> all routers support it.
>
> One way of detecting support for the mechanism would be to check if
> neighbors announce the new options. In that case, what should be the
> content of the options if not all neighbors support it. Also, is it OK
> to use the mechanism if the neighbors not supporting it have a low DR
> priority, or is it better to require that all neighbors support it?
> What should be the behavior once all neighbors support it (a
> non-capable neighbor went away), or if a non-capable neighbor comes
> up?
>
> Section 4.2 should talk about primary address, not Router ID.
>
> Regards,
> Stig
>
> On Mon, Jan 14, 2019 at 2:08 PM Holland, Jake <jholland@akamai.com> wrote:
> >
> > Hi,
> >
> >
> >
> > I think the extension is a good idea and that this doc gives a good
> >
> > explanation of how it works. However, I think there’s some issues that
> >
> > should be addressed before publication as a Standards Track RFC.
> >
> >
> >
> >
> >
> > Major issues:
> >
> > 1. The security considerations section seems too thin. (The complete
> >
> > contents of the section are “For general PIM Security Considerations.”)
> >
> >
> >
> > 1.a. I think there are some security implications because of
> >
> > the new stickiness in the DR election process. For instance, in
> >
> > https://tools.ietf.org/html/rfc5015#section-5.1.1 when describing what
> >
> > happens when a DR has been impersonated, it implies there’s a
> >
> > mitigation (“[The impersonated] node typically will be able to detect
> >
> > the anomaly and, possibly, restart a new election.”)
> >
> >
> >
> > But because the DR is more sticky with this new extension, I think the
> >
> > kind of temporary disruption would have a more permanent effect that
> >
> > the impersonated node could not mitigate. I might be wrong about that
> >
> > being actually more dangerous, but it worries me that there’s no
> >
> > mention of issues like these in the security considerations section.
> >
> >
> >
> > I think for this point, it might be enough to just say that the
> >
> > election process may be more vulnerable to temporary disruption because
> >
> > the DR election is more persistent, and that this increases the
> >
> > importance of using source authentication to avoid DoS from malicious
> >
> > activity.
> >
> >
> >
> > 1.b. I think this probably should mention that BFD security
> >
> > considerations are applicable also, or the considerations for whatever
> >
> > DR failure detection mechanism is used.
> >
> >
> >
> > 2. There should probably be a reference to BFD, and perhaps other
> >
> > fast failure detection mechanisms, if they’re recommended.
> >
> >
> >
> > More generally, it seems to me that the speed of DR failure detection
> >
> > is of critical importance in using this mechanism, so the one brief
> >
> > mention (which doesn't explain the pros and cons of faster detection or
> >
> > make any recommendations about technologies to use) seems like it
> >
> > skims past a key point without explaining it in depth.
> >
> >
> >
> >
> >
> > Minor/editorial issues:
> >
> >
> >
> > 1. In section 3.2, it probably should talk about the IP version in the
> >
> > PIM message, instead of IP version supported by the network. The way
> >
> > it’s written, it seems to make it impossible to run a dual-stacked
> >
> > network with 2 instances of PIM, but I don’t think that’s the intent.
> >
> >
> >
> > 2. Should the reference to 2328 be informative instead of normative? It
> >
> > seems like it’s only used as an example.
> >
> >
> >
> > 3. The IANA considerations section should follow the guidelines from
> >
> > RFC 8126 section 1.3 (exact name of the registry, for instance). It
> >
> > also seems useful to make 2 separate values, TBD1 and TBD2 instead of
> >
> > using TBD for both.
> >
> >
> >
> > 4. “SW” is not defined in the diagram in Figure 1. I think the 2 SW
> >
> > boxes are Layer 2 switches on the same LAN, but I’m not certain.
> >
> >
> >
> > 5. In section 4, I think "MUST not" in the last paragraph should have
> >
> > NOT capitalized?
> >
> >
> >
> > 6. I don't understand the meaning of "The treatment" as the title
> >
> > for section 4.5.
> >
> >
> >
> > 7. There are a lot of English language nits. I saw that Greg covered
> >
> > several of them, so I’ll just mention the ones I saw in sections he
> >
> > didn’t cover:
> >
> >
> >
> > section 1:
> >
> > “can be adjust to” -> “can be adjusted to”
> >
> > “Still, may multicast packets” – should this be “many” instead of “may”?
> >
> > “new comers” is one word (this appears several times in the doc)
> >
> > I’m not certain, but I think each time the word “Ethernet” is used, “LAN” was intended?
> >
> > “new comers which has a higher”: has->have
> >
> >
> >
> > ... (skipping sections Greg Mirsky covered) ...
> >
> >
> >
> > section 4.5:
> >
> > “are start to work on the same time”
> >
> > “when a new router start to work” -> starts to work
> >
> > “fails or manually adjustment” -> fails or is manually adjusted
> >
> >
> >
> > I had to stop early before finishing a catalogue of all the rest of the
> >
> > issues I could find, but because of the very high density of nits, I’ll
> >
> > suggest it might be a good idea to try using an English-language
> >
> > proofreading service that works with technical documents.
> >
> >
> >
> > This is not an endorsement, and I’ve never used their services, but as
> >
> > an example of the kind of service I mean, here’s one I found in a few
> >
> > moments with a search engine:
> >
> > https://www.proof-reading-service.com/
> >
> >
> >
> >
> >
> > Thanks for this work, it seems like a useful extension.
> >
> >
> >
> > Best,
> >
> > Jake
> >
> >
> >
> >
> >
> > From: Michael McBride <Michael.McBride@huawei.com>
> > Date: 2019-01-08 at 10:29
> > To: "pim@ietf.org" <pim@ietf.org>
> > Subject: [pim] pim-dr-improvement wglc
> >
> >
> >
> > 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.
> >
> >
> >
> > https://tools.ietf.org/html/draft-ietf-pim-dr-improvement-06
> >
> >
> >
> > thanks,
> >
> > mike
> >
> > _______________________________________________
> > pim mailing list
> > pim@ietf.org
> > https://www.ietf.org/mailman/listinfo/pim
>
> _______________________________________________
> pim mailing list
> pim@ietf.org
> https://www.ietf.org/mailman/listinfo/pim
>
>