Hi Xiao, Thanks for adding the references. This and the previous clarification update will address all my concerns. Cheers.
> On Oct 17, 2024, at 12:23 AM, <[email protected]> <[email protected]> > wrote: > > Hi Jeff, Mahesh, > > > > I'm following your discussion. > Please see inline. > Original > From: JeffreyHaas <[email protected]> > To: Mahesh Jethanandani <[email protected]>; > Cc: 肖敏10093570;The IESG > <[email protected]>;[email protected] > <[email protected]>;[email protected] > <[email protected]>;rtg-bfd@ietf. <[email protected]>; > Date: 2024年10月17日 08:47 > Subject: Re: Mahesh Jethanandani's No Objection on > draft-ietf-bfd-unaffiliated-echo-12: (with COMMENT) > Mahesh, > > >> On Oct 16, 2024, at 7:23 PM, Mahesh Jethanandani <[email protected] >> <mailto:[email protected]>> wrote: >> >>> On Oct 16, 2024, at 12:15 PM, Jeffrey Haas <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Mahesh, >>> >>> >>>> On Oct 16, 2024, at 2:41 PM, Mahesh Jethanandani <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> [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. >>> >>> This draft is meant to be read with RFC 5880/5881 and should avoid trying >>> to redefine things. >>> >>> https://datatracker.ietf.org/doc/html/rfc5880#autoid-12 >>> <https://datatracker.ietf.org/doc/html/rfc5880#autoid-12> >>> https://datatracker.ietf.org/doc/html/rfc5881#section-4 >>> <https://datatracker.ietf.org/doc/html/rfc5881#section-4> >>> Please see the above to see if this clarifies your thinking. >> >> It did, and thanks for the pointer. >> >> Rather than add the above suggested text, and if the idea is to not redefine >> things, how about adding the two links you suggest as a reference? > > The authors certainly could add some additional text in the Introduction > section clarifying that this feature extends the existing BFD Echo > functionality with those references. > [XM]>>> OK. Propose to add those references as below. > > OLD > > When the Echo function is activated, the local system sends BFD Echo packets > and the remote system loops back the received Echo packets through the > forwarding path. If several consecutive BFD Echo packets are not received by > the local system, then the BFD session is declared to be Down. > > NEW > > When the Echo function is activated, the local system sends BFD Echo packets > and the remote system loops back the received Echo packets through the > forwarding path, as described in Section 5 of [RFC5880] and Section 4 of > [RFC5881]. If several consecutive BFD Echo packets are not received by the > local system, then the BFD session is declared to be Down. > > END > > > > Cheers, > > Xiao Min > > > > -- Jeff > > 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. > > Mahesh Jethanandani [email protected]
