Hi Zahed, As agreed in our off-list discussion, I've posted version -14 to address your Discuss point by using your proposed text. Link as below. https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-14 I've also incorporated the changes for addressing John's non-blocking comments that were missed in version -13.
Best Regards, Xiao Min Original From: 肖敏10093570 To: ZaheduzzamanSarker <[email protected]>; Cc: [email protected] <[email protected]>;[email protected] <[email protected]>;[email protected] <[email protected]>;[email protected] <[email protected]>;[email protected] <[email protected]>;[email protected] <[email protected]>; Date: 2024年10月30日 14:19 Subject: Re: Zaheduzzaman Sarker's Discuss on draft-ietf-bfd-unaffiliated-echo-12: (with DISCUSS and COMMENT) From: ZaheduzzamanSarker <[email protected]> To: 肖敏10093570; Cc: [email protected] <[email protected]>;[email protected] <[email protected]>;[email protected] <[email protected]>;[email protected] <[email protected]>;[email protected] <[email protected]>;[email protected] <[email protected]>; Date: 2024年10月29日 21:28 Subject: Re: Zaheduzzaman Sarker's Discuss on draft-ietf-bfd-unaffiliated-echo-12: (with DISCUSS and COMMENT) On Mon, Oct 21, 2024 at 8:23 AM <[email protected]> wrote: Hi Zahed, Jeff, I'm following your discussion. As Jeff noted, I'll handle the proposed text change. Please see inline. Original From: ZaheduzzamanSarker <[email protected]> To: Jeffrey Haas <[email protected]>; Cc: The IESG <[email protected]>;[email protected] <[email protected]>;[email protected] <[email protected]>;[email protected] <[email protected]>;[email protected] <[email protected]>; Date: 2024年10月19日 01:21 Subject: Re: Zaheduzzaman Sarker's Discuss on draft-ietf-bfd-unaffiliated-echo-12: (with DISCUSS and COMMENT) On Thu, Oct 17, 2024 at 3:49 PM Jeffrey Haas <[email protected]> wrote: Zahed, > On Oct 17, 2024, at 8:52 AM, Zaheduzzaman Sarker via Datatracker > <[email protected]> wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for working on this specificaition. This is an interesting protocol to > enable system to loopback packets to itself. > > [...] > I am holding a discuss on the relaxation of congestion control statements in > the operational considerations. I think it is very important that we explain > the reason better on why we are relaxing that requirement on BFD session ( > but > not session) in this specification. > > [...] > and this specification says > > All Operational Considerations from [RFC5880] apply, except that the > Unaffiliated BFD Echo can only be used across one hop, which result in > unnecessity of a congestion control mechanism. > > It seems like this specification is relaxing the congestion control > requirements without really explaining why it is an exception from what is a > SHOULD in RFC 5880, even for single hop. Note that RFC 8085 cprovides > congestion control guidelines for protocol that uses UDP. I understand that > there is a periodicity and configured value to send the BFD Echo packets, > still that does not automatically result in unnecessity of a congestion > control requirement for UDP traffic, especially when RFC 5880 also says the > congestion is not only a traffic phenomenon. I was expecting more > explanation > of this exception ( this was also brought up by the TSVART review ) and > potential operation impacts as RFC 5880 also indicates the effects can be > catastrophic. This sentence, which is admittedly a bit vague, seems only to be causing confusion and grief. Would dropping it make these concerns go away? Note, keeping or dropping it doesn't really change anything. Two things are going on here: 1. Since this mechanism leverages existing BFD machinery, particularly periodic pacing of traffic based on configuration, there's no real "congestion control" present. That's true even in the base BFD protocol. If the session is unable to sustain the paced traffic, the session drops because some combination of link or protocol resources is unable to sustain it. In such cases, "works as designed". 2. The Echo mechanism in the base BFD protocol gave zero guarantees about any sort of congestion control to start with. All behavior was locally chosen. But similar to 1, above, since the point is to determine if the link is up and providing bidirectional connectivity, doing Bad Things to it doesn't make sense. In particular, this document's recommendations to leverage the existing BFD machinery toward Echo makes for a better behaved system rather than the less specified "do as you like" in RFC 5880. Thus, the sentence adds no deep clarity, nor its absence removes any real considerations. You are saying the pacing works in a way that guarantees no congestion on the path, and that covers both traffic on the wire and computational considerations, right? Also if the sender of echo packets not receiving anything back for whatever reasons the session is dropped. In that case, can we add a summary of what you just wrote above and drop the last part of the sentence under question? Perhaps the following: All Operational Considerations from [RFC5880] apply. Since this mechanism leverages existing BFD machinery, particularly periodic pacing of traffic based on configuration, there's no real possibility to create congestion. Moreover, creating congestion would be counter productive to check the bidirectional connectivity. [XM]>>> To my understanding, BFD congestion control (Section 7 of RFC 5880) relies on BFD timer negotiation (Section 6.8.2 of RFC 5880). So propose to change the text as you suggested with small tweaks. OLD All Operational Considerations from [RFC5880] apply, except that the Unaffiliated BFD Echo can only be used across one hop, which result in unneccessity of a congestion control mechanism.NEW All Operational Considerations from [RFC5880] apply. Since this mechanism leverages existing BFD machinery, at the same time removing BFD timer negotiation and being based on configuration, there's no real possibility to perform congestion control. Moreover, creating congestion would be counterproductive to check the bidirectional connectivity. END I have an issue with saying we created a protocol that cannot perform congestion control while using UDP. I am fine with saying due to configuration and periodic pacing the congestion control is unnecessary but not fine with saying we cannot do congestion control. Your proposed text exactly says there is no real possibility to perform congestion control. [XM]>>> Got it. Let me try again. OLD All Operational Considerations from [RFC5880] apply, except that the Unaffiliated BFD Echo can only be used across one hop, which result in unneccessity of a congestion control mechanism. NEW All Operational Considerations from [RFC5880] apply. Since this mechanism leverages existing BFD machinery, at the same time removing BFD timer negotiation and being based on configuration, there's no real possibility to perform BFD specific congestion control, although UDP based congestion control can still be applied. Note that the specific UDP based congestion control mechanism is beyond the scope of this document. Moreover, creating congestion would be counterproductive to check the bidirectional connectivity. Cheers, Xiao Min //Zahed > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I have further comments below as I believe when addressed that will improve > the > specification description - > > # Section 1 : I don't quite get this statement > > This document updates [RFC5880] by defining a new method of BFD Echo-Only > without requiring an implementation to support the full BFD protocol. The intent here is to cover the one-sidedness of the mechanism. Did you have any suggested text changes to clarify that? I see. even if this might be obvious to the experts I would still rewrite it as This document updates [RFC5880] by defining a new method of BFD Echo-Only which only impacts the BFD Echo sender without requiring an implementation to support the BFD protocol at the loop-back device, such that any IP forwarder can loop-back the BFD Echo packets. [XM]>>> OK. Will change the text as you suggested. > > Does this mean any IP packet forwarder can be Device B in figure 1? Any forwarder. Then we should call the Device B as a regular IP forwarder without associating it to BFD terminology. OLD: As shown in Figure 1, device A supports BFD, whereas device B does not support BFD NEW: As shown in Figure 1, device A supports BFD, whereas device B is a regular IP forwarder that does not support BFD [XM]>>> LGTM. Will use it. > or the > device B actually needs to implement RFC5880 partially. Device B only loops packets. It may be completely ignorant of the BFD protocol, and that is the purpose of this mechanism. > In the description of > Figure 1 , it says Device B does not support BFD. So to me, Device B can be > anything that understands IP forwarding, is it? > > # Section 5 : it is not clear to me if Device B (loop-back device) in figure > 1 > does not support BFD then how it can provide the authentication as per RFC > 8550. I think we should say that for authentication the loop-back device > needs > to support RFC 5880. Device B only provides loopback support. All authentication is isolated to device A which implements this mechanism. Reviewing section 5, the intent here is to cover attacks where the active attacker spoofs traffic targeting Device A by sending them through the loopback Device B. Authentication prevents Device A from being susceptible to that attack. What text would you prefer to see instead? The whole point is, it was not super clear just from this specification that all the updates, related mechanisms, and considerations in this specification only impact Device A that supports BFD and does not impact Device B. If we make that clear early in the document then it will address the confusions. I have proposed changes in the introduction above, that explicitness should clarify things, at least for me. [XM]>>> Thank you for the suggestions! Cheers, Xiao Min //Zahed -- jeff > >
