Re: Fw: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt

Greg Mirsky <gregimirsky@gmail.com> Tue, 09 May 2023 16:02 UTC

Return-Path: <gregimirsky@gmail.com>
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 1D049C15155C for <rtg-bfd@ietfa.amsl.com>; Tue, 9 May 2023 09:02:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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_NONE=-0.0001, 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 VkKFkfN1z9L6 for <rtg-bfd@ietfa.amsl.com>; Tue, 9 May 2023 09:02:11 -0700 (PDT)
Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (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 9FA3CC14CE5D for <rtg-bfd@ietf.org>; Tue, 9 May 2023 09:02:11 -0700 (PDT)
Received: by mail-yb1-xb29.google.com with SMTP id 3f1490d57ef6-b9a6eec8611so31348272276.0 for <rtg-bfd@ietf.org>; Tue, 09 May 2023 09:02:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683648131; x=1686240131; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=PcBGNygN0l01+R64XT8ovb96/cLmHT1rWpGWxsZaidI=; b=r7r9ONHZVmat3wZhZwskV5Ng9xEHC1VQGzXjNuZ6T+ICgXcy3t//HwJRHXi6Ns2cGD SPnWRzBZ/kG+d/yo1sfpcKCI2GgWm96mxvg/Gh158e1LdTpiM1N552xw1qnZV79PbmnM hT2nxJ79PprLvm8TH0iIN+aLzTkuznSvy7q+VR57Rvr+yibsyNAjfBArF8zwvOjWhru7 O0UBsM3LJ/RmJkcaLWDPi8jj3VMh1YxRJPNDOQLXAG9Edu/YsYG+tc4uwrdbbDUIqESK vPqQ5j69tGCIEpyI9nzEHzZLwhfEViGbs6ZejK1D0l1ejYCymLtuWAyh24/UnYUWucrl 8s2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683648131; x=1686240131; 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=PcBGNygN0l01+R64XT8ovb96/cLmHT1rWpGWxsZaidI=; b=hMp/cTBx6idO0ogCi8gqWqXaKj94B7T+jUWbkz9lcVFrLa18FA1Z8soKY/m6kQtW3J b7CSjqYAKvWdYDVzy7oXAeD9hVHRwaP/J8Z+lmItk9Udc80t+FEVY7BNsQj41BRFHuZo INN4uDPTTeU6T61b8wLzx/Bc9rLV+olo4cY+skjSBxFqN178WzY5i9GT+q1XQPFdDCDy EoQ97BTuMY98WfM7SPooTfyautZ48jblwRMT9zAI/vGB8V781PAidN2pPx83cSowV4nj pG0uOhZNNoeSnPm8842r8ayhkEonrdytwPxnQLP8KYfFpCXOXMffX/7MnThmMtR2LcrX nFzg==
X-Gm-Message-State: AC+VfDxbxAHNZuv8uY8caiHeKg3QyRtPR6iIu1fstn5rdR8exi0f7559 1yOTCCtcvEtLvJtzuGrZ6Hp1rGF/Q15jgrXwYoig3Xgx
X-Google-Smtp-Source: ACHHUZ7Tbcs983jmpZBOcEomuA94ulDU8oc9F6O8yWCflZZtYMX0zV1oLlm7mtLyDjB5u86YnodD5aUiMipORWSqm7c=
X-Received: by 2002:a25:e6d3:0:b0:b94:bbf0:349b with SMTP id d202-20020a25e6d3000000b00b94bbf0349bmr15647406ybh.10.1683648130455; Tue, 09 May 2023 09:02:10 -0700 (PDT)
MIME-Version: 1.0
References: <CA+RyBmWNYRpWVxGdeX39t+HUW_6BS=GbYCpy5hBkUxRMERR9ug@mail.gmail.com> <202305041528021843067@zte.com.cn>
In-Reply-To: <202305041528021843067@zte.com.cn>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 09 May 2023 09:01:59 -0700
Message-ID: <CA+RyBmWhN__1sAXWBjJ2Fbx4scpP=3N14nPs6Pdqoi0UhpgbHg@mail.gmail.com>
Subject: Re: Fw: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt
To: xiao.min2@zte.com.cn
Cc: rtg-bfd@ietf.org
Content-Type: multipart/alternative; boundary="000000000000be1da905fb44e008"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/JU3BSJE8EfA0CeDPI2Aej_D8WgQ>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 May 2023 16:02:14 -0000

Hi Xiao Min,
thank you for your expedient response. Please find my follow-up notes below
tagged GIM>>.

Regards,
Greg

On Thu, May 4, 2023 at 12:28 AM <xiao.min2@zte.com.cn> wrote:

> Hi Greg,
>
>
> Thank you for the detailed review and comments, although I don't think
> your comments justify your conclusion.
>
> Please see inline...
> Original
> *From: *GregMirsky <gregimirsky@gmail.com>
> *To: *肖敏10093570;
> *Cc: *rtg-bfd@ietf.org <rtg-bfd@ietf.org>;
> *Date: *2023年04月29日 03:42
> *Subject: **Re: Fw: New Version Notification for
> draft-ietf-bfd-unaffiliated-echo-07.txt*
> Hi Xiao Min,
> thank you for sharing updates. I've read the new version and have several
> questions and comments.
>
>    -
>
>    It is stated in the Abstract:
>
>    BFD Async procedures can be executed over the BFD
>
>    Echo port where the neighboring system only loops packets back to the
>
>    local system.
>
> Is this conclusion differs from the definition of the BFD Echo function in
> RFC 5880? If it is not, what is the value of such a re-statement? If it is,
> it seems like an explicit attribution of this conclusion to this document
> would be helpful.
> [XM]>>> RFC 5880 doesn't say BFD Async procedures can be executed over the
> BFD Echo port because it classifies BFD Echo as an affiliated function.
> Would you please suggest some text you think helpful?
>
> GIM>> I am a bit confused by the "BFD Async procedures" term. In your
opinion, what are these procedures defined in RFC 5880? BFD state machine?
BFD state changes? I believe it would help me if you could give an example,
and add more details to the interpretation of that term.

>
>
>    -
>
>    Is the following a requirement or an observation:
>
>    a network device must be able to quickly detect
>
>    faults in communication with adjacent devices.
>
> If the former, please capitalize the normative language. If the latter,
> then it appears as an arguable view. Indeed, in some cases, local
> protection is a viable option, while in other environments, e2e path
> protection might be preferable.
> [XM]>>> At the beginning of the sentence "in some cases" can be added, is
> that acceptable to you?
>
> GIM>> I think that the capability to faster detection of a network failure
is always desirable. Thus, the statement can be presented as a general node
requirement. On the other hand, it can be worded as an observation. Using
normative keywords in a lowercase form might confuse readers.

>
>
>    -
>
>    Further, in Introduction, I read:
>
>    Section 5 of
>    [RFC5880] indicates that the payload of a BFD Echo packet is a local
>    matter and hence its contents are outside the scope of that
>    specification.  This document, on the other hand, specifies the
>    contents of the Echo packets and what to do with them.
>
> It seems to me that this draft is positioned as the definition of the
> content of an Echo message and the processing of it, whether as an
> unaffiliated or affiliated (RTC5880-style) function. Is that correct?
> [XM]>>> That's incorrect. This document specifies only Unaffiliated BFD
> Echo, and  it doesn't touch affiliated BFD Echo.
>
> GIM>> Thank you for the clarification. I feel that the current text and
its location are unclear. Reiterating the scope of the proposed solution
will certainly make it clearer.

>
>
>    -
>
>    I hope you can help me understand the demultiplexing of Unaffiliated
>    BFD sessions:
>
>    Device A performs its
>    initial demultiplexing of a Unaffiliated BFD Echo session using the
>    source IP address or UDP source port, once the remote system echoes
>    back the local discriminator, all further received packets are
>    demultiplexed based on the "Your Discriminator" field only, which is
>    conformed to the procedure specified in Section 6.3 of [RFC5880].
>
>
>    -
>
>    Does "initial demultiplexing" refers to the first BFD Control message
>    transmitted in the Unaffiliated BFD Echo mode?
>
>    [XM]>>> Not exactly. Actually "initial demultiplexing" is applied to
>    the received BFD Control packet(s) whose "Your Discriminator" is zero.
>
> GIM>> Perhaps that can be added to the document as "In the case when the
value of Your Discriminator in the received packet is zero, demultiplexing
is done based on ..."?

>
>    -
>
>    Considering that "device B would not intercept any received
>    Unaffiliated BFD Echo packet", how "the remote system echoes back the local
>    discriminator"?
>
>    [XM]>>> Here "echoes back" means "loops back", is "loops back" more
>    clear?
>
> GIM>> I think it is better, thank you.

>
>    -
>
>
>
>
>    -
>
>    A lengthy copy of a text from Section 4 of RFC 5881 seems like
>    unnecessary:
>
>    the destination address MUST be chosen in such a way as to
>    cause the remote system to forward the packet back to the local
>    system.  The source address MUST be chosen in such a way as to
>    preclude the remote system from generating ICMP or Neighbor Discovery
>    Redirect messages.  In particular, the source address SHOULD NOT be
>    part of the subnet bound to the interface over which the BFD Echo
>    packet is being transmitted, and it SHOULD NOT be an IPv6 link-local
>    address, unless it is known by other means that the remote system
>    will not send Redirects.
>
> It seems that a reference to that section and something like "rules stated
> in Section 4 [RFC5881] are applicable to the encapsulation of an
> Unaffiliated BFD Echo Control message" could be sufficient.
> [XM]>>> I'd like to follow your suggestion if there is no objection from
> Jeff.
>
> GIM>> Of course.

>
>
>    -
>
>    What is the interpretation of "expected value"? It appears that none
>    of these values are used, but are ignored. Right?
>
>    [XM]>>> As indicated by Jeff, "the desire is that we avoid unset
>    values being a potential vector for disclosure of uninitialized memory".
>
> GIM>> I agree with that. I think it would be helpful to use this reasoning
in the text, including the Security Consideration section.

>
>    -
>
>    A zero value of the Required Min Echo RX Interval field per RFC 5880
>    is interpreted as no support for the Echo function. But it is the
>    recommended value. Although it is ignored. Thus, what is the benefit of
>    initializing the field after all?
>
>    [XM]>>> As indicated by Jeff, "the desire is that we avoid unset
>    values being a potential vector for disclosure of uninitialized memory".
>    -
>
>    In the description
>
>    Afterwards, the
>    provisioned transmission interval is used.
>
> What is the event that triggers the "afterward" transition?
> [XM]>>> The preceding text says "
>
> The slow transmission rate SHOULD be no less then
>    one second per packet, until the session is Up.
>
> ".
>
> GIM>> Perhaps my question was unclear. I understand that the Sender starts
the session at a slow rate. Then, after some event, the Sender switches to
"the provisioned transmission interval". Hence my question What is that
event that is described as "afterward"?

>
>    -
>
>    With the high number of "this value MUST be ignored on receipt", "the
>    Unaffiliated BFD Echo packet reuses the format of the BFD Control packet
>    defined in [RFC5880]" seems like a severe overstatement.
>
>    [XM]>>> I don't think so. Ignoring some fields on receipt doesn't
>    break the truth that BFD Control packet is reused here.
>    -
>
>    Which event triggers the transition in
>
>    *  Your Discriminator MUST be set to 0 initially, and then MUST be
>       set to the same as My Discriminator echoed back.
> [XM]>>> The event is that "My Discriminator" is echoed/looped back.
>
> GIM>> To me, that is not clear from the current text. I think that adding
more detail would help.

>
>    -
>
>    What happens if Desired Min TX Interval, Required Min RX Interval,
>    or Required Min Echo is not set to "the expected value"?
>
>    [XM]>>> Unset values can be a potential vector for disclosure of
>    uninitialized memory.
>
> GIM>> I find myself confused. As I understand it, "expected value" is
something that is known to the system either through configuration or a
pre-set (hardcoded) value. And that value, supposedly,  in validating the
received packet, hence the "expected value" clause. But if the value must
be ignored, then there's no expectation of it in the system. Right? I agree
with the reasoning for initializing memory before transmitting a packet,
but that is far from setting it to an "expected value", in my opinion. WDYT?

>
> Best Regards,
>
> Xiao Min
>
>
> In conclusion. As we learned from the BBF Liason, the Broadband Forum is
> not seeking standardization of the mechanism described in TR-146. Also, I
> learned about the implementation of the mechanism described in
> BBF's TR-146, and the authors are not interested in standardization either,
> as, in their opinion, there's no externally noticeable behavior that
> requires specification. So, I still don't see any value in standardizing
> what is described in the document.
>
> Regards,
> Greg
>
> On Sun, Apr 23, 2023 at 7:16 PM <xiao.min2@zte.com.cn> wrote:
>
>> Dear BFD WG,
>>
>>
>> A -07 revision of draft-ietf-bfd-unaffiliated-echo has been posted,
>> attempting to address all the WGLC comments.
>>
>> The main updates are as below.
>>
>> * add a sentence to clarify that this document doesn't change the
>> affiliated BFD Echo function.
>>
>> * change the order of section 2 "Updates to RFC 5880" and section 3
>> "Unaffiliated BFD Echo Procedures".
>>
>> * add a summary on the Unaffiliated BFD Echo packet fields setting into
>> the end of section "Unaffiliated BFD Echo Procedures".
>>
>> * change the text on IP address setting to the same as specified in
>> section 4 of RFC 5881.
>>
>> * some editorial changes, e.g., s/BFD Unaffiliated Echo
>> packet/Unaffiliated BFD Echo packet/g.
>>
>>
>> Best Regards,
>>
>> Xiao Min
>> Original
>> *From: *internet-drafts@ietf.org <internet-drafts@ietf.org>
>> *To: *Raj Boddireddy <rchetan@juniper.net>;Raj Chetan Boddireddy <
>> rchetan@juniper.net>;Reshad Rahman <reshad@yahoo.com>;Ruixue Wang <
>> wangruixue@chinamobile.com>;Weiqiang Cheng <chengweiqiang@chinamobile.com
>> >;肖敏10093570;
>> *Date: *2023年04月24日 10:09
>> *Subject: **New Version Notification for
>> draft-ietf-bfd-unaffiliated-echo-07.txt*
>>
>> A new version of I-D, draft-ietf-bfd-unaffiliated-echo-07.txt
>> has been successfully submitted by Xiao Min and posted to the
>> IETF repository.
>>
>> Name:        draft-ietf-bfd-unaffiliated-echo
>> Revision:    07
>> Title:        Unaffiliated BFD Echo
>> Document date:    2023-04-23
>> Group:        bfd
>> Pages:        12
>> URL:
>> https://www.ietf.org/archive/id/draft-ietf-bfd-unaffiliated-echo-07.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo
>> Diff:
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-unaffiliated-echo-07
>>
>> Abstract:
>>    Bidirectional Forwarding Detection (BFD) is a fault detection
>>    protocol that can quickly determine a communication failure between
>>    two forwarding engines.  This document proposes a use of the BFD Echo
>>    where the local system supports BFD but the neighboring system does
>>    not support BFD.  BFD Async procedures can be executed over the BFD
>>    Echo port where the neighboring system only loops packets back to the
>>    local system.
>>
>>    This document updates RFC 5880.
>>
>>
>>
>>
>>
>> The IETF Secretariat
>>
>>
>>
>>
>