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