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 kindly accepting the proposed updates. I've made the last
edit you've suggested. I'll upload the working version when Alvaro gives me
the sign.

Regards,
Greg

On Wed, Dec 8, 2021 at 3:37 PM Benjamin Kaduk <[e-mail]> wrote:

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