Re: Several questions about the draft-ietf-bfd-unaffiliated-echo

[Greg Mirsky <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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
>