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

[Greg Mirsky <[e-mail]>]

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



On Sat, Nov 27, 2021 at 6:26 PM Benjamin Kaduk via Datatracker <
[e-mail]> wrote:

> 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?
>
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.

>
>                                                          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".
>
GIM>> You're interpretation of this text is correct. Thank you for the
suggested improvement.

>
> 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.
>
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.

>
>    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)?
>
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.

>
>    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.)
>
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.

>
> 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?
>
GIM>> A GDR Candidate acts as the MultipointHead, which enables monitoring
of all active GDR Candidates by the PIM-SM DR.

>
>                            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).
>
GIM>> Thank you for the suggestion. Yes, the text needs the normative
language to be clearer. Done.

>
>              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.
>
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?

>
> 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?
>
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;

>
> Section 4
>
>    The security considerations discussed in [RFC7761], [RFC5880],
>    [RFC8562], and [RFC8775] apply to this document.
>
> 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.

>
> 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.
>
GIM>> Thanks, agree.