Dear Authors, thank you for the well-written document. I have several questions and comments that are listed below:
- An Introduction, states that it is not clear whether the devices using echo function need to support the full BFD procotol, including maintaining the state machine of BFD session as described in [RFC5880] and [RFC5881]. I think that Section 6.8.9 in RFC 5880 explicitly states: BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not Up. BFD Echo packets MUST NOT be transmitted unless the last BFD Control packet received from the remote system contains a nonzero value in Required Min Echo RX Interval. Could you point to a statement in RFC 5880 or RFC 5881 that updates the requirements above? - Based on my understanding of the BFD Echo function definition in RFC 5880, the use case described in section 6.2.2 TR-146 is not based on the standard use of the BFD Echo function. - Section 2 describes the behavior of a BFD system in the Unaffiliated Echo mode. Would there be a BFD session created? If yes, which BFD state variables must be set? - Regarding the encapsulation of the BFD Echo in unaffiliated mode section 2 states device will send the BFD echo packets with the IP address destined for itself Which address will be used in IPv4 and IPv6? Which address will be used as the source IP address? And as we are discussing the IP encapsulation, which value be set in the TTL/HL field? - in the second paragraph, Section 2 stated that the device that does not support BFD protocol immediately loops back the packet by normal IP forwarding, implementing quick link failure detection It appears that the quick link failure detection is on the side of the system that does not support the BFD protocol. Is that right? - Further, you describe that system A (Fig.1) "rapidly detect a connectivity loss to device B". How in the unaffiliated BFD Echo mode is controlled the rate of transition for the BFD Echo packets? RFC 5880 allows the remote system to use Required Min Echo RX Interval for that. Which mechanism would you recommend in the unaffiliated BFD Echo mode? - Additionally, how does system A detects a failure? RFC 5880 in Section 6.8.5 gives a hint: a sufficient number of Echo packets have not arrived as they should, the session has gone down but the mechanism to determine when an Echo packet should arrive and by that when it is lost, as I understand the text in the section, is outside the scope of RFC 5880. Do you have a recommendation on how system A determines that a packet is lost? - nits: s/BFD procotol/BFD protocol/3 s/capablity/capability/ Regards, Greg On Tue, Aug 4, 2020 at 6:04 AM Jeffrey Haas <jh...@pfrc.org> wrote: > Working Group, > > https://datatracker.ietf.org/doc/draft-cw-bfd-unaffiliated-echo/ > > At the virtual IETF 108, Unaffiliated BFD Echo Function was presented. > This > is a followup of a presentation given at IETF 106. > > The authors have indicated they would like to have this work adopted by the > BFD WG. This begins the adoption call ending August 16. Please respond to > the mailing list with your thoughts on this adoption. > > It should be noted that this document overlaps work in the Broadband Forum > (BBF) document TR-146. As noted in the presentation, the BBF document > lacks > some clarity and also doesn't discuss interactions with BFD > implementations. > This draft has good clarifications with regard to implementations of this > mechanism when the a BFD Echo-capable implementation is used. > > This raises two points to consider as part of adoption: > - This document with its current goals would Update RFC 5880. > - The status of this document would need to be Proposed Standard. > > -- Jeff > >
