Last Call Review of draft-ietf-bfd-unaffiliated-echo-12
review-ietf-bfd-unaffiliated-echo-12-genart-lc-mishra-2024-10-14-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-bfd-unaffiliated-echo-??
Reviewer: Gyan Mishra
Review Date: 2024-10-14
IETF LC End Date: 2024-10-09
IESG Telechat date: 2024-10-17

Summary:

Bidirectional Forwarding Detection (BFD) is a fault detection protocol that can
quickly determine a communication failure between two forwarding engines. This
document defines a use of the BFD Echo where the local system supports BFD but
the adjacent system does not support BFD. BFD Control packet and its processing
procedures can be executed over the BFD Echo port where the adjacent system
only loops packets back to the local system.

Overall I think this draft is an excellent idea and concept as very applicable
to many operator network going between administrative domains between service
providers or even within the same service provider but between groups.  As well
there maybe use cases where BFD may not be supported on far end peer and this
could be for cloud native computing with containers kubernetes or openshift and
CNI integrated with open BGP instances running BFD in a router in a docker
container peering with worker node not supporting BFD.  Many use cases where
BFD is not supported on one end of the neighborship. Thank you authors and
contributors for this work.

Major issues:

I don’t see affiliated or unaffiliated BFD defined in RFC 5880.  I recommend
correlation of the concept with a section and verbiage in RFC 5880.

Since the echo function is an adjunct to asynchronous or demand modes, I am not
sure if it’s possible to use echo function without one of the two modes defined
in RFC 5880.   Also this draft states that unaffiliated BFD solution can only
be used for single hop BFD RFC 5881,  but I don’t see why it cannot be used for
multi hop RFC 5883.  Also why not use echo function with one of the two modes
asynchronous or on demand modes or for both modes.  What is the advantage
developing this solution that is non in line with RFC 5880 by using the echo
function without one of the defined modes. Also would it be possible to use
this unaffiliated BFD solution using S-BFD RFC 7880.  RFC 5880 describes the
echo function and asymmetry.  As this is exactly what the draft is performing
having a session only in one direction for the device supporting BFD as it’s
not possible with the device not supporting BFD.  This section should be
referenced in the draft.

Minor issues:
This draft updates RFC 5880 to use adjunct echo function without using one of
the required modes asynchronous or on demand,  I understand this is a change
however is sending echo packets independent of BFD control packets possible
since AFAIK echo function does is an adjunct supplementary function to the main
BFD function with BFD control packets using one of the modes defined in RFC
5880.

Nits/editorial comments:
None