Hi Jeff. > On Oct 16, 2024, at 12:15 PM, Jeffrey Haas <[email protected]> wrote: > > Mahesh, > > >> On Oct 16, 2024, at 2:41 PM, Mahesh Jethanandani <[email protected] >> <mailto:[email protected]>> wrote: >>> 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. >> >> [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? > > One motivation to not put in explicit conflicting text for this draft is that > when it's time to add the next encapsulation, we don't have to have a > completely new section for the base procedure. For U-BFD, support for Echo > in that encapsulation strongly suggests that U-BFD can also be used. > > Note that Echo support isn't guaranteed for all modes or encapsulations, and > similar non-support for U-BFD in those environments holds as an assumption. > > -- Jeff > Mahesh Jethanandani [email protected]
