Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Jeffrey Haas <[e-mail]>]

Greg,


> On Mar 27, 2023, at 1:40 AM, Greg Mirsky <[e-mail]> wrote:
> 
> Dear Authors,
> I read the latest version of the draft. I appreciate your work on improving its readability. I have several concerns and appreciate your consideration:
> It appears like the document defines the format of the Echo message. As I understand the RFC 5880, the format of the Echo message is not specified in the RFC 5880. It seems like by defining the format in this document, you affect RFC 5880 compliance of implementations that do support RFC 5880 as it exists today.
One way to alternatively view this is we're documenting what one implementation puts in its Echo packets.  This draft does not try to require that all BFD Echo implementations use these procedures.

> The draft, in my opinion, significantly changes the architecture of the BFD, as it is defined in RFC 5880. I believe that characterizing Echo as a function stresses its dependency from a BFD mode, Asynchronous and Demand. The changes proposed in this draft are very extensive and severely affect the existing architecture of BFD by setting the Echo function on par, unrelated with the BFD modes.

Interesting.  My view has been that this mechanism leverages existing BFD Async procedures to avoid trying to completely invent new mechanisms for the unafilliated case.  Where I might have some level of agreement with your point is this "mode" needs to be clearly defined from a configuration standpoint.  For example, how would it manifest in YANG?

> Also, I think that the normative language in the last paragraph of the Secrity Considerations sections are too soft. Currently used recommendation level, in my opinion, is insufficient and should be brought to the requirement level. I.e., I propose s/RECOMMENDED/MUST/ and s/SHOULD NOT/SHALL NOT/

I'd recommend that you show the explicit sections you want updated.  Using version -06:
- I would not personally suggest that the RECOMMENDED for authentication turn into a MUST.  BFD Authentication simply isn't used in enough circumstances to try to turn this into the default case, especially when the intent of this feature is to deal with systems that don't have a matching BFD on the opposite side.
- I not super supportive of the SHOULD NOT for the TTL 255 loop being upgraded to SHALL NOT.  This will likely make a number of existing deployments of this feature non-conformant.

Please note that I expect to have a repeat of this conversation with the security AD during review.  So, your comments are apropos.

-- Jeff