Date: Fri, 11 Apr 2025 12:33:29 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Gyan Mishra <hayabusagsm@gmail.com>
Message-ID: <20250411163329.GB14995@pfrc.org>
References: 
 <174417105286.640622.10458000659367443138@dt-datatracker-64c5c9b5f9-hz6qg>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <174417105286.640622.10458000659367443138@dt-datatracker-64c5c9b5f9-hz6qg>
User-Agent: Mutt/1.5.21 (2010-09-15)
Message-ID-Hash: CSCRCHDUO2UXY2S5XZETKKNPQYRA7GMS
CC: ops-dir@ietf.org, draft-ietf-bfd-stability.all@ietf.org, rtg-bfd@ietf.org
Precedence: list
Subject: =?utf-8?q?=5BOPS-DIR=5DRe=3A_Opsdir_early_review_of_draft-ietf-bfd-stability?=
	=?utf-8?q?-18?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/ops-dir/jVq_aS73R-LmcAvf_X2RfAIISl0>

[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