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

[[e-mail]]

Greg, Jeff,

It looks that you converge on comparison between S-BFD Echo and Unaffiliated Echo.
What I want to point out is, allowing using standalone BFD/S-BFD Echo without periodically transmitted BFD/S-BFD Control packets, doesn't mean it's Unaffiliated Echo.
In RFC 5880 section 3.2 the 4th paragraph, it says
"Since the Echo function is handling the task of detection, the rate of periodic transmission of Control packets may be reduced (in the case of Asynchronous mode) or eliminated completely (in the case of Demand mode)."

Best Regards,
Xiao Min
------------------原始邮件------------------
发件人：GregMirsky
收件人：Jeffrey Haas;
抄送人：肖敏10093570;rtg-bfd WG;[e-mail];
日 期 ：2021年11月24日 05:17
主 题 ：Re: Several questions about the draft-ietf-bfd-unaffiliated-echo
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