Greg,
Thank you for the detailed reply. I suspect I've known where your concern derive from, that's a misunderstanding. Note that the Unaffiliated BFD Echo is NOT intended to replace the BFD Echo function defined in RFC 5880. I don't think an interoperability between a system using the RFC5880-style Echo function and a system with the unaffiliated Echo is needed. In Figure 1, device A supports BFD and device B does not support BFD, that means neither device A nor device B can run RFC5880-style Echo function in this scenario. With that said, I suggest to add below text into the third paragraph from the bottom of Introduction section, clarifying the relationship between the Unaffiliated BFD Echo and the RFC5880-style Echo. NEW The former scenario is not changed by this document in any way. As to your new technical questions, please see inline... Original From: GregMirsky <gregimir...@gmail.com> To: 肖敏10093570; Cc: jh...@pfrc.org <jh...@pfrc.org>;rtg-bfd@ietf.org <rtg-bfd@ietf.org>; Date: 2023年04月06日 09:03 Subject: Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023) Hi Xiao Min,thank you for sharing your views. I have several technical questions: As this specification replaces the Echo function defined in RFC 5880, I expect it will describe the applicability of the new Echo functionality when the link in Figure 1 is a tunnel or a member link of a LAG. [XM]>>> As said above, this specification does NOT replace the Echo function defined in RFC 5880, it adds a new usage of BFD Echo while not affecting the existing one. In section 2.2 of RFC 7130 (BFD on LAG), it says "the use of the BFD echo function is outside the scope of this document". The draft describes how the destination IP address of the Echo packet is set. Are there any special considerations for selecting IPv6 destination address? [XM]>>> The draft currently says "Device A would send BFD Unaffiliated Echo packets with IP destination address destined for itself, such as the IP address of interface 1 of device A". No any special considerations. Also, are there any special considerations for selecting the source IP address for IPv4 and/or IPv6 network? [XM]>>> No. If you have any suggestions, please let me know. :) Best Regards, Xiao Min Furthermore, please find my notes below under the GIM>> tag. Regards, Greg On Sun, Apr 2, 2023 at 6:51 PM <xiao.m...@zte.com.cn> wrote: Dear Greg, Thanks for sharing your thoughts, even if they're concerns. Please see inline... Original From: GregMirsky <gregimir...@gmail.com> To: Jeffrey Haas <jh...@pfrc.org>; Cc: rtg-bfd@ietf.org <rtg-bfd@ietf.org>; Date: 2023年03月27日 13:40 Subject: Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023) 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. [XM]>>> As far as I can tell, several vendors have implemented this feature and nobody reports the problem. GIM>>I think that it would be beneficial to reflect information about existing implementation in the Implementation State section as described in RFC 7942. At the same time, your update about deployed implementations doesn't resolve my concern about the impact of the proposal on earlier implementations of the Echo function as it is defined in RFC 5880. 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. [XM]>>> Please see above. GIM>> My question is about the impact on implementations that support the Echo function as currently defined in RFC 5880. Perhaps you have verified that there's no adverse impact? Please, if you have it, share information about any interoperability between a system using the RFC5880-style Echo function and a system with the unaffiliated Echo. 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/ [XM]>>> I agree we can strengthen the requirements for security. I'll incorporate the changes you proposed if no objection from others. In conclusion, I am very much concerned with the amount of changes to the BFD architecture proposed in the document. I am also concerned with the affect on the protocol conformance standing of the established BFD implementations, SH BFD in particular. Hence, I propose changing this draft to the Experimental track. [XM]>>> As said, I have different opinion on the implication of this feature. As to the Standards Track vs Experimental Track, I'm open to it, I personally prefer the former. Cheers, Xiao Min Regards, Greg On Tue, Mar 21, 2023 at 11:02 AM Jeffrey Haas <jh...@pfrc.org> wrote: Working Group, https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/05/ The authors of draft-ietf-bfd-unaffiliated-echo have requested WGLC. The draft, in my opinion, is in fairly good shape. However, since it functions via looping packets back to itself and trying to exercise the normal RFC 5880 state machine behaviors to a large extent, the draft could use very high scrutiny for several matters: - Does the state machine behave appropriately at all stages? - Are the descriptions of the values of the BFD fields clear in all cases? Please supply the authors and the Working Group with your feedback. The intended finish date for this WGLC is 7 April, 2023. This is one week after the end of IETF 116. Note that Reshad is an author on the draft, so I'll be handling the full set of review and shepherding work. -- Jeff
