Subject: [pim] Benjamin Kaduk's No Objection on draft-ietf-pim-bfd-p2mp-use-case-09: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Sat, 27 Nov 2021 18:26:26 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-pim-bfd-p2mp-use-case-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pim-bfd-p2mp-use-case/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Do we want to provide any guidance on how to configure the BFD
parameters (most notably the timeout intervals)?  (I assume the answer
is "no", but still have to ask.)

Section 1

   Among specific characteristics of p2mp BFD that 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].  [...]

I'm not sure I understand how this works.  RFC 8562 seems to require the
head node to stay in down state for the max timeout before transitioning
to "up" and starting to send control packets.  With a three-way
handshake there is immediate feedback at startup and, while there is a
round-trip cost incurred, there is no mandatory enforced delay.  Could
you say a bit more about which scenarios are being compared so that p2mp
BFD is faster to Up than p2p BFD?

                                                         Point-to-
   multipoint (p2mp) BFD can enable faster detection of PIM-SM router
   failure and thus minimize multicast service disruption.  [...]

Just to confirm: here, the comparison is PIM-SM without BFD against
PIM-SM with (p2mp) BFD, right?  So that we're going from 105 seconds to
potentially sub-second detection.  Assuming that, I'd consider "faster
detection of PIM-SM router failure compared to PIM-SM without BFD".

Section 2.1

   Note that any PIM-SM router, regardless of its role, MAY become a
   head of a p2mp BFD session.  [...]

While I don't see any problem with this behavior, I'm also a bit
confused as to when an arbitrary (i.e., non-RP) router would benefit
from being the head of a p2mp BFD session.  Also, RFC 7761 doesn't seem
to use "role" as a defined term, so there may be some room for
clarification if we had particular roles in mind.

   If a PIM-SM router is configured to monitor the head by using p2mp
   BFD, referred to through this document as 'tail', receives a PIM-
   Hello packet with the BFD Discriminator PIM Hello option, the tail

Since we're presuming that the tail is configured to monitor "the head",
does this behavior only apply to PIM-Hello packets received specifically
from "the head" (as opposed to all received PIM-Hello packets)?

   If the tail detects a MultipointHead failure [RFC8562], it MUST
   delete the corresponding neighbor state and follow procedures defined
   in [RFC7761].

Do we want to give a more precise reference for which RFC 7761
procedures are to be followed in this case?  (Perhaps, the
neighbor.timeout behavior?)  (Also, we might clarify that the neighbor
state being deleted is the PIM state, not the BFD state.)

Section 2.2

                 The head router administratively sets the
   bfd.SessionState to Up in the MultipointHead session [RFC8562] only
   if it is a Group Designated Router (GDR) Candidate, as specified in
   Sections 5.5 and 5.6 of [RFC8775].  If the router is no longer the
   GDR, then it MUST shut down following the procedures described in
   Section 5.9 [RFC8562].  [...]

There seems to be a slight mismatch, here -- we start the BFD session if
we're a GDR *Candidate*, and stop it if we're no longer *the GDR*.  So
what do we do if we are a candidate but not the selected GDR?

                           For each GDR Candidate that includes BFD
   Discriminator option in its PIM Hello, the PIM DR creates a
   MultipointTail session [RFC8562].  [...]

Interestingly, this seems to be a stronger requirement on the tail than
in the non-RFC8775 case, where we just say "MAY create a p2mp BFD
session of type MultipointTail".  It might be worth emphasizing the
contrast by using "MUST" here (assuming that the contrast is intended).

             If PIM DR detects a failure of one of the sessions, it MUST
   remove that router from the GDR Candidate list and immediately
   transmit a new DRLB-List option.

Is this "MUST ... immediately transmit" going to run any risk of causing
a traffic spike/congestion?  I find it unlikely, but am not really an
expert here.

Section 2.3

   The MultipointHead of a p2mp BFD session when transmitting BFD
   Control packets:

      MUST set TTL or Hop Limit value to 255 (Section 5 [RFC5881]);

Is there a corresponding requirement or recommendation on tails to
reject BFD Control packets with received TTL or Hop Limit not equal to
255?  Where is this requirement specified?

Section 4

   The security considerations discussed in [RFC7761], [RFC5880],
   [RFC8562], and [RFC8775] apply to this document.

Do the considerations of RFC 5881 also apply?

NITS

Section 1

   Bidirectional Forwarding Detection (BFD) [RFC5880] had been
   originally defined to detect a failure of a point-to-point (p2p)

I'd s/had been/was/ -- the "had been" verb tense feels out of place
here.

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 28 Nov 2021 13:17:45 -0800

Hi Ben,
thank you for the review and detailed comments. Please find my notes
in-lined below under the GIM>> tag. Attached is the diff that highlights
all proposed updates (these also include updates to address comments by
Martin).

Regards,
Greg

> https://datatracker.ietf.org/doc/draft-ietf-pim-bfd-p2mp-use-case/
GIM>> Thinking of your question, I've realized that this text is not
essential, doesn't lead to the solution. You're right, in some scenarios,
"classical" p2p RFC 5880-based BFD with the three-way handshake will be
reaching the Up state faster than for p2mp scenario with the
same bfd.DesiredMinTxInterval and bfd.DetectMult. But, as I've realized,
that is not why the described mechanism is based on p2mp BFD, and not on
p2p BFD. I propose removing the sentence and slightly rewording the next
one:
OLD TEXT:
   Also, because the router that
   transmits BFD Control messages uses the BFD Demand mode [RFC5880], it
   maintains less BFD state than the Asynchronous mode.
NEW TEXT:
   A BFD system in
   p2mp environment that transmits BFD Control messages uses the BFD
   Demand mode [RFC5880] creates less BFD state than the Asynchronous
   mode.

> detection of PIM-SM router failure compared to PIM-SM without BFD".
GIM>> You're interpretation of this text is correct. Thank you for the
suggested improvement.

> clarification if we had particular roles in mind.
GIM>> Thank you for the question. Our intention was to define a mechanism
that can be used in different scenarios, perhaps some that might not be
defined yet.

> from "the head" (as opposed to all received PIM-Hello packets)?
GIM>> The intended behavior is that a PIM-SM router may be enabled as a
tail for all possible heads on the given LAN segment. On the other hand, it
can be more restrictive and act the BFD Discriminator option from the
particular PIM-SM router. In other words, we wanted to leave the choice to
the implementors and operators.

> state being deleted is the PIM state, not the BFD state.)
GIM>>  Yes, you are right, a tail is required to act as if the neighbor
timeout has expired. I've found that there are several places in RFC 7761
referencing actions upon the timer expiration. Perhaps the clarification
that the actions are as if the neighbor timeout expired make the text
clearer:
NEW TEXT:
   If the tail detects a MultipointHead failure [RFC8562], it MUST
   delete the corresponding neighbor state and follow procedures defined
   in [RFC7761] for the DR and additional neighbor state deletion after
   the neighbor timeout expires.

> what do we do if we are a candidate but not the selected GDR?
GIM>> A GDR Candidate acts as the MultipointHead, which enables monitoring
of all active GDR Candidates by the PIM-SM DR.

> contrast by using "MUST" here (assuming that the contrast is intended).
GIM>> Thank you for the suggestion. Yes, the text needs the normative
language to be clearer. Done.

> a traffic spike/congestion?  I find it unlikely, but am not really an
GIM>> We didn't receive any warnings from the multicast experts (I am far
from that myself). Would s/immediately/as soon as possible/ elevate your
concern?

> 255?  Where is this requirement specified?
GIM>> I agree, a requirement to discard demultiplexed BFD Control packet,
similar to the one in RFC 5881, is beneficial. Added
OLD TEXT:
      MUST set TTL or Hop Limit value to 255 (Section 5 [RFC5881]);
NEW TEXT:
      MUST set TTL or Hop Limit value to 255 (Section 5 [RFC5881]).
      Similarly, all received BFD Control packets that are demultiplexed
      to the session MUST be discarded if the received TTL or Hop Limit
      is not equal to 255;

> Do the considerations of RFC 5881 also apply?
GIM>> A good question, thank you. Based on the use of GTSM/RFC 5082, these
also apply. Added.

> I'd s/had been/was/ -- the "had been" verb tense feels out of place
GIM>> Thanks, agree.