Subject: Re: [pim] AD Review of draft-ietf-pim-bfd-p2mp-use-case-05

From: Alvaro Retana <[email-masked]>
Date: Wed, 1 Sep 2021 15:41:12 +0200

On August 31, 2021 at 4:51:17 PM, Jeffrey Haas wrote:

Jeff:

Hi!  Thanks for looking at this document!

...
> If I were to re-state the longer version of the draft's name, this is
> effectively "using BFD-MP to let PIM hello procedures fail faster". If
> that's an adequate assessment, perhaps the title might be adjusted a bit.
>
> I think Alvaro's point is that this is really covering a small bit of
> PIM procedure and it sounds like it's intended to be a lot more broad from
> the document title.

Yup, that's the point. :-)

...
> My second concern is shorter. Section 2.3 recommends that the p2mp BFD
> sessions use a TTL of 255 and reference the GTSM procedures in RFC 5881.
> However, since the destination address is a multicast group and the
> underlying PIM protocol uses a TTL of 1 for its messages, I'm not sure the
> 255 is appropriate for this use case.

The draft originally (-05) required using a TTL of 1, but I asked Greg
to change it because both rfc5880/rfc5881 require the use of GTSM --
they don't talk about any exceptions, and rfc8562 doesn't mention TTL
at all.

I find it very hard to justify a change in the BFD requirements; the
BFD documents specify what the BFD behavior is, independent of the
application.  In this case, PIM just benefits from it.

I'm not saying that the requirements can't be changed -- but if we
were going to do that we would need some more discussion in the BFD
WG.

Thanks!

Alvaro.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 1 Sep 2021 11:08:02 -0400

Alvaro,

> they don't talk about any exceptions, and rfc8562 doesn't mention TTL

Pedantically, I can't disagree with you.  RFC 5881 doesn't discuss whether
the destination address of the UDP encapsulated address must be an IP
unicast address.  But I had to check, because that's not a case I've seen
before.

> were going to do that we would need some more discussion in the BFD

I had a conversation with Lenny Giuliano to try to get a sense of what other
multicast forwarding mechanisms might take advantage of GTSM.  He wasn't
aware of any.  So, we might be in somewhat new territory.

One of his points is that 224/24 is flagged for IPV4 link local multicast by
convention and long history.  This means that to a great extent my concern
is irrelevant.  A non-1 TTL should not result in propagation when sent to
the IPv4 all-pim-routers group.

For IPv6 encapsulation, it's explicitly tagged as a link-local group and is
not a consideration.

So, for purposes of this internet-draft, I think my concern is irrelevant.

That said, I think we should clarify GTSM for multicast scenarios.  It's
fine for link local but may have concerns if it's part of a group that is
propagated.

-- Jeff

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 9 Sep 2021 16:57:46 -0700

Hi Jeff,
thank you for your detailed and thoughtful comments. I've followed your
suggestions and updated the working version as follows:

   - re-worded the long title to be "Fast Failover in Protocol Independent
   Multicast - Sparse Mode (PIM-SM) Using Bidirectional Forwarding Detection
   (BFD) for Multipoint Networks". It does read a bit long. Do you think using
   acronyms without the extended versions is acceptable? That might be "Fast
   Failover in PIM-SM Using BFD for Multipoint Networks". What do you think?
   - Added the following text to the first paragraph in Section 2.1:

NEW TEXT:
   To control the volume of BFD control
   traffic on a shared media segment, an operator should carefully
   select PIM-SM routers configured as a head of a p2mp BFD session.
   The head MUST include the BFD Discriminator option in its Hello
   messages.

Attached, please find the updated working version of the draft along with
the diff.

I greatly appreciate your feedback on the changes.

Regards,
Greg

On Tue, Aug 31, 2021 at 1:51 PM Jeffrey Haas <[email-masked]> wrote:

> Mike,
>
> Thanks for bringing this to the BFD Working Group.  I've had a chance to
> read through the draft.  In spite of it being several years since I've
> worked on/with PIM, I think I've understood it. :-)
>
> The procedures seem to be largely straight-forward, as long as you're
> comfortable with the error handling procedures for the wrong OptionLength.
> Perhaps alternatively if this field is the incorrect length you simply
> ignore the procedure rather than stopping the processing of PIM.  That
> said,
> do whatever is normative within the protocol for such cases.
>
> My two remaining comments are one operational one, and one related to
> forwarding:
>
> As written, any PIM speaker could become a BFD MultiPointHead.  This
> theoretically means that on a busy LAN segment you can get a lot of chatty
> multi-point BFD traffic.  I realize that typical PIM deployments mean that
> this is less likely to happen.
>
> Since PIM is used to build multicast trees, realistically you only need the
> MultiPointHead procedures to be running on upstream nodes.  At typical
> multicast endpoints, it's usually clear what the upstreams will be.  At
> other arbitrary points in the network, this is less clear but those are
> typically not LAN segments.
>
> If there's text to operationally suggest that you only do the
> MultiPointHead
> configuration on appropriate nodes, that may be helpful.
>
> If there is documentation in PIM for the use of GTSM procedures, I'd
> suggest
> referencing those procedures in this draft.
>
> -- Jeff
>
>
> On Fri, Aug 20, 2021 at 08:05:10PM +0000, Reshad Rahman wrote:
> >  Thanks Michael.  Adding BFD WG.
> >
> > Regards,Reshad.
> > -----Original Message-----
> > From: pim <[email-masked]> On Behalf Of Michael McBride
> > Sent: Tuesday, August 17, 2021 10:53 PM
> > To: Alvaro Retana <[email-masked]>; [email-masked]
> > Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> > Subject: Re: [pim] AD Review of draft-ietf-pim-bfd-p2mp-use-case-05
> >
> > Hi Greg,
> >
> > Please consider either 1) dropping the "use-case" from the draft name
> and keep it a specific pim-bfd-p2mp solution and less generalized or 2)
> keeping the existing name and make it more generalized with more use cases
> as Alvaro suggests.
> >
> > I'll ping the bfd chairs and cc you to ensure they are in the loop.
> >
> > Thanks,
> > mike
> >
> > -----Original Message-----2021-02-04-Network TMT Meetings :
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fefutureway.sharepoint.com%2Fteams%2FNetworkLabTMT%2FShared&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C58e9d5e586be49da514708d9620c8c21%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637648628320865112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=AlTELyg1EqhpLnl8aYSCv9YKEH6zldm46UVAx8MZaus%3D&reserved=0
> Documents/General/Network Lab TMT Meeting/February 4 2021
> Meeting/2021-02-04-Network TMT Meetings.pptx?web=1G
> > From: pim <[email-masked]> On Behalf Of Alvaro Retana
> > Sent: Tuesday, August 17, 2021 8:19 AM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> > Subject: Re: [pim] AD Review of draft-ietf-pim-bfd-p2mp-use-case-05
> >
> > On July 21, 2021 at 7:42:42 PM, [email-masked] wrote:
> >
> >
> > Greg:
> >
> > Hi!
> >
> > Thanks for the update!!
> >
> > I have some comments in-line.  I am also attaching (below) a review of
> -06, which mostly contains minor issues and nits related to new/updated
> text.
> >
> >
> > The main item I would like WG input on is the generalization of the
> mechanism.  In short, bootstrapping the BFD session is the main focus of
> this document; I don't see a reason to avoid generalizing its use to other
> scenarios.  We already agree on the wider applicability -- the incremental
> changes needed to generalize the text is far less than the process it will
> take to do it later.
> >
> > Mike: as Shepherd/Chair, please start a conversation in the WG as
> needed.  Please take a look at the discussion below.
> >
> >
> > Thanks!
> >
> > Alvaro.
> >
> >
> >
> > ...
> > > Sender: AlvaroRetana
> > ...
> > > This document specifies two things: (1) a Hello option to help the
> > > tail bootstrap the BFD session, and, (2) the actions that the tail
> > > takes when a failure is detected. The former is common to all cases,
> > > while the latter depends on the role of the head with respect to the
> > > tail. The actions are basically an acceleration of what would
> > > naturally happen (if BFD was not used and the failure detection was
> > > "slow"). Is this a fair characterization of the document?
> >
> > GIM>> Yes, absolutely correct.
> >
> > ...
> > > Are there other cases that could use this mechanism to track? I can
> > > think of a couple of cases: monitor PIM neighbors that send Joins, RPF
> > > neighbors, Assert winners... As with the DR case, for example, these
> > > cases don't require actions beyond an acceleration. It would be ideal
> > > if the document could cover these cases, and possibly others, in a
> > > generic way -- I can't think of good phrasing with now, but I'm sure
> > > you can. ;-)
> >
> > GIM>> I agree that the defined PIM Hello BFD Discriminator option can be
> > GIM>> used by not only PIM DR/BDR nodes. Indeed, there are other use
> > GIM>> cases where a faster detection will improve the convergence in the
> > GIM>> control plane and minimize the negative impact on the multicast
> > GIM>> data plane. These use cases may be covered in the future.
> >
> > Maybe I'm missing something obvious, and would like to understand what.
> :-)
> >
> > The Hello option helps the tail bootstrap a BFD session, correct?  If
> so, there's nothing in that description about the function of the tail (or
> the head).  The point that I'm trying to make above is that the only thing
> that BFD is providing any use case is faster detection of a failure (which
> is very significant, of course!), so regardless of the application or
> function of the tail/head, the operation can be generalized.  Is this not
> true?  What am I missing?
> >
> > To be more specific, the description in §2.1 (Using P2MP BFD in PIM
> DR/BDR Monitoring) is a generic description, and not one that only applies
> to a DR/BDR.  In fact, the text says that any node "regardless of its role,
> MAY become a head of a p2mp BFD session" -- which means that it is up to
> the tail to monitor it or not.
> >
> > The last two paragraphs in §2.1 do mention the DR/BDR function, but they
> could easily be generalized:
> >
> > OLD>
> >    If the tail detects a MultipointHead failure [RFC8562], it MUST
> >    delete the corresponding neighbor state.  If the failed head was the
> >    DR (or BDR), the DR (or BDR) election mechanism in [RFC7761] or
> >    [I-D.ietf-pim-dr-improvement] is followed.
> >
> >    If the head ceases to include the BFD Discriminator PIM Hello option
> >    in its PIM-Hello message, tails MUST close the corresponding
> >    MultipointTail BFD session.  Thus the tail stops using BFD to monitor
> >    the head and reverts to the procedures defined in [RFC7761] and
> >    [I-D.ietf-pim-dr-improvement].
> >
> >
> > NEW>
> >    If the tail detects a MultipointHead failure [RFC8562], it MUST
> >    delete the corresponding neighbor state.  If the head ceases to
> >    include the BFD Discriminator PIM Hello option in its PIM-Hello
> >    message, tails MUST close the corresponding MultipointTail BFD
> >    session.  In both cases, the tail continues to follow the
> >    specification related to the function of the head.
> >
> >
> >
> > GIM>> As I think of it, one aspect would be homogeneity of p2mp BFD
> > GIM>> capability throughout the domain. In other words, what happens if
> > GIM>> some PIM nodes don't support the BFD Discriminator option and do
> > GIM>> not use p2mp BFD? What their slow (regular) convergence impact
> > GIM>> other nodes? But that, I think, is for further discussion, work.
> Would you agree?
> >
> > I don't.
> >
> > In fact, this is a very important deployment point that I had
> overlooked.  If the support is not homogeneous, then some parts of the
> network will converge (to the new state) faster than others. As with
> unicast routing I think the main effect may be longer than expected
> inconsistency, but not worst than without BFD.  The specific effect relates
> to the use case...but because the deployment would be localized (the DR and
> other routers on the LAN, for example), then any negative effect of not
> supporting BFD (i.e. behaving as today) would be localized.
> >
> > Thank you for bringing this up.  If you consider the effect significant
> for a specific case then please add a couple of sentences.
> >
> >
> > ...
> > > 183 3.1. Using P2MP BFD in PIM DR/BDR Monitoring
> > ...
> > > 229 If the head ceased to include BFD TLV in its PIM-Hello message,
> > > tails
> > > 230 MUST close the corresponding MultipointTail BFD session. Thus the
> > > 231 tail stops using BFD to monitor the head and reverts to the
> > > 232 procedures defined in [RFC7761] and [I-D.ietf-pim-dr-improvement].
> > ...
> > > [major] Let me see if I understand: if the head doesn't use the BFD
> > > hello option anymore then the tail can gracefully stop using BFD.
> > > IOW, this way the BFD session does not expire and result in the DR
> > > being declared dead. Is that it?
> >
> > GIM>> Yes, that is what we've intended - revert to "slow" detection.
> >
> > > Given that the BFD session can be bootstrapped at the tail by manually
> > > configuring the corresponding discriminator, it seems that stopping
> > > the use of the BFD hello option may not result in the expected
> > > outcome. ???
> >
> > GIM>> Yes, the head's My Discriminator value can be provisioned using
> > GIM>> the management plane. If that is the case, then I think this
> > GIM>> document is not applicable as the head and leaves use RFC 8562
> without any additions.
> >
> > The problem is that the text now says this:
> >
> >    If the head ceases to include the BFD Discriminator PIM Hello option
> >    in its PIM-Hello message, tails MUST close the corresponding
> >    MultipointTail BFD session.  Thus the tail stops using BFD to monitor
> >    the head...
> >
> > s/MUST/SHOULD   Provisioning the node is the exception, so the action
> should be recommended and not required.
> >
> >
> > ...
> > > 288 5. Security Considerations
> > ...
> > > 299 An implementation that supports this specification SHOULD use a
> > > 300 mechanism to control the maximum number of BFD sessions that can
> > > be
> > > 301 active at the same time.
> > >
> > > [major] rfc8562 already requires "protective measures to prevent an
> > > infinite number of MultipointTail sessions from being created". It is
> > > then not needed for this document to recommend anything that is
> > > required elsewhere.
> >
> > GIM>> Done.
> >
> > ??  You left the paragraph in.
> >
> >
> > > [major] What new security risks are introduced by the mechanism in
> > > this draft? In general, a rogue node can stop sending or delay BFD
> > > packets causing the tail to conclude that the head is down: the DR/BDR
> > > may change causing instability. I was surprised that rfc8562 did not
> > > mention the interaction risk, but rfc5880 already does. I feel that
> > > something needs to be mentioned specific to this document, even if it
> > > is highlighted that the risk is not new.
> >
> > GIM>> Then that "rogue" node is the PIM DR/BDR, not a man-in-the-middle.
> > GIM>> And the attack is by making the p2mp BFD session expire on leaves
> > GIM>> while still periodically sending PIM Hello. AFAIK, since PIM
> > GIM>> DR/BDR election takes several Hello cycles, I don't think that
> > GIM>> that behavior will affect the multicast service. Perhaps I'm
> missing something, please advise.
> >
> > Yes, the problem is that §2.1 says that the tail "MUST delete the
> corresponding neighbor state".  This results in the DR not being elected
> for a while.
> >
> > I see what you mean: if the DR is still there then the election will
> probably elect it again.  However, in the meantime the DR may not think it
> is the DR anymore if the other routers in the LAN start a new DR election.
> (??)   Please add the explanation (or something like it) to make it clear
> that the risk is mitigated by the "double set of hellos".
> >
> > In the general case...  If tracking the sender of a Join, for example,
> the effect would be more significant: an outage would exist until the next
> Join is received.
> >
> >
> > ...
> > > 310 7.1. Normative References
> > > ..
> > > 327 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding
> > > Detection
> > > 328 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
> > > 329 DOI 10.17487/RFC5881, June 2010,
> > > 330 .
> > >
> > > [minor] This reference can be Informative.
> >
> > I know you moved it...but now that you added a reference to it in §2.3
> then we need it to be Normative.  Sorry.
> >
> >
> > ...
> > > [End of review -05.]
> >
> >
> >
> > [Start -06]
> > [Line numbers from idnits.]
> >
> > ...
> > 129    2.  BFD Discriminator PIM Hello Option
> > ...
> > 153      If the value of the OptionLength field is not equal to 4, the
> BFD
> > 154      Discriminator PIM Hello option is considered malformed, and the
> > 155      receiver MUST stop processing PIM Hello options.  If the value
> of the
> > 156      My Discriminator field equals zero, then the BFD Discriminator
> PIM
> > 157      Hello option MUST be considered invalid, and the receiver MUST
> ignore
> > 158      it.  The receiver SHOULD log the notification regarding the
> malformed
> > 159      or invalid BFD Discriminator Hello option under the control of a
> > 160      throttling logging mechanism.
> >
> > [major] "MUST stop processing PIM Hello options"
> >
> > Stop in the current Hello message?  Should it ignore all the options or
> just the ones after this one?  In all future Hello messages?
> >
> > I haven't thought about this enough, but there could be an effect on
> other functionality.  What is that effect?  I couldn't find anywhere a
> general way to handle malformed Hello options -- did I miss it?
> >
> >
> > [nit] s/log the notification/log a notification
> >
> >
> > 162    2.1.  Using P2MP BFD in PIM DR/BDR Monitoring
> > ...
> > 169      If a PIM-SM router is configured to monitor the head by using
> p2mp
> > 170      BFD, referred to through this document as 'tail', receives
> PIM-Hello
> > 171      packet with BFD Discriminator PIM Hello option, the tail MAY
> create a
> > 172      p2mp BFD session of type MultipointTail, as defined in
> [RFC8562].
> >
> > [minor] s/router is configured/router that is configured
> >
> > [nit] s/receives PIM-Hello packet with BFD Discriminator/receives a
> PIM-Hello packet with the BFD Discriminator
> >
> >
> > ...
> > 188      If the head ceases to include the BFD Discriminator PIM Hello
> option
> > 189      in its PIM-Hello message, tails MUST close the corresponding
> > 190      MultipointTail BFD session.  Thus the tail stops using BFD to
> monitor
> > 191      the head and reverts to the procedures defined in [RFC7761] and
> > 192      [I-D.ietf-pim-dr-improvement].
> >
> > [minor] "...MUST close the corresponding MultipointTail BFD session"
> >
> > It might be a good thing adding that the PIM state is not affected by
> this action.
> >
> >
> > 194    2.2.  P2MP BFD in PIM DR Load Balancing
> >
> > 196      [RFC8775] specifies the PIM Designated Router Load Balancing
> (DRLB)
> > 197      functionality.  Any PIM router that advertises the DRLB-Cap
> Hello
> > 198      Option can become the head of a p2mp BFD session, as specified
> in
> > 199      Section 2.1.  The head router administratively sets the
> > 200      bfd.SessionState to Up in the MultipointHead session [RFC8562]
> only
> > 201      if it is a Group Designated Router (GDR) Candidate, as
> specified in
> > 202      Sections 5.5 and 5.6 of [RFC8775].  If the router is no longer
> the
> > 203      GDR, then it MUST shut down following the procedures described
> in
> > 204      Section 5.9 [RFC8562].  For each GDR Candidate that includes BFD
> > 205      Discriminator option in its PIM Hello, the PIM DR creates a
> > 206      MultipointTail session [RFC8562].  PIM DR demultiplexes BFD
> sessions
> > 207      based on the value of the My Discriminator field and the source
> IP
> > 208      address.  If PIM DR detects a failure of one of the sessions,
> it MUST
> > 209      remove that router from the GDR Candidate list and immediately
> > 210      transmit a new DRLB-List option.
> >
> > [] Continuing with my theme of generalizing this specification...
> > This section says everything that the last section already specified in
> a generic way.  IOW, it is not really needed.
> >
> > There is one thing that this paragraph adds: "If the router is no longer
> the GDR, then it MUST shut down following the procedures described in
> Section 5.9 [RFC8562]."   Yes, shutting down the BFD session is important,
> but so is not including the BFD Discriminator option in the Hello anymore.
> As with everything else, this part can also be generalized:
> >
> >    If the head is no longer serving the function that prompted it
> >    to be monitored, then it MUST cease including the BFD Discriminator
> >    PIM Hello option in its PIM-Hello message, and it MUST shut down
> >    the BFD session following the procedures described in Section 5.9
> >    [RFC8562].
> >
> >
> > 212    2.3.  Multipoint BFD Encapsulation
> >
> > 214      The MultipointHead of a p2mp BFD session when transmitting BFD
> > 215      Control packet:
> >
> > [nit] s/packet/packets
> >
> >
> > 217         MUST set TTL or Hop Limit value to 255 (Section 5 [RFC5881]);
> >
> > [major] "MUST set...RFC5881"   This action is already required in an RFC
> that this document depends on, please don't specify the behavior again.  I
> understand that rfc5682 can be used in multi-hop scenarios, but rfc5881 is
> the source here.    s/MUST/must
> >
> >
> > ...
> > 222    3.  IANA Considerations
> > ...
> > 227
> +=============+================+===================+===============+
> > 228      | Value Name  | Length Number  | Name Protocol     | Reference
>     |
> > 229
> +=============+================+===================+===============+
> > 230      | TBA         | 4              | BFD Discriminator | This
> document |
> > 231      |             |                | Option            |
>     |
> > 232
> +-------------+----------------+-------------------+---------------+
> >
> > [major] Please use the same field names as in the registry: Value,
> Length, Name, Reference
> >
> > [EoR -06]
> >
> > _______________________________________________
> > pim mailing list
> > [email-masked]
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C58e9d5e586be49da514708d9620c8c21%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637648628320865112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=zhFkLPkgOJ9EeuloewKnNDe75JqgzbOWdfV3%2Bd5EBRk%3D&reserved=0
> >
> > _______________________________________________
> > pim mailing list
> > [email-masked]
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C58e9d5e586be49da514708d9620c8c21%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637648628320875108%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4SrgiS9qdwYswCMitpP4Qf1iWZ4zJkVauDz%2B4%2BKyvyA%3D&reserved=0
> >
>
>