Hi Greg,
Thanks for the review and comments. Please see inline.
On Sunday, February 20, 2022, 05:09:22 PM EST, Greg Mirsky
<gregimir...@gmail.com> wrote:
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.
<RR> This was debated extensively ~15 months ago. I'll defer to Jeff H and John
S, but the last email I have on this is the following:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/vOMZl9ucZwNKu5_MHHti-4ImOjQ/#
- 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?
<RR> As per reply to Gyan, we will extend the document + YANG to support
multi-hop.
https://mailarchive.ietf.org/arch/msg/rtg-bfd/567Ey36geGC427ulnAqcWFag3xc/
- 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?
<RR> It is for the already created session. So a session is created in
"passive" state via BFD unsolicited procedure (no local client or config for
it). After that a local client wants the same session (e.g. because BFD was
enabled under a client), the BFD session becomes "active". We'll see if we can
make this clearer.
- 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).
<RR> Good point. I think it depends. e.g. if BFD authentication is already in
use, this is not an issue.
Regards,Reshad.
Regards,Greg
