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 <[email protected]> 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 > 收件人：[email protected];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. > > 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. > > 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. > > 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. > > 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? > 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. > > 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. > > 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 >
