From nobody Thu Apr 13 13:10:08 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 C1900C1522DB; Thu, 13 Apr 2023 13:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uDJ4ZuBKMyjg; Thu, 13 Apr 2023 13:10:03 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 56452C1524DB; Thu, 13 Apr 2023 13:10:03 -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 B0F901E037; Thu, 13 Apr 2023 16:10:02 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check From: Jeffrey Haas In-Reply-To: Date: Thu, 13 Apr 2023 16:10:02 -0400 Cc: draft-ietf-bfd-unaffiliated-echo@ietf.org, rtg-bfd WG Content-Transfer-Encoding: quoted-printable Message-Id: <2764EEC4-FFFE-46FE-BE19-8E9C2A6FCE71@pfrc.org> References: To: Greg Mirsky X-Mailer: Apple Mail (2.3696.120.41.1.1) 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, 13 Apr 2023 20:10:07 -0000 Greg, > On Apr 12, 2023, at 1:09 PM, Greg Mirsky = wrote: >=20 > Dear All, > after reading the document once more, I've realized that I need help = with a paragraph in Section 3. Please find my notes in-lined in the = original text below under the GIM>> tag: > Once a BFD Unaffiliated Echo session is created on device A, it > starts sending BFD Unaffiliated Echo packets, which MUST include = BFD > Unaffiliated Echo session demultiplexing fields, such as BFD "Your > Discriminator" and/or "My Discriminator" defined in [RFC5880]. > GIM>> It seems like the requirement is not clear on which fields must = be initialized by the device A - Your Discriminator, My Discriminator, = or both. Furthermore, these fields are characterized as demultiplexing, = although the next sentence states that demultiplexing is based on the = source IP address or UDP source port number. If that is the case, what = is the role of discriminators in demultiplexing BFD Unaffiliated Echo = sessions? The intent here is that this part of the BFD Async machinery is = preserved. My Discriminator is set to the known value, Your = Discriminator is zero, and the session proceeds with the device talking = to itself and resulting in My Discriminator and Your Discriminator = getting the identical value. We want to avoid re-stating RFC 5880 procedures on this point. I = realize one of your considerations here is likely that some BFD = technologies begin by having out of band discriminator advertisement. Would you find it helpful in illustrating the setup in bullet-point = fashion as Aijun mentioned in prior threads? > Device A performs its initial demultiplexing of a BFD Unaffiliated > Echo session using the source IP address or UDP source port. =20 > GIM>> Does the source IP address sufficient to demultiplex BFD = Unaffiliated Echo sessions? Consider the case that Interface 1 is = connected to a broadcast link. Can there be multiple BFD Unaffiliated = sessions off Interface 1? > Device > A would send BFD Unaffiliated Echo packets with IP destination > address destined for itself, such as the IP address of interface 1 = of > device A. My expectation is that there would be a single such session to a given = destination endpoint simlar to what we see out of the usual BFD 1-hop = cases. It'd be good to see if this matches the expectations of the = authors. > GIM>> Is "such as" in the sentence above used as "for example" or = "that is"? > GIM>> And a general observation on the terminology. It seems like = "device A" is used as a short version of "BFD system hosted on device = A". If that is correct, perhaps that can be explained in the Terminology = section (although it is missing in the current version of the draft). Reviewing RFC 5880, that RFC tends to use "the system". While I find = "device A/B" to be clear, is it your desire to see "system" to be used = for consistency with other RFCs? -- Jeff