Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)

[Greg Mirsky <[e-mail]>]

Dear Authors, et al.,
thank you for this well-written document. The mechanism described in the
draft is, in my opinion, useful and will save considerable efforts of the
operator. I have several questions and comments listed below:

   - Would the introduction of Unsolicited mode make this draft updating
   RFC 5881?
   - I didn't find any new values of BFD parameters that distinguish an
   unsolicited BFD session from the "classic single-hop" session. Do you think
   such a distinction could be useful to an operator?
   - In Section 2 stated

   On the passive side, the "unsolicited BFD" SHOULD be configured
   explicitly on an interface.

Does that imply that it MAY be configured node-wide? I think it would be
helpful to explicitly list the alternative option.


   - The fourth paragraph in Section 2 explains the handling of the first
   BFD control packet with Your Discriminator == 0, i.e., "it does not find an
   existing session with the same source address". What happens if the
   matching BFD session has been found?
   - A BFD session then created "based on the source address and
   destination address". Does that mean that there will be only one session
   with the same source address despite different destination addresses
   listed? If that is the case, could the BFD session be associated only with
   the source IP address of the received BFD control packet?
   - Between creating the BFD session (above) and

   It would
   then start sending the BFD Control packets and perform necessary
   procedure for bringing up, maintaining and tearing down the BFD
   session.

the local BFD system assigns My Discriminator to the session. Though it is
standard (RFC 5880) step, it might be useful to mention it.


   - Does "an established BFD session goes down" mean the state is Down and
   only Down or it also includes AdminDown state?
   - Furter stated

   the
   passive side would stop sending BFD Control packets and delete the
   BFD session created until the BFD Control packets is initiated by the
   active side again.

Probably some normative language be helpful to replace "would". And is the
stop applied immediately or after some grace period? The same question
about the deletion of BFD parameters and the FSM (probably this is left to
the implementation).


   - I'd admit got confused by the last paragraph in Section 2:

  The "Passive role" may change to the "Active role" when a local
   client registers for the same BFD session ...

Is it normative MAY? Does that mean that the unsolicited BFD cannot be in
passive role if it has a local client registered? But what I wonder is how
these transitions affect the operation. What happens if both BFD systems
are passive after changes in the clients registered? Or both are active?


   - Section 5.1 appears to only RECOMMEND setting TTL to 255 while RFC
   5881 says that TTL MUST be set to 255. What could be the case for not
   setting TTL to 255?
   - Nits:
      - s/"Discriminator"/"My Discriminator"
      - s/does not initiates/does not initiate/
      - s/"remote-discriminator"/"Your Discriminator"/

Regards,
Greg

On Tue, Aug 4, 2020 at 6:10 AM Jeffrey Haas <[e-mail]> wrote:

> Working Group,
>
> https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/
>
> With apologies to the authors of BFD unsolicited, this document is past due
> for Working Group Last Call.  The primary holdup on the document had been
> last minute interaction with the RFC Editor with regard to its impact on
> the
> BFD Yang model.  That work had completed some time ago.  (The Yang model,
> however, is still lingering in MISREF state.)
>
> This begins a last call period ending on 16 August.
>
> Please send your comments to the mailing list whether you think this work
> is
> ready to advance to the IESG or not.
>
> -- Jeff & Reshad
>
>