Re: John Scudder's No Objection on draft-ietf-bfd-unaffiliated-echo-12: (with COMMENT)
xiao.min2@zte.com.cn Thu, 17 October 2024 08:14 UTC
Return-Path: <xiao.min2@zte.com.cn>
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 3880BC169434; Thu, 17 Oct 2024 01:14:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.892
X-Spam-Level:
X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_TEMPERROR=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 FIQXnjoxPzAc; Thu, 17 Oct 2024 01:14:37 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AF5EC16942C; Thu, 17 Oct 2024 01:14:29 -0700 (PDT)
Received: from mse-fl2.zte.com.cn (unknown [10.5.228.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4XTgbj0BcJz8RV7M; Thu, 17 Oct 2024 16:14:25 +0800 (CST)
Received: from njb2app05.zte.com.cn ([10.55.22.121]) by mse-fl2.zte.com.cn with SMTP id 49H8E7eK098828; Thu, 17 Oct 2024 16:14:07 +0800 (+08) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njy2app08[null]) by mapi (Zmail) with MAPI id mid201; Thu, 17 Oct 2024 16:14:09 +0800 (CST)
Date: Thu, 17 Oct 2024 16:14:09 +0800
X-Zmail-TransId: 2b006710c751420-cfc75
X-Mailer: Zmail v1.0
Message-ID: <20241017161409571aHW_dpgrTEdcOvMxCZ3ay@zte.com.cn>
In-Reply-To: <172912943281.1327442.8517113308209685588@dt-datatracker-78dc5ccf94-w8wgc>
References: 172912943281.1327442.8517113308209685588@dt-datatracker-78dc5ccf94-w8wgc
Mime-Version: 1.0
From: xiao.min2@zte.com.cn
To: jgs@juniper.net
Subject: Re: John Scudder's No Objection on draft-ietf-bfd-unaffiliated-echo-12: (with COMMENT)
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 49H8E7eK098828
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 6710C761.000/4XTgbj0BcJz8RV7M
Message-ID-Hash: 22M22OXNA4E6P7HFNXOUS765HQFLAODG
X-Message-ID-Hash: 22M22OXNA4E6P7HFNXOUS765HQFLAODG
X-MailFrom: xiao.min2@zte.com.cn
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rtg-bfd.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: iesg@ietf.org, draft-ietf-bfd-unaffiliated-echo@ietf.org, bfd-chairs@ietf.org, rtg-bfd@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection" <rtg-bfd.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/WmzTWlFeoxYf_3llDD-18yyQHzU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Owner: <mailto:rtg-bfd-owner@ietf.org>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Subscribe: <mailto:rtg-bfd-join@ietf.org>
List-Unsubscribe: <mailto:rtg-bfd-leave@ietf.org>
Hi John, Thanks for your thoughtful review and comments. Please see inline. Original From: JohnScudderviaDatatracker <noreply@ietf.org> To: The IESG <iesg@ietf.org>; Cc: draft-ietf-bfd-unaffiliated-echo@ietf.org <draft-ietf-bfd-unaffiliated-echo@ietf.org>;bfd-chairs@ietf.org <bfd-chairs@ietf.org>;rtg-bfd@ietf.org <rtg-bfd@ietf.org>; Date: 2024年10月17日 09:44 Subject: John Scudder's No Objection on draft-ietf-bfd-unaffiliated-echo-12: (with COMMENT) John Scudder has entered the following ballot position for draft-ietf-bfd-unaffiliated-echo-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this document! It's a little unusual in that it talks about how a system can talk to... itself! Which stretches the usual definition of "protocol". Still, it's useful and I'm glad you've done the work. [XM]>>> Thank you! :-) ## COMMENT ### General, theory of operation I didn't see anywhere the document explains in simple terms that the way the extension functions is for the active side to send a packet with one of its own IP addresses as the destination address, upon receipt of which the other side sends it back to the active side. It seems like the lack of this simple explanation led to confusion for at least one reviewer. I suggest adding something like that to avoid future confusion. The Abstract and Introduction seem like the right places. [XM]>>> OK. Propose to add some text to the Introduction section. OLD Note that this method monitors the connectivity to a system over a specific interface and does not verify the availability of a specific IP address at that system.NEW Note that this method requires the local device to send packets with one of its own IP addresses as the destination address, upon receipt of which the adjacent device sends it back to the local device. Also note that this method monitors the connectivity to a device over a specific interface and does not verify the availability of a specific IP address at that device.END ### General, choice of DA Related, I wonder if there is some need for the document to talk about how the local system should be careful in its choice of destination address. Specifically, I would imagine that if system S is sending a packet out interface F, the best DA to choose would be the local address of F, and not one of S's other addresses (e.g. a loopback address, a different interface address). That's because the far-end system can be expected to know the address of F, but is less sure of knowing S's other addresses. [XM]>>> There were discussions within the BFD WG and with the responsible AD Eric on this topic. The conclusion was that this document should just provide a reference to Section 4 of RFC 5881 on how to select the IP DA and IP SA. Does that make sense for you? ### Section 2, couldn't understand Once an Unaffiliated BFD Echo session is created on device A, it starts sending Unaffiliated BFD Echo packets. Unaffiliated BFD Echo packets with zeroed "Your Discriminator" field are demultiplexed to the proper session based on the source IP address or UDP source port, once the remote system loops back the local discriminator, all further received packets are demultiplexed based on the "Your Discriminator" field only, which is conform to the procedure specified in Section 6.3 of [RFC5880]. I find it impossible to understand what the preceding sentence is trying to tell me. If I could understand it I'd suggest a rewrite, but I can't even guess. :-( [XM]>>> This is basically a reuse of the existing mechanism described in RFC 5880 and 5881. In Section 6.3 of RFC 5880 it says: " Once the remote end echoes back the local discriminator, all further received packets are demultiplexed based on the Your Discriminator field only (which means that, among other things, the source address field can change or the interface over which the packets are received can change, but the packets will still be associated with the proper session). The method of demultiplexing the initial packets (in which Your Discriminator is zero) is application dependent, and is thus outside the scope of this specification." In Section 4 of RFC 5881 it says: " An implementation MAY use the UDP port source number to aid in demultiplexing incoming BFD Control packets, but ultimately the mechanisms in [BFD] MUST be used to demultiplex incoming packets to the proper session." (Also, "which is conform to" should be something like "in conformance to".) [XM]>>> OK. Will do s/which is conform to/which is conformed to. ### Section 2, IP redirect provisioned on device A. The Unaffiliated BFD Echo feature depends on device B performing IP forwarding (actually IP redirect) functionality. While such functionality may normally be expected to As far as I know "IP redirect" isn't a defined thing, although there's a confusing overlap with ICMP redirect. I suggest deleting the parenthetical. [XM]>>> OK. Will delete the parenthetical. ### Section 2, confusion about the definition of "rate" Similar to what's specified in [RFC5880], the Unaffiliated BFD Echo session begins with the periodic, slow transmission of Unaffiliated BFD Echo packets. The slow transmission rate SHOULD be no less than one second per packet, until the session is Up. After the session is Up, the provisioned transmission interval is used. When the Unaffiliated BFD Echo session goes Down, the slow transmission rate is resumed. The "Detect Mult" defined in [RFC5880] MUST be set to a There seems to be some confusion between "interval" and "rate" here. A "rate" is conventionally defined as quantity per unit time, i.e. it's a synonym for frequency. So, "rate SHOULD be no less than one second per packet" doesn't make sense, that's a period, not a frequency. The easiest fix would be "rate SHOULD be no greater than one packet per second". [XM]>>> Make sense. Will change the text as you suggested. ### Section 5, specified As specified in Section 5 of [RFC5880], BFD Echo packets may be spoofed. Specifically for Unaffiliated BFD Echo, a DoS attacker may "Specified" is an unfortunate verb in this context, perhaps "explained"? [XM]>>> Is "described" ok for you? ## NITS ### Section 3 NEW TEXT When the Echo function is active with Asynchronous mode, a system SHOULD set bfd.RequiredMinRxInterval to a value of not less than one second (1,000,000 microseconds). This is intended to keep received BFD Control traffic at a negligible level, since the actual detection function is being performed using BFD Echo packets. While a system operating in Demand mode would not receive BFD Control traffic. The last sentence ("While...") is a sentence fragment. Probably you could fix it by deleting "while", so "A system operating in..." [XM]>>> OK. Will delete "While". ### Section 4 As specified in Section 2 of this document, some configurations are needed to make the Unaffiliated BFD Echo work, although the configurations won't go beyond the scope of [RFC5880]. At a BFD- The RFC Editor would fix this, but should be something like, "some configuration is needed"... "although the configuration won't go". [XM]>>> OK. Will fix it as you suggested. Cheers, Xiao Min
- John Scudder's No Objection on draft-ietf-bfd-una… John Scudder via Datatracker
- Re: John Scudder's No Objection on draft-ietf-bfd… xiao.min2