[Replying wearing my BFD chair hat] Gyan,
On Tue, Apr 08, 2025 at 08:57:32PM -0700, Gyan Mishra via Datatracker wrote: > Document: draft-ietf-bfd-stability > Title: BFD Stability > Reviewer: Gyan Mishra > Review result: Not Ready > > Summary: > > This document describes extensions to the Bidirectional Forwarding Detection > (BFD) protocol to measure BFD stability. Specifically, it describes a > mechanism > for detection of BFD packet loss. > > Major issues: > None > > Minor issues: > Section 7 describes the stability Yang model. It references RFC 9314 BGP Yang > model for lacp, lag, sh, mh, mpls but does not mention SR-MPLS or SRv6 which > should be included as data planes stability that should be supported with this > draft. Which drafts cover SR-MPLS or SRv6 BFD YANG? > Section 6.2 talks about out of order packet. I wonder if with the null > authentication header with the sequence number counter that could be used for > sequencing and ordering of packets over lag or ECMP. As BFD control packets > are > not stateful as is with TCP as long as packet is received on far end it does > not matter what path is taken. For purposes of authentication that requires meticulous authentication modes, out of order packets may result in the older packet being dropped by the receiving BFD implementation. The motivation for 6.2 is recognizing operational reality and noting that implementations can be more sophisticated in how they choose to measure loss in such situations. > I agree out of order packets are not lost > packets as long as the BFD packet is received by far end. In case of lag with > lacp bundle with BFD over bundle member, there is a micro BFD session on each > bundle member. Note that "LACP" is irrelevant here. As you note, for BFD on LAG, there are individual sessions. The discussion point covered by section 6.2 for this draft is intended to cover the fact that BFD sessions that traverse a LAG (not BFD on LAG sessions) may be subject to misordering due to load balancing considerations of Layer 3 or similar packets over the LAG. > For ECMP it’s a single BFD session across all paths if S-BGD is > used and if running IGP OSPF or ISIS as BFD registered client then a single > BFD > session exists between the ingress PE or VM compute node and egress PE or VM > compute node. In that case their is no OOO BFD control plane. For multihop BFD, there is no way to control out of order delivery of packets. Any element that causes traffic to be able to be delivered over more than one path could misorder the packets. For single hop BFD delivered over a transport that may be implemented by some other underlying mechanism, say an MPLS LSP, unless that transport guarantees in-order delivery, BFD may be subject to misordering. These things are not in any way new considerations. However, these things may impact the measurements done by the BFD stability mechanism. Given this, reconsider your "not ready" classification. Thanks. -- Jeff
