Hi Jeff,
I just took a look at -07, thanks for the updates. I am good with the changes
made, ack for your response wrt operational data.
- Section 4.2: do we need 2119 language for the following paragraph and should
the should be a MUST?
In the case multiple BFD clients desire to test the same BFD
endpoints using different bfd.PaddedPduSize parameters,
implementations should select the largest bfd.PaddedPduSize parameter
from the configured sessions.
- Section 5.2: the YANG module addresses the cases where the BFD sessions are
configured directly in BFD. Should we have some text in there which mentions
that configuring the pdu-size in BFD clients is out of scope and requires the
clients to use the new grouping "bfd-large-common"? Do you know anyone e.g. in
IDR who could do that for BGP :-)
I'll ask for a YD review and I'll start WGLC very soon.
Regards,Reshad.
On Tuesday, April 9, 2024, 08:32:24 PM EDT, Jeffrey Haas <[email protected]>
wrote:
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
><[email protected]> 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
><[email protected]> 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, [email protected] 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
> >
>
>
