I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is Ready with NITS.

This ID describes the encoding of BGP UPDATE messages for the SD-WAN edge node property discovery, for the case in which a BGP Route Reflector (RR) receives the BGP UPDATE from SD-WAN edges and then propagates the information to the intended peers.   This is generally considered the best architecture for propagating updates,  because it requires the fewest communications.  After the preliminaries the ID gives, in Section 3, a framework for SD-WAN edge discovery, and in Section 4, an outline of constrained propagation of BFG update.   Both of these are copiously illustrated with examples,  and help to give an idea of the kinds of issues that might arise.  This part seems to be more informational than descriptive; there are very few SHOULDs or MUSTs.

Sections 6 through 8ngive the meat of the ID: the messages, their format, and the information that is encoded in them.  These are presented in detail.  Section 9 deals with error handling.  This mainly repeats material that is in RFC9012, and RFC7606, but it is useful to have for context.

Sections 10 and 11 deal with Manageability Considerations and Security Considerations, respectively.

I like the approach taken by the this ID.  Instead of just giving the bare specifications, (given in Section 6 through 8), the authors make the effort  to provide the context behind them, so the reader can understand  how to use them.  It also is I think the first ID I’ve seen with a manageability considerations section, although the inclusion of such a section has been under discussion for a long time.  In this case, the section recommends a simplified set of information with which to set up IPsec Security Associations for the SD-WAN hybrid tunnel, which makes it easier to avoid and identify mismatching SAs.


On the negative side, the presentation is a little rough around the edges.   There are numerous typos and misspellings, many which should have been caught by the spellchecker.  A careful proofreading is in order.  

In addition, I noticed that  the list of acronyms in Section 2 has many missing definitions:  I noticed 

MPLS, SA, VRF, BGP, NRLI (different kinds of NRLI are defined, but not NRLI itself), TLV and subTLV, GRE, VXLAN, and VNI

were missing before I gave up.  Please, if it’s an acronym, put it in!  Also, RT-EC is out of alphabetical order.

Finally, I think that the Security Considerations Section should have a pointer to the SA mismatch issue discussed in the Manageability Considerations Section, since that is a security issue too.