# OPSDIR review of draft-ietf-bfd-unaffiliated-echo-11

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in the last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last-call comments.

The document describes the use of BFD Echo when the peer does not support BFD but only loops packets back. 

The document does not include an explicit manageability & operational considerations section. Authors could consider adding it. RFC 5880 has it and it would make sense to call out considerations that are specific to Unaffiliated BFD Echo (if any). For instance - Does BFD enabled system A know that the BFD Echo session is unaffiliated? Is there a configuration? How does it work with affiliated BFD Echo sessions?

## Minor

- There are many instances where you use normative BCP14 keywords when restating text from existing RFCs. It would be best if you either used lowercase when paraphrasing or converted those to Verbatim with the use of "". 

- Section 1; "It also supports an Echo function to reduce the device requirement for BFD." - This needs more explanation or a reference if it is already described in the existing RFC. I am guessing you mean control plane processing but I am unsure. 

- Section 1; "The former scenario is referred to as affiliated BFD Echo, which is not changed by this document in any way." - Unless I am incorrect, this is the I-D that is using the term for the first time, and thus this needs to be rephrased - "The former scenario is referred to as 'affiliated BFD Echo' in this document, which remains unchanged from [RFC5880]." 

- Section 1; "Section 5 of [RFC5880] indicates that the payload of an affiliated BFD Echo packet is a local matter and hence its contents are outside the scope of that specification. This document, on the other hand, specifies the contents of the Unaffiliated BFD Echo packet and what to do with them." - Why is there no OLD/NEW text for Section 5 of [RFC5880] in Section 3? Also, does the last paragraph of section 9 of RFC 5880 that should be updated? 

- It would make sense to have the use case described in this document itself with suitable references. Reading section 6.2.2 of [BBF-TR-146] does not help in having a clear description of why an Unaffiliated BFD Echo is needed. 

- All Unaffiliated BFD Echo packets for the session MUST be sent with a Time to Live (TTL) or Hop Limit value of 255, and received with a TTL or Hop Limit value of 254, otherwise the received packets MUST be dropped [RFC5082].

- For handling "unset values" in section 2 and section 4, why SHOULD and not a MUST? 

## Nits
- Expand BFD in title

- s/make use of Unicast Reverse Path Forwarding (URPF) [RFC3704] in strict mode/make use of Unicast Strict Reverse Path Forwarding (RPF) [RFC3704]/ -> to match with RFC3704. Perhaps you can also explicitly state why for the reader. 

Thanks! 
Dhruv