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

[Mahesh Jethanandani via Datatracker <[e-mail]>]

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"?

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.

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?

-------------------------------------------------------------------------------
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.