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

Reshad Rahman <reshad@yahoo.com> Thu, 23 March 2023 19:06 UTC

Return-Path: <reshad@yahoo.com>
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 7182BC13AE3F for <rtg-bfd@ietfa.amsl.com>; Thu, 23 Mar 2023 12:06:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com
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 JO7bVPtyCU1g for <rtg-bfd@ietfa.amsl.com>; Thu, 23 Mar 2023 12:06:43 -0700 (PDT)
Received: from sonic302-3.consmr.mail.bf2.yahoo.com (sonic302-3.consmr.mail.bf2.yahoo.com [74.6.135.42]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B03C13AE3A for <rtg-bfd@ietf.org>; Thu, 23 Mar 2023 12:06:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1679598402; bh=iRTuCQlUEnREjn6IfaY4bmIabfLSgqB+4Dw2GE5Xxig=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=WU/L5if1i1XEQNdOnz+xG1W1E2GKzOyrVlrjiVwzDE9qPgItjKZLK7CtmM8hoffYnUSscUOXnqpfDf69bqeG/UaeuP0yd3jIyH84UiNOk3R6qM2Uh+nnMhzt8fQtx9/NHrBKSrNb0PF4R6EL5k37txbBGCxBx55VELnNYzBG/u+dgiuwrwmipJcbToI9c99jdfmYXPqLUq18qU4FvFqCQrIFCV4H2khSN6BmUdIAVCX65FhWuq+7OzFa2vScfmRmJyIZurEwpznHJmlIecA9LDVAM1oxYOowAw4PIbdx0zcTR4AyRTudalFX1u8pwdiO6qoiEYDNb5W1F8kKBY83Dg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1679598402; bh=rxtu7Pu+14Pdz9BcGFVPlCCJx/kRzeng10WceLDYVpI=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=HPaDPK50vx39MtO611Wmf1mFEy5y14eApSiuG1iKGK1D/+aGgNq2jVHJ38C1teCmv4XaXbHaXTO4CaVBfZrd6XQBNC4Ytwn7ugJIa35yy0QA8oXpijE0RfpYlPEPXCe2Gm3M4Moupritup3ilcfwmiRGZs5SUHP3cphwuM7SrDrWdnkqU1wiWpRSCJxo8gIjrfHJe6p56F6OvVsvatjQ8EMtGktgcQpTwPNfVuoTCJnu8EErFxaeaR/3lZ4T2sJemsQInEfS/r/D8hfcS7MjN4hwbY2PMhN8terhraTzCVhkodUXWMYPOc3GItiTd1hxJjc8lPc7q5L+r2gPNP+7ZQ==
X-YMail-OSG: aQV1l1gVM1me04.IGuOdhC9b6j31T1ojw7bAxPatEVy1hUjzrpsUXVvHHbcb3Rp y198iu2gSpqKLEpYMaGRAojkA6m2t3fl4vXDYP8GiqM0GGLdabTYfnJtFSaP3rei89.kwQgGfyou 5csFSafb07U4k8B6_t.3gtoeHdUxYUkgfwf6yqTTQuXZzIHnOUqQcCcANXymD6EQBhOJfYkQmCKq 4wRsncmjpZwLliEuuGd8p2OQ.8ESF2JkjaKr2jnjb.bj.nzNKNySyso79J9n6cXK6ew3LRQu3Qe8 C0D14_QQKNlCh2H2NvaRIHdHizPeOgguWwaQ3VcGau2EL6dh4.UvWQq64Qk39V153YPaJM3XH8P8 JuIAIUEF84lfrc.AXvdZOhoq4753XkLG97TNK2umXodCHsKToF94LwyzEZENIqcMf3aUE08jnvLe SCGK.Gm9dervM1OCbdy97bShqFSGC2DYRc8m4HVRJSDd_I_YO3IwC1yqP1gpDDIeybK6y4Zf_rkc oDjLVuQBmSmn_9W2Tc9egV8DzzdkFDxaER6baES7XL8634Lc0qRpQ4.sNcuLit_Xnqo8ENVWQ9Xc o5kujZKEJi8cg.NpmOlsLJKmfWOvLblcNRRJ3_668Go9lPem7cBaVN1tXYyj4pVCdcNjrurWjERL 23B8eC21tdzadYW9NoFrgzyuReiUchyzLJj9ZBmsxQi6liC85q7HXgiFh7_JoMWMFzoIFgLF2N6C gFGVAep8BZj2etMYKJ179TDumZhuza2LME9dMPpVadr0dfOdkLoRhU8R21JHP4gWdXgF3p3Ji81w 7R0u3wpxs7KIrTgYIDjhINKiyLGt9JEluje.nsd38imwiFxVrvkR82YH7zIbZ9n5Ysuug_cAmp3e 1aCMEFsozb0DVGuFhsyJnBZYP8Ux3egO8Fc2htM3j.6EABWeS5KIErzCIaMZLF.417Z2h82wRphj WPj8zbZ3hZLx18sHrVkkl4bUHIexCmiuiC_5G.Q.flQ.OA2LzdCPNuE5nzBJ4__k9EpwfpiLfc0q 9qCjE9zIUzhUci.6lbiXkX9UE9bvIjwusDUbe7qUixz6xM6VGhP9N0CQSIM7rbAOM0XGwp6dNABR wMYv_RI9gd7yC2sDvFUdd2_3X06bOOYsyF3k0kVRfZzzUjW9ZdTfnEdo6Iax8De8GMD6fw5zfqgx 9KNa_CbgybMFL7imbTXcGJ.dmWQ7is1LD.vZB1fUqz9eZrQh04hLiddnPkKEWSGlbDN3Xaaky1RL VX1y.QDzz1q648rdEsxSap4XYoSDyhhB1WNZoUjcXYC1zoWebOOvqojfU83LgNX7wwP6RsHAHU7U k_pghnIJ4Key9R3sbDPWTfVvPBXIWtO_DKi.eIrLDWME1eHXTuFqJURTdxfUwnJkNYLcxdHylM3D doTWvfxM8YDFKgTzmOhKoUA9kba5ayJTOWyvHpft1gTTdizHVfVtCJGtxEeCjGUbOGur3Y_sPTn2 .cNcyyNjtpZXi9CtXinCQsM0Sy4_3eB2fM_8r00loa3tmxAjWnMIxVlctOrdhtlcUOyzGnwM2V9T NMnqfpc1hdOM5fe6excHTwbaLq9Xc1aIity.c4mFI3JAy34k9MG3lK1651Tr62N.QrrBmklYypWX tKGfWLPyEVgNbXGyPHpTKQiwtBr3znvqlu7mqQt9Grt1O_coaaMrc4JvJLGxorm9NMyiAALyvjgI hNuAr5faHalm6C0z.X5azfQzFacojs8wm7ptUjg4SWF1feU3fvKMQrXOmvjEounI6qRtjJKnavtC VXkUaHjdua6Y03pYKlkuY0h5zbCfIo0OwuGLZoe_hWrk5.ejvKWSmICz8FsYw5hjXVOY4lsS7EPb PhitLztj6IK8k.ZVwAPQMkD77c4gvMYnYlKEhFi_hK.YZuGSft8tpCIckLAVZprEgCH9hzB0x6Kl Y43QBKWjKdZA.y.v5pDw.4fNiklhpguZCumLFH6wcBviY0Gzfq9Q3s1c2CFvs_WfnjdJGcXi.PbS SOHR6dhwUYdfrEqCUJuFjTE_lrTuWtA1ta13UzEVlV58SMPm3i1fX0BChSBZwLPOM4dbhRcScSbG Kj5Ox4uMx_ZbaqmLMwc8N9wVArOhR11VKDiVBscLplCOIUUjFHpDc2beJPRdXbWyvOXWOpkNZ7q5 EnFxL4E4ynAQONdC3NtB2GvSDU_PJfkjAVv4u1MfZ7rkUzHczN8aZDDj3Q_uZZuIkmruQmkypEYr 0XcVLv8nvWt5dZbVuhhq4_WFvXGlQr8uPMGpvmQ93oKuW8Ob4s7MISbnr1YNcRhdw8XUHGE3ftPN 7ToOj3YQu
X-Sonic-MF: <reshad@yahoo.com>
X-Sonic-ID: 56aefedb-cece-4617-a820-feacbcfb2c7b
Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Thu, 23 Mar 2023 19:06:42 +0000
Date: Thu, 23 Mar 2023 19:06:39 +0000
From: Reshad Rahman <reshad@yahoo.com>
Reply-To: Reshad Rahman <reshad@yahoo.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: Abhinav Srivastava <absrivas@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Message-ID: <72440624.2417352.1679598399810@mail.yahoo.com>
In-Reply-To: <4F6F3693-6B8B-4F16-BCAA-410558609248@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>
Subject: Re: Can a BFD session change its source port to facilitate auto recovery
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_2417351_694325216.1679598399808"
X-Mailer: WebService/1.1.21311 YMailNorrin
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/I5RTyX8Gmzcn3Zs35xN18CyYb_g>
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:06:48 -0000

 
    On Thursday, March 23, 2023, 02:36:53 PM EDT, Jeffrey Haas <jhaas@pfrc.org> wrote:  
 
 


On Mar 23, 2023, at 2:17 PM, Reshad Rahman <reshad=40yahoo.com@dmarc.ietf.org> wrote:
 Hi all,
+1 to Jeff's comment on not wanting to pretend that everything is fine.
And if we're running BFD single-hop and BFDoLAG where needed, this is a non-issue right?

Not quite.
In theory, if we had a full set of link tests from A..Z, including exercising each LAG member, one would think everything should be fine.  This is an ideal basis case.
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 correct implementation, but besides the point...
It's for reasons like this that we have discussions about whether it makes sense to run single-hop BFD in addition to BFD-on-LAG covering the same link.<RR> Right. This is what I meant by "running BFD SH and BFDoLAG where needed".  I'd think that running BFD SH on top of LAG, even if  BFDoLAG is enabled, would be needed anyway just because they exercise different layers. 
(It's also worth reminding the Working Group that these types of discussions were a motivation for the LIME Working Group we had some years ago.  It very much covered this space, but didn't come to successful outcomes.)
Going back to Abhinav's original question, here are my own observations:
RFC 5880 tells us that once a session is Up, we should demultiplex solely based on the Discriminators.  (RFC 5880, §6.3)
RFC 5881, used by RFC 5883 tells us that we MUST NOT change the source ports.  However, it doesn't provide a lot of justification for the WHY of that.  Given the prior point, what is the harm?  Some speculation:
- Even if you MUST demux based on Discriminators, I wouldn't place wagers on there being no implementations that aren't looking at the full layer-4 signature as part of the procedures.  In particular, middlebox steering may get in the way.- It's often necessary for hardware based BFD implementations to put in exceptions to rate policers to permit BFD to work.
Speculation aside, changing the source port most likely would work.
Is it a good idea?  Probably not.  
Is it a great tool to try to exercise specific legs of an ECMP?  Almost certainly not at high rates.  It'd also be clumsy.
Could you do this with some level of success?  Probably.
Would I want to support debugging issues with this as a vendor?  No.<RR> +1 to all the above.
Regards,Reshad.
-- Jeff