Re: Mahesh Jethanandani's No Objection on draft-ietf-bfd-unaffiliated-echo-12: (with COMMENT)

[[e-mail]]

Hi Mahesh,
Thanks for your review and comments.Please see inline.

Original


From: MaheshJethanandaniviaDatatracker <[e-mail]>
To: The IESG <[e-mail]>;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2024年10月16日 01:31
Subject: Mahesh Jethanandani's No Objection on draft-ietf-bfd-unaffiliated-echo-12: (with COMMENT)

Mahesh Jethanandani 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:
----------------------------------------------------------------------
 
Section 1, paragraph 2
>    BFD [RFC5880] is a low-overhead, short-duration method to detect
>    faults on the communication path between adjacent forwarding engines.
>    The faults can be on interfaces, data links, and even the forwarding
>    engines.  It is a single, unified mechanism to monitor any media and
>    protocol layers in real time.
 
I do not know if "short-duration" is the right way to describe a "BFD session",
even as the document says it is not a "BFD session". Whatever you call the
continious sending of packets that are echoed back, which in my mind is a
session, it can run with a short interval, but can run for a very long
duration. Maybe "short-interval"?
 [XM]>>> Make sense. Will do s/short-duration/short-interval.


Section 1, paragraph 9
>    This document updates [RFC5880] by defining a new method of BFD Echo-
>    Only without requiring an implementation to support the full BFD
>    protocol.  It specifies the use of the Unaffiliated BFD Echo over
>    IPv4 and IPv6 for a single IP hop.  A full description of the updates
>    to [RFC5880] is provided in Section 3.
 
As noted in Gyan Mishra's review, even as it might be obvious to some, it would
help to clarify why Unaffliated BFD Echo cannot be supported over multi-hop BFD.
 [XM]>>> OK. Propose to add some text as below.
OLD
It specifies the use of the Unaffiliated BFD Echo over
 IPv4 and IPv6 for a single IP hop. A full description of the updates
 to [RFC5880] is provided in Section 3.NEW
It specifies the use of the Unaffiliated BFD Echo over
 IPv4 and IPv6 for a single IP hop. The reason why it cannot be used for multihop paths is that the Unaffiliated BFD Echo packets would be looped back by the first hop. A full description of the updates
 to [RFC5880] is provided in Section 3.END


Section 2, paragraph 10
>    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
>    value provisioned on device A.  When the bfd.SessionState is Up and a
>    "Detect Mult" number of Unaffiliated BFD Echo packets have not
>    arrived at device A as they should, the device A "MUST set
>    bfd.SessionState to Down and bfd.LocalDiag to 2 (Echo Function
>    Failed)", as specified in Section 6.8.5 of [RFC5880].
 
In this example, device A is the one implementing the full BFD stack. Thus it
is the only one to have a notion of session being up. Can that be made explicit
in the text?
 [XM]>>> With the suggested text from Adrian and Gunter, the third paragraph of this section now reads:
"
 An Unaffiliated BFD Echo session is not actually a BFD session
 because there is no coordination of BFD protocol state between the
 two link ends: the remote end does not support BFD and so cannot
 engage in a BFD session. The local end as an initiator may regard
 the Unaffiliated BFD Echo session as a BFD session within its
 own standpoint."
Is that explicit enough?


-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------
 
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool) so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.
 
Section 2, paragraph 6
> iscriminator" field only, which is conform to the procedure specified in Sect
>                                    ^^^^^^^
Consider using either the past participle "conformed" or the present participle
"conforming" here.
 [XM]>>> OK. Will do s/is conform to/is conformed to.
 




Cheers,
Xiao Min