Hi Gyan,
Thanks for your review and comments.
Please see inline.
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.
[XM]>>> Thank you for pointing out so many use cases I didn't learn before.
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.
[XM]>>> I noticed that both Gunter and Adrian have proposed some text change on the Introduction section. Could you please take a look? Please see below for more explanations.
sure if it’s possible to use echo function without one of the two modes defined
in RFC 5880.
[XM]>>> Yes, it's possible. Actually in the echo function specified in this document, the BFD Control packets are still be used.
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 formulti hop RFC 5883.
[XM]>>> The reason is that if it's used for multi hop, then the echo packets would be looped back by the first hop.
Also why not use echo function with one of the two modes
asynchronous or on demand modes or for both modes. What is the advantagedeveloping this solution that is non in line with RFC 5880 by using the echo
function without one of the defined modes.
[XM]>>> Whether asynchronous mode or demand mode, the remote system needs to support BFD. That's the reason why Unaffiliated BFD Echo is introduced.
Also would it be possible to use
this unaffiliated BFD solution using S-BFD RFC 7880.
[XM]>>> No, it's not possible. Because by using S-BFD, the remote system needs to support BFD.
RFC 5880 describes the
echo function and asymmetry. As this is exactly what the draft is performinghaving 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.
[XM]>>> As said above, the Unaffiliated BFD Echo is not the echo function described in RFC 5880, because RFC 5880 requires the remote system to support BFD when using echo function.
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.
[XM]>>> Note that in this document the echo packets are exactly BFD Control packets, so either asynchronous mode or demand mode is not required.
Cheers,
Xiao Min
None
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
