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 AM Jeffrey Haas <[email protected]> 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 > > >
