Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Greg Mirsky <[e-mail]>]

Hi Xiao Min,
thank you for sharing your views. I have several technical questions:

   - As this specification replaces the Echo function defined in RFC 5880,
   I expect it will describe the applicability of the new Echo functionality
   when the link in Figure 1 is a tunnel or a member link of a LAG.
   - The draft describes how the destination IP address of the Echo packet
   is set. Are there any special considerations for selecting IPv6 destination
   address?
   - Also, are there any special considerations for selecting the source IP
   address for IPv4 and/or IPv6 network?

Furthermore, please find my notes below under the GIM>> tag.

Regards,
Greg

On Sun, Apr 2, 2023 at 6:51 PM <[e-mail]> wrote:

> Dear Greg,
>
>
> Thanks for sharing your thoughts, even if they're concerns.
>
> Please see inline...
> Original
> *From: *GregMirsky <[e-mail]>
> *To: *Jeffrey Haas <[e-mail]>;
> *Cc: *[e-mail] <[e-mail]>;
> *Date: *2023年03月27日 13:40
> *Subject: **Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7
> April, 2023)*
> Dear Authors,
> I read the latest version of the draft. I appreciate your work on
> improving its readability. I have several concerns and appreciate your
> consideration:
>
>    -
>
>    It appears like the document defines the format of the Echo message.
>    As I understand the RFC 5880, the format of the Echo message is not
>    specified in the RFC 5880. It seems like by defining the format in this
>    document, you affect RFC 5880 compliance of implementations that do support
>    RFC 5880 as it exists today.
>
>    [XM]>>> As far as I can tell, several vendors have implemented this
>    feature and nobody reports the problem.
>
> GIM>>I think that it would be beneficial to reflect information about
existing implementation in the Implementation State section as described in RFC
7942 <https://datatracker.ietf.org/doc/rfc7942/>. At the same time, your
update about deployed implementations doesn't resolve my concern about the
impact of the proposal on earlier implementations of the Echo function as
it is defined in RFC 5880.

>
>    -
>
>
>    -
>
>    The draft, in my opinion, significantly changes the architecture of
>    the BFD, as it is defined in RFC 5880. I believe that characterizing Echo
>    as a function stresses its dependency from a BFD mode, Asynchronous and
>    Demand. The changes proposed in this draft are very extensive and severely
>    affect the existing architecture of BFD by setting the Echo function on
>    par, unrelated with the BFD modes.
>
>    [XM]>>> Please see above.
>
> GIM>> My question is about the impact on implementations that support the
Echo function as currently defined in RFC 5880. Perhaps you have verified
that there's no adverse impact? Please, if you have it, share information
about any interoperability between a system using the RFC5880-style Echo
function and a system with the unaffiliated Echo.

>
>    -
>
>
>    -
>
>    Also, I think that the normative language in the last paragraph of the
>    Secrity Considerations sections are too soft. Currently used recommendation
>    level, in my opinion, is insufficient and should be brought to the
>    requirement level. I.e., I propose s/RECOMMENDED/MUST/ and s/SHOULD
>    NOT/SHALL NOT/
>
>    [XM]>>> I agree we can strengthen the requirements for security. I'll
>    incorporate the changes you proposed if no objection from others.
>
>
>
> In conclusion, I am very much concerned with the amount of changes to the
> BFD architecture proposed in the document. I am also concerned with the
> affect on the protocol conformance standing of the established BFD
> implementations, SH BFD in particular. Hence, I propose changing this draft
> to the Experimental track.
>
> [XM]>>> As said, I have different opinion on the implication of this
> feature. As to the Standards Track vs Experimental Track, I'm open to it, I
> personally prefer the former.
>
>
> Cheers,
>
> Xiao Min
>
>
> Regards,
> Greg
>
> On Tue, Mar 21, 2023 at 11:02 AM Jeffrey Haas <[e-mail]> wrote:
>
>> Working Group,
>>
>> https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/05/
>>
>> The authors of draft-ietf-bfd-unaffiliated-echo have requested WGLC.
>>
>> The draft, in my opinion, is in fairly good shape.  However, since it
>> functions via looping packets back to itself and trying to exercise the
>> normal RFC 5880 state machine behaviors to a large extent, the draft could
>> use very high scrutiny for several matters:
>>
>> - Does the state machine behave appropriately at all stages?
>> - Are the descriptions of the values of the BFD fields clear in all cases?
>>
>> Please supply the authors and the Working Group with your feedback.
>>
>> The intended finish date for this WGLC is 7 April, 2023.  This is one week
>> after the end of IETF 116.
>>
>> Note that Reshad is an author on the draft, so I'll be handling the full
>> set
>> of review and shepherding work.
>>
>> -- Jeff
>>
>>
>>
>