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

[Zaheduzzaman Sarker via Datatracker <[e-mail]>]

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-bfd-unaffiliated-echo-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for working on this specificaition. This is an interesting protocol to
enable system to loopback packets to itself.

Also thanks for Brian Trammell for his good TSVART review. That email thread
had a very good conversation to understand this specification better. Thanks to
Erik, Jeffrey for reaching to resolutions.

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.

# RFC 5880 says -

     Note that "congestion" is not only a traffic phenomenon, but also a
   computational one.  It is possible for systems with a large number of
   BFD sessions and/or very short packet intervals to become CPU-bound.
   As such, a congestion control algorithm SHOULD be used even across
   single hops in order to avoid the possibility of catastrophic system
   collapse, as such failures have been seen repeatedly in other
   periodic Hello-based protocols.

  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.


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

  Does this mean any IP packet forwarder can be Device B in figure 1? or the
  device B actually needs to implement RFC5880 partially. 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.