Hi Greg, Thanks for your thorough review and insightful questions. I hold the pen for draft-ietf-bfd-unaffiliated-echo, so I'd like to give my reply first. As you may have known or not, before this draft was posted, we ever tried to submit an errata instead of an I-D. However, under the direction of the responsible AD and WG chairs, we realized that an informational draft might be the proper way to record our implementation and deployment. And then, during the adoption poll of this draft, there was rough consensus that this draft should be adopted as standards track document, so we changed the intended status from informational to standards track. Please see inline for more responses with XM>>>.
Best Regards, Xiao Min ------------------原始邮件------------------ 发件人：GregMirsky 收件人：draft-ietf-bfd-unaffiliated-e...@ietf.org;rtg-bfd WG; 日 期 ：2021年11月17日 01:40 主 题 ：Several questions about the draft-ietf-bfd-unaffiliated-echo Dear Authors,I've read the latest version and I have several questions. I greatly appreciate your insights and clarifications: Firstly, what is being standardized by this specification? I couldn't find that the described process requires any cooperation, action from a remote BFD peer. As I can see, only the sender of BFD Echo packets is acting and thus every action, e.g., construction of the test probe, a method to demultiplex incoming test packets, etc., is internal to the sender. Hence, it appears that there is nothing to be standardized as all of it is internal processing that does not impact any other BFD system. XM>>> The intention is to record a popular use of the BFD Echo function that doesn't comply with RFC 5880, at the same time this document does some clean-ups to RFC 5880. The first update to RFC 5880 seems to suggest that the Echo function is an essential part of both Asynchronous and Demand modes of BFD. The original text of RFC 5880 characterizes the Echo function as an adjunct, i.e., a supplemental, function. The proposed new text - as a function that completes both BFD modes, makes them perfect, i.e., is an essential, necessary component. I think that that is not really the case and the BFD Echo function is not an essential, optional function of the BFD protocol. XM>>> Does s/complement/supplement work for you? The last sentence in the next proposed update to the RFC 5880 concerns me: The Echo function may also be used independently, with neither Asynchronous nor Demand mode. It appears that, if accepted, the BFD Echo function is transformed into an additional BFD mode. If that is the case, then this specification, in my opinion, is not updating the RFC 5880 but is defining a new protocol. XM>>> I tend to agree that the Unaffiliated BFD Echo can be seen as a new BFD mode, however I don't think it's defining a new protocol, it's definitely based on BFD protocol. For all the proposed updates to the RFC 5880, it is not clear why in some proposed texts, both modes, Asynchronous, and Demand, are referenced but in some only the Asynchronous. For example, updates to Section 6.1, Section 6.4, and Section 6.8.3 refer only to the Asynchronous mode, while updates to Section 6.8 and Section 6.8.9 - refer to both BFD modes. XM>>> As I recall it, the reason is that some updated text applies to Asynchronous mode only, and some others applies to both modes. In the second paragraph of Section 3 of the draft, the specification recommends that an implementation supporting this draft follows the BFD state machine, as defined in RFC 5880. Why is it a recommendation and not a requirement? And further, if an implementation does not follow the BFD state machine, is it still BFD? XM>>> Make sense. I think we can make it a requirement instead of recommendation. Further, in the third paragraph of Section 3, it appears that the BFD Echo function on device A starts transmitting BFD control packets once the session is created. What is the state of the created BFD Echo session? As I understand it, the BFD state machine starts from the Init. Isn't that the case for this document as well? XM>>> No change to the BFD state machine. As I understand it, it's DOWN state. In the same first sentence of the third paragraph in Section 3, another recommendation reads as "SHOULD include a BFD Echo session demultiplexing field". I have questions similar to the recommendation in the second paragraph of Section 3: Why is it a recommendation and not a requirement? What happens if an implementation does not include that particular field in the transmitted packets? Is it still a BFD Echo? How then sessions are demultiplexed? I greatly appreciate your consideration and help in clarifying these aspects of the draft. XM>>> Is that possible an implementation uses IP five tuples to demultiplex the loopbacked packets? If not, I agree to change from SHOULD to MUST. Now, I may have an alternative proposal that can produce the desired result and not require any update to RFC 5880. Please consider the following: RFC 8562 introduced a new type of the BFD session - MultipointHead. A system acting as the MultipointHead periodically transmits BFD Control packets in Demand mode, doesn't have the Init state, and starts in the Up state (no three-way handshake). Considering the above, a system that uses the Unaffiliated BFD Echo starts as MultipointHead with bfd.DesiredMinTxInterval set to the maximum value (or any sanely large enough). The exact construction of the periodic BFD Control packets transmitted by the MultipointHead needs some detailed analysis (I haven't spent enough time on that). In the meantime, because the BFD session for the MultipointHead started in the Up state, it can transmit BFD Echo packets according to RFC 5880 and RFC 8562. I think that if this proposal works, it may be moved as Informational since it describes the use of well-known BFD principles and mechanisms in an innovative and useful manner. XM>>> Although I'm unfamiliar with RFC 8562, while seeing BFD Demand mode, the first question came to my mind is that, can the peer system of MultipointHead be a BFD-unware device? That's the key requirement which results in Unaffiliated BFD Echo. Thank you again, Greg. What are your thoughts, questions? Regards, Greg
