Re: Zaheduzzaman Sarker's Discuss on draft-ietf-bfd-unaffiliated-echo-12: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Zahed, Jeff,

I'm following your discussion.
As Jeff noted, I'll handle the proposed text change.
Please see inline.

Original


From: ZaheduzzamanSarker <[e-mail]>
To: Jeffrey Haas <[e-mail]>;
Cc: The IESG <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
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 <[e-mail]> wrote:

Zahed,
 
 
 > On Oct 17, 2024, at 8:52 AM, Zaheduzzaman Sarker via Datatracker <[e-mail]> 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 



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