Skip to main content

Unaffiliated Bidirectional Forwarding Detection (BFD) Echo
draft-ietf-bfd-unaffiliated-echo-14

Revision differences

Document history

Date Rev. By Action
2024-12-13
14 (System) IANA Action state changed to No IANA Actions from In Progress
2024-12-11
14 (System) RFC Editor state changed to EDIT
2024-12-11
14 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2024-12-11
14 (System) Announcement was received by RFC Editor
2024-12-11
14 (System) IANA Action state changed to In Progress
2024-12-11
14 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2024-12-11
14 Cindy Morgan IESG has approved the document
2024-12-11
14 Cindy Morgan Closed "Approve" ballot
2024-12-11
14 Cindy Morgan Ballot approval text was generated
2024-12-11
14 (System) Removed all action holders (IESG state changed)
2024-12-11
14 Éric Vyncke IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2024-12-11
14 Zaheduzzaman Sarker [Ballot comment]
Thanks for addressing my discuss point.
2024-12-11
14 Zaheduzzaman Sarker [Ballot Position Update] Position for Zaheduzzaman Sarker has been changed to No Objection from Discuss
2024-12-10
14 Xiao Min New version available: draft-ietf-bfd-unaffiliated-echo-14.txt
2024-12-10
14 Xiao Min New version accepted (logged-in submitter: Xiao Min)
2024-12-10
14 Xiao Min Uploaded new revision
2024-12-04
13 (System) Changed action holders to Éric Vyncke (IESG state changed)
2024-12-04
13 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-12-04
13 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2024-12-04
13 Xiao Min New version available: draft-ietf-bfd-unaffiliated-echo-13.txt
2024-12-04
13 Xiao Min New version accepted (logged-in submitter: Xiao Min)
2024-12-04
13 Xiao Min Uploaded new revision
2024-10-29
12 Roman Danyliw
[Ballot comment]
Thank you to Gyan Mishra for the GENART review.  Please review this thread as it proposes helpful clarifying language.

Thank you for re-chartering …
[Ballot comment]
Thank you to Gyan Mishra for the GENART review.  Please review this thread as it proposes helpful clarifying language.

Thank you for re-chartering the WG to address my DISCUSS feedback.
2024-10-29
12 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss
2024-10-17
12 (System) Changed action holders to Reshad Rahman, Xiao Min, Weiqiang Cheng, Ruixue Wang, Raj Boddireddy (IESG state changed)
2024-10-17
12 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2024-10-17
12 Zaheduzzaman Sarker
[Ballot discuss]
Thanks for working on this specificaition. This is an interesting protocol to enable system to loopback packets to itself.

Also thanks for Brian …
[Ballot discuss]
Thanks for working on this specificaition. This is an interesting protocol to enable system to loopback packets to itself.

Also thanks for Brian Trammell for his good TSVART review. That email thread had a very good conversation to understand this specification better. Thanks to Erik, Jeffrey for reaching to resolutions.

I am holding a discuss on the relaxation of congestion control statements in the operational considerations. I think it is very important that we explain the reason better on why we are relaxing that requirement on BFD session ( but not session) in this specification.  

# RFC 5880 says -

     Note that "congestion" is not only a traffic phenomenon, but also a
   computational one.  It is possible for systems with a large number of
   BFD sessions and/or very short packet intervals to become CPU-bound.
   As such, a congestion control algorithm SHOULD be used even across
   single hops in order to avoid the possibility of catastrophic system
   collapse, as such failures have been seen repeatedly in other
   periodic Hello-based protocols.

  and this specification says

     All Operational Considerations from [RFC5880] apply, except that the Unaffiliated BFD Echo can only be used across one hop, which result in unnecessity of a congestion control mechanism.

  It seems like this specification is relaxing the congestion control requirements without really explaining why it is an exception from what is a SHOULD in RFC 5880, even for single hop. Note that RFC 8085 cprovides congestion control guidelines for protocol that uses UDP. I understand that there is a periodicity and configured value to send the BFD Echo packets, still that does not automatically result in unnecessity of a congestion control requirement for UDP traffic, especially when RFC 5880 also says the congestion is not only a traffic phenomenon. I was expecting more explanation of this exception ( this was also brought up by the TSVART review ) and potential operation impacts as RFC 5880 also indicates the effects can be catastrophic.
2024-10-17
12 Zaheduzzaman Sarker
[Ballot comment]
I have further comments below as I believe when addressed that will improve the specification description -

# Section 1 : I don't …
[Ballot comment]
I have further comments below as I believe when addressed that will improve the specification description -

# Section 1 : I don't quite get this statement

    This document updates [RFC5880] by defining a new method of BFD Echo-Only without requiring an implementation to support the full BFD protocol.

  Does this mean any IP packet forwarder can be Device B in figure 1? or the device B actually needs to implement RFC5880 partially. In the description of Figure 1 , it says Device B does not support BFD. So to me, Device B can be anything that understands IP forwarding, is it?

# Section 5 : it is not clear to me if Device B (loop-back device) in figure 1 does not support BFD then how it can provide the authentication as per RFC 8550. I think we should say that for authentication the loop-back device needs to support RFC 5880.
2024-10-17
12 Zaheduzzaman Sarker [Ballot Position Update] New position, Discuss, has been recorded for Zaheduzzaman Sarker
2024-10-16
12 Murray Kucherawy
[Ballot comment]
I support Roman's DISCUSS.

The SHOULD in Section 2 appears to be re-stating advice from RFC 5880.  I suggest not using SHOULD …
[Ballot comment]
I support Roman's DISCUSS.

The SHOULD in Section 2 appears to be re-stating advice from RFC 5880.  I suggest not using SHOULD here if that advice is simply being carried forward, since you already refer back to that document whose advice is still in effect.  Or if you're actually tweaking that advice here, I suggest being more explicit that that's what's going on.
2024-10-16
12 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2024-10-16
12 John Scudder
[Ballot 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 …
[Ballot 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.

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

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

### 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. :-(

(Also, "which is conform to" should be something like "in conformance 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.

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

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

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

### 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".
2024-10-16
12 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2024-10-16
12 Roman Danyliw
[Ballot discuss]
(For the BFD WG chairs and responsible AD) This document does not appear to be in scope of the charter (version -08).  The …
[Ballot discuss]
(For the BFD WG chairs and responsible AD) This document does not appear to be in scope of the charter (version -08).  The current charter identifies 7 specific topics (numbers 1, 2a, 2b, 2c, 3, 4, and 5), none of which appear to cover this document.
2024-10-16
12 Roman Danyliw [Ballot comment]
Thank you to Gyan Mishra for the GENART review.  Please review this thread as it proposes helpful clarifying language.
2024-10-16
12 Roman Danyliw [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw
2024-10-16
12 Deb Cooley [Ballot comment]
Thanks to Stephen Farrell for both of his secdir reviews of this draft.
2024-10-16
12 Deb Cooley [Ballot Position Update] New position, No Objection, has been recorded for Deb Cooley
2024-10-15
12 Warren Kumari
[Ballot comment]
Much thanks to Dhruv for the initial OpsDir review (https://datatracker.ietf.org/doc/review-ietf-bfd-unaffiliated-echo-11-opsdir-lc-dhody-2024-10-08/), and then for updating the reviw (https://datatracker.ietf.org/doc/review-ietf-bfd-unaffiliated-echo-12-opsdir-telechat-dhody-2024-10-10/) to explicitly note that their concerns have been addressed.
I'm traveling at the moment, and so have relied heavily on the review.
2024-10-15
12 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2024-10-15
12 Mahesh Jethanandani
[Ballot comment]
Section 1, paragraph 2
>    BFD [RFC5880] is a low-overhead, short-duration method to detect
>    faults on the communication …
[Ballot 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.
2024-10-15
12 Mahesh Jethanandani [Ballot Position Update] New position, No Objection, has been recorded for Mahesh Jethanandani
2024-10-15
12 Paul Wouters [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters
2024-10-15
12 Brian Trammell Request for Telechat review by TSVART Completed: Not Ready. Reviewer: Brian Trammell. Sent review to list.
2024-10-15
12 Francesca Palombini [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini
2024-10-14
12 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2024-10-14
12 Gyan Mishra Request for Last Call review by GENART Completed: Not Ready. Reviewer: Gyan Mishra. Sent review to list. Submission of review completed at an earlier date.
2024-10-14
12 Gyan Mishra Request for Last Call review by GENART Completed: Not Ready. Reviewer: Gyan Mishra.
2024-10-14
12 Orie Steele [Ballot Position Update] New position, No Objection, has been recorded for Orie Steele
2024-10-14
12 Gunter Van de Velde
[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-bfd-unaffiliated-echo-12.txt

# line numbers are derived with the idnits tool https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-bfd-unaffiliated-echo-12.txt

# idnits spits …
[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-bfd-unaffiliated-echo-12.txt

# line numbers are derived with the idnits tool https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-bfd-unaffiliated-echo-12.txt

# idnits spits a warning about pre-rfc5378 work

# i found the document well written and a nice read into this technology. Thank you.

# In what follows you will find some detailed observations and some editorial suggestions trying to improve readability while keeping original message.

#DETAILED COMMENTS
#=================

18   Bidirectional Forwarding Detection (BFD) is a fault detection
19   protocol that can quickly determine a communication failure between
20   two forwarding engines.  This document defines a use of the BFD Echo
21   where the local system supports BFD but the adjacent system does not
22   support BFD.  BFD Control packet and its processing procedures can be
23   executed over the BFD Echo port where the adjacent system only loops
24   packets back to the local system.

26   This document updates RFC 5880 by defining a new method of BFD Echo-
27   Only without requiring an implementation to support the full BFD
28   protocol.

GV> proposed alternative abstract rewrite for readability and high level understanding of the technology proposed:

"
This document specifies an extension to the Bidirectional Forwarding Detection (BFD) protocol that enables the use of the BFD Echo function without the need for an associated BFD control session. This "Unaffiliated BFD Echo" mechanism allows rapid detection of forwarding path failures in networks where establishing BFD control sessions is impractical or undesirable. By decoupling the Echo function from the control plane, network devices can utilize BFD's fast failure detection capabilities in a simplified manner, enhancing network resiliency and operational efficiency.

This document updates RFC 5880 by defining a new Unaffiliated BFD Echo mechanism.
"

77 1.  Introduction
78
79   To minimize the impact of device/link faults on services and improve
80   network availability, in the single-hop cases a network device needs
81   to be able to quickly detect faults in communication with adjacent
82   devices.  Measures can then be taken to promptly rectify the faults
83   to ensure service continuity.
84
85   BFD [RFC5880] is a low-overhead, short-duration method to detect
86   faults on the communication path between adjacent forwarding engines.
87   The faults can be on interfaces, data links, and even the forwarding
88   engines.  It is a single, unified mechanism to monitor any media and
89   protocol layers in real time.
90
91   BFD defines the Asynchronous mode and the Demand mode to satisfy
92   various deployment scenarios.  It also supports an Echo function that
93   reduces the level of BFD support required in device implementations,
94   as described in Section 3.2 of [RFC5880].  When the Echo function is
95   activated, the local system sends BFD Echo packets and the remote
96   system loops back the received Echo packets through the forwarding
97   path.  If several consecutive BFD Echo packets are not received by
98   the local system, then the BFD session is declared to be Down.
99
100   When using BFD Echo function, there are two typical scenarios as
101   below:
102
103   *  Full BFD protocol capability with adjunct Echo function.  This
104       scenario requires both the local device and the adjacent device to
105       support the full BFD protocol.
106
107   *  BFD Echo-Only method without full BFD protocol capability.  This
108       scenario requires only the local device to support sending and
109       demultiplexing BFD Control packets.  In this scenario, the BFD
110       Control packets are sent over the BFD Echo port, but that the
111       processing procedures for Asynchronous mode are used with the
112       modifications described in this document.  Note that this method
113       monitors the connectivity to a system over a specific interface
114       and does not verify the availability of a specific IP address at
115       that system.
116
117   The former scenario is referred to as "Affiliated BFD Echo" in this
118   document, which remains unchanged from [RFC5880].  The latter
119   scenario is referred to as "Unaffiliated BFD Echo", which is
120   specified in this document.
121
122   Section 5 of [RFC5880] indicates that the payload of an affiliated
123   BFD Echo packet is a local matter and hence its contents are outside
124   the scope of that specification.  This document, on the other hand,
125   specifies the contents of the Unaffiliated BFD Echo packet and what
126   to do with them.  This would appear to contravene Section 5 of
127   [RFC5880].  However, the core behavior in that RFC simply states that
128   the contents of the BFD Echo packets are a local matter, and this
129   document is simply defining "the local matter".  Regarding the
130   selection of IP address, the rules stated in Section 4 of [RFC5881]
131   are applicable to the encapsulation of an Unaffiliated BFD Echo
132   packet.
133
134   Section 6.2.2 of [BBF-TR-146] describes one use case of the
135   Unaffiliated BFD Echo.
136
137   This document updates [RFC5880] by defining a new method of BFD Echo-
138   Only without requiring an implementation to support the full BFD
139   protocol.  It specifies the use of the Unaffiliated BFD Echo over
140   IPv4 and IPv6 for a single IP hop.  A full description of the updates
141   to [RFC5880] is provided in Section 3.

GV> proposed rewrite for improved readability:

"
To minimize the impact of device and link faults on services and to improve network availability in single-hop scenarios, a network device needs the capability to quickly detect communication faults with adjacent devices. Prompt detection allows for timely remedial actions to ensure service continuity.

BFD [RFC5880] provides a low-overhead, short-duration method for detecting faults on the communication path between adjacent forwarding engines, which may include interfaces, data links, and the forwarding engines themselves. BFD offers a unified mechanism to monitor any media and protocol layers in real time.

BFD defines two primary modes—Asynchronous mode and Demand mode—to accommodate various deployment scenarios. Additionally, it supports an Echo function that reduces the level of BFD support required in device implementations, as described in Section 3.2 of [RFC5880]. When the Echo function is activated, the local system sends BFD Echo packets, and the remote system loops back the received Echo packets through the forwarding path. If several consecutive BFD Echo packets are not received by the local system, the BFD session is declared Down.

There are two typical scenarios when using the BFD Echo function:

* Full BFD protocol capability with adjunct Echo function (Affiliated BFD Echo): This scenario requires both the local device and the adjacent device to support the full BFD protocol. This operation remains unchanged from [RFC5880].

* BFD Echo-Only method without full BFD protocol capability (Unaffiliated BFD Echo): This scenario requires only the local device to support sending and demultiplexing BFD Control packets. In this case, BFD Control packets are sent over the BFD Echo port, and the processing procedures for Asynchronous mode are used with the modifications specified in this document. 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 on that system.

This document specifies the Unaffiliated BFD Echo scenario.

Section 5 of [RFC5880] indicates that the payload of an Affiliated BFD Echo packet is a local matter and, therefore, its contents are outside the scope of that specification. This document, however, specifies the contents of the Unaffiliated BFD Echo packet and the procedures for handling them. While this may appear to contravene Section 5 of [RFC5880], the core behavior in that RFC states that the contents of BFD Echo packets are a local matter; this document is defining that "local matter." Regarding the selection of IP addresses, the rules stated in Section 4 of [RFC5881] are applicable to the encapsulation of an Unaffiliated BFD Echo packet.

Section 6.2.2 of [BBF-TR-146] describes a use case for the Unaffiliated BFD Echo.

This document updates [RFC5880] by defining a new method of BFD Echo-only operation that does not require 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.
"

186   engage in a BFD session.  The local end as an initiator may regard
187   the Unaffiliated BFD Echo session as a BFD session within its
188   implementation.

GV> To me the wording "within its implementation" is not so clear what it exactly means. I suspect that the intent is to say that this session is perceived to be internal contained within its own implementation without any external control plane devices or systems? Can the text be made more descriptive?

190   For unaffiliated echo, an Unaffiliated BFD Echo session is created on
191   device A, and the Unaffiliated BFD Echo session MUST follow the BFD
192   state machine defined in Section 6.2 of [RFC5880], except that the

GV> The wording "For unaffiliated echo" reads odd. Would it be correct to say "For the unaffiliated echo procedure" to be more accurate? or was this suggesting something else?


190   For unaffiliated echo, an Unaffiliated BFD Echo session is created on
191   device A, and the Unaffiliated BFD Echo session MUST follow the BFD
192   state machine defined in Section 6.2 of [RFC5880], except that the
193   received state is not extracted from BFD Control packets originated
194   by the remote system, but from packets originated by the local system
195   and looped back from the remote system.  Therefore, Unaffiliated BFD
196   Echo does not use the AdminDown state.  BFD Control packets are
197   transmitted and received as Unaffiliated BFD Echo packets using
198   destination UDP port 3785, as defined in [RFC5881].  The procedures
199   for BFD Async sessions are executed for the looped BFD Control
200   packets as per [RFC5880], including validation and authentication.

GV> From a readability perspective, what about the following editorial suggestion:

"
For the Unaffiliated Echo procedure, an Unaffiliated BFD Echo session is established on device A. The session MUST adhere to the BFD state machine specified in Section 6.2 of [RFC5880], with the exception that the received state is not derived from BFD Control packets originating from the remote system, but rather from packets that are generated by the local system and looped back from the remote system. Consequently, the AdminDown state is not utilized in Unaffiliated BFD Echo.

BFD Control packets are transmitted and received as Unaffiliated BFD Echo packets, using UDP destination port 3785, as defined in [RFC5881]. The standard procedures for BFD Asynchronous sessions are applied to the looped BFD Control packets, including packet validation and authentication, in accordance with [RFC5880].
"

216   Within the Unaffiliated BFD Echo packet, the "Desired Min TX
217   Interval" and "Required Min RX Interval" defined in [RFC5880] MUST be
218   populated with a certain value, which can avoid unset value being a
219   potential vector for disclosure of uninitialized memory.  A suggested
220   value is 1 second (1,000,000 microseconds).  These values, however,
221   MUST be ignored on receipt.  Furthermore, these values MUST NOT be
222   used to calculate the Detection Time.

GV> I got thrown off guard when reading the word 'certain' I am not sure it the correct construct to use here. There is no certainty. I suspect that the intent is to say that a specific value must be used. I am not sure why or how the uninitialized memory comes into the picture? Maybe a word to explain this could be added for non-bfd experts?

To make the existing paragraph better readable what about the following rewrite:

"
In the context of an Unaffiliated BFD Echo packet, the "Desired Min TX Interval" and "Required Min RX Interval" fields, as defined in [RFC5880], MUST be populated with a specific value to prevent the potential exposure of uninitialized memory. It is RECOMMENDED that these fields be set to a value of 1 second (1,000,000 microseconds). However, upon receipt, these values MUST be ignored and MUST NOT be used in the calculation of the Detection Time.
"

224   The "Required Min Echo RX Interval" defined in [RFC5880] MUST be
225   populated with a certain value, which can avoid unset value being a
226   potential vector for disclosure of uninitialized memory.  A suggested
227   value is 0.  This value MUST be ignored on receipt.  The transmission
228   interval for Unaffiliated BFD Echo packets in the Up state MUST be
229   provisioned on device A.  The Unaffiliated BFD Echo feature depends
230   on device B performing IP forwarding (actually IP redirect)
231   functionality.  While such functionality may normally be expected to
232   be supported on a router, it may not be enabled on a host by default.
233   The method for provisioning device B to loop back Unaffiliated BFD
234   Echo packets is outside the scope of this document.

GV> What about the following rewrite:

"
The "Required Min Echo RX Interval" field, as defined in [RFC5880], MUST be populated with a specific value to prevent the potential disclosure of uninitialized memory. It is RECOMMENDED that this value be set to 0. However, this value MUST be ignored upon receipt. The transmission interval for Unaffiliated BFD Echo packets when in the Up state MUST be provisioned on device A.

The functionality of the Unaffiliated BFD Echo feature is dependent on device B performing IP forwarding (specifically, IP redirect functionality). While this capability is typically expected to be supported on routers, it may not be enabled by default on hosts. The method for provisioning device B to loop back Unaffiliated BFD Echo packets is outside the scope of this document.
"

236   Similar to what's specified in [RFC5880], the Unaffiliated BFD Echo
237   session begins with the periodic, slow transmission of Unaffiliated
238   BFD Echo packets.  The slow transmission rate SHOULD be no less than
239   one second per packet, until the session is Up.  After the session is
240   Up, the provisioned transmission interval is used.  When the

GV> In the above is described that with slow transmission rate to be no less as one second per packet. Next the text moves to the provisioned transmission interval. I was wondering if it would be useful to inform about the range of the valid transmission intervals with unaffiliated sessions for completeness of the paragraph?

253   *  "My Discriminator" MUST be set to the provisioned local
254       discriminator.
255
256   *  "Your Discriminator" MUST be set to 0 initially, and then MUST be
257       set to the same as "My Discriminator" looped back.
258
259   *  "Desired Min TX Interval" MUST be set to a certain value.  A
260       suggested value is 1 second (1,000,000 microseconds).
261
262   *  "Required Min RX Interval" MUST be set to a certain value.  A
263       suggested value is 1 second (1,000,000 microseconds).
364
265   *  "Required Min Echo RX Interval" MUST be set to a certain value.  A
266       suggested value is 0.
267
268   *  "Detect Mult" MUST be set to the provisioned maximum allowable
269       number of consecutively lost Unaffiliated BFD Echo packets.

GV> Proposed readability rewrite:

"
* My Discriminator: MUST be set to the provisioned local discriminator.

* Your Discriminator: MUST initially be set to 0, and then MUST be set to the value of "My Discriminator" looped back from the remote system.

* Desired Min TX Interval: MUST be set to a specific value, with a suggested value of 1 second (1,000,000 microseconds).

* Required Min RX Interval: MUST be set to a specific value, with a suggested value of 1 second (1,000,000 microseconds).

* Required Min Echo RX Interval: MUST be set to a specific value, with a suggested value of 0.

* Detect Mult: MUST be set to the provisioned maximum allowable number of consecutively lost Unaffiliated BFD Echo packets.
"

273   The Unaffiliated BFD Echo described in this document reuses the BFD
274   Echo function as described in [RFC5880] and [RFC5881], but does not
275   require BFD Asynchronous or Demand mode.  When using the Unaffiliated

GV> Is the following more accurate?

s/require BFD Asynchronous or Demand mode/require BFD Asynchronous or Demand mode on the remote system/

275   require BFD Asynchronous or Demand mode.  When using the Unaffiliated
276   BFD Echo, only the local system has the BFD protocol enabled; the
277   remote system just loops back the received BFD Echo packets as
278   regular data packets.

GV> suggested editorial rewrite:

"
In the Unaffiliated BFD Echo operation, only the local system has the BFD protocol enabled, while the remote system simply loops back the received BFD Echo packets as ordinary data packets, without engaging in the BFD protocol.
"
2024-10-14
12 Gunter Van de Velde [Ballot Position Update] New position, No Objection, has been recorded for Gunter Van de Velde
2024-10-12
12 Adrian Farrel Request for Last Call review by RTGDIR Completed: Ready. Reviewer: Adrian Farrel. Review has been revised by Adrian Farrel.
2024-10-12
12 Stephen Farrell Request for Telechat review by SECDIR Completed: Has Issues. Reviewer: Stephen Farrell. Sent review to list.
2024-10-11
12 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2024-10-10
12 Tero Kivinen Request for Telechat review by SECDIR is assigned to Stephen Farrell
2024-10-10
12 Dhruv Dhody Request for Telechat review by OPSDIR Completed: Ready. Reviewer: Dhruv Dhody. Sent review to list.
2024-10-10
12 Magnus Westerlund Request for Telechat review by TSVART is assigned to Brian Trammell
2024-10-10
12 Carlos Pignataro Request for Telechat review by OPSDIR is assigned to Dhruv Dhody
2024-10-10
12 Éric Vyncke Placed on agenda for telechat - 2024-10-17
2024-10-10
12 Éric Vyncke Ballot has been issued
2024-10-10
12 Éric Vyncke [Ballot Position Update] New position, Yes, has been recorded for Éric Vyncke
2024-10-10
12 Éric Vyncke Created "Approve" ballot
2024-10-10
12 Éric Vyncke IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2024-10-10
12 Éric Vyncke Ballot writeup was changed
2024-10-10
12 (System) Changed action holders to Éric Vyncke (IESG state changed)
2024-10-10
12 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-10-10
12 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2024-10-10
12 Xiao Min New version available: draft-ietf-bfd-unaffiliated-echo-12.txt
2024-10-10
12 Xiao Min New version accepted (logged-in submitter: Xiao Min)
2024-10-10
12 Xiao Min Uploaded new revision
2024-10-10
11 Éric Vyncke
A revised I-D is required to address all directorate reviews; authors & reviewers have agreed on the content of the next revision, so, let's submit …
A revised I-D is required to address all directorate reviews; authors & reviewers have agreed on the content of the next revision, so, let's submit it.

Email sent to the authors and to the BFD mailing list.
2024-10-10
11 (System) Changed action holders to Reshad Rahman, Xiao Min, Weiqiang Cheng, Ruixue Wang, Raj Boddireddy (IESG state changed)
2024-10-10
11 Éric Vyncke IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead
2024-10-09
11 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2024-10-08
11 Dhruv Dhody Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Dhruv Dhody. Sent review to list.
2024-10-07
11 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2024-10-07
11 David Dong
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-bfd-unaffiliated-echo-11, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-bfd-unaffiliated-echo-11, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist
2024-10-07
11 Stephen Farrell Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Stephen Farrell. Sent review to list.
2024-10-05
11 Tim Wicinski Request for Last Call review by INTDIR Completed: Ready with Nits. Reviewer: Tim Wicinski. Sent review to list.
2024-09-30
11 Carlos Pignataro Assignment of request for Last Call review by OPSDIR to Tony Li was withdrawn
2024-09-30
11 Carlos Pignataro Request for Last Call review by OPSDIR is assigned to Dhruv Dhody
2024-09-30
11 Carlos Pignataro Request for Last Call review by OPSDIR is assigned to Tony Li
2024-09-27
11 Tero Kivinen Request for Last Call review by SECDIR is assigned to Stephen Farrell
2024-09-26
11 Adrian Farrel Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Adrian Farrel. Sent review to list.
2024-09-26
11 Jean Mahoney Request for Last Call review by GENART is assigned to Gyan Mishra
2024-09-25
11 Carlos Jesús Bernardos Request for Last Call review by INTDIR is assigned to Tim Wicinski
2024-09-25
11 Daniam Henriques Request for Last Call review by RTGDIR is assigned to Adrian Farrel
2024-09-25
11 Éric Vyncke Requested Last Call review by RTGDIR
2024-09-25
11 Éric Vyncke Requested Last Call review by OPSDIR
2024-09-25
11 Éric Vyncke Requested Last Call review by INTDIR
2024-09-25
11 Cindy Morgan IANA Review state changed to IANA - Review Needed
2024-09-25
11 Cindy Morgan
The following Last Call announcement was sent out (ends 2024-10-09):

From: The IESG
To: IETF-Announce
CC: bfd-chairs@ietf.org, draft-ietf-bfd-unaffiliated-echo@ietf.org, evyncke@cisco.com, jhaas@pfrc.org, rtg-bfd@ietf.org …
The following Last Call announcement was sent out (ends 2024-10-09):

From: The IESG
To: IETF-Announce
CC: bfd-chairs@ietf.org, draft-ietf-bfd-unaffiliated-echo@ietf.org, evyncke@cisco.com, jhaas@pfrc.org, rtg-bfd@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Unaffiliated BFD Echo) to Proposed Standard


The IESG has received a request from the Bidirectional Forwarding Detection
WG (bfd) to consider the following document: - 'Unaffiliated BFD Echo'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-10-09. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Bidirectional Forwarding Detection (BFD) is a fault detection
  protocol that can quickly determine a communication failure between
  two forwarding engines.  This document defines a use of the BFD Echo
  where the local system supports BFD but the adjacent system does not
  support BFD.  BFD Control packet and its processing procedures can be
  executed over the BFD Echo port where the adjacent system only loops
  packets back to the local system.

  This document updates RFC 5880.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/



No IPR declarations have been submitted directly on this I-D.




2024-09-25
11 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2024-09-25
11 Cindy Morgan Last call announcement was generated
2024-09-24
11 Éric Vyncke Last call was requested
2024-09-24
11 Éric Vyncke Ballot approval text was generated
2024-09-24
11 Éric Vyncke Ballot writeup was generated
2024-09-24
11 Éric Vyncke IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2024-09-24
11 Éric Vyncke Last call announcement was generated
2024-09-24
11 (System) Changed action holders to Éric Vyncke (IESG state changed)
2024-09-24
11 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-09-24
11 Xiao Min New version available: draft-ietf-bfd-unaffiliated-echo-11.txt
2024-09-24
11 Xiao Min New version accepted (logged-in submitter: Xiao Min)
2024-09-24
11 Xiao Min Uploaded new revision
2024-09-20
10 Éric Vyncke
AD review sent to rtg-bfd@ietf.org and the authors.

Dear BFD, dear authors,

To lighten John Scudder’s workload, I will be the alternate responsible AD for …
AD review sent to rtg-bfd@ietf.org and the authors.

Dear BFD, dear authors,

To lighten John Scudder’s workload, I will be the alternate responsible AD for draft-ietf-bfd-unaffiliated-echo. As I am an INT AD, please bear with me if I state something wrong about BFD ;-)

First of all: thanks to the authors and the WHG for authoring this I-D and to Jeff Haas for being the shepherd.

Before proceeding with the publication process, I usually do my AD review before starting the IETF Last Call and *I request either a reply or an action (revised I-D) for all the points below* (some of them are nits); the only goal is to ease the IESG evaluation later.

Let’s work together to get this I-D published :-)

Regards

-éric

# Abstract

s/ This document proposes a use of the BFD Echo/ This document defines a use of the BFD Echo/

s/but the neighboring system does/but the adjacent system does/ ? (to be consistent with S1)

# Generic

The section 1 should include some explanations about how packets are looped back to the source. RFC 5881 says ‘no LLA and not the subnet addresses’, so which addresses are used for source and destination ? The addressing probably deserves one section in the document.

# Section 1

s/Full BFD protocol capability with affiliated Echo function/Full BFD protocol capability in the local and adjacent systems/ ? As the term ‘affiliated’ is defined in a subsequent paragraph and is not defined in RFC 5880.

In `BFD Echo-Only method without full BFD protocol capability` should “in the adjacent system” be added ?

Does it make sense to refer to an expired draft, draft-wang-bfd-one-arm-use-case-00 ? Expiration was in 2020...

s/This document describes the use/This document specifies the use/ It is a standard track document after all ;-)

# Section 2

Suggest using aasvg for nicer picture in rendering

About figure 1, unsure whether “interface 1” adds anything, suggest removing (same for the top “Device A” and “Device B”).

s/with zeroed "Your Discriminator"/with zeroed "Your Discriminator" field/   

s/which is conformed to/which is conform to/ ?

As I am not an English speaker, I wonder whether “with a certain value” is really the appropriate wording.

The use of SHOULD should come with explanation of what happens if the SHOULD is bypassed (i.e., the previous issue of memory disclosure should be moved here).

At the end of this section, the BFD fields are not enclosed in double quotes, they should be for clarity as well as to be consistent with the previous text.

# Section 3

Bear with my lack of expertise in BFD, but can this be achieved `Demand mode MUST NOT be active if the session goes Down`?

# Section 4

Unsure whether it brings any value, either delete this applicability section or move it as a subsection of the introduction ?

# Section 5

As I wrote above, it is unclear for me (and probably many readers) what are the src/dst addresses of the IP packets, i.e., I cannot understand whether uRPF must be disabled or not. => an addressing considerations section is welcome with some examples.

About the GSTM, as the technique clearly specifies that the adjacent system does not implement BFD, how can this document require that looping is only done with TTL/HL=255 ?

RFC 8704 does not define a strict mode uRPF, so, remove this reference.
2024-09-20
10 (System) Changed action holders to Éric Vyncke, Reshad Rahman, Xiao Min, Weiqiang Cheng, Ruixue Wang, Raj Boddireddy (IESG state changed)
2024-09-20
10 Éric Vyncke IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested
2024-09-20
10 Éric Vyncke Changed action holders to Éric Vyncke (Éric Vyncke acting as alternate AD)
2024-09-20
10 Éric Vyncke Shepherding AD changed to Éric Vyncke
2024-01-17
10 Jeffrey Haas
Prelude:
The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap
with a similar feature specified in BBF TR-146.  A liaison statement was
exchanged with BBF with …
Prelude:
The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap
with a similar feature specified in BBF TR-146.  A liaison statement was
exchanged with BBF with regard to this work:

https://mailarchive.ietf.org/arch/msg/rtg-bfd/vw31qO1UpD7epoZKXT8_obmY64A/

This internet-draft is largely intended to cover a full IETF specification for
the functionality covered by TR-146 and address the minor issues where TR-146
is incompletely specified.

: Document History
:
: 1.  Does the working group (WG) consensus represent the strong concurrence of a
:    few individuals, with others being silent, or did it reach broad agreement?

The document has weak but positive Working Group consensus to advance.  This is
somewhat typical of documents progressing through BFD at this point.  That said,
the document has had a degree of strong review from the interested parties.

: 2.  Was there controversy about particular points, or were there decisions where
:    the consensus was particularly rough?

There were several concerns from Greg Mirsky largely regarding the following
points:

1. The mechanism specified in the document bypassed the pre-existing BFD Async
mechanism which permitted the Echo functionality to be enabled.  However, this
is exactly the point of this feature.  Much of the updates to RFC 5880 are
present to permit ths mode.  It's important to note that this mechanism is not
intended to completely replace the Echo mode for RFC 5880 when used in
conjunction with the traditional Async mode.

2. The mechanism specified in the document specified a format for the BFD Echo
packets.  This would appear to contravene RFC 5880, Section 5.  However, the
core behavior in the RFC simply states that the contents of the Echo packets
are a local matter - and this document is simply defining "the local matter".

3. The normative Security Considerations were not strong enough.  Discussion
with the authors and Greg eventually has converged with RFC 5082 GTSM procedures
being required.  This may mean existing implementations of these procedures are
non-conformant.  However, this does not impact interoperability since the entire
point of this feature is a "BFD implementation talking to itself".

4. A further point of discussion is the intended destination and source
addresses used by this mechanism.  RFC 5881, in particular, provides guidance
for the source address selection such that it is not on the same subnet as the
destination address in order to prevent unnecessary ICMP/ND redirect messages.
However, existing implementations (e.g. Broadcom) use exactly behavior with
source and destination addresses being identical.  RFC 5881 makes this behavior
a SHOULD NOT, so using the same considerations for this mechanism avoids making
existing implementations non-conformant.

5. In the discussion over the document's intended status, Greg has noted that the Broadband Forum,
in its liaison For Information TR-146 and draft-ietf-bfd-unaffiliated-echo
(https://datatracker.ietf.org/liaison/1775/) informed the IETF and BFD WG that:

  "In our [Broadband Forum's] opinion, no future standardization
    is required to support TR-146."

Greg also expressed an opinion that the document should be Experimental rather
than Proposed Standard.  As noted in the IETF webpage, "Choosing between
Informational and Experimental Status", it is Shepherd's opinion is that
Experimental is inappropriate.  "The "Experimental" designation typically
denotes a specification that is part of some research or development effort".
In this case, implementations are commercially available utilizing mechanisms
largely similar to those being codified in this Internet-Draft. 

While the procedures in this draft are purely local (the implementation "talks to itself"),
the behavior requires a violation of RFC 5880 with regard to Echo procedures only
being available after the Up state has been achieved in Asynchronous mode. 
It is thus the Chairs' opinion that the text permitting the relaxation of that
requirement is appropriate to standardize for this document, and thus an appropriate
change of status requiring an update to RFC 5880.

: 3.  Has anyone threatened an appeal or otherwise indicated extreme discontent? If
:    so, please summarize the areas of conflict in separate email messages to the
:    responsible Area Director. (It should be in a separate email because this
:    questionnaire is publicly available.)

No.

: 4.  For protocol documents, are there existing implementations of the contents of
:    the document? Have a significant number of potential implementers indicated
:    plans to implement? Are any existing implementations reported somewhere,
:    either in the document itself (as RFC 7942 recommends) or elsewhere
:    (where)?

There are multiple implementations that claim some deployment of BBF TR-146
implementation behavior.


: Additional Reviews
:
: 5.  Do the contents of this document closely interact with technologies in other
:    IETF working groups or external organizations, and would it therefore benefit
:    from their review? Have those reviews occurred? If yes, describe which
:    reviews took place.

No additional reviews have been requested. 

: 6.  Describe how the document meets any required formal expert review criteria,
:    such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

This mechanism currently does not have a YANG module. It may benefit from one
at some point in the future that extends the existing RFC 9314 YANG module for
BFD.

: 7.  If the document contains a YANG module, has the final version of the module
:    been checked with any of the recommended validation tools for syntax and
:    formatting validation? If there are any resulting errors or warnings, what is
:    the justification for not fixing them at this time? Does the YANG module
:    comply with the Network Management Datastore Architecture (NMDA) as specified
:    in RFC 8342?

N/A

: 8.  Describe reviews and automated checks performed to validate sections of the
:    final version of the document written in a formal language, such as XML code,
:    BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

: Document Shepherd Checks
:
: 9.  Based on the shepherd's review of the document, is it their opinion that this
:    document is needed, clearly written, complete, correctly designed, and ready
:    to be handed off to the responsible Area Director?

Yes.

: 10. Several IETF Areas have assembled lists of common issues that their
:    reviewers encounter. For which areas have such issues been identified
:    and addressed? For which does this still need to happen in subsequent
:    reviews?

N/A

: 11. What type of RFC publication is being requested on the IETF stream (Best
:    Current Practice, Proposed Standard, Internet Standard,
:    Informational, Experimental or Historic)? Why is this the proper type
:    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard.  This mechanism leverages existing BFD procedures in a new
profile (BFD Async over the Echo port) and is appropriate for the standards
track.  The Echo port procedures from the core RFC 5880 intentionally leave
the contents of the Echo packets out of scope from that document, and thus
not a normative change in this document.  However, the ability to use BFD
state machinery without the associated Async session is a normative change
of behavior, even if solely a local one.

: 12. Have reasonable efforts been made to remind all authors of the intellectual
:    property rights (IPR) disclosure obligations described in BCP 79? To
:    the best of your knowledge, have all required disclosures been filed? If
:    not, explain why. If yes, summarize any relevant discussion, including links
:    to publicly-available messages when applicable.

IPR attestations:
Weiqiang Cheng:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/ZWMtOxUKZZbECUmmtLU9ZtZeGEk/

Ruixue Wang:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/K9D3KG7MqAm1yk0WaAIOoh5B_Z8/

Xiao Min:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/VQRGASf2GGiv6-J4vp515aY0HYs/

Reshad Rahman:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/9dEQm-IZy_48pjtkKKTu7yWOXYI/

Raj Chetan Boddireddy:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/esD26TKSjvRFJSm0qbcAJ-7EKvo/

It is also necessary to point out that this mechanism is an IETF instantiation
of similar procedures from BBF TR-146.  See liaison statement referenced above.

: 13. Has each author, editor, and contributor shown their willingness to be
:    listed as such? If the total number of authors and editors on the front page
:    is greater than five, please provide a justification.

Yes.  There are exactly five authors.

: 14. Document any remaining I-D nits in this document. Simply running the idnits
:    tool is not enough; please review the "Content Guidelines" on
:    authors.ietf.org. (Also note that the current idnits tool generates
:    some incorrect warnings; a rewrite is underway.)

There are no nits noted in version -10.

: 15. Should any informative references be normative or vice-versa? See the IESG
:    Statement on Normative and Informative References.

No.

: 16. List any normative references that are not freely available to anyone. Did
:    the community have sufficient access to review any such normative
:    references?

All references, including the Informative BBF TR-146 reference, are publicly
available.

: 17. Are there any normative downward references (see RFC 3967 and BCP
:    97) that are not already listed in the DOWNREF registry? If so,
:    list them.

No.

: 18. Are there normative references to documents that are not ready to be
:    submitted to the IESG for publication or are otherwise in an unclear state?
:    If so, what is the plan for their completion?

No such references.

: 19. Will publication of this document change the status of any existing RFCs? If
:    so, does the Datatracker metadata correctly reflect this and are those RFCs
:    listed on the title page, in the abstract, and discussed in the
:    introduction? If not, explain why and point to the part of the document
:    where the relationship of this document to these other RFCs is discussed.

This document does not change the status of other existing RFCs.

: 20. Describe the document shepherd's review of the IANA considerations section,
:    especially with regard to its consistency with the body of the document.
:    Confirm that all aspects of the document requiring IANA assignments are
:    associated with the appropriate reservations in IANA registries. Confirm
:    that any referenced IANA registries have been clearly identified. Confirm
:    that each newly created IANA registry specifies its initial contents,
:    allocations procedures, and a reasonable name (see RFC 8126).

This document makes no further requests from IANA.

: 21. List any new IANA registries that require Designated Expert Review for
:    future allocations. Are the instructions to the Designated Expert clear?
:    Please include suggestions of designated experts, if appropriate.

N/A

2024-01-15
10 Jeffrey Haas
Prelude:
The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap
with a similar feature specified in BBF TR-146.  A liaison statement was
exchanged with BBF with …
Prelude:
The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap
with a similar feature specified in BBF TR-146.  A liaison statement was
exchanged with BBF with regard to this work:

https://mailarchive.ietf.org/arch/msg/rtg-bfd/vw31qO1UpD7epoZKXT8_obmY64A/

This internet-draft is largely intended to cover a full IETF specification for
the functionality covered by TR-146 and address the minor issues where TR-146
is incompletely specified.

: Document History
:
: 1.  Does the working group (WG) consensus represent the strong concurrence of a
:    few individuals, with others being silent, or did it reach broad agreement?

The document has weak but positive Working Group consensus to advance.  This is
somewhat typical of documents progressing through BFD at this point.  That said,
the document has had a degree of strong review from the interested parties.

: 2.  Was there controversy about particular points, or were there decisions where
:    the consensus was particularly rough?

There were several concerns from Greg Mirsky largely regarding the following
points:

1. The mechanism specified in the document bypassed the pre-existing BFD Async
mechanism which permitted the Echo functionality to be enabled.  However, this
is exactly the point of this feature.  Much of the updates to RFC 5880 are
present to permit ths mode.  It's important to note that this mechanism is not
intended to completely replace the Echo mode for RFC 5880 when used in
conjunction with the traditional Async mode.

2. The mechanism specified in the document specified a format for the BFD Echo
packets.  This would appear to contravene RFC 5880, Section 5.  However, the
core behavior in the RFC simply states that the contents of the Echo packets
are a local matter - and this document is simply defining "the local matter".

3. The normative Security Considerations were not strong enough.  Discussion
with the authors and Greg eventually has converged with RFC 5082 GTSM procedures
being required.  This may mean existing implementations of these procedures are
non-conformant.  However, this does not impact interoperability since the entire
point of this feature is a "BFD implementation talking to itself".

4. A further point of discussion is the intended destination and source
addresses used by this mechanism.  RFC 5881, in particular, provides guidance
for the source address selection such that it is not on the same subnet as the
destination address in order to prevent unnecessary ICMP/ND redirect messages.
However, existing implementations (e.g. Broadcom) use exactly behavior with
source and destination addresses being identical.  RFC 5881 makes this behavior
a SHOULD NOT, so using the same considerations for this mechanism avoids making
existing implementations non-conformant.

5. In discussion over the document's intended status, Greg has expressed an opinion
that the document should be Experimental rather than Proposed Standard.  As noted
in the IETF webpage, "Choosing between Informational and Experimental Status", it is
the Shepherd's opinion that Experimental is inappropriate.  "The "Experimental"
designation typically denotes a specification that is part of some research or
development effort".  In this case, implementations are commercially available
utilizing mechanisms largely similar to those being codified in this Internet-Draft. 

While the procedures in this draft are purely local (the implementation "talks to itself"),
the behavior requires a violation of RFC 5880 with regard to Echo procedures only
being available after the Up state has been achieved in Asynchronous mode. 
It is thus the Chairs' opinion that the text permitting the relaxation of that
requirement is appropriate to standardize for this document, and thus an appropriate
change of status requiring an update to RFC 5880.

: 3.  Has anyone threatened an appeal or otherwise indicated extreme discontent? If
:    so, please summarize the areas of conflict in separate email messages to the
:    responsible Area Director. (It should be in a separate email because this
:    questionnaire is publicly available.)

No.

: 4.  For protocol documents, are there existing implementations of the contents of
:    the document? Have a significant number of potential implementers indicated
:    plans to implement? Are any existing implementations reported somewhere,
:    either in the document itself (as RFC 7942 recommends) or elsewhere
:    (where)?

There are multiple implementations that claim some deployment of BBF TR-146
implementation behavior.


: Additional Reviews
:
: 5.  Do the contents of this document closely interact with technologies in other
:    IETF working groups or external organizations, and would it therefore benefit
:    from their review? Have those reviews occurred? If yes, describe which
:    reviews took place.

No additional reviews have been requested. 

: 6.  Describe how the document meets any required formal expert review criteria,
:    such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

This mechanism currently does not have a YANG module. It may benefit from one
at some point in the future that extends the existing RFC 9314 YANG module for
BFD.

: 7.  If the document contains a YANG module, has the final version of the module
:    been checked with any of the recommended validation tools for syntax and
:    formatting validation? If there are any resulting errors or warnings, what is
:    the justification for not fixing them at this time? Does the YANG module
:    comply with the Network Management Datastore Architecture (NMDA) as specified
:    in RFC 8342?

N/A

: 8.  Describe reviews and automated checks performed to validate sections of the
:    final version of the document written in a formal language, such as XML code,
:    BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

: Document Shepherd Checks
:
: 9.  Based on the shepherd's review of the document, is it their opinion that this
:    document is needed, clearly written, complete, correctly designed, and ready
:    to be handed off to the responsible Area Director?

Yes.

: 10. Several IETF Areas have assembled lists of common issues that their
:    reviewers encounter. For which areas have such issues been identified
:    and addressed? For which does this still need to happen in subsequent
:    reviews?

N/A

: 11. What type of RFC publication is being requested on the IETF stream (Best
:    Current Practice, Proposed Standard, Internet Standard,
:    Informational, Experimental or Historic)? Why is this the proper type
:    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard.  This mechanism leverages existing BFD procedures in a new
profile (BFD Async over the Echo port) and is appropriate for the standards
track.  The Echo port procedures from the core RFC 5880 intentionally leave
the contents of the Echo packets out of scope from that document, and thus
not a normative change in this document.  However, the ability to use BFD
state machinery without the associated Async session is a normative change
of behavior, even if solely a local one.

: 12. Have reasonable efforts been made to remind all authors of the intellectual
:    property rights (IPR) disclosure obligations described in BCP 79? To
:    the best of your knowledge, have all required disclosures been filed? If
:    not, explain why. If yes, summarize any relevant discussion, including links
:    to publicly-available messages when applicable.

IPR attestations:
Weiqiang Cheng:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/ZWMtOxUKZZbECUmmtLU9ZtZeGEk/

Ruixue Wang:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/K9D3KG7MqAm1yk0WaAIOoh5B_Z8/

Xiao Min:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/VQRGASf2GGiv6-J4vp515aY0HYs/

Reshad Rahman:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/9dEQm-IZy_48pjtkKKTu7yWOXYI/

Raj Chetan Boddireddy:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/esD26TKSjvRFJSm0qbcAJ-7EKvo/

It is also necessary to point out that this mechanism is an IETF instantiation
of similar procedures from BBF TR-146.  See liaison statement referenced above.

: 13. Has each author, editor, and contributor shown their willingness to be
:    listed as such? If the total number of authors and editors on the front page
:    is greater than five, please provide a justification.

Yes.  There are exactly five authors.

: 14. Document any remaining I-D nits in this document. Simply running the idnits
:    tool is not enough; please review the "Content Guidelines" on
:    authors.ietf.org. (Also note that the current idnits tool generates
:    some incorrect warnings; a rewrite is underway.)

There are no nits noted in version -10.

: 15. Should any informative references be normative or vice-versa? See the IESG
:    Statement on Normative and Informative References.

No.

: 16. List any normative references that are not freely available to anyone. Did
:    the community have sufficient access to review any such normative
:    references?

All references, including the Informative BBF TR-146 reference, are publicly
available.

: 17. Are there any normative downward references (see RFC 3967 and BCP
:    97) that are not already listed in the DOWNREF registry? If so,
:    list them.

No.

: 18. Are there normative references to documents that are not ready to be
:    submitted to the IESG for publication or are otherwise in an unclear state?
:    If so, what is the plan for their completion?

No such references.

: 19. Will publication of this document change the status of any existing RFCs? If
:    so, does the Datatracker metadata correctly reflect this and are those RFCs
:    listed on the title page, in the abstract, and discussed in the
:    introduction? If not, explain why and point to the part of the document
:    where the relationship of this document to these other RFCs is discussed.

This document does not change the status of other existing RFCs.

: 20. Describe the document shepherd's review of the IANA considerations section,
:    especially with regard to its consistency with the body of the document.
:    Confirm that all aspects of the document requiring IANA assignments are
:    associated with the appropriate reservations in IANA registries. Confirm
:    that any referenced IANA registries have been clearly identified. Confirm
:    that each newly created IANA registry specifies its initial contents,
:    allocations procedures, and a reasonable name (see RFC 8126).

This document makes no further requests from IANA.

: 21. List any new IANA registries that require Designated Expert Review for
:    future allocations. Are the instructions to the Designated Expert clear?
:    Please include suggestions of designated experts, if appropriate.

N/A

2024-01-15
10 Jeffrey Haas
Prelude:
The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap
with a similar feature specified in BBF TR-146.  A liaison statement was
exchanged with BBF with …
Prelude:
The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap
with a similar feature specified in BBF TR-146.  A liaison statement was
exchanged with BBF with regard to this work:

https://mailarchive.ietf.org/arch/msg/rtg-bfd/vw31qO1UpD7epoZKXT8_obmY64A/

This internet-draft is largely intended to cover a full IETF specification for
the functionality covered by TR-146 and address the minor issues where TR-146
is incompletely specified.

: Document History
:
: 1.  Does the working group (WG) consensus represent the strong concurrence of a
:    few individuals, with others being silent, or did it reach broad agreement?

The document has weak but positive Working Group consensus to advance.  This is
somewhat typical of documents progressing through BFD at this point.  That said,
the document has had a degree of strong review from the interested parties.

: 2.  Was there controversy about particular points, or were there decisions where
:    the consensus was particularly rough?

There were several concerns from Greg Mirsky largely regarding the following
points:

1. The mechanism specified in the document bypassed the pre-existing BFD Async
mechanism which permitted the Echo functionality to be enabled.  However, this
is exactly the point of this feature.  Much of the updates to RFC 5880 are
present to permit ths mode.  It's important to note that this mechanism is not
intended to completely replace the Echo mode for RFC 5880 when used in
conjunction with the traditional Async mode.

2. The mechanism specified in the document specified a format for the BFD Echo
packets.  This would appear to contravene RFC 5880, Section 5.  However, the
core behavior in the RFC simply states that the contents of the Echo packets
are a local matter - and this document is simply defining "the local matter".

3. The normative Security Considerations were not strong enough.  Discussion
with the authors and Greg eventually has converged with RFC 5082 GTSM procedures
being required.  This may mean existing implementations of these procedures are
non-conformant.  However, this does not impact interoperability since the entire
point of this feature is a "BFD implementation talking to itself".

4. A further point of discussion is the intended destination and source
addresses used by this mechanism.  RFC 5881, in particular, provides guidance
for the source address selection such that it is not on the same subnet as the
destination address in order to prevent unnecessary ICMP/ND redirect messages.
However, existing implementations (e.g. Broadcom) use exactly behavior with
source and destination addresses being identical.  RFC 5881 makes this behavior
a SHOULD NOT, so using the same considerations for this mechanism avoids making
existing implementations non-conformant.

: 3.  Has anyone threatened an appeal or otherwise indicated extreme discontent? If
:    so, please summarize the areas of conflict in separate email messages to the
:    responsible Area Director. (It should be in a separate email because this
:    questionnaire is publicly available.)

No.

: 4.  For protocol documents, are there existing implementations of the contents of
:    the document? Have a significant number of potential implementers indicated
:    plans to implement? Are any existing implementations reported somewhere,
:    either in the document itself (as RFC 7942 recommends) or elsewhere
:    (where)?

There are multiple implementations that claim some deployment of BBF TR-146
implementation behavior.


: Additional Reviews
:
: 5.  Do the contents of this document closely interact with technologies in other
:    IETF working groups or external organizations, and would it therefore benefit
:    from their review? Have those reviews occurred? If yes, describe which
:    reviews took place.

No additional reviews have been requested. 

: 6.  Describe how the document meets any required formal expert review criteria,
:    such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

This mechanism currently does not have a YANG module. It may benefit from one
at some point in the future that extends the existing RFC 9314 YANG module for
BFD.

: 7.  If the document contains a YANG module, has the final version of the module
:    been checked with any of the recommended validation tools for syntax and
:    formatting validation? If there are any resulting errors or warnings, what is
:    the justification for not fixing them at this time? Does the YANG module
:    comply with the Network Management Datastore Architecture (NMDA) as specified
:    in RFC 8342?

N/A

: 8.  Describe reviews and automated checks performed to validate sections of the
:    final version of the document written in a formal language, such as XML code,
:    BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

: Document Shepherd Checks
:
: 9.  Based on the shepherd's review of the document, is it their opinion that this
:    document is needed, clearly written, complete, correctly designed, and ready
:    to be handed off to the responsible Area Director?

Yes.

: 10. Several IETF Areas have assembled lists of common issues that their
:    reviewers encounter. For which areas have such issues been identified
:    and addressed? For which does this still need to happen in subsequent
:    reviews?

N/A

: 11. What type of RFC publication is being requested on the IETF stream (Best
:    Current Practice, Proposed Standard, Internet Standard,
:    Informational, Experimental or Historic)? Why is this the proper type
:    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard.  This mechanism leverages existing BFD procedures in a new
profile (BFD Async over the Echo port) and is appropriate for the standards
track.  The Echo port procedures from the core RFC 5880 intentionally leave
the contents of the Echo packets out of scope from that document, and thus
not a normative change in this document.  However, the ability to use BFD
state machinery without the associated Async session is a normative change
of behavior, even if solely a local one.

: 12. Have reasonable efforts been made to remind all authors of the intellectual
:    property rights (IPR) disclosure obligations described in BCP 79? To
:    the best of your knowledge, have all required disclosures been filed? If
:    not, explain why. If yes, summarize any relevant discussion, including links
:    to publicly-available messages when applicable.

IPR attestations:
Weiqiang Cheng:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/ZWMtOxUKZZbECUmmtLU9ZtZeGEk/

Ruixue Wang:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/K9D3KG7MqAm1yk0WaAIOoh5B_Z8/

Xiao Min:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/VQRGASf2GGiv6-J4vp515aY0HYs/

Reshad Rahman:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/9dEQm-IZy_48pjtkKKTu7yWOXYI/

Raj Chetan Boddireddy:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/esD26TKSjvRFJSm0qbcAJ-7EKvo/

It is also necessary to point out that this mechanism is an IETF instantiation
of similar procedures from BBF TR-146.  See liaison statement referenced above.

: 13. Has each author, editor, and contributor shown their willingness to be
:    listed as such? If the total number of authors and editors on the front page
:    is greater than five, please provide a justification.

Yes.  There are exactly five authors.

: 14. Document any remaining I-D nits in this document. Simply running the idnits
:    tool is not enough; please review the "Content Guidelines" on
:    authors.ietf.org. (Also note that the current idnits tool generates
:    some incorrect warnings; a rewrite is underway.)

There are no nits noted in version -10.

: 15. Should any informative references be normative or vice-versa? See the IESG
:    Statement on Normative and Informative References.

No.

: 16. List any normative references that are not freely available to anyone. Did
:    the community have sufficient access to review any such normative
:    references?

All references, including the Informative BBF TR-146 reference, are publicly
available.

: 17. Are there any normative downward references (see RFC 3967 and BCP
:    97) that are not already listed in the DOWNREF registry? If so,
:    list them.

No.

: 18. Are there normative references to documents that are not ready to be
:    submitted to the IESG for publication or are otherwise in an unclear state?
:    If so, what is the plan for their completion?

No such references.

: 19. Will publication of this document change the status of any existing RFCs? If
:    so, does the Datatracker metadata correctly reflect this and are those RFCs
:    listed on the title page, in the abstract, and discussed in the
:    introduction? If not, explain why and point to the part of the document
:    where the relationship of this document to these other RFCs is discussed.

This document does not change the status of other existing RFCs.

: 20. Describe the document shepherd's review of the IANA considerations section,
:    especially with regard to its consistency with the body of the document.
:    Confirm that all aspects of the document requiring IANA assignments are
:    associated with the appropriate reservations in IANA registries. Confirm
:    that any referenced IANA registries have been clearly identified. Confirm
:    that each newly created IANA registry specifies its initial contents,
:    allocations procedures, and a reasonable name (see RFC 8126).

This document makes no further requests from IANA.

: 21. List any new IANA registries that require Designated Expert Review for
:    future allocations. Are the instructions to the Designated Expert clear?
:    Please include suggestions of designated experts, if appropriate.

N/A

2024-01-15
10 Jeffrey Haas IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2024-01-15
10 Jeffrey Haas IESG state changed to Publication Requested from I-D Exists
2024-01-15
10 (System) Changed action holders to John Scudder (IESG state changed)
2024-01-15
10 Jeffrey Haas Responsible AD changed to John Scudder
2024-01-15
10 Jeffrey Haas Document is now in IESG state Publication Requested
2024-01-15
10 Jeffrey Haas Tags Doc Shepherd Follow-up Underway, Revised I-D Needed - Issue raised by WGLC cleared.
2024-01-15
10 Jeffrey Haas Changed consensus to Yes from Unknown
2024-01-15
10 Jeffrey Haas Intended Status changed to Proposed Standard from None
2024-01-15
10 Jeffrey Haas
Prelude:
The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap
with a similar feature specified in BBF TR-146.  A liaison statement was
exchanged with BBF with …
Prelude:
The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap
with a similar feature specified in BBF TR-146.  A liaison statement was
exchanged with BBF with regard to this work:

https://mailarchive.ietf.org/arch/msg/rtg-bfd/vw31qO1UpD7epoZKXT8_obmY64A/

This internet-draft is largely intended to cover a full IETF specification for
the functionality covered by TR-146 and address the minor issues where TR-146
is incompletely specified.

: Document History
:
: 1.  Does the working group (WG) consensus represent the strong concurrence of a
:    few individuals, with others being silent, or did it reach broad agreement?

The document has weak but positive Working Group consensus to advance.  This is
somewhat typical of documents progressing through BFD at this point.  That said,
the document has had a degree of strong review from the interested parties.

: 2.  Was there controversy about particular points, or were there decisions where
:    the consensus was particularly rough?

There were several concerns from Greg Mirsky largely regarding the following
points:

1. The mechanism specified in the document bypassed the pre-existing BFD Async
mechanism which permitted the Echo functionality to be enabled.  However, this
is exactly the point of this feature.  Much of the updates to RFC 5880 are
present to permit ths mode.  It's important to note that this mechanism is not
intended to completely replace the Echo mode for RFC 5880 when used in
conjunction with the traditional Async mode.

2. The mechanism specified in the document specified a format for the BFD Echo
packets.  This would appear to contravene RFC 5880, Section 5.  However, the
core behavior in the RFC simply states that the contents of the Echo packets
are a local matter - and this document is simply defining "the local matter".

3. The normative Security Considerations were not strong enough.  Discussion
with the authors and Greg eventually has converged with RFC 5082 GTSM procedures
being required.  This may mean existing implementations of these procedures are
non-conformant.  However, this does not impact interoperability since the entire
point of this feature is a "BFD implementation talking to itself".

4. A further point of discussion is the intended destination and source
addresses used by this mechanism.  RFC 5881, in particular, provides guidance
for the source address selection such that it is not on the same subnet as the
destination address in order to prevent unnecessary ICMP/ND redirect messages.
However, existing implementations (e.g. Broadcom) use exactly behavior with
source and destination addresses being identical.  RFC 5881 makes this behavior
a SHOULD NOT, so using the same considerations for this mechanism avoids making
existing implementations non-conformant.

: 3.  Has anyone threatened an appeal or otherwise indicated extreme discontent? If
:    so, please summarize the areas of conflict in separate email messages to the
:    responsible Area Director. (It should be in a separate email because this
:    questionnaire is publicly available.)

No.

: 4.  For protocol documents, are there existing implementations of the contents of
:    the document? Have a significant number of potential implementers indicated
:    plans to implement? Are any existing implementations reported somewhere,
:    either in the document itself (as RFC 7942 recommends) or elsewhere
:    (where)?

There are multiple implementations that claim some deployment of BBF TR-146
implementation behavior.


: Additional Reviews
:
: 5.  Do the contents of this document closely interact with technologies in other
:    IETF working groups or external organizations, and would it therefore benefit
:    from their review? Have those reviews occurred? If yes, describe which
:    reviews took place.

No additional reviews have been requested. 

: 6.  Describe how the document meets any required formal expert review criteria,
:    such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

This mechanism currently does not have a YANG module. It may benefit from one
at some point in the future that extends the existing RFC 9314 YANG module for
BFD.

: 7.  If the document contains a YANG module, has the final version of the module
:    been checked with any of the recommended validation tools for syntax and
:    formatting validation? If there are any resulting errors or warnings, what is
:    the justification for not fixing them at this time? Does the YANG module
:    comply with the Network Management Datastore Architecture (NMDA) as specified
:    in RFC 8342?

N/A

: 8.  Describe reviews and automated checks performed to validate sections of the
:    final version of the document written in a formal language, such as XML code,
:    BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

: Document Shepherd Checks
:
: 9.  Based on the shepherd's review of the document, is it their opinion that this
:    document is needed, clearly written, complete, correctly designed, and ready
:    to be handed off to the responsible Area Director?

Yes.

: 10. Several IETF Areas have assembled lists of common issues that their
:    reviewers encounter. For which areas have such issues been identified
:    and addressed? For which does this still need to happen in subsequent
:    reviews?

N/A

: 11. What type of RFC publication is being requested on the IETF stream (Best
:    Current Practice, Proposed Standard, Internet Standard,
:    Informational, Experimental or Historic)? Why is this the proper type
:    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard.  This mechanism leverages existing BFD procedures in a new
profile (BFD Async over the Echo port) and is appropriate for the standards
track.  The Echo port procedures from the core RFC 5880 intentionally leave
the contents of the Echo packets out of scope from that document, and thus
not a normative change in this document.  However, the ability to use BFD
state machinery without the associated Async session is a normative change
of behavior, even if solely a local one.

: 12. Have reasonable efforts been made to remind all authors of the intellectual
:    property rights (IPR) disclosure obligations described in BCP 79? To
:    the best of your knowledge, have all required disclosures been filed? If
:    not, explain why. If yes, summarize any relevant discussion, including links
:    to publicly-available messages when applicable.

IPR attestations:
Weiqiang Cheng:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/ZWMtOxUKZZbECUmmtLU9ZtZeGEk/

Ruixue Wang:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/K9D3KG7MqAm1yk0WaAIOoh5B_Z8/

Xiao Min:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/VQRGASf2GGiv6-J4vp515aY0HYs/

Reshad Rahman:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/9dEQm-IZy_48pjtkKKTu7yWOXYI/

Raj Chetan Boddireddy:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/esD26TKSjvRFJSm0qbcAJ-7EKvo/

It is also necessary to point out that this mechanism is an IETF instantiation
of similar procedures from BBF TR-146.  See liaison statement referenced above.

: 13. Has each author, editor, and contributor shown their willingness to be
:    listed as such? If the total number of authors and editors on the front page
:    is greater than five, please provide a justification.

Yes.  There are exactly five authors.

: 14. Document any remaining I-D nits in this document. Simply running the idnits
:    tool is not enough; please review the "Content Guidelines" on
:    authors.ietf.org. (Also note that the current idnits tool generates
:    some incorrect warnings; a rewrite is underway.)

There are no nits noted in version -10.

: 15. Should any informative references be normative or vice-versa? See the IESG
:    Statement on Normative and Informative References.

No.

: 16. List any normative references that are not freely available to anyone. Did
:    the community have sufficient access to review any such normative
:    references?

All references, including the Informative BBF TR-146 reference, are publicly
available.

: 17. Are there any normative downward references (see RFC 3967 and BCP
:    97) that are not already listed in the DOWNREF registry? If so,
:    list them.

No.

: 18. Are there normative references to documents that are not ready to be
:    submitted to the IESG for publication or are otherwise in an unclear state?
:    If so, what is the plan for their completion?

No such references.

: 19. Will publication of this document change the status of any existing RFCs? If
:    so, does the Datatracker metadata correctly reflect this and are those RFCs
:    listed on the title page, in the abstract, and discussed in the
:    introduction? If not, explain why and point to the part of the document
:    where the relationship of this document to these other RFCs is discussed.

This document does not change the status of other existing RFCs.

: 20. Describe the document shepherd's review of the IANA considerations section,
:    especially with regard to its consistency with the body of the document.
:    Confirm that all aspects of the document requiring IANA assignments are
:    associated with the appropriate reservations in IANA registries. Confirm
:    that any referenced IANA registries have been clearly identified. Confirm
:    that each newly created IANA registry specifies its initial contents,
:    allocations procedures, and a reasonable name (see RFC 8126).

This document makes no further requests from IANA.

: 21. List any new IANA registries that require Designated Expert Review for
:    future allocations. Are the instructions to the Designated Expert clear?
:    Please include suggestions of designated experts, if appropriate.

N/A

2023-09-28
10 Xiao Min New version available: draft-ietf-bfd-unaffiliated-echo-10.txt
2023-09-28
10 Xiao Min New version accepted (logged-in submitter: Xiao Min)
2023-09-28
10 Xiao Min Uploaded new revision
2023-09-26
09 Xiao Min New version available: draft-ietf-bfd-unaffiliated-echo-09.txt
2023-09-26
09 Xiao Min New version accepted (logged-in submitter: Xiao Min)
2023-09-26
09 Xiao Min Uploaded new revision
2023-07-05
08 Xiao Min New version available: draft-ietf-bfd-unaffiliated-echo-08.txt
2023-07-05
08 Xiao Min New version accepted (logged-in submitter: Xiao Min)
2023-07-05
08 Xiao Min Uploaded new revision
2023-04-24
07 Jeffrey Haas
Prelude:
The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap
with a similar feature specified in BBF TR-146.  A liaison statement was
exchanged with BBF with …
Prelude:
The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap
with a similar feature specified in BBF TR-146.  A liaison statement was
exchanged with BBF with regard to this work:

https://mailarchive.ietf.org/arch/msg/rtg-bfd/vw31qO1UpD7epoZKXT8_obmY64A/

This internet-draft is largely intended to cover a full IETF specification for
the functionality covered by TR-146 and address the minor issues where TR-146
is incompletely specified.

: Document History
:
: 1.  Does the working group (WG) consensus represent the strong concurrence of a
:    few individuals, with others being silent, or did it reach broad agreement?

The document has weak but positive Working Group consensus to advance.  This is
somewhat typical of documents progressing through BFD at this point.

: 2.  Was there controversy about particular points, or were there decisions where
:    the consensus was particularly rough?

There were several concerns from Greg Mirsky largely regarding the following
points:

1. The mechanism specified in the document bypassed the pre-existing BFD Async
mechanism which permitted the Echo functionality to be enabled.  However, this
is exactly the point of this feature.  Much of the updates to RFC 5880 are
present to permit ths mode.  It's important to note that this mechanism is not
intended to completely replace the Echo mode for RFC 5880 when used in
conjunction with the traditional Async mode.

2. The mechanism specified in the document specified a format for the BFD Echo
packets.  This would appear to contravene RFC 5880, Section 5.  However, the
core behavior in the RFC simply states that the contents of the Echo packets
are a local matter - and this document is simply defining "the local matter".

3. The normative Security Considerations are not strong enough, particularly in
the requirement that RFC 5082 GTSM procedures MUST be utilized by the host
providing the loopback services.  While a great idea in general, this document
largely exists to provide an IETF definition of a feature already described in
BBF TR-146.  Such default limitation of the loopback may not be widely deployed
and thus the more restrictive MUST requirements for GTSM would make existing
deployments non-conformant.

4. A further point of discussion is the intended destination and source
addresses used by this mechanism.  RFC 5881, in particular, provides guidance
for the source address selection such that it is not on the same subnet as the
destination address in order to prevent unnecessary ICMP/ND redirect messages.
However, existing implementations (e.g. Broadcom) use exactly behavior with
source and destination addresses being identical.  RFC 5881 makes this behavior
a SHOULD NOT, so using the same considerations for this mechanism avoids making
existing implementations non-conformant.

: 3.  Has anyone threatened an appeal or otherwise indicated extreme discontent? If
:    so, please summarize the areas of conflict in separate email messages to the
:    responsible Area Director. (It should be in a separate email because this
:    questionnaire is publicly available.)

No.

: 4.  For protocol documents, are there existing implementations of the contents of
:    the document? Have a significant number of potential implementers indicated
:    plans to implement? Are any existing implementations reported somewhere,
:    either in the document itself (as RFC 7942 recommends) or elsewhere
:    (where)?

There are multiple implementations that claim some deployment of BBF TR-146
implementation behavior.


: Additional Reviews
:
: 5.  Do the contents of this document closely interact with technologies in other
:    IETF working groups or external organizations, and would it therefore benefit
:    from their review? Have those reviews occurred? If yes, describe which
:    reviews took place.

No additional reviews have been requested. 

: 6.  Describe how the document meets any required formal expert review criteria,
:    such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

This mechanism currently does not have a YANG module. It may benefit from one
at some point in the future that extends the existing RFC 9314 YANG module for
BFD.

: 7.  If the document contains a YANG module, has the final version of the module
:    been checked with any of the recommended validation tools for syntax and
:    formatting validation? If there are any resulting errors or warnings, what is
:    the justification for not fixing them at this time? Does the YANG module
:    comply with the Network Management Datastore Architecture (NMDA) as specified
:    in RFC 8342?

N/A

: 8.  Describe reviews and automated checks performed to validate sections of the
:    final version of the document written in a formal language, such as XML code,
:    BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

: Document Shepherd Checks
:
: 9.  Based on the shepherd's review of the document, is it their opinion that this
:    document is needed, clearly written, complete, correctly designed, and ready
:    to be handed off to the responsible Area Director?

Yes.

: 10. Several IETF Areas have assembled lists of common issues that their
:    reviewers encounter. For which areas have such issues been identified
:    and addressed? For which does this still need to happen in subsequent
:    reviews?

N/A

: 11. What type of RFC publication is being requested on the IETF stream (Best
:    Current Practice, Proposed Standard, Internet Standard,
:    Informational, Experimental or Historic)? Why is this the proper type
:    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard.  This mechanism leverages existing BFD procedures in a new
profile (BFD Async over the Echo port) and is appropriate for the standards
track.  The Echo port procedures from the core RFC 5880 intentionally leave
the contents of the Echo packets out of scope from that document, and thus
not a normative change in this document.  However, the ability to use BFD
state machinery without the associated Async session is a normative change
of behavior, even if solely a local one.

: 12. Have reasonable efforts been made to remind all authors of the intellectual
:    property rights (IPR) disclosure obligations described in BCP 79? To
:    the best of your knowledge, have all required disclosures been filed? If
:    not, explain why. If yes, summarize any relevant discussion, including links
:    to publicly-available messages when applicable.

IPR attestations from the authors are currently pending.  (10 April, 2023)  The
document will be progressed to the IESG once the attestations are all accounted
for.

IPR attestations:
Weiqiang Cheng:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/ZWMtOxUKZZbECUmmtLU9ZtZeGEk/

Ruixue Wang:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/K9D3KG7MqAm1yk0WaAIOoh5B_Z8/

Xiao Min:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/VQRGASf2GGiv6-J4vp515aY0HYs/

Reshad Rahman:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/9dEQm-IZy_48pjtkKKTu7yWOXYI/

Raj Chetan Boddireddy:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/esD26TKSjvRFJSm0qbcAJ-7EKvo/

It is also necessary to point out that this mechanism is an IETF instantiation
of similar procedures from BBF TR-146.  See liaison statement referenced above.

: 13. Has each author, editor, and contributor shown their willingness to be
:    listed as such? If the total number of authors and editors on the front page
:    is greater than five, please provide a justification.

Yes.  There are exactly five authors.

: 14. Document any remaining I-D nits in this document. Simply running the idnits
:    tool is not enough; please review the "Content Guidelines" on
:    authors.ietf.org. (Also note that the current idnits tool generates
:    some incorrect warnings; a rewrite is underway.)

There are no nits noted in version -07.

: 15. Should any informative references be normative or vice-versa? See the IESG
:    Statement on Normative and Informative References.

No.

: 16. List any normative references that are not freely available to anyone. Did
:    the community have sufficient access to review any such normative
:    references?

All references, including the Informative BBF TR-146 reference, are publicly
available.

: 17. Are there any normative downward references (see RFC 3967 and BCP
:    97) that are not already listed in the DOWNREF registry? If so,
:    list them.

No.

: 18. Are there normative references to documents that are not ready to be
:    submitted to the IESG for publication or are otherwise in an unclear state?
:    If so, what is the plan for their completion?

No such references.

: 19. Will publication of this document change the status of any existing RFCs? If
:    so, does the Datatracker metadata correctly reflect this and are those RFCs
:    listed on the title page, in the abstract, and discussed in the
:    introduction? If not, explain why and point to the part of the document
:    where the relationship of this document to these other RFCs is discussed.

This document does not change the status of other existing RFCs.

: 20. Describe the document shepherd's review of the IANA considerations section,
:    especially with regard to its consistency with the body of the document.
:    Confirm that all aspects of the document requiring IANA assignments are
:    associated with the appropriate reservations in IANA registries. Confirm
:    that any referenced IANA registries have been clearly identified. Confirm
:    that each newly created IANA registry specifies its initial contents,
:    allocations procedures, and a reasonable name (see RFC 8126).

This document makes no further requests from IANA.

: 21. List any new IANA registries that require Designated Expert Review for
:    future allocations. Are the instructions to the Designated Expert clear?
:    Please include suggestions of designated experts, if appropriate.

N/A

2023-04-23
07 Xiao Min New version available: draft-ietf-bfd-unaffiliated-echo-07.txt
2023-04-23
07 Xiao Min New version accepted (logged-in submitter: Xiao Min)
2023-04-23
07 Xiao Min Uploaded new revision
2023-04-11
06 Jeffrey Haas
Prelude:
The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap
with a similar feature specified in BBF TR-146.  A liaison statement was
exchanged with BBF with …
Prelude:
The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap
with a similar feature specified in BBF TR-146.  A liaison statement was
exchanged with BBF with regard to this work:

https://mailarchive.ietf.org/arch/msg/rtg-bfd/vw31qO1UpD7epoZKXT8_obmY64A/

This internet-draft is largely intended to cover a full IETF specification for
the functionality covered by TR-146 and address the minor issues where TR-146
is incompletely specified.

: Document History
:
: 1.  Does the working group (WG) consensus represent the strong concurrence of a
:    few individuals, with others being silent, or did it reach broad agreement?

The document has weak but positive Working Group consensus to advance.  This is
somewhat typical of documents progressing through BFD at this point.

: 2.  Was there controversy about particular points, or were there decisions where
:    the consensus was particularly rough?

There were several concerns from Greg Mirsky largely regarding the following
points:

1. The mechanism specified in the document bypassed the pre-existing BFD Async
mechanism which permitted the Echo functionality to be enabled.  However, this
is exactly the point of this feature.  Much of the updates to RFC 5880 are
present to permit ths mode.  It's important to note that this mechanism is not
intended to completely replace the Echo mode for RFC 5880 when used in
conjunction with the traditional Async mode.

2. The mechanism specified in the document specified a format for the BFD Echo
packets.  This would appear to contravene RFC 5880, Section 5.  However, the
core behavior in the RFC simply states that the contents of the Echo packets
are a local matter - and this document is simply defining "the local matter".

3. The normative Security Considerations are not strong enough, particularly in
the requirement that RFC 5082 GTSM procedures MUST be utilized by the host
providing the loopback services.  While a great idea in general, this document
largely exists to provide an IETF definition of a feature already described in
BBF TR-146.  Such default limitation of the loopback may not be widely deployed
and thus the more restrictive MUST requirements for GTSM would make existing
deployments non-conformant.

4. A further point of discussion is the intended destination and source
addresses used by this mechanism.  RFC 5881, in particular, provides guidance
for the source address selection such that it is not on the same subnet as the
destination address in order to prevent unnecessary ICMP/ND redirect messages.
However, existing implementations (e.g. Broadcom) use exactly behavior with
source and destination addresses being identical.  RFC 5881 makes this behavior
a SHOULD NOT, so using the same considerations for this mechanism avoids making
existing implementations non-conformant.

: 3.  Has anyone threatened an appeal or otherwise indicated extreme discontent? If
:    so, please summarize the areas of conflict in separate email messages to the
:    responsible Area Director. (It should be in a separate email because this
:    questionnaire is publicly available.)

No.

: 4.  For protocol documents, are there existing implementations of the contents of
:    the document? Have a significant number of potential implementers indicated
:    plans to implement? Are any existing implementations reported somewhere,
:    either in the document itself (as RFC 7942 recommends) or elsewhere
:    (where)?

There are multiple implementations that claim some deployment of BBF TR-146
implementation behavior.


: Additional Reviews
:
: 5.  Do the contents of this document closely interact with technologies in other
:    IETF working groups or external organizations, and would it therefore benefit
:    from their review? Have those reviews occurred? If yes, describe which
:    reviews took place.

No additional reviews have been requested. 

: 6.  Describe how the document meets any required formal expert review criteria,
:    such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

This mechanism currently does not have a YANG module. It may benefit from one
at some point in the future that extends the existing RFC 9314 YANG module for
BFD.

: 7.  If the document contains a YANG module, has the final version of the module
:    been checked with any of the recommended validation tools for syntax and
:    formatting validation? If there are any resulting errors or warnings, what is
:    the justification for not fixing them at this time? Does the YANG module
:    comply with the Network Management Datastore Architecture (NMDA) as specified
:    in RFC 8342?

N/A

: 8.  Describe reviews and automated checks performed to validate sections of the
:    final version of the document written in a formal language, such as XML code,
:    BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

: Document Shepherd Checks
:
: 9.  Based on the shepherd's review of the document, is it their opinion that this
:    document is needed, clearly written, complete, correctly designed, and ready
:    to be handed off to the responsible Area Director?

The document is integrating comments raised during Working Group Last Call and
should be ready for progression afterwards.

: 10. Several IETF Areas have assembled lists of common issues that their
:    reviewers encounter. For which areas have such issues been identified
:    and addressed? For which does this still need to happen in subsequent
:    reviews?

N/A

: 11. What type of RFC publication is being requested on the IETF stream (Best
:    Current Practice, Proposed Standard, Internet Standard,
:    Informational, Experimental or Historic)? Why is this the proper type
:    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard.  This mechanism leverages existing BFD procedures in a new
profile (BFD Async over the Echo port) and is appropriate for the standards
track.

: 12. Have reasonable efforts been made to remind all authors of the intellectual
:    property rights (IPR) disclosure obligations described in BCP 79? To
:    the best of your knowledge, have all required disclosures been filed? If
:    not, explain why. If yes, summarize any relevant discussion, including links
:    to publicly-available messages when applicable.

IPR attestations from the authors are currently pending.  (10 April, 2023)  The
document will be progressed to the IESG once the attestations are all accounted
for.

IPR attestations:
Weiqiang Cheng:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/ZWMtOxUKZZbECUmmtLU9ZtZeGEk/

Ruixue Wang:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/K9D3KG7MqAm1yk0WaAIOoh5B_Z8/

Xiao Min:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/VQRGASf2GGiv6-J4vp515aY0HYs/

Reshad Rahman:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/9dEQm-IZy_48pjtkKKTu7yWOXYI/

Raj Chetan Boddireddy:

It is also necessary to point out that this mechanism is an IETF instantiation
of similar procedures from BBF TR-146.  See liaison statement referenced above.

: 13. Has each author, editor, and contributor shown their willingness to be
:    listed as such? If the total number of authors and editors on the front page
:    is greater than five, please provide a justification.

Yes.  There are exactly five authors.

: 14. Document any remaining I-D nits in this document. Simply running the idnits
:    tool is not enough; please review the "Content Guidelines" on
:    authors.ietf.org. (Also note that the current idnits tool generates
:    some incorrect warnings; a rewrite is underway.)

There are no nits noted in version -06.

: 15. Should any informative references be normative or vice-versa? See the IESG
:    Statement on Normative and Informative References.

No.

: 16. List any normative references that are not freely available to anyone. Did
:    the community have sufficient access to review any such normative
:    references?

All references, including the Informative BBF TR-146 reference, are publicly
available.

: 17. Are there any normative downward references (see RFC 3967 and BCP
:    97) that are not already listed in the DOWNREF registry? If so,
:    list them.

No.

: 18. Are there normative references to documents that are not ready to be
:    submitted to the IESG for publication or are otherwise in an unclear state?
:    If so, what is the plan for their completion?

No such references.

: 19. Will publication of this document change the status of any existing RFCs? If
:    so, does the Datatracker metadata correctly reflect this and are those RFCs
:    listed on the title page, in the abstract, and discussed in the
:    introduction? If not, explain why and point to the part of the document
:    where the relationship of this document to these other RFCs is discussed.

This document does not change the status of other existing RFCs.

: 20. Describe the document shepherd's review of the IANA considerations section,
:    especially with regard to its consistency with the body of the document.
:    Confirm that all aspects of the document requiring IANA assignments are
:    associated with the appropriate reservations in IANA registries. Confirm
:    that any referenced IANA registries have been clearly identified. Confirm
:    that each newly created IANA registry specifies its initial contents,
:    allocations procedures, and a reasonable name (see RFC 8126).

This document makes no further requests from IANA.

: 21. List any new IANA registries that require Designated Expert Review for
:    future allocations. Are the instructions to the Designated Expert clear?
:    Please include suggestions of designated experts, if appropriate.

N/A

2023-04-10
06 Jeffrey Haas
Prelude:
The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap
with a similar feature specified in BBF TR-146.  A liaison statement was
exchanged with BBF with …
Prelude:
The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap
with a similar feature specified in BBF TR-146.  A liaison statement was
exchanged with BBF with regard to this work:

https://mailarchive.ietf.org/arch/msg/rtg-bfd/vw31qO1UpD7epoZKXT8_obmY64A/

This internet-draft is largely intended to cover a full IETF specification for
the functionality covered by TR-146 and address the minor issues where TR-146
is incompletely specified.

: Document History
:
: 1.  Does the working group (WG) consensus represent the strong concurrence of a
:    few individuals, with others being silent, or did it reach broad agreement?

The document has weak but positive Working Group consensus to advance.  This is
somewhat typical of documents progressing through BFD at this point.

: 2.  Was there controversy about particular points, or were there decisions where
:    the consensus was particularly rough?

There were several concerns from Greg Mirsky largely regarding the following
points:

1. The mechanism specified in the document bypassed the pre-existing BFD Async
mechanism which permitted the Echo functionality to be enabled.  However, this
is exactly the point of this feature.  Much of the updates to RFC 5880 are
present to permit ths mode.  It's important to note that this mechanism is not
intended to completely replace the Echo mode for RFC 5880 when used in
conjunction with the traditional Async mode.

2. The mechanism specified in the document specified a format for the BFD Echo
packets.  This would appear to contravene RFC 5880, Section 5.  However, the
core behavior in the RFC simply states that the contents of the Echo packets
are a local matter - and this document is simply defining "the local matter".

3. The normative Security Considerations are not strong enough, particularly in
the requirement that RFC 5082 GTSM procedures MUST be utilized by the host
providing the loopback services.  While a great idea in general, this document
largely exists to provide an IETF definition of a feature already described in
BBF TR-146.  Such default limitation of the loopback may not be widely deployed
and thus the more restrictive MUST requirements for GTSM would make existing
deployments non-conformant.

4. A further point of discussion is the intended destination and source
addresses used by this mechanism.  RFC 5881, in particular, provides guidance
for the source address selection such that it is not on the same subnet as the
destination address in order to prevent unnecessary ICMP/ND redirect messages.
However, existing implementations (e.g. Broadcom) use exactly behavior with
source and destination addresses being identical.  RFC 5881 makes this behavior
a SHOULD NOT, so using the same considerations for this mechanism avoids making
existing implementations non-conformant.

: 3.  Has anyone threatened an appeal or otherwise indicated extreme discontent? If
:    so, please summarize the areas of conflict in separate email messages to the
:    responsible Area Director. (It should be in a separate email because this
:    questionnaire is publicly available.)

No.

: 4.  For protocol documents, are there existing implementations of the contents of
:    the document? Have a significant number of potential implementers indicated
:    plans to implement? Are any existing implementations reported somewhere,
:    either in the document itself (as RFC 7942 recommends) or elsewhere
:    (where)?

There are multiple implementations that claim some deployment of BBF TR-146
implementation behavior.


: Additional Reviews
:
: 5.  Do the contents of this document closely interact with technologies in other
:    IETF working groups or external organizations, and would it therefore benefit
:    from their review? Have those reviews occurred? If yes, describe which
:    reviews took place.

No additional reviews have been requested. 

: 6.  Describe how the document meets any required formal expert review criteria,
:    such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

This mechanism currently does not have a YANG module. It may benefit from one
at some point in the future that extends the existing RFC 9314 YANG module for
BFD.

: 7.  If the document contains a YANG module, has the final version of the module
:    been checked with any of the recommended validation tools for syntax and
:    formatting validation? If there are any resulting errors or warnings, what is
:    the justification for not fixing them at this time? Does the YANG module
:    comply with the Network Management Datastore Architecture (NMDA) as specified
:    in RFC 8342?

N/A

: 8.  Describe reviews and automated checks performed to validate sections of the
:    final version of the document written in a formal language, such as XML code,
:    BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

: Document Shepherd Checks
:
: 9.  Based on the shepherd's review of the document, is it their opinion that this
:    document is needed, clearly written, complete, correctly designed, and ready
:    to be handed off to the responsible Area Director?

The document is integrating comments raised during Working Group Last Call and
should be ready for progression afterwards.

: 10. Several IETF Areas have assembled lists of common issues that their
:    reviewers encounter. For which areas have such issues been identified
:    and addressed? For which does this still need to happen in subsequent
:    reviews?

N/A

: 11. What type of RFC publication is being requested on the IETF stream (Best
:    Current Practice, Proposed Standard, Internet Standard,
:    Informational, Experimental or Historic)? Why is this the proper type
:    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard.  This mechanism leverages existing BFD procedures in a new
profile (BFD Async over the Echo port) and is appropriate for the standards
track.

: 12. Have reasonable efforts been made to remind all authors of the intellectual
:    property rights (IPR) disclosure obligations described in BCP 79? To
:    the best of your knowledge, have all required disclosures been filed? If
:    not, explain why. If yes, summarize any relevant discussion, including links
:    to publicly-available messages when applicable.

IPR attestations from the authors are currently pending.  (10 April, 2023)  The
document will be progressed to the IESG once the attestations are all accounted
for.

It is also necessary to point out that this mechanism is an IETF instantiation
of similar procedures from BBF TR-146.  See liaison statement referenced above.

: 13. Has each author, editor, and contributor shown their willingness to be
:    listed as such? If the total number of authors and editors on the front page
:    is greater than five, please provide a justification.

Yes.  There are exactly five authors.

: 14. Document any remaining I-D nits in this document. Simply running the idnits
:    tool is not enough; please review the "Content Guidelines" on
:    authors.ietf.org. (Also note that the current idnits tool generates
:    some incorrect warnings; a rewrite is underway.)

There are no nits noted in version -06.

: 15. Should any informative references be normative or vice-versa? See the IESG
:    Statement on Normative and Informative References.

No.

: 16. List any normative references that are not freely available to anyone. Did
:    the community have sufficient access to review any such normative
:    references?

All references, including the Informative BBF TR-146 reference, are publicly
available.

: 17. Are there any normative downward references (see RFC 3967 and BCP
:    97) that are not already listed in the DOWNREF registry? If so,
:    list them.

No.

: 18. Are there normative references to documents that are not ready to be
:    submitted to the IESG for publication or are otherwise in an unclear state?
:    If so, what is the plan for their completion?

No such references.

: 19. Will publication of this document change the status of any existing RFCs? If
:    so, does the Datatracker metadata correctly reflect this and are those RFCs
:    listed on the title page, in the abstract, and discussed in the
:    introduction? If not, explain why and point to the part of the document
:    where the relationship of this document to these other RFCs is discussed.

This document does not change the status of other existing RFCs.

: 20. Describe the document shepherd's review of the IANA considerations section,
:    especially with regard to its consistency with the body of the document.
:    Confirm that all aspects of the document requiring IANA assignments are
:    associated with the appropriate reservations in IANA registries. Confirm
:    that any referenced IANA registries have been clearly identified. Confirm
:    that each newly created IANA registry specifies its initial contents,
:    allocations procedures, and a reasonable name (see RFC 8126).

This document makes no further requests from IANA.

: 21. List any new IANA registries that require Designated Expert Review for
:    future allocations. Are the instructions to the Designated Expert clear?
:    Please include suggestions of designated experts, if appropriate.

N/A

2023-04-10
06 Jeffrey Haas The document will move forward, but must address lingering issues raised during WGLC.
2023-04-10
06 Jeffrey Haas Tags Revised I-D Needed - Issue raised by WGLC, Doc Shepherd Follow-up Underway set.
2023-04-10
06 Jeffrey Haas IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2023-04-10
06 Jeffrey Haas Notification list changed to jhaas@pfrc.org because the document shepherd was set
2023-04-10
06 Jeffrey Haas Document shepherd changed to Jeffrey Haas
2023-03-25
06 Xiao Min New version available: draft-ietf-bfd-unaffiliated-echo-06.txt
2023-03-25
06 Xiao Min New version accepted (logged-in submitter: Xiao Min)
2023-03-25
06 Xiao Min Uploaded new revision
2023-03-21
05 Jeffrey Haas IETF WG state changed to In WG Last Call from WG Document
2023-02-02
05 (System) Document has expired
2022-08-01
05 Xiao Min New version available: draft-ietf-bfd-unaffiliated-echo-05.txt
2022-08-01
05 Xiao Min New version accepted (logged-in submitter: Xiao Min)
2022-08-01
05 Xiao Min Uploaded new revision
2022-02-08
04 Xiao Min New version available: draft-ietf-bfd-unaffiliated-echo-04.txt
2022-02-08
04 (System) New version accepted (logged-in submitter: Xiao Min)
2022-02-08
04 Xiao Min Uploaded new revision
2022-01-24
03 Xiao Min New version available: draft-ietf-bfd-unaffiliated-echo-03.txt
2022-01-24
03 (System) New version accepted (logged-in submitter: Xiao Min)
2022-01-24
03 Xiao Min Uploaded new revision
2021-12-24
02 (System) Document has expired
2021-06-22
02 Xiao Min New version available: draft-ietf-bfd-unaffiliated-echo-02.txt
2021-06-22
02 (System) New version approved
2021-06-22
02 (System) Request for posting confirmation emailed to previous authors: Raj Boddireddy , Reshad Rahman , Ruixue Wang , Weiqiang Cheng , Xiao Min , bfd-chairs@ietf.org
2021-06-22
02 Xiao Min Uploaded new revision
2021-05-06
01 (System) Document has expired
2020-11-02
01 Weiqiang Cheng New version available: draft-ietf-bfd-unaffiliated-echo-01.txt
2020-11-02
01 (System) New version accepted (logged-in submitter: Weiqiang Cheng)
2020-11-02
01 Weiqiang Cheng Uploaded new revision
2020-09-10
00 Reshad Rahman This document now replaces draft-cw-bfd-unaffiliated-echo instead of None
2020-09-10
00 Weiqiang Cheng New version available: draft-ietf-bfd-unaffiliated-echo-00.txt
2020-09-10
00 (System) WG -00 approved
2020-09-09
00 Weiqiang Cheng Set submitter to "Weiqiang Cheng ", replaces to (none) and sent approval email to group chairs: bfd-chairs@ietf.org
2020-09-09
00 Weiqiang Cheng Uploaded new revision