Dear WG, My main comment about this draft was in respect to the solution not working well for ECMP paths and the latest version that it still remains to be the issue. I was hoping we could resolve it better (for example just like multipath traceroute does --> Hint: Paris Traceroute or maybe even Dublin Traceroute). None of those need to be implementation specific (like draft says in subsequent paragraph) and IMO BFD would really benefit from standardizing it.
Quote from the document: *However, for testing forwarding over multiple hops, there is no such specified general purpose BFD mechanism for exercising all links in an ECMP. This may result in a BFD session being in the Up state while some traffic may be dropped or otherwise negatively impacted along some component links.* However clearly this is not really an issue with this specific document hence *I am supportive of progressing this work fwd.* I am hearing that ECMP support for BFD will be handled separately and that will be very useful (feature/fix). Kind regards, Robert On Thu, May 9, 2024 at 10:18 PM Reshad Rahman <reshad= 40yahoo....@dmarc.ietf.org> wrote: > <Re-resend since first 2 attempts seem to have gone to /dev/null> > > BFD WG, > > This email (re)starts a 2 week Working Group Last Call for "BFD > encapsulated in large packets": > https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/ > > > Please take the time to review the document and provide comments by May > 24th. Feedback such as "I believe the document is ready to advance" is also > welcome. > > FYI we did WGLC a few years ago, see previous discussions at > https://mailarchive.ietf.org/arch/msg/rtg-bfd/rjyxii23qp8-EQSZQ7d8631kMwY/ > > There is no known IPR for this document: > https://mailarchive.ietf.org/arch/msg/rtg-bfd/jaAjdrkePSocqvvcxt4ffx0NDg8/ > > https://mailarchive.ietf.org/arch/msg/rtg-bfd/0yfGFB-ywYQMQWledrRRLXhrVYY/ > > > Regards, > Reshad (co-chair). > > > > > >
