Dear Authors,
I've read the current version of the draft and have several questions.
Greatly appreciate your consideration and feedback.

   - The document uses the normative language and is on the Standard track.
   At the same time, the behavior of the passive BFD system is entirely local
   and has no impact on the active BFD system. It appears like the use of
   normative language describing the implementation of the passive BFD system
   is unnecessary. It appears that the Informational track is more appropriate
   for this specification.
   - It appears that the YANG data model allows the BFD unsolicited only
   for the single-hop BFD. What, in your opinion, prevents allowing it for
   multi-hop BFD?
   - In the following text:

   The "Passive role" may change to the "Active role" when a local

   client registers for the same BFD session, and from the "Active role

   " to the "Passive role " when there is no longer any locally

   registered client for the BFD session.

it is not clear to me as to which BFD session is the reference "for the
same BFD session". Is that for the session that is already in the Up state?
Or something else?


   - Two recommendations in the Security Considerations section:

   o  Apply "access control" to allow BFD packets only from certain
      subnets or hosts.
...
   o  Use BFD authentication.

leave some serious doubts that the proposed model does bring any
operational simplification compared to explicitly configuring BFD on both
systems (especially to use authentication).


Regards,
Greg

Reply via email to