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

[Greg Mirsky <[e-mail]>]

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]> 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]> 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]> 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]> 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
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/pim
> >>
> >> _______________________________________________
> >> pim mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/pim
>