From nobody Wed Apr 12 10:09:48 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 05A52C152A11; Wed, 12 Apr 2023 10:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 F-L19Cf3UeET; Wed, 12 Apr 2023 10:09:43 -0700 (PDT) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 4D918C151B29; Wed, 12 Apr 2023 10:09:43 -0700 (PDT) Received: by mail-yb1-xb2c.google.com with SMTP id n203so751241ybg.6; Wed, 12 Apr 2023 10:09:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681319382; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=cgzIfweSOhcs5G3NO7sbsv++IoWCtTtNQZfZ8OjkVe4=; b=YywTe8nitVX3PlE1481G8ayvRw5AWNWbqskeGMVLJ92fIKXpej9HgvqACObwogVOuV bIZIw6FZI4jAUrFecLM9Jfw/PYkjotfFXBLNEh/ItD+ytlAa6IPtjt8PqoPhiA9TKpez GmloBuNlB9aK0QdX0d1gy10IPaBdZFUTE8mS7fRJpC/nvvwMw0DRiFWq+s68RdrY9tNF g56KCh3qNPVgbEjFEEG9y3lOh/PjqlCCQ8r/6FwWmfXe1SYNbN//OtEFDfKW1qiPgTQS l+VBE8hK2KzdGLuIBGOFroQqa+x4nr7lB8Usabqrmn1jzxi/iwMPGKkpTuad7dCpTPjN wVCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681319382; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=cgzIfweSOhcs5G3NO7sbsv++IoWCtTtNQZfZ8OjkVe4=; b=jmMPsDabXOj0zKJ/nHtrhqGgA1ArO/lg//GloqZSqRGmVLeLqvrh7q2bSfgUC0vG/0 z8eji4e9NuugpsxH+wRleqfiwy2Lzx171b1oOlot5Glts1SIqCCuIBu1l59NS3pGaR0Z 7xg0yI53VBpXW9Eq+pFW7Gl5rcfALa4wtGFzx/+sh6NC3sBUxzegfDL2D68YGvheHmLf VJSRdDWkFdNe1x4l92v+FEG20CUjjDz493MEF1ZOGRpklVHp7XcA3D+JPCTEgY+es/di vrTc4X/zdYMOyxcAMcDjawsCN2Cvf2K4IYqXPbq0rUvND73w1GAL/uhqW+d3dlaMRNyc QdYA== X-Gm-Message-State: AAQBX9fR47ZodClIzxNaZxpbKQ2K7PtEm4S+xnMp23WzJ971Zv9H5GhB zaZtQyfgJCWmO9fwLSQq9Xt00w8fRuFSfnfbaLeCCLb3vg0= X-Google-Smtp-Source: AKy350bMnssW4qlpzMoimbLZcOVtFZEnqHXQNEwDA4vUM5JvvIL3TE89S3BXufw1DOzMcMs8DtHBGUXT1rmtiYqLfZw= X-Received: by 2002:a25:778f:0:b0:b8f:43d8:eba2 with SMTP id s137-20020a25778f000000b00b8f43d8eba2mr1420083ybc.2.1681319382026; Wed, 12 Apr 2023 10:09:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Wed, 12 Apr 2023 10:09:30 -0700 Message-ID: Subject: Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check To: Jeffrey Haas Cc: draft-ietf-bfd-unaffiliated-echo@ietf.org, rtg-bfd WG Content-Type: multipart/alternative; boundary="000000000000850e8705f926ac2a" 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: Wed, 12 Apr 2023 17:09:47 -0000 --000000000000850e8705f926ac2a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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= ? Device A performs its initial demultiplexing of a BFD Unaffiliated Echo session using the source IP address or UDP source port. 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. 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). Regards, Greg On Mon, Apr 10, 2023 at 8:27=E2=80=AFAM Jeffrey Haas wrote= : > https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo > > Working Group, > > The Working Group Last Call for draft-ietf-bfd-unaffiliated-echo has > completed. My judgment is that it has weak, but positive support to > proceed to publication. This isn't atypical of BFD work at this point in > the BFD Working Group's life. > > The next steps for the document: > > 1. Please continue to iterate through the issues raised during last call. > I will be summarizing them in the original WGLC thread. I suspect we can > reach conclusion for them shortly. > > 2. Each of the authors needs to make an attestation as to whether they're > aware of any additional IPR applicable to this document. The rest of the > Working Group, as per BCP 78/79[1] should also disclose of any applicable > IPR if they're aware of it. > > One thing that makes this document particularly interesting is that this > work is covered partially under work done in BBF in TR-146. This will be > noted in the shepherd writeup. > > > -- Jeff > > [1] https://www.rfc-editor.org/rfc/rfc8179.html#section-5.1 > > > --000000000000850e8705f926ac2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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:
=C2=A0 =C2=A0Once a BFD Unaffiliated Echo session= is created on device A, it
=C2=A0 =C2=A0starts sending BFD Unaff= iliated Echo packets, which MUST include BFD
=C2=A0 =C2=A0Unaffil= iated Echo session demultiplexing fields, such as BFD "Your
= =C2=A0 =C2=A0Discriminator" and/or "My Discriminator" define= d in [RFC5880].
GIM>> It seems like the requirement is not = clear on which fields must be initialized by the device A - Your Discrimina= tor, My=C2=A0 Discriminator, or both. Furthermore, these fields are charact= erized as demultiplexing, although the next sentence states that demultiple= xing is based on the source IP address or UDP source port number. If that i= s the case, what is the role of discriminators=C2=A0in demultiplexing BFD U= naffiliated Echo sessions?
=C2=A0 =C2=A0Device A performs its ini= tial demultiplexing of a BFD Unaffiliated
=C2=A0 =C2=A0Echo sessi= on using the source IP address or UDP source port.=C2=A0=C2=A0
GI= M>> Does the source IP address sufficient to demultiplex BFD Unaffili= ated Echo sessions? Consider the case that Interface 1 is connected to a br= oadcast link. Can there be multiple BFD Unaffiliated sessions off Interface= 1?
=C2=A0 =C2=A0Device
=C2=A0 =C2=A0A would send BFD U= naffiliated Echo packets with IP destination
=C2=A0 =C2=A0address= destined for itself, such as the IP address of interface 1 of
= =C2=A0 =C2=A0device A.
GIM>> Is "such as" i= n the sentence above used as "for example" or "that is"= ?
GIM>> And a general observation on the terminology. It se= ems like "device A" is used as a short version of "BFD syste= m hosted on device A". If that is correct, perhaps that can be explain= ed in the Terminology section (although it is missing in the current versio= n of the draft).

Regards,
Greg

On Mon, Apr 10, 2023 at 8:27=E2=80=AFAM Jeffrey Haas <jhaas@pfrc.org> wrote:
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo

Working Group,

The Working Group Last Call for draft-ietf-bfd-unaffiliated-echo has comple= ted.=C2=A0 My judgment is that it has weak, but positive support to proceed= to publication.=C2=A0 This isn't atypical of BFD work at this point in= the BFD Working Group's life.=C2=A0

The next steps for the document:

1. Please continue to iterate through the issues raised during last call.= =C2=A0 I will be summarizing them in the original WGLC thread.=C2=A0 I susp= ect we can reach conclusion for them shortly.

2. Each of the authors needs to make an attestation as to whether they'= re aware of any additional IPR applicable to this document.=C2=A0 The rest = of the Working Group, as per BCP 78/79[1] should also disclose of any appli= cable IPR if they're aware of it.

One thing that makes this document particularly interesting is that this wo= rk is covered partially under work done in BBF in TR-146.=C2=A0 This will b= e noted in the shepherd writeup.


-- Jeff

[1] https://www.rfc-editor.org/rfc/rfc8179.ht= ml#section-5.1


--000000000000850e8705f926ac2a--