Hi Mahesh, Thank you for the prompt feedback. Please see inline.
Original From: MaheshJethanandani <[email protected]> To: 肖敏10093570; Cc: The IESG <[email protected]>;[email protected] <[email protected]>;[email protected] <[email protected]>;rtg-bfd@ietf. <[email protected]>; Date: 2024年10月17日 02:41 Subject: Re: Mahesh Jethanandani's No Objection on draft-ietf-bfd-unaffiliated-echo-12: (with COMMENT) Hi Xiao, Thanks for addressing most of my comments. Just a couple of followup question. See inline with [mj] On Oct 15, 2024, at 8:03 PM, <[email protected]> <[email protected]> wrote: Hi Mahesh, Thanks for your review and comments.Please see inline. [mj] I think I saw a similar comment on one of the other threads. It is not clear whether this “loopback” of packets is happening at layer 1 (physical) or layer 2 (IP layer). From the sound of it, it appears it is happening at layer 1, or at least where there is no lookup of IP address(es) happening. If there was, the destination address could be more than one hop away. In either case, clarifying how the packets are being “looped” back would help. [XM]>>> I noticed there was some discussion between you and Jeff. I'll respond to that discussion on this item. [mj] Sorry, if I was not explicit in my ask for being explicit :-). What I was referring to was that the notion of a BFD “session” in Unaffiliated BFD Echo only exists on Device A as it is the only one to implement the BFD stack. So when you say “until the session in Up”, what you really mean is “until the session on Device A is Up”. Similarly, when you say “session goes Down”, you really mean “session on Device A goes Down”. Is this a little more clear? [XM]>>> Aha, I see your point. :-) Yes, your text is more clear. Best Regards, Xiao Min Thanks. Cheers, Xiao Min Mahesh Jethanandani [email protected] From: MaheshJethanandaniviaDatatracker <[email protected]> To: The IESG <[email protected]>; Cc: [email protected] <[email protected]>;[email protected] <[email protected]>;[email protected] <[email protected]>; Date: 2024年10月16日 01:31 Subject: Mahesh Jethanandani's No Objection on draft-ietf-bfd-unaffiliated-echo-12: (with COMMENT) Mahesh Jethanandani has entered the following ballot position fordraft-ietf-bfd-unaffiliated-echo-12: No ObjectionWhen responding, please keep the subject line intact and reply to allemail addresses included in the To and CC lines. (Feel free to cut thisintroductory paragraph, however.)Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions.The document, along with other ballot positions, can be found here:https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/----------------------------------------------------------------------COMMENT:----------------------------------------------------------------------Section 1, paragraph 2> BFD [RFC5880] is a low-overhead, short-duration method to detect> faults on the communication path between adjacent forwarding engines.> The faults can be on interfaces, data links, and even the forwarding> engines. It is a single, unified mechanism to monitor any media and> protocol layers in real time.I do not know if "short-duration" is the right way to describe a "BFD session",even as the document says it is not a "BFD session". Whatever you call thecontinious sending of packets that are echoed back, which in my mind is asession, it can run with a short interval, but can run for a very longduration. Maybe "short-interval"? [XM]>>> Make sense. Will do s/short-duration/short-interval. Section 1, paragraph 9> This document updates [RFC5880] by defining a new method of BFD Echo-> Only without requiring an implementation to support the full BFD> protocol. It specifies the use of the Unaffiliated BFD Echo over> IPv4 and IPv6 for a single IP hop. A full description of the updates> to [RFC5880] is provided in Section 3.As noted in Gyan Mishra's review, even as it might be obvious to some, it wouldhelp to clarify why Unaffliated BFD Echo cannot be supported over multi-hop BFD. [XM]>>> OK. Propose to add some text as below. OLD It specifies the use of the Unaffiliated BFD Echo over IPv4 and IPv6 for a single IP hop. A full description of the updates to [RFC5880] is provided in Section 3. NEW It specifies the use of the Unaffiliated BFD Echo over IPv4 and IPv6 for a single IP hop. The reason why it cannot be used for multihop paths is that the Unaffiliated BFD Echo packets would be looped back by the first hop. A full description of the updates to [RFC5880] is provided in Section 3.
