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

From: Michael McBride <[email-masked]>
Date: Fri, 6 Nov 2020 21:10:22 +0000

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

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 9 Nov 2020 08:55:58 -0800

Hi Mike, Stig and All,
as co-author, I support the progress of this draft. I believe that the
proposed solution can improve the convergence in PIM-SM networks.

Also, I am not aware of any other than the disclosed IPR that is related to
this draft.

Regards,
Greg

On Fri, Nov 6, 2020 at 1:10 PM Michael McBride <
[email-masked]> 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.
>
>
>
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim
>

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 9 Nov 2020 10:18:39 -0800

Yes/support

Regards,
Jeff
> 
>> On Fri, Nov 6, 2020 at 1:10 PM Michael McBride <[email-masked]> wrote:
>> Hello people of pim,
>> 
>>  
>>

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 9 Nov 2020 18:33:14 +0000

Yes support, very useful

Thanks
Hooman

From: pim <[email-masked]> On Behalf Of Michael McBride
Sent: Friday, November 6, 2020 4:10 PM
To: [email-masked]
Subject: [pim] draft-ietf-pim-bfd-p2mp-use-case WGLC

Hello people of pim,

Thanks,
mike

---

From: <[email-masked]>
Date: Tue, 10 Nov 2020 08:54:35 +0800 (CST)

Support the advancement of this draft.

Thanks,

Sandy

原始邮件

发件人：MichaelMcBride
收件人：[email-masked];
日 期 ：2020年11月07日 05:10
主 题 ：[pim] draft-ietf-pim-bfd-p2mp-use-case WGLC

Hello people of pim,

 

 

Thanks,

mike

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 12 Nov 2020 22:11:23 -0500

I support advancement.

Thanks

Gyan

On Mon, Nov 9, 2020 at 7:55 PM <[email-masked]> wrote:

> *发件人：*MichaelMcBride
> *收件人：[email-masked];
> *日 期 ：*2020年11月07日 05:10
> *主 题 ：**[pim] draft-ietf-pim-bfd-p2mp-use-case WGLC*
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Stig Venaas <[email-masked]>
Date: Tue, 24 Nov 2020 11:32:49 -0800

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

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 24 Nov 2020 14:30:18 -0800

Yes/support

Cheers,
Jeff

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 24 Nov 2020 14:55:49 -0800

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

---

From: Stig Venaas <[email-masked]>
Date: Mon, 30 Nov 2020 14:03:52 -0800

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 <[email-masked]> 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
>
> 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
>>
>>
> 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?
>>
>>
> 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:
> 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
>>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 30 Nov 2020 14:11:48 -0800

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 <[email-masked]> wrote:

> > GIM>> Perhaps the following update of the last paragraph in the
> Introduction give additional information:
> > OLD TEXT:
> > 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:
> > 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:
> > 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:

---

From: Michael McBride <[email-masked]>
Date: Tue, 1 Dec 2020 01:17:44 +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 <[email-masked]>
Sent: Monday, November 30, 2020 2:12 PM
To: Stig Venaas <[email-masked]>
Cc: Michael McBride <[email-masked]>; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg

Regards,
Stig

On Thu, Nov 26, 2020 at 8:07 PM Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
> On Tue, Nov 24, 2020 at 11:33 AM Stig Venaas <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Hi
>>
>> <[email-masked]<mailto:[email-masked]>> 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>.
>> >
>> >
>> >
>> > [email-masked]<mailto:[email-masked]>
>> > 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>
>>
>> [email-masked]<mailto:[email-masked]>
>> 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>