From nobody Thu Mar 23 12:09:21 2023 Return-Path: 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 52D3BC13AE3A for ; Thu, 23 Mar 2023 12:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_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 jwpG-AJCBjeR for ; Thu, 23 Mar 2023 12:09:17 -0700 (PDT) Received: from sonic314-14.consmr.mail.bf2.yahoo.com (sonic314-14.consmr.mail.bf2.yahoo.com [74.6.132.124]) (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 8D22CC13AE48 for ; Thu, 23 Mar 2023 12:09:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1679598556; bh=T2du7uAdvIIhbJM9dWjvR6628VQ5W+Z2ZYpfdUneia8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=Oa2DYi9hdfSXBLISiibaOXagnY/FHmwTNMM+VYqAojEEVzmXOI7ZM7ULFRwJ7Xkire5wvhGnu0vsqw5OecoJJCADEzl88jZyqCczN2brx7BI70WYCJpcRfFHHRvFMSNX6u99prfs0WTDb5pN4Kb15IVd5UIjeTAYCTbbmv0jVIwaivsOsu/MfpeGJm/O903R0ordJ21fJow7t/0NrtKWHRo55TR8wyL1zgn3wjVFbIY4Nxt+fqfO4rkN2/SaxGPk2Qwo+sLkhzZW/oAOahRGvhT7pxF1ZK1757Z/grNQG+rnZiMmpKyC5yT8xfowzUIK23DNzGPX/MEQdKXu/ITTiA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1679598556; bh=DYHheBq/DfJBBSCHi4wW7OpjwwgGd8+YIfFUvgIvqZo=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=gvRKPyIVWqcVLGeWRm5R48egWB0DiPapxa4k2xD8IehQX0z3mLSjgcKVxDIlP1ZaN33PmRbftWupUMwQPYPOFdDRlBdzF1WRDeMbM0UAtUYF3yRXgbPvw7wj+mtvZLAsYWXgwTsh5GshZpd2tFcYCa1hvgGBeeDyGXa12gd+3lYlyUrCUtQ9Hd2BD9M1r8vF3lOO/3bU8QoniBGwwa+sFM8IrLQxh/fogTv6F5zqJA6PlX43sxfUbjQjRl45aa1qPZ6QgknXu9Ku6Mm2EOdWFjhcoWy3yebfUvoxdFYxoBxMy1KPvt0+9sAMdyweiAhCKmd7d6lOiRd9MxC4iCjqZw== X-YMail-OSG: xuH1uo4VM1mE0NRBvaUEEPYkfJUToHnyG.7.Dyxtz3KXmKkje91XTRtnzpi3bHr ngpOrolMTW85ywtR6QxrXy98ZudbUCeo8GkurCXxkq64R_CC8g_dCTpc2H7Oj2WDybYaon9T6BJr 7Q3rAyYGRjYuoi59EpBN7hBlytl.tcYkLggtc_3b9.9hw55CXPHKhxqLNgK5Irs3ZsioUIm1foRv Gr4oXp8TZY3c8DnJm0RnDjpAkkBmHND4_TjkakmXCfsNkJJaNLtvSWZEgkiR.q4lyDdEvx_AXn7H vfbdBQM6ZM1KBV50MUqK24I738_SRo.Ss8ltWSHyKUEpZxI96JnuxxLUoHaQPB3LBDD3FM1VyHTc SwDqewzoJ3hroX33o6okW0jliMdXuzFga9Xq103Ry5KqEVDKUK.tlGPOO1gU57KLhlZ3mGAA78fl 7nLj3HYm7_6d.Af.PH3d2eWCtrnvxDNCjF9kc6_UtCIVk8BgPv5OPdlxzpfcGOhxQF4qXcYzX7FK 2LNSIv7BUFBPEeOMfCytNKv6l4OAhUHo_owk1eTpAe4._pc9knWrGNCcmUlJef7DcLo6cjIkf9NQ sbb.7tfKiOU4fmQC1bMTjT5rg0LjM0UqMQYAoqoZZVfkryJzPVmavTnYzgFgNGvWLM2pT_cBilIU 6vLc0IwtUiMVTXNhw3ESdWhvkguWDXFUwJkNJJ0aClee7bbPjh68eBlhJMusHBE07Zj5F0Unv3ae 05f7p2sqFDACb5w8vgNw0stRDEoMkkyCnm4TfkfKgB6NYeBIoyU2qRzNlPdBATNIVG.DHhk7Prp9 .N36p6KVuk9c6a11.LjGRGi7ia9_flVjYFSO74sjvoH4Y2iixQiHoUP8Cu9zGRJgBi5sO2g7l5L_ ZqzogWRF5Jyac65R_wF38Wp.CHH59Hwb2sOOnH_2jYwXoMCKfX36We1AYNhkIZmazaNBZ7cuUt2N 0BD7ed_TAzSIFXoQiRwAU5fGIEvcpqU1RRuc8TiztE9f4VAG1PXI1q0PzdeHTe8oxMECDnpQl2jB 78_lt_cLUiImiWHgjO8kmzbRIyqSJI6n69aUp1xoeZ.gmVRALrRwijinsmFrA36EoPKUqUcrVb2c 8hQUniJ04y5doAat2kY__ZsrE2_aHXyaiGnHfkh17imePjWPFj6XJ.5qlhtRPvugL3GchADVw8Y9 7dWmd1V9tCzFVkiBbzFFiXsPBO1LcF6IQ_lzthzDIZHgTDUEmqCNC0CQBBbLFpGNfyzLxEtqWdJJ TOrlWNFOUYig4uhVUEfQn6j4KIuiBje4pUOai1i5ejmvXV9J9_A12GgfJvZuDu1lhq0XahKSdpqU 8mNUo8U8EwmP_Nnu.Eddym.xuZZqXGgV6eSLZxYwA2d0rYN1.Yfy_y4h3aMCHJe80W_DJI62gdFO b1gDSzGBc7m1T7CGCja3qBZHpcQrpwBq5bVZD0ccqsYKkuTPBm7.f7_1siIdSMi9HOqM_GjBhsJU 5y9P9nTYq5VjgxrOTxBb9CTH868MRdx3jYzn8RSOn4Gd8Sxgr2kd41L96u2kFzf8cvAdJNuN1DsU sVFwxV1uNOVmWNospN._n7phl4Tux1wU1UioI65knAuWeQY8I5w4QjZI0tr9t1eqmDEP6JCMe4yX CDBzuVP7JeuZrpacxgVWKGj9dtW0jPws5OjrmqypPS8w.knQ.sirFbZ53lpB4PQhVqzOC_CW_L8B XKbFiVwEqWWA5cGwv7AiJKtoMZsz1Oab4KnomQazlHjfvMdnlki9G9t9dE2laGhGGAa73cWJ2iIu WCsiW5MIq6q94k2ceBJN4gE2e74J28evdVAWKMOcLVPucMp2vJiCzXwGDNnsODv0W.IzkferhVMv ndRmunczqbQRp2jORhbQjJbBByO5.oEyjP_T03FbNbPPbuK9l6Yr4y2BjiH2qiZLe2DE5iDoXskN .igbvNtyXGcf8YSuVKgpy4L79_iyfpw3H8zoeMCHMvUWlRFQNRBvwg7BsTMOAldTcl4FCSegz15f eCIx12TI7fUdakvrSD3OXJWTnFAXRoJ.UFCbpXOx7QZxHQV6L5NikEn5M1ZAvFXfqZdHCoEJQr58 DNoHvmV5YL6ksOvchyCpbqOP94wVCDmxNgs0aHvuN9i9jMo3_QP4LzUo4X7wShgwsfu7Vx.JNUrw .G.QA64czipH6Fpz1FE2vpecFpTVfqGz654PzzS3FWMLnlBH0AxMnnrueaSYhRSwmVSK2hIYthOm CJtCHz_O1kffHSMRdzdLa6KtIdbgFU9156qyXKYK4nPxnJ_KUgF0oXNdj3fqhrxbIG0OhG_TMZnK D.HThcLau X-Sonic-MF: X-Sonic-ID: 82fd4641-87eb-43c9-84f1-5e96cf805e99 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.bf2.yahoo.com with HTTP; Thu, 23 Mar 2023 19:09:16 +0000 Date: Thu, 23 Mar 2023 19:09:10 +0000 (UTC) From: Reshad Rahman Reply-To: Reshad Rahman To: Jeffrey Haas Cc: "rtg-bfd@ietf.org" , Abhinav Srivastava Message-ID: <1727040461.2415541.1679598550704@mail.yahoo.com> In-Reply-To: <72440624.2417352.1679598399810@mail.yahoo.com> References: <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> Subject: Re: Can a BFD session change its source port to facilitate auto recovery MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2415540_933702448.1679598550703" X-Mailer: WebService/1.1.21311 YMailNorrin Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.39 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, 23 Mar 2023 19:09:20 -0000 ------=_Part_2415540_933702448.1679598550703 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I meant "That does seem to be an incorrect implementation" On Thursday, March 23, 2023, 03:06:53 PM EDT, Reshad Rahman wrote: =20 =20 =20 On Thursday, March 23, 2023, 02:36:53 PM EDT, Jeffrey Haas wrote: =20 =20 =20 On Mar 23, 2023, at 2:17 PM, Reshad Rahman 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 exercisi= ng each LAG member, one would think everything should be fine. =C2=A0This i= s 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. =C2=A0In = at least some of these cases it's because BFD is implemented in a layer tha= t isn't exercising the full data path. =C2=A0To pick a somewhat vendor neut= ral example, consider BFD implemented directly on the line card but not par= ticipating in the layer 3 ECMP load balancer, or at the LAG level not parti= cipating in the layer 2 equivalent. That does seem to be a correct impl= ementation, 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 lin= k. Right. This is what I meant by "running BFD SH and BFDoLAG where nee= ded". =C2=A0I'd think that running BFD SH on top of LAG, even if =C2=A0BFDo= LAG is enabled, would be needed anyway just because they exercise different= layers.=C2=A0 (It's also worth reminding the Working Group that these types of discussion= s were a motivation for the LIME Working Group we had some years ago. =C2= =A0It 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 b= ased on the Discriminators. =C2=A0(RFC 5880, =C2=A76.3) RFC 5881, used by RFC 5883 tells us that we MUST NOT change the source port= s. =C2=A0However, it doesn't provide a lot of justification for the WHY of = that. =C2=A0Given the prior point, what is the harm? =C2=A0Some speculation= : - Even if you MUST demux based on Discriminators, I wouldn't place wagers o= n there being no implementations that aren't looking at the full layer-4 si= gnature as part of the procedures. =C2=A0In particular, middlebox steering = may get in the way.- It's often necessary for hardware based BFD implementa= tions 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? =C2=A0Probably not. =C2=A0 Is it a great tool to try to exercise specific legs of an ECMP? =C2=A0Almos= t certainly not at high rates. =C2=A0It'd also be clumsy. Could you do this with some level of success? =C2=A0Probably. Would I want to support debugging issues with this as a vendor? =C2=A0No. +1 to all the above. Regards,Reshad. -- Jeff =20 ------=_Part_2415540_933702448.1679598550703 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I meant "That does seem to be an incorrect implementation"
=20
=20
On Thursday, March 23, 2023, 03:06:53 PM EDT, Reshad Ra= hman <reshad=3D40yahoo.com@dmarc.ietf.org> wrote:



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



=

<= /div>
In theory, if we had a full set of link tests from A..Z, includin= g exercising each LAG member, one would think everything should be fine. &n= bsp;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 forwar= ding 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 impleme= nted directly on the line card but not participating in the layer 3 ECMP lo= ad balancer, or at the LAG level not participating in the layer 2 equivalen= t.
<RR> That does seem to be a correct implemen= tation, but besides the point...

It's for reasons like this that w= e have discussions about whether it makes sense to run single-hop BFD in ad= dition to BFD-on-LAG covering the same link.
<RR&g= t; 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 lay= ers. 

(It's also worth reminding the Working Group that these= types of discussions were a motivation for the LIME Working Group we had s= ome years ago.  It very much covered this space, but didn't come to su= ccessful outcomes.)

Going back to Abhinav's original question, her= e are my own observations:

RFC 5880 tells us that once a session i= s Up, we should demultiplex solely based on the Discriminators.  (RFC = 5880, =C2=A76.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 jus= tification for the WHY of that.  Given the prior point, what is the ha= rm?  Some speculation:

- Even if you MUST demux based on Disc= riminators, 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. &nb= sp;In particular, middlebox steering may get in the way.
- It's o= ften necessary for hardware based BFD implementations to put in exceptions = to rate policers to permit BFD to work.

Speculation aside, changin= g the source port most likely would work.

Is it a good idea?  = ;Probably not.  

Is it a great tool to try to exercise specif= ic legs of an ECMP?  Almost certainly not at high rates.  It'd al= so 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

------=_Part_2415540_933702448.1679598550703--