Reshad, Sorry about the -06 noise; I posted the template rather than the generated document. See -07 for updates.
On Tue, Apr 02, 2024 at 02:40:34PM +0000, Reshad Rahman wrote: > Regarding the grouping for pdu-size, that would also be helpful for BFD > clients to include it (if needed) in their config model. > Regards,Reshad. > On Friday, March 29, 2024, 01:32:21 PM EDT, Reshad Rahman > <reshad=40yahoo....@dmarc.ietf.org> wrote: > > Jeff, Albert, > Thank you for the doc update. With work travel and the email flurry on > optimized authentication, this one slipped through. > On the YANG model, I believe the replicated portion with leaf pdu-size etc > should be a grouping. It's been moved to a grouping in -07. > I was also thinking that some extra operational data would be useful. I > haven't given much thought to it, and I don't know if you have, but something > along the lines of pdu-size of received BFD packets. There's two considerations to not have a operational leaf monitoring the size of received packets: 1. It can vary substantially. :-) So, you could always be behind. And some flavor of weighted moving average won't be terribly helpful since all it takes is Detect Mult number of wrong packets to knock the session over. 2. There's no guarantee that the BFD portion of the stack is aware of the encapsulated size, especially in implementations that do hardware front-ending of the packet path for BFD. For implementations where BFD might be directly part of the receive path, the usual POSIX cmesg data may be helpful... but that probably should be left as an implementation detail. > Section 4.1, I think it's worth stating that if padding is enabled on a > session which is up, the session will go down if the peer does not support > large BFD packets. > A security section for the YANG is needed, and the impact of setting leaf > pdu-size (as stated above). Done! -- Jeff > Regards,Reshad. > On Tuesday, January 30, 2024, 03:13:03 PM EST, Jeffrey Haas > <jh...@pfrc.org> wrote: > > Working Group, > > After a fumble in -04, -05 updates -03's republish earlier this week with a > YANG module to configure the padded size. > > Comments are appreciated. YANG doctor review will be getting requested as > we hopefuly move this forward soon. > > -- Jeff and Albert > > On Tue, Jan 30, 2024 at 12:09:02PM -0800, internet-dra...@ietf.org wrote: > > Internet-Draft draft-ietf-bfd-large-packets-05.txt is now available. It is a > > work item of the Bidirectional Forwarding Detection (BFD) WG of the IETF. > > > > Title: BFD Encapsulated in Large Packets > > Authors: Jeffrey Haas > > Albert Fu > > Name: draft-ietf-bfd-large-packets-05.txt > > Pages: 12 > > Dates: 2024-01-30 > > > > Abstract: > > > > The Bidirectional Forwarding Detection (BFD) protocol is commonly > > used to verify connectivity between two systems. BFD packets are > > typically very small. It is desirable in some circumstances to know > > that not only is the path between two systems reachable, but also > > that it is capable of carrying a payload of a particular size. This > > document discusses thoughts on how to implement such a mechanism > > using BFD in Asynchronous mode. > > > > The IETF datatracker status page for this Internet-Draft is: > > https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/ > > > > There is also an HTML version available at: > > https://www.ietf.org/archive/id/draft-ietf-bfd-large-packets-05.html > > > > A diff from the previous version is available at: > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-large-packets-05 > > > > Internet-Drafts are also available by rsync at: > > rsync.ietf.org::internet-drafts > > > >
