Hi Jeff, thank you for the continued technical discussion. I've added my notes below in-line under the GIM>> tag.
Regards, Greg On Mon, Nov 22, 2021 at 2:10 PM Jeffrey Haas <jh...@pfrc.org> wrote: > 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. > GIM>> I've proposed to consider using RFCs 8562/8563 as a starting point. A MultipointHead operates in the Demand mode, does not use the three-way handshake, and the BFD state machine is Up with the first transmitted BFD Control packet. True, the use of the BFD Echo function is not described in RFCs 8562/8563 but I don't expect it would present a serious problem to the group. The advantage of making the unaffiliated BFD Echo an extension of RFCs 8562/8563, in my opinion, is that the transmitted by MultipointHead BFD Control packets, though go unprocessed, would nolt affect anything. The rate of transmission can be one in an hour, one a day. And the BFD Echo function is not required to bring the BFD session state Up but can be used to detect the failure. > > 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 >
