Hi Greg, Please see inline with [XM].
Best Regards, Xiao Min ------------------原始邮件------------------ 发件人：GregMirsky 收件人：肖敏10093570; 抄送人：draft-ietf-bfd-unaffiliated-e...@ietf.org;rtg-bfd WG; 日 期 ：2021年11月17日 23:48 主 题 ：Re: Several questions about the draft-ietf-bfd-unaffiliated-echo Hi Xiao Min,thank you for your quick response to my questions and comments. Please find my follow-up notes in-lined below under the GIM>> tag. Regards, Greg On Wed, Nov 17, 2021 at 1:00 AM <xiao.m...@zte.com.cn> wrote: 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. GIM>> In my opinion, if something doesn't comply with the protocol, then it must be re-worked, not the protocol. If that is not possible, then, probably, that is not really a part of the protocol. [XM] I don't think so. RFC 5880 has been updated by RFC 7419, RFC 7880 and RFC 8562. Any IETF RFC can be updated or even obsoleted. 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? GIM>> That is better but "adjunct" has the same meaning as "complement". I propose removing "complement" altogether and, as the result, leaving the text in RFC 5880 unchanged. [XM] To my understanding, "adjunct" implies BFD Echo is dependent, however Unaffiliated BFD Echo is independent, so this update is needed. 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. GIM>> If the BFD Echo is a new BFD mode then that seems to be in conflict with "adjunct to both modes is the Echo function". I think that the proponents of this document must decide and clarify their position in regard to the status of the BFD Echo Is it a mode or function in BFD protocol? Then, resulting from the answer to that question, it will be clear whether the proposal is complying with RFC 5880 or not. [XM] As I said above, "adjunct" needs to be updated. In addition, I tend to agree it's a new BFD mode, however a new BFD mode looks a bit heavy to be documented, my proposal is to call it just "Unaffiliated BFD Echo", remove "function" from its name. 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. GIM>> As I understand it, BFD Echo applies to both BFD modes - Asynchronous and Demand. The text in RFC 5880 is clear about that in the following "An adjunct to both modes is the Echo function." I think that these updates of RFC 5880 are more confusing and not necessary. I propose removing them altogether. [XM] I disagree. We need these updates to make Unaffiliated BFD Echo complied with RFC 5880. If you have concern on any specific update, please raise it up, and then we can dig into the details. 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. GIM>> Thank you. In that case, I have a question. If the BFD Echo follows the BFD state machine as defined in RFC 5880, sending BFD Echo before a BFD session is in the Up state is a violation of: BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not Up. BFD Echo packets MUST NOT be transmitted unless the last BFD Control packet received from the remote system contains a nonzero value in Required Min Echo RX Interval. So, hence my question How the BFD session reaches the Up state? [XM] That's why I disagree with your proposal to remove all the updates to RFC 5880. I've noticed the text you quoted from RFC 5880 and made an update, please take a look at Section 2 of this draft. As to your question, please take a look at last paragraph of Section 3 of this draft, if it's still not clear, please let me know and I can improve it. 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. GIM>> I think that the first BFD Control packet in the Asynchronous mode is sent with the Init state. According to RFC 5880, BFD Echo packets MUST NOT be transmitted before the session reaches the Up state. I cannot find in the draft an explanation of how the state machine progresses from Down to Up state to allow a BFD Echo packet transmission. [XM] Acc to my reading on Section 6.2 of RFC 5880, the first BFD Control packet in the Asynchronous mode is sent with *Down* state, not *Init* 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. GIM>> I really don't know. I believe that the authors need to decide and clarify in the specification. [XM] OK, I'll discuss it with my co-authors and act on the draft in the next rev. 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. GIM>> RFC 8562 enables BFD peer(s), referred to as MultipointTail, to monitor the MutipointHead and the continuity of the multipoint network. In that scenario, the MultipointHead is not aware of the presence of any MultipointTail. Thus, answering your question, the sender of BFD Control packets, per RFC 8562, does not require its remote peer is BFD-capable. Perhaps others would share their understanding of RFC 8562? What are your thoughts, questions? Regards, Greg
