Reviewer: Gyan Mishra Review result: Not Ready 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 -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
