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

[[e-mail]]

Jeff,

I have no objection to the comparison, please go on.
One thing I want to emphasize is that, whether DC use case (brought up by draft-wang-bfd-one-arm-use-case) or broadband access use case (brought up by BBF TR-146), the key requirement is that the peer system is totally BFD-Unaware, in other words, the peer system would never send or parse any BFD Control packets, from the very beginning.
Another thing is that the Unaffiliated BFD Echo can only work between the local system and its one-hop-away peer system.

Best Regards,
Xiao Min
------------------原始邮件------------------
发件人：JeffreyHaas
收件人：肖敏10093570;
抄送人：Greg Mirsky;rtg-bfd WG;[e-mail];
日 期 ：2021年11月24日 20:32
主 题 ：Re: Several questions about the draft-ietf-bfd-unaffiliated-echo
Xiao Min,
BFD Echo, completely underspecified in RFC 5880, is fine with that lack of detail when it is paired with an Async session.
For the unaffiliated case and no Async session to help provide correlating activities, some of the work of Async will need to be done in the Echo stream itself.  These things would include:
- Security - why do I believe this is for my session?
- Session demultiplexing - why do I believe this is an Echo packet for one session instead of another?
The only option you have for Echo is "I can hear myself".  The question becomes what data you encode in there that covers at least those properties.
It's likely that some existing BFD Echo implementations already achieve this through proprietary means.  Some implementors may have chosen to simply encode a BFD Async packet in the Echo stream since they already have code that can deal with such packets.
If so, the question that needs answered is procedure for dealing with those packets.  We have several extensions to BFD that discusses ways that can be done.  This is the reason for comparison vs. existing mechanisms.
-- Jeff
> On Nov 23, 2021, at 10:36 PM, <[e-mail]> <[e-mail]> wrote:
>
> 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