Hi Greg, Many thanks for your insightful questions and comments.
We've discussed them, please see inline our responses with <Weiqiang>. Best Regards, Weiqiang (on behalf of co-authors) 发件人: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] 代表 Greg Mirsky 发送时间: 2020年8月5日 10:51 收件人: Jeffrey Haas 抄送: rtg-bfd WG 主题: Re: Adoption call for draft-cw-bfd-unaffiliated-echo (ending 16 August, 2020) 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? <Weiqiang> This draft would update RFC 5880. We've pointed some other text in RFC 5880 that needs to be updated, in a presentation given at IETF 106. · 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. <Weiqiang> With this draft, we attempt to standardize the use of unaffiliated echo function, which has at least two use cases including that one described in section 6.2.2 of TR-146. · 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? <Weiqiang> Yes, there would be a BFD session. We think at least the following BFD state variables need be set: bfd.SessionState bfd.LocalDiscr bfd.RemoteDiscr bfd.DetectMult · 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? <Weiqiang> Both the IP DA and IP SA are configurable, usually the local and the remote interface IP addresses of the detected link are used. TTL/HL is set to 255. · 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? <Weiqiang> No, it's on the side of the local system that supports BFD protocol. Will reword to make it clear. · 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? <Weiqiang> It's by configuration, i.e., we configure at the local system the value of Required Min Echo RX Interval for the peer system. · 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? <Weiqiang> The local system behaves the same as it's expecting to receive BFD Control Packets. At the local system, both the Required Min Echo RX Interval for the peer system and the desired Detection Time multiplier for BFD Echo Packets are configured by the operator. · nits: s/BFD procotol/BFD protocol/3 s/capablity/capability/ <Weiqiang> Good catch, will fix them, thank you. 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
