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

Michael McBride <michael.mcbride@futurewei.com> Tue, 01 December 2020 01:17 UTC

Return-Path: <michael.mcbride@futurewei.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 4B9C23A12EA for <pim@ietfa.amsl.com>; Mon, 30 Nov 2020 17:17:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 zxKV5XoTOp4M for <pim@ietfa.amsl.com>; Mon, 30 Nov 2020 17:17:47 -0800 (PST)
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2119.outbound.protection.outlook.com [40.107.94.119]) (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 31BFB3A12E9 for <pim@ietf.org>; Mon, 30 Nov 2020 17:17:46 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ARYXPtKNjdjxw3ldBSBW0ugxYttZXwHENF6czKGo66uKrgD6ZiAHjLR2uET8OvROQ+CQonrdhwSKnkDKgRGNqH2D8S8GsDwQYdDgaL+9dwu/MsRadOsodKB5AWn6V9wTZKQLJj38tL9Drb05FWDC9LPvYfejZn8NN6bb85JUV8yoijADWQ+6mRg3Z5/o48tj93h/ETElixfvCN5TVDdKO7pxGsNgVdAUpnq7IDsTdPEV5qd49Dzv+vBznVW8xKT1PvyHrCkeUt2+DU+YcDfsBClCGgVQJxU6ynCigUkbFgc6i+62MZoaKGsb4CBaw5/WBgs8hQFMf/BuDyMMcTRLrA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7suZmuaHK3PX1cmHVGv1laTOW1e53d/gGpLka3Ivfjk=; b=oDJpz2ras35D6cHBqDcpHoXN6pJRo45ubx3BJbtVH+KMjP4Dz9bMRPA8hYNnraTR8y3M3Enf+NNWEjdiyPhvMgDvOnldOJNcs2rJpjQUKb2e4FFG3JH9F6SSJV+KudUW2Ul5w833HVpKRDgJNFEomOKsF6zCgmoi/Ckj6bQTjUODcz/wuycO4Fxfvd8psYFOhXVC5AnqQtZ8h07MV+1irBN7L6Kk2UZ8eZPcf6a+4Rm47gz0lq5UoTyQsJV5ENPmE9qtGXQHokDAqvG05D3dkwbNV0iejTEGVE3eptC163Ny+GwKhaFo45PtwGoo/jrfMqw0uOL78VRdGaG+NUHToA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7suZmuaHK3PX1cmHVGv1laTOW1e53d/gGpLka3Ivfjk=; b=P30R7ypdSBtkyx+V9Oal3Zi/G028Us9DCTcUJk+9zsxdJbG/IpYtNOUXtXQfJvoSxXU4gnpADdoyNizbLkgF4wy/m3Mhlmj/hlzxKKSudktch/R+YXVz+E1O9cwfNUp/4mSYdLJO6bk03VMUReQHT5o7ip9tjuuxAeSnGRA/m/c=
Received: from BYAPR13MB2582.namprd13.prod.outlook.com (2603:10b6:a03:b2::19) by BY5PR13MB3748.namprd13.prod.outlook.com (2603:10b6:a03:22b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.6; Tue, 1 Dec 2020 01:17:45 +0000
Received: from BYAPR13MB2582.namprd13.prod.outlook.com ([fe80::b462:e81c:41fa:4bee]) by BYAPR13MB2582.namprd13.prod.outlook.com ([fe80::b462:e81c:41fa:4bee%7]) with mapi id 15.20.3632.009; Tue, 1 Dec 2020 01:17:45 +0000
From: Michael McBride <michael.mcbride@futurewei.com>
To: Greg Mirsky <gregimirsky@gmail.com>, Stig Venaas <stig@venaas.com>
CC: "pim@ietf.org" <pim@ietf.org>
Thread-Topic: [pim] draft-ietf-pim-bfd-p2mp-use-case WGLC
Thread-Index: Ada0gQrU9zQu4Q6zTBez4JgljosuTgOF4ziAAHaO+4AAvHchAAAARu4AAAZ+J6A=
Date: Tue, 1 Dec 2020 01:17:44 +0000
Message-ID: <BYAPR13MB2582F92B5BB44880ECE563DAF4F40@BYAPR13MB2582.namprd13.prod.outlook.com>
References: <BYAPR13MB2582CD7E83E6F1E25A8F4226F4ED0@BYAPR13MB2582.namprd13.prod.outlook.com> <CAHANBtLLA0fWVEr0rtyVoCNVVPL9oXxSpvwHZoJTYJvp7y1BEw@mail.gmail.com> <CA+RyBmUhiOW+cdewod2xECyo5NPupA0QPknHneeQ1nSYcAn+Vg@mail.gmail.com> <CAHANBtJQ0KayXZSyVSCU8dNYxvCQycypQfgg4BA_s40Nwd6awA@mail.gmail.com> <CA+RyBmU8UcB2wch_7s53dr-F5Y_vAQYeTBtmwWo207DVEPgqtg@mail.gmail.com>
In-Reply-To: <CA+RyBmU8UcB2wch_7s53dr-F5Y_vAQYeTBtmwWo207DVEPgqtg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=futurewei.com;
x-originating-ip: [108.197.145.62]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: fa35163c-47be-4f6b-7cdf-08d89596e873
x-ms-traffictypediagnostic: BY5PR13MB3748:
x-microsoft-antispam-prvs: <BY5PR13MB3748C814A3B76CCC063FC2A0F4F40@BY5PR13MB3748.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: WIk3CG1sRUlqKWNz4/JLxZkn/bMCHZwR1vOSW5dboCrRJjav0yA3K43RIKqS1PTd3W9RjZGVbB4uHVIKbsHsMZYxbqQkukwcxJ12pYCCgbl5BPSd5Blhg16NcLfYvlQ8nMjRQsvg8a/A/BjYDldBMlydxif6sB/iKCbFOxjVtOavqDAIbO/bMsypVf4AFHnBJSoXfuFqc7YbVHwbIPsmfD+UTVKRksH32PcX6HZcBssnFTCPvDz9svVOL3teZpaF/igkF2b7/Lm8fCNvTXz5w0xbMY/rFQnOE2ZF1aRTzHDG+ahDRn1mzJ8/iptLOXdV9I7wsEEzrnwhLinttS3CnLGM4W+iXEVvCeeNZSs7PwNUhP/LRvmLqF0TvLPaGsaQcOgkIcMX9jSXacVgBLGwFQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR13MB2582.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39840400004)(376002)(346002)(136003)(396003)(166002)(86362001)(8936002)(33656002)(316002)(4326008)(30864003)(26005)(71200400001)(110136005)(966005)(66556008)(66574015)(83380400001)(7696005)(66476007)(6506007)(66946007)(64756008)(53546011)(478600001)(55016002)(9686003)(2906002)(8676002)(186003)(5660300002)(52536014)(66446008)(76116006); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?TkIvdlVCQnpibmYydFhRSjlaT0Y2YXBzdHlNc2tEZ2FmV2psWVl1SFBKRUNM?= =?utf-8?B?LzRmL1J6aHloTDRnRXpuNmZ2Z21Oa2hBMmtSbHNoWTVwdTRnN2J0UEhLcTBE?= =?utf-8?B?cjVXcTRjNno2dlM5Y2JFaW00Z3oyeENZdTBjUk5SK0VtdnFoU0I3cnBYTUho?= =?utf-8?B?M2FuWmJlejFBd0o5b3F5SHZoZ3ZnRE9pSE9vd3BCZHlSWXlrZEQyc3ZpNTBx?= =?utf-8?B?MzIzZVlwbGhISC91Qk9qcWs2VzVHdlg3QkgybFJUZWY2b2xkMmFneEhweEd3?= =?utf-8?B?R3NrTzZzWklCMTVmMnNKMG5FRmlXeVlvQXZLSm9IYjMzUlMrRzdXajlZWXds?= =?utf-8?B?VzA2L0VzZmlvUzhwYlBGbUNhc3dtanpOTkdERkErK3ErQlJDNW1hb0QwY1Vj?= =?utf-8?B?V21FdC9EZWQ5V2FBNTVhUWZCZFNOK2JkRDhrWFlHVHV4QmNjSE04ektwKy83?= =?utf-8?B?cmRZL0FLMy9kWDBhb2dHc0pRbmtROFUvMFBRT1hsU3dPQ2h5VVNYTzVuQzJL?= =?utf-8?B?T3JKTlNCdlBzK3hFUWMybnBWVnVMMU9MZStnRFcvNjVqUlR3VUxDeG1BcS9T?= =?utf-8?B?Z2xNcDJxS0RObkZEYlowRnBEUWRZSTlpWXBhSnNJbzluRWxhZEgrRlg2aDRJ?= =?utf-8?B?TmVvVTBhK3IvWUNxMjZZQklPUURWelZJd25wN0xZcG5NKzJybmltTVRJYWYw?= =?utf-8?B?RHhSbVUrUnFVNlZaVDlXS0VQUVBubGdPTE9zL1RDcThsdkFpRWxyT0NacE5w?= =?utf-8?B?L3VxQlkzSm1DaHAwdFpJSEZWdysxT05IdG9KbGFKNUJ0MGZBWnR2QkZsbnZQ?= =?utf-8?B?eFJ4Q0t4dm1MWGhlVXViQkg3Q3pobUtwOFhVU2hHRklLZnFOcUdhMk9RUi92?= =?utf-8?B?KzVyeDhSTDBzS0Y5M0xjTlZkMTdLT1p5MjlzVm5RQWhGZkloaWJrOUlpekRE?= =?utf-8?B?Q0tiK2xoQVhJZTJsby9ITTNYU3Y5UVltVU8zZkVqc2s1TExyUFpuUk1BeTdK?= =?utf-8?B?bStzamhwNXdWN2xraEZTakZsMy9tSDFPSnBuYllUSG9NYU1JelY0SlRZUGxV?= =?utf-8?B?OWRCYnAycDVMY2dTdVBjbVViS1hCbUV2VVQ0dWVxNGZlZkdEU0FqNmRVaktW?= =?utf-8?B?aThITlpDSGpOSkRmeXZGamFuUTVuWFVQMnJRUFJwTldTVlVBdlVPa2VlV1k1?= =?utf-8?B?TWZIeDFjWmV3azhvS3pGTEx1dWlmTEVwWnpJaVNXc1hvbHF6QmtNSDlzT3A1?= =?utf-8?B?QlJPM0dtd3gwMGJWNnZlMWlkYjFuUHZjWm1DNXorZWFnYWxsZzJOU2VSVmh3?= =?utf-8?Q?irWHtRWd2pytg=3D?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BYAPR13MB2582F92B5BB44880ECE563DAF4F40BYAPR13MB2582namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR13MB2582.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fa35163c-47be-4f6b-7cdf-08d89596e873
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2020 01:17:44.8891 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: tm99Qj9on1XhFvEVuaiscDZZwWzVFp/dKtWK1aCYGozHYUaK2LF+NRUPzrHiwvSuqtj7b/rQ+OAbIlcmGLHGgg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3748
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/FoGtGT0C4AvaT03Hagxbz-KmPuI>
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, 01 Dec 2020 01:17:50 -0000

Thank you Greg. The rest of the wg agrees with Stig that this is ready for publication. I’ll shepherd it along to the iesg.

mike

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Monday, November 30, 2020 2:12 PM
To: Stig Venaas <stig@venaas.com>
Cc: Michael McBride <michael.mcbride@futurewei.com>om>; pim@ietf.org
Subject: Re: [pim] draft-ietf-pim-bfd-p2mp-use-case WGLC

Hi Stig,
thank you for your comments and quick response. I'll upload the new version shortly.

Regards,
Greg

On Mon, Nov 30, 2020 at 2:04 PM Stig Venaas <stig@venaas.com<mailto:stig@venaas.com>> wrote:
Hi Greg

This looks great. As a working group participant, I believe the draft
is ready for publication once these changes are made.

Regards,
Stig

On Thu, Nov 26, 2020 at 8:07 PM Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:
>
> Hi Stig,
> thank you for your comments and suggestions. Please find proposed updates below tagged GIM>>.
> Attached is the diff highlighting the proposed updates.
>
> Regards,
> Greg
>
> On Tue, Nov 24, 2020 at 11:33 AM Stig Venaas <stig@venaas.com<mailto: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.
>
> GIM>> Perhaps the following update of the last paragraph in the Introduction give additional information:
> OLD TEXT:
>    Bidirectional Forwarding Detection (BFD) [RFC5880] had been
>    originally defined to detect failure of point-to-point (p2p) paths -
>    single-hop [RFC5881], multihop [RFC5883].  [RFC8562] extends the BFD
>    base specification [RFC5880] for multipoint and multicast networks,
>    which precisely characterizes deployment scenarios for PIM-SM over
>    LAN segment.  This document demonstrates how point-to-multipoint
>    (p2mp) BFD can enable faster detection of PIM-SM router failure and
>    thus minimize multicast service disruption.  The document also
>    defines the extension to PIM-SM [RFC7761] and
>    [I-D.ietf-pim-dr-improvement] to bootstrap a PIM-SM router to join in
>    p2mp BFD session over shared-media link.
> NEW TEXT:
>    Bidirectional Forwarding Detection (BFD) [RFC5880] had been
>    originally defined to detect failure of point-to-point (p2p) paths -
>    single-hop [RFC5881], multihop [RFC5883].  In some PIM-SM
>    deployments, a p2p BFD can be used to detect a failure and enable
>    faster conversion.  [RFC8562] extends the BFD base specification
>    [RFC5880] for multipoint and multicast networks, which precisely
>    characterizes deployment scenarios for PIM-SM over a LAN segment.
>    Among specific characteristics of p2mp BFD that are particularly
>    benefit PIM-SM over a LAN segment is a faster transition to the Up
>    state of the p2mp BFD session due to avoidance of the three-way
>    handshake required in p2p BFD [RFC5880].  Also, because the router
>    that transmits BFD Control messages uses the BFD Demand mode
>    [RFC5880] it maintains less BFD state comparing to the Asynchronous
>    mode.  This document demonstrates how point-to-multipoint (p2mp) BFD
>    can enable faster detection of PIM-SM router failure and thus
>    minimize multicast service disruption.  The document also defines the
>    extension to PIM-SM [RFC7761] and [I-D.ietf-pim-dr-improvement] to
>    bootstrap a PIM-SM router to join in p2mp BFD session over shared-
>    media link.
>>
>>
>> Typo here:
>> p2mp: Pont-to-Multipoint
>
> GIM>> Thank you. fixed
>>
>>
>> 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?
>
> GIM>> BFD TLV only applies to p2mp BFD as defined in RFC 8562. BFD TLV is defined in Section 3 and its format referenced in the following sentence:
>    Figure 1 displays the new optional BFD
>    Discriminator PIM Hello Option to bootstrap tail of the p2mp BFD
>    session.
> Also, when explaining the use of the fields, we've defined My Discriminator field as:
>       My Discriminator - My Discriminator value allocated by the root of
>       the p2mp BFD session.
> Would you recommend an additional text to stress that the BFD TLV can bootstrap only p2mp BFD session?
>>
>>
>> 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.
>
> GIM>> I've added notes in the first paragraph of Section 3.1 to emphasize that any PIM-SM router that supports the draft may include the BFD TLV in its Hello, transmit BFD Control packet and, as a result, be monitored by other PIM-SM routers on that LAN segment. Please let me know if the updated text conveys that message:
> OLD TEXT:
>    If PIM-SM routers that support this specification are configured to
>    use p2mp BFD for faster convergence, then the router to be monitored,
>    referred to as 'head', MUST create BFD session of type
>    MultipointHead, as defined in [RFC8562].  If the head doesn't support
>    [I-D.ietf-pim-dr-improvement], but, for example, uses procedures
>    defined in [I-D.mankamana-pim-bdr], then it MUST include BFD TLV in
>    its PIM-Hello message.  If the head uses extensions defined in
>    [I-D.ietf-pim-dr-improvement], then DR MUST include BFD TLV in its
>    Hello message.  The DR Address TLV also MUST be included in the Hello
>    message.  For a BDR it is RECOMMENDED to include BFD TLV in its Hello
>    message.  If BDR includes BFD TLV, then the BDR Address TLV also MUST
>    be present in the Hello message.  Then the head MUST begin periodic
>    transmission of BFD control packets.  Source IP address of the BFD
>    control packet MUST be the same as the source IP address of the PIM-
>    Hello with BFD TLV messages being transmitted by the head.  The
>    values of My Discriminator in the BFD control packet and My
>    Discriminator field of the BFD TLV in PIM-Hello, transmitted by the
>    head MUST be the same.  When a PIM-SM router is configured to monitor
>    the head by using p2p BFD, referred to through this document as
>    'tail', receives PIM-Hello packet with BFD TLV it MAY create p2mp BFD
>    session of type MultipointTail, as defined in [RFC8562].
> NEW TEXT:
>    If PIM-SM routers that support this specification are configured to
>    use p2mp BFD for faster convergence, then the router to be monitored,
>    referred to as 'head', MUST create a BFD session of type
>    MultipointHead, as defined in [RFC8562].  Note that any PIM-SM router
>    that supports this specification, regardless of its role in PIM-SM,
>    MAY become a head of a p2mp BFD session.  If the head doesn't support
>    [I-D.ietf-pim-dr-improvement], but, for example, uses procedures
>    defined in [I-D.mankamana-pim-bdr], then it MUST include BFD TLV in
>    its PIM-Hello message.  If the head uses extensions defined in
>    [I-D.ietf-pim-dr-improvement], then DR MUST include BFD TLV in its
>    Hello message.  The DR Address TLV also MUST be included in the Hello
>    message.  For a BDR, it is RECOMMENDED to include BFD TLV in its
>    Hello message.  If BDR includes BFD TLV, then the BDR Address TLV
>    also MUST be present in the Hello message.  As mentioned earlier, any
>    non-DR and non-BDR MAY include BFD TLV in its Hello message.  Then
>    the head MUST begin periodic transmission of BFD control packets.
>    The Source IP address of the BFD control packet MUST be the same as
>    the source IP address of the PIM-Hello with BFD TLV messages being
>    transmitted by the head.  My Discriminator's field value in the BFD
>    Control packet and My Discriminator field of the BFD TLV in PIM-
>    Hello, transmitted by the head, MUST be the same.  When a PIM-SM
>    router is configured to monitor the head by using p2mp BFD, referred
>    to through this document as 'tail', receives PIM-Hello packet with
>    BFD TLV, the tail MAY create a p2mp BFD session of type
>    MultipointTail, as defined in [RFC8562].
>>
>>
>> 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?
>
> GIM>> Thank you for the questions. p2mp BFD inherits authentication mechanisms defined in the base BFD specification, in RFC 5880. I think that there is no dependency and each protocol, PIM and BFD, could be used in the authenticated mode or not. I propose inserting the following paragraph in the Security Considerations section as the second paragraph in the section:
> NEW TEXT:
>     PIM-SM link-local messages can be authenticated using various
>    mechanisms, as described in Section 6.3 [RFC7761].  Authentication of
>    BFD Control messages defined in Section 6.7 [RFC5880].  Each protocol
>    MAY use authentication of its messages independently of the mode used
>    by the other protocol.
>>
>>
>> Regards,
>> Stig
>>
>> On Fri, Nov 6, 2020 at 1:10 PM Michael McBride
>> <michael.mcbride@futurewei.com<mailto: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<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-pim-bfd-p2mp-use-case-04&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C355e70d7a56a4c23986e08d8957cf6fc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637423711252146490%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=w6NBL7pVWsNtzeVEbTq8oQFZKxcbS3JeMn1b9tDmyo4%3D&reserved=0>amp;reserved=0>.
>> >
>> >
>> >
>> > Please share your opinions on the readiness of this draft to be sent to the iesg.
>> >
>> >
>> >
>> > Thanks,
>> >
>> > mike
>> >
>> > _______________________________________________
>> > pim mailing list
>> > pim@ietf.org<mailto:pim@ietf.org>
>> > https://www.ietf.org/mailman/listinfo/pim<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C355e70d7a56a4c23986e08d8957cf6fc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637423711252156493%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=m7DnCnnPKL46l9dEFjVHrTzJ3TVSJxNWU3QY3XR7ngg%3D&reserved=0>
>>
>> _______________________________________________
>> pim mailing list
>> pim@ietf.org<mailto:pim@ietf.org>
>> https://www.ietf.org/mailman/listinfo/pim<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C355e70d7a56a4c23986e08d8957cf6fc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637423711252156493%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=m7DnCnnPKL46l9dEFjVHrTzJ3TVSJxNWU3QY3XR7ngg%3D&reserved=0>