This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

I have reviewed BFD for Geneve (draft-ietf-nvo3-bfd-geneve-10) and have one significant point on this protocol. So when BFD was published after quite some discussion about the lack of an actual congestion control mechanism in BFD in RFC 5880 there was agreement on the following that was included in Section 7 of RFC 5880:

   When BFD is used across multiple hops, a congestion control mechanism
   MUST be implemented, and when congestion is detected, the BFD
   implementation MUST reduce the amount of traffic it generates.  The
   exact mechanism used is outside the scope of this specification, and
   the requirements of this mechanism may differ depending on how BFD is
   deployed, and how it interacts with other parts of the system (for
   example, exponential backoff may not be appropriate in cases where
   routing protocols are interacting closely with BFD).

As this usage of BFD although is point to point inside the tunnel, the fact that it is a tunnel and can bridge both multisegment L2 and especially IP networks means that this document in my view need to define how it fulfills the above requirements when using BFD. 

I do note the security consideration do note that overload is a factor due to multiple path sharing tunnel establishments. So there are apparently risks from two types of overlad situations here. First that multiple tunnles between endpoints are established. Secondly, that there are congestion due to network cross traffic on the paths the tunnels share. 

So I think there are two paths forward. Either restrict the applicability of this usage to paths where it is known to have provisioned capacity for the BFD, as noted as required in RFC 5881 applicability statement. The alternative is to extend BFD to actually have a real congestion control. Something I think would have benefit all considering how wide spread use there is of BFD over various overlay networks that really are ignoring this potential issue. 

To conclude I am of the oppinion that this document should not be approved for publication until this issue of congestion control is handled one way of another.