Hi Jeff, I agree that S-BFD may provide a more suitable architectural framework for the Unaffiliated Echo (would that then be referred to as Unaffiliated S-BFD Echo?). Though, reading the S-BFD Echo Function section in RFC 7880, I find that the specification allows using standalone S-BFD Echo without periodically transmitted S-BFD Control packets. It seems precisely what is the Unaffiliated Echo.
Regards, Greg On Tue, Nov 23, 2021 at 11:43 AM Jeffrey Haas <jh...@pfrc.org> wrote: > Greg, > > On Tue, Nov 23, 2021 at 09:21:42AM -0800, Greg Mirsky wrote: > > On Mon, Nov 22, 2021 at 2:10 PM Jeffrey Haas <jh...@pfrc.org> wrote: > > > 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. > > A place where I consider the multipoint functionality to be an awkward fit > is that there's expected to be two participant roles: the head and the > tail. > For an echo solution, the local system is BOTH head and tail. > > This is contrasted vs. S-BFD where the Initiator expects to hear its own > stuff back from the reflector. > > Valid points of comparison include that with multipoint the packets are not > expected to be changed, but S-BFD procedure requires that the Reflector > flip > the discriminators. > > It can be observed that the state machines for S-BFD and multipoint are > largely the same, with a slight simplification for S-BFD not having to deal > with the Down state. IMO, the S-BFD state machine is closer to what we're > looking for. > > Observations flipping through RFC 7880 with regard to what would likely > need > to change to be the basis for bfd-unaffiliated pdus: > > The roles of Initiator and Reflector are still clear - although reflector > is > more literal. > > You'd still want to have network-wide discriminator pools to help reduce > diagnostic headache if an Initiator get someone else's packet > inappropriately. > > We'd want a new SessionType > > We'd still want to set demand mode. > > The demultiplexing critieria would need to map to a session based on the > transmitted discriminators. HOWEVER, some normative text would be required > on something we don't standardize - BFD Echo format in 5880, etc. In > particular, the Initiator has to make sure you can distinguish received > Echo packets as being associated with a BFD unaffiliated session perhaps > distinctly from other Echo packets. > > The responder/reflector procedure is largely eliminated - this is BFD Echo > as per RFC 5880. > > Many of the initiator procedures need mild tweaks because we are talking to > ourselves rather than an active reflector. > > The S-bfd echo function section provides some wisdom on the security issues > with bfd unaffiliated. > > -- Jeff >
