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.
//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 >> >> >> > >> > >> >> >
