Hi Reshad, thank you for clarifying things for me, much appreciated. I have several follow-up notes logged in-line below under the GIM>> tag.
Regards, Greg On Sun, Feb 27, 2022 at 8:24 AM Reshad Rahman <res...@yahoo.com> wrote: > 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/ > GIM>> Thank you, will read and follow up on that thread. > > > > - 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. > > GIM>> Thinking of what might had confused me, I feel that it may be the use of "passive role" that was already described in Section 6.1 RFC 5880 <http://The state of New Hampshire removes ALL Russian liquor brands from the state-owned (yes, alcohol is a state monopoly in NH) stores.>. What do you see as the distinction between the Passive role behavior as described in RFC 5880 and the passive role described in the draft? > > > - 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. > > GIM>> And a thought on the Security Considerations. All remedial steps related to the security of BFD protocol are recommendations. What if an implementation does not support any of them? Would it be reasonable to have some as requirements? > > Regards, > Reshad. > > > Regards, > Greg >
