Gorry, On Tue, Oct 15, 2024 at 05:26:04PM +0100, Gorry Fairhurst wrote: > I have a few comments, but i am not a routing expert, so I'm maybe > misisng context on the intended use, and why this is a good thing to > allow.... > > I did not find a description of why this was needed. Like many IETF specifications, the use cases often get dropped from the work as the document proceeds through its discussion. This "one sided BFD" covers the use case where a device that understands BFD wants to validate bidirectional connectivity to a second device that doesn't understand BFD. Devices supporting traditional RFC 5880 BFD are able to leverage Echo mode where the forwarding path is verified by looping packets through the remote node. This has been deployed for years by multiple vendors. Traditional RFC 5880 requires the BFD asynchronous mode session to be in the Up state prior to using the Echo mode. This draft leverages the existing looping mechanism used by Echo to permit one BFD speaker to use Echo without requiring BFD asynchronous mode to be present on the remote side. To provide protection vs. running BFD Echo mode at speed with a non-consenting remote party, the existing BFD state machine is executed on the BFD speaker while talking to itself. Thus, BFD only moves to sending packets at speed once the looped BFD session has moved to the Up state. > Whereas I understand BFD is a protocol setup between two endpoints, > this draft appears to describe a version without the setup, which > makes it a UDP-based request/response protocol in itself. That > brings questions about how it addresses RFC 8085 (also known as BCP > 145), with respect to the UDP Usage? This does not appear to be > explained. Hopefully the above comments about leveraging the existing BFD state machine helps. > Can this be misused as a DoS vector? BFD's state machine starts in a sedate mode (1 packet per second is common) until the session moves to Up before it will send packets at speed. > GTSM, aka RFC 5082, isn't mentioned or used, but it seems to be > relevent? If not, then the mechanism used to protect from forwarding > needs more explanation. See the text covering TTL in the draft. > Best wishes, > Gorry > > P.S. I didn't understand this: "Unaffiliated BFD Echo requires the > remote device to loop Unaffiliated > > BFD Echo packets.", so the packetw ould fail an RPF check to the source - why is this good? Packet looping is the mechanism that has been used by BFD Echo for years. This part is not new. -- Jeff -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
