Re: [pim] draft-ietf-pim-bfd-p2mp-use-case WGLC

Greg Mirsky <gregimirsky@gmail.com> Tue, 24 November 2020 22:56 UTC

Return-Path: <gregimirsky@gmail.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 3DAA83A07D3 for <pim@ietfa.amsl.com>; Tue, 24 Nov 2020 14:56:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Q3CWqKdcHa70 for <pim@ietfa.amsl.com>; Tue, 24 Nov 2020 14:56:50 -0800 (PST)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 B0CEE3A07C3 for <pim@ietf.org>; Tue, 24 Nov 2020 14:56:03 -0800 (PST)
Received: by mail-lf1-x12f.google.com with SMTP id l11so456426lfg.0 for <pim@ietf.org>; Tue, 24 Nov 2020 14:56:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r5+W1KMrntDvwhUwOBYhbSKDzy/rBPTcVNySfLl56/4=; b=Zf9RfH6g9rWz+arA++y+zVq2IuZ29H4WI5e8HBxL1BC4fqhZvo/TOAQkdWIyUJeXpR QO1XcqpfAExCjnFeNO5JF15LkEzUU49oCrIXqcaRMMq13EpNblMZn0uKcoRshhjYT62l ZHHIlQvSsiytLVKrp7cs374rHL6jyGzi0vYPH/l9+3+qn48WUVrBsaAa27uwbJQOhlrU UrqNI9iafqe6z/knb1C/KxAosF1K5T5rX3uaYChFt9RX6A371Q3VwW2lO/G49P5f0aUw Uxk6dQT8EsaweITDpjNIQpNdgNHOJ7xk3tUvDR9OrZn+SG1uW7cwsWc+JLgakXBqTY/V SaRA==
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; bh=r5+W1KMrntDvwhUwOBYhbSKDzy/rBPTcVNySfLl56/4=; b=eX7aPCJUtH52BFN7LZqmId5Y3no0Jp4mgbvx+WisGm09dxF8K8+dM0YO5trXsgH1mu Inpl/7mEDuh4hPBML2YUusUYYwtUtqcP3kBsoMXpE+c3qXj0yuvpbNDaB213f65qWMIL Fpgf/28SjsrC2HgdJK0r0SJ8wik9HYP98E6zWdUT1vh+7eCAN6xySqUVMlaHSGGvR/eq aYHFsKdJnNIhQjKl6qRkzNDITKZwwjLZsT4RopE9EGJO1UcyuGRpjTSZp3U8d3QMo0mn CqyUeRRVAhitqZyQrfWePVOhz0Jbb2W2O72UiIZTdegYSt8VI1CLA7hjALoprfYHAH8I 49gg==
X-Gm-Message-State: AOAM532Tzq+3kpqmxMxukiYI/7d0yLlNpKfigtiRO9/fBBQaVAV2Gvgh Vt147FPQvjDbw7Qi2K+3TDd3SWgR2EbNsl0h6o8=
X-Google-Smtp-Source: ABdhPJxnX2WxujnbRIB8lyzbCfQBo57ohmKzZwTPaR3/crsx04BHKtHf8pU6RzdaeD6CswxekRmTXiL495PDhvAUCps=
X-Received: by 2002:a05:6512:1102:: with SMTP id l2mr142900lfg.500.1606258561656; Tue, 24 Nov 2020 14:56:01 -0800 (PST)
MIME-Version: 1.0
References: <BYAPR13MB2582CD7E83E6F1E25A8F4226F4ED0@BYAPR13MB2582.namprd13.prod.outlook.com> <CAHANBtLLA0fWVEr0rtyVoCNVVPL9oXxSpvwHZoJTYJvp7y1BEw@mail.gmail.com>
In-Reply-To: <CAHANBtLLA0fWVEr0rtyVoCNVVPL9oXxSpvwHZoJTYJvp7y1BEw@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 24 Nov 2020 14:55:49 -0800
Message-ID: <CA+RyBmXkSq0DajGNEOitYL32qXEbxBNpyH=SGtajQk_kFjuf_A@mail.gmail.com>
To: Stig Venaas <stig@venaas.com>
Cc: Michael McBride <michael.mcbride@futurewei.com>, "pim@ietf.org" <pim@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fc2cc705b4e2368e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/UKan2fH7YgaSLpRLuhB0lE76xnI>
Subject: Re: [pim] draft-ietf-pim-bfd-p2mp-use-case 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: Tue, 24 Nov 2020 22:56:52 -0000

Hi Stig,
thank you for your comments and suggestions. We'll work on them and will
propose updates addressing your comments later this week.

Regards,
Greg

On Tue, Nov 24, 2020 at 11:33 AM Stig Venaas <stig@venaas.com> wrote:

> Hi
>
> Apologies for being a bit behind the deadline, I have a few WGLC comments.
>
> I believe the document is nearly ready for publication. I just have a
> few minor comments that I think should be considered. Although my
> comments may seem lengthy, I think it might just be a matter of adding
> a few sentences.
>
> In the intro where p2p BFD is mentioned, I think it would be good to
> mention that there are PIM-SM implementations making use of p2p BFD,
> and then maybe point out why p2mp BFD is better suited for this. I see
> you mention that p2mp BFD precisely characterizes the pim deployment
> scenario, and I agree with that, but maybe could add more details why
> p2mp is better. I think this is important as it will indicate why
> existing pim BFD implementations should move to p2mp BFD.
>
> Typo here:
> p2mp: Pont-to-Multipoint
>
> A few comments on section 3.1.
>
> I imagine there could be some confusion whether the BFD TLV applies to
> regular BFD or only p2mp BFD. Can you clarify this?
>
> If I read this correctly, any PIM router can be configured to use p2mp
> and one doesn't need to be BDR or DR to use this. Perhaps it is good
> to add a sentence saying that any PIM-SM router may announce the BFD
> TLV, and other PIM-SM routers MAY monitor it. Basically, even though
> the section name is about DR/BDR monitoring, it can also be used to
> monitor other neighbors. I think it is good to include this, as this
> is done by BFD implementations today. I can imagine that there will be
> other use-cases now or in the future, for monitoring neighbors that
> are not DR/BDR.
>
> Security considerations:
> Is it worth stating how this relates to PIM authentication? If PIM-SM
> is configured to require neighbors to be authenticated, then this
> would only apply to authenticated neighbors. It looks like p2mp BFD
> also has its own authentication mechanism? Should that be considered
> used for PIM? Is there value in doing that if PIM authentication is
> used?
>
> Regards,
> Stig
>
> On Fri, Nov 6, 2020 at 1:10 PM Michael McBride
> <michael.mcbride@futurewei.com> wrote:
> >
> > Hello people of pim,
> >
> >
> >
> > Today begins a two week wglc of
> https://tools.ietf.org/html/draft-ietf-pim-bfd-p2mp-use-case-04.
> >
> >
> >
> > Please share your opinions on the readiness of this draft to be sent to
> the iesg.
> >
> >
> >
> > 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
>