Re: Rtg-bfd Digest, Vol 163, Issue 25

Jeffrey Haas <> Thu, 03 October 2019 19:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C7CE1201E4 for <>; Thu, 3 Oct 2019 12:34:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CXh3Ss7Ud7jM for <>; Thu, 3 Oct 2019 12:34:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9F8B6120098 for <>; Thu, 3 Oct 2019 12:34:19 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 50DD71E2F4; Thu, 3 Oct 2019 15:37:25 -0400 (EDT)
Date: Thu, 3 Oct 2019 15:37:25 -0400
From: Jeffrey Haas <>
To: "Albert Fu (BLOOMBERG/ 120 PARK)" <>
Subject: Re: Rtg-bfd Digest, Vol 163, Issue 25
Message-ID: <>
References: <5D93DD11010004620119029E_0_2183410@msclnypmsgsv04>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5D93DD11010004620119029E_0_2183410@msclnypmsgsv04>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Oct 2019 19:34:21 -0000

On Tue, Oct 01, 2019 at 11:11:13PM -0000, Albert Fu (BLOOMBERG/ 120 PARK) wrote:
> There are well known cases, including those you mentioned, where BFD has
> limitations in deterministically detecting data plane issue, and not
> specific with the BFD Large Packet Draft. I am a novice to the IETF
> process, and not sure if we need to mention them here, but shall discuss
> with Jeff if it is worth highlighting them.

It's reasonable to make note of issues where common operational scenarios
will complicate the solution.  But it's not up to a draft carried on top of
an RFC with that core issue to try to solve the issue in that core RFC.

So, trying to solve "BFD doesn't work perfectly in the presence of LAGs" in
bfd-large is the wrong place to do it. :-)

That said, Robert, there's room for you to work on that if you want to kick
off a draft on the topic. 

> > We won't have control over how the Provider maps our traffic (BFD/data).  
> > Well of course you do :)  Just imagine if your BFD packets (in set equal to configured multiplier) would start 
> > using random UDP source port which then would be mapped to different ECMP buckets along the way in provider's
> > underlay ? 

And that's an example of possible solution space for such a draft on the
underlying issue.

That said, LAG fan-out issues are a massive operational pain.  While it's
likely that varying L3 PDU fields for entropy to distribute traffic across
the LAG may work (and we have any number of customers who rely on this for
UDP especially), it starts getting very problematic when you have multiple
LAGs in a path.  I have a vague memory that someone had started some
discussions with IEEE to try to figure out what OAM mechanisms would look
like for such scenarios, but that's very much out of normal BFD scope.

-- Jeff