Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check

[[e-mail]]

Jeff, Greg,






Please see inline...



Original



From: JeffreyHaas <[e-mail]>
To: Greg Mirsky <[e-mail]>;
Cc: [e-mail] <[e-mail]>;rtg-bfd WG <[e-mail]>;
Date: 2023年04月14日 04:10
Subject: Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check


Greg,
 
 
> On Apr 12, 2023, at 1:09 PM, Greg Mirsky <[e-mail]> wrote:
>  
> 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.   
> 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.
 [XM]>>> My expectation is the same to Jeff. Besides, ZTE's implementation allows for multiple BFD Unaffiliated sessions off Interface 1, differentiated by IP addresses (both DA and SA), so the answer to Greg's question is Yes, although there is no real use till now.




Best Regards,

Xiao Min




> 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