We will need to address the Routing Directorate review from Thomas Morin reproduced here for the record.

Summary:

   The document is concise, well written, and raises no major issue.
   However, bringing clarifications to a few areas should be considered
   prior to publication.

Major Issues:

   None.

Minor Issues:

- Mi.1) The document mentions the use of a specific UDP port for the
micro-BFD sessions (6784). It should probably explain what is the
behavior if BFD messages from a micro-BFD sessions are received on the
normal BFD port (3784), and vice-versa what is the behavior for BFD
messages from a non-BFD sessions is received on the micro-BFD UDP port.

- Mi.2) The document indicates in section 2.2 that "The details of how
[the destination IP address of the BFD peer] is learned are outside the
scope of this document.".  First, an example of a common practice would
be great to provide an illustration.  Second, I would find it worth
documenting how this can be done in practice on an unnumbered link

- Mi.3) The notion of "L3 continuity" is used in the introduction, but
it is not explained what this means; it would deserve being explained as
the idea of "continuity" may not be obvious to interpret in a contect
where a single L3 hop is being tested.

- Mi.4) Section 4 mentions "LMM" and "some Interface management module"
without providing any definition nor explaining the role of such modules.

- Mi.5) The behavior described in the Appendix looks very important for
smooth activation of the feature in a real network and is actually
specification text. I'm thus surprised to find it in an Appendix --
where it could be missed by implementors.  I would suggest considering
moving this text among the rest of technical specifications sections.


** Editorial comments:

- Ed.1) I would suggest removing the mention of the use of a specific
UDP port from the Abstract, which would then be more concise -- the
motivation for using a specific UDP port so could be provided in section
2.2.

- Ed.2) Section 2.3: "For the following BFD packets with Up state the
MAC address from the received BFD packets for the session MAY be used
instead of the dedicated MAC. "

    => "the _source_ MAC address from the received BFD packets" ?
(adding "source" would remove any risk of ambiguous interpretation)

- Ed.3) Section 5: "MAY remove the member link from the load balance
table only that matches the address family of the failing BFD session"

   I had issues parsing this sentence; what about: "MAY remove the
member link from only the load balance table that matches..."

   Furthermore, it would be nice to add a colon at the end of the
sentence to indicate that what follows is an illustration of what precedes.

   Last, I think it would be worth indicating explicitly that "The
member link MAY also be removed from both the L4 and L6 load balancing
table".

- Ed.4) I believe you need to update contact information for Nitin Bahadur.