Jeff, I agree to your analysis. In the current draft, I've tried to make the desired behavior clear, at the same time, reuse the already defined BFD procedure as much as possible. As always, I'm open to any suggestions and comments. Although I disagree to a specific suggestion sometimes, the process of discussion is necessary and valuable.
Best Regards, Xiao Min ------------------原始邮件------------------ 发件人：JeffreyHaas 收件人：Greg Mirsky; 抄送人：肖敏10093570;rtg-bfd WG;draft-ietf-bfd-unaffiliated-e...@ietf.org; 日 期 ：2021年11月23日 06:10 主 题 ：Re: Several questions about the draft-ietf-bfd-unaffiliated-echo Greg, Xiao Min, Picking one small section of the replies as the basis of my own reply: On Wed, Nov 17, 2021 at 07:48:34AM -0800, Greg Mirsky wrote: > > 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. The original versions of the document changes were primarily targeted toward updating text that forbade echo mode from running when a session was not in the Up state. The point that you're making, Greg, is a fair one: This draft is attempting to have portions of a BFD state machine signaled through the Echo port but is missing normative procedure. The desired behavior is "obvious". If you support BFD Echo, you'd like to turn on that code to the remote system and do so without letting Echo be initiated using the Async procedures. However, since Echo is intentionally under-documented in the BFD RFCs and is expected to have a paired async session, this leaves the proposal missing quite a bit. As an example, the three states of the RFC 5880 state machine assume the ability to transition states based on hearing one's own discriminator echoed in the Your Discriminator field. This Discriminator swapping would not happen for Echo. This is where even a more closely analogous S-BFD (RFC 7880) procedure would break down. That said, S-BFD provides probably a closer experience to what is the desired behavior. The question the authors have is effectively, "given the presence of an IP stack capable of supporting BFD Echo packet looping, how do I specify the least procedure to have enough of BFD for my client stack to use and change the least code possible? -- Jeff
