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

[Michael McBride <[e-mail]>]

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 <[e-mail]>
Sent: Monday, November 30, 2020 2:12 PM
To: Stig Venaas <[e-mail]>
Cc: Michael McBride <[e-mail]>; [e-mail]
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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
>> <[e-mail]<mailto:[e-mail]>> 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>.
>> >
>> >
>> >
>> > Please share your opinions on the readiness of this draft to be sent to the iesg.
>> >
>> >
>> >
>> > Thanks,
>> >
>> > mike
>> >
>> > _______________________________________________
>> > pim mailing list
>> > [e-mail]<mailto:[e-mail]>
>> > 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
>> [e-mail]<mailto:[e-mail]>
>> 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>