IETF Logo Mail Archive

Re: Can a BFD session change its source port to facilitate auto recovery

Jeffrey Haas <jhaas@pfrc.org> Thu, 23 March 2023 19:14 UTC

Return-Path: <jhaas@pfrc.org>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED71C13AE3F for <rtg-bfd@ietfa.amsl.com>; Thu, 23 Mar 2023 12:14:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBADVKtAxZfh for <rtg-bfd@ietfa.amsl.com>; Thu, 23 Mar 2023 12:14:21 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C36A0C13AE3A for <rtg-bfd@ietf.org>; Thu, 23 Mar 2023 12:14:21 -0700 (PDT)
Received: from smtpclient.apple (104-10-90-238.lightspeed.livnmi.sbcglobal.net [104.10.90.238]) by slice.pfrc.org (Postfix) with ESMTPSA id 6E6C21E037; Thu, 23 Mar 2023 15:14:20 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D65696B9-BD5F-4E43-95E0-6E19D48B161A"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: Can a BFD session change its source port to facilitate auto recovery
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <72440624.2417352.1679598399810@mail.yahoo.com>
Date: Thu, 23 Mar 2023 15:14:20 -0400
Cc: Abhinav Srivastava <absrivas@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Message-Id: <A11D68DB-46B9-474D-8695-01DC887F067D@pfrc.org>
References: <CAL9v8R2iYMGjxF-A9SuDMcu2EF6h0isquTxjuAtNdqFwv_6etg@mail.gmail.com> <6DE166F3-5E02-446B-A105-0C6E2CC4E448@gmail.com> <1269529512.2412873.1679595445738@mail.yahoo.com> <4F6F3693-6B8B-4F16-BCAA-410558609248@pfrc.org> <72440624.2417352.1679598399810@mail.yahoo.com>
To: Reshad Rahman <reshad@yahoo.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/LWbRvbEY0hp4ZyFSTyw_GzHhRq4>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Mar 2023 19:14:23 -0000


> On Mar 23, 2023, at 3:06 PM, Reshad Rahman <reshad@yahoo.com> wrote:
> 
>> In practice, what's often seen is that even with full coverage of the paths that there are end-to-end forwarding faults for various reasons.  In at least some of these cases it's because BFD is implemented in a layer that isn't exercising the full data path.  To pick a somewhat vendor neutral example, consider BFD implemented directly on the line card but not participating in the layer 3 ECMP load balancer, or at the LAG level not participating in the layer 2 equivalent.
> <RR> That does seem to be a [in]correct implementation, but besides the point...

Indeed, and a sore point.

As someone who normally prefers to work in control-plane stuff, one of my favorite ways to get linecard engineers to turn interesting colors is to ask them "what payload can I use to deterministically exercise a given ECMP forwarding path for this card, for this set of software, for these chips revisions".

-- Jeff

v2.26.15 | Report a Bug | By Email | System Status