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

[Benjamin Kaduk <[e-mail]>]

Hi Greg,

Sorry for the slow response -- I had balloted early since I expected the
telechat week itself to be very busy, and it did prove to be so.

On Sun, Nov 28, 2021 at 01:17:45PM -0800, Greg Mirsky wrote:
> 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.

(nit) s/uses/using/, but sounds good.

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

Ah, okay.  No change needed, then :)

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

Looks great; thanks!

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

Okay.  Sorry for not following the reference myself...

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

It would, but honestly, just your email here would address my concern, even
without changing the text in the draft.

Everything else looks good -- thanks again!

-Ben

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