[Idr] Re: RtgDir Early review: draft-ietf-idr-sdwan-edge-discovery-22

[Susan Hares <[e-mail]>]

Alvaro:

Thank you for your review.

Please see my inline comments below to your major points.  Prior to responding to individual inline items, I would like clarity on the major points.  See my inline comments on the major points.

My understanding from the text is the following is your editorial mechanism:
[1]Nits – means a NIT.     Do you require the NITs to be adjusted according to your English definitions or are “nits” truly NITs?
[minor] – minor
[major] -  is a major comment.

How do I differentiate which of your major comments go with numbers 1-5. How do I find where you consider something inconsistent?

Sue

From: Alvaro Retana <[e-mail]>
Sent: Thursday, April 3, 2025 4:06 PM
To: [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: RtgDir Early review: draft-ietf-idr-sdwan-edge-discovery-22

Hello I have been selected to do a routing directorate “early” review of this draft. https://datatracker.ietf.org/doc/draft-ietf-idr-sdwan-edge-discovery/ The routing directorate will, on request from
External ([e-mail]<mailto:[e-mail]>)
  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tL2QyZDVmNzk3NmJlOTBmYWRhNDgxOWIxNDlhNTc3YzRjLzE3NDM3MTA3ODUuNDI3MTQ0OA==#key=a797f1e4a3715c72ce2e4a736bc7eb38>  FAQ<https://www.godaddy.com/help/report-email-with-advanced-email-security-40813>  GoDaddy Advanced Email Security, Powered by INKY<https://www.inky.com/protection-by-inky>


Hello



I have been selected to do a routing directorate “early” review of this

draft.

https://datatracker.ietf.org/doc/draft-ietf-idr-sdwan-edge-discovery/<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org&t=h.eJwdzs0OgyAQBOBXaTgXEYsinnyVlV1_okID2KZt-u6VXmcyX-bDjrCx7sLmlO6xEwIhQQpgVwrFQmksfJgEeiswwJh4jviCgUd8guOEE3FcovUPCi_Brhe2Zs1ROneyrNvGyErEGQLF3uF7LqzfBVZYj9roZiBTjoCgWmkGqQzUWltlhdTqpmWp27pQlZZKtZmmTJ9SAgf_c_20w7JlMtd41u7Ytu8PS9tC2w.MEUCIDoxSJk1K_fICv1na7IdY5kh8ttRgZTdotkXcEQqzivXAiEAjFZgFssIgDCY_OaDL-BRLOs_zN-PufTOIXuwy-a_Zhs>



The routing directorate will, on request from the working group chair,

perform an “early” review of a draft before it is submitted for publication

to the IESG. The early review can be performed at any time during the

draft’s lifetime as a working group document. The purpose of the early

review depends on the stage that the document has reached.



As this document is in working group last call, my focus for the review was

to determine whether the document is ready to be published. Please consider

my comments along with the other working group last call comments.



For more information about the Routing Directorate, please see

https://wiki.ietf.org/en/group/rtg/RtgDir<https://shared.outlook.inky.com/link?domain=wiki.ietf.org&t=h.eJwdzkEOgyAUBNCrGNYNXyz4wZWLnqA3QEEkIhrENGnTu1e6npmX-ZAzBdJVZM55PzqAl1889TZPdEsObASXtnOHlB08s3v4RG4VWcoi2nxVWC1kq1gDx6yTPfpo3jMdtxVMY8SECtvBqnrSRnPJ1MC40gJx5CMw5HdkNUpBeYOMc1loW-hLyjrq_4_erdqHQpbYXHE8Q_j-ACBtODg.MEUCIEUrK1qsNWUA4zMlqJY-78mvACeQBwE2lP-51othW66zAiEAtI4nZNd21vXtNlrlGdCpEvlB433MIt4Vax9dVktVkH4>



Thanks!



Alvaro.



=================



Document: draft-ietf-idr-sdwan-edge-discovery-22

Reviewer: Alvaro Retana

Review Date: April 3, 2025

Intended Status: Standards Track



Summary:  I have significant concerns about this document. It needs more work before being submitted to the IESG.





Comments:



Please see inline comments/questions below.



(1) What is the purpose of this document?



   Both companion drafts (draft-ietf-bess-bgp-sdwan-usage and draft-ietf-rtgwg-net2cloud-problem-statement) were returned by the IESG,

   asking this question, so I want to start there.



  Given the existence of the other two drafts and the fact that this document  is a product of the idr WG, its purpose should be to define BGP extensions

  based on rfc9012 (and the new NLRI). That's it!



 Some parts don't belong in this document but can be referenced (not copied or paraphrased). Specifically, the companion documents can be used as references that talk about SD-WAN in general, the topologies, etc. It is unnecessary for all that to also exist in this draft. Note that this is the approach taken in rfc9012: it doesn't specifically go into sample topologies

or applications of the different tunnel types.



Also, this document contains mentions, descriptions, and specifications related to the data plane. Being a BGP document, those don't belong here either. Compared with rfc9012, it sometimes explains how to form an encapsulation header (see §3.1.1, for example), but it does not go into the behavior of the data plane itself. It may not be possible to describe an encapsulation header in this document, but that is as far into the data plane as it should go.



[While a significant amount of text doesn't belong on this document, I still  provided comments inline.]



[Sue]:

Please review the previous RTG-DIR review by Ketan (see below).  In addition, Ketan specifically asked for a new format (see item Editorial in his review)

https://datatracker.ietf.org/doc/review-ietf-idr-sdwan-edge-discovery-18-rtgdir-early-talaulikar-2024-11-01/

[Ketan quote]:  “1) The relationship of this document with the Informational document draft-ietf-bess-bgp-sdwan-usage is not clear. I see a lot of overlap. I get the impression that the BESS document is the one that describes a BGP-based SD-WAN solution framework (albiet it also ventures into some BGP encoding aspects). The v12 of this document referenced the BESS document but was later removed.  Note: the IESG returned the BESS document to the WG with several issues raised - many of them seem applicable to this document as well.

2) There are no references to any SD-WAN specifications - I believe this is done at MEF? I was not able to find an IETF informational document other than the BESS document in (1).”

So, I have two RTG-DIR reviews – with opposite viewpoints on the explanatory text. One from a past AD and one from the current AD.

  *   As to the BESS document, I have advised the authors to remove sections that overlapped with the NLRI definition.  Please review the current WG document.
  *   As to the RTGWG, the IESG review (https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/ballot/) states the issue was requirements in a use case document.  If

I will glad to make the changes to the explanation section or remove, if I get a confirmation from RTG-AD (Ketan) on exactly what needs to be in the document.



(2) rfc9012



   rfc9012 does a very good job specifying the framework for the Tunnel Encapsulation Attribute as related to different tunnel types. This document

   should focus on the extension and any differences.



   To be specific, this document should define the new TLVs. Any error handling (for example) that is the same as what rfc9012 already specifies should Not

  be redefined or paraphrased. A general statement that the procedures specified in rfc9012 are followed should be enough (for the NLRIs specified

   in rfc9012, and the new one specified here). Look for "per [RFC9012]".



[Sue-1]: Are you concerned about section 1 and 2 or sections 3-7.



If you are specifying the link to [RFC9012] related information, please see IDR wiki at:

https://wiki.ietf.org/group/idr/TEA-templates



Due to “looseness” in the [RFC9012], these templates/guidelines were agreed upon the IDR chairs.



Section 3 was rewritten to follow this format including error handling.

Section 4 provides manageability issues (operations) for security + routing.

Section 5 security considerations.



If you believe there is duplication for procedures specified in [RFC9012] and the additional considerations in the IDR wiki, please be specific.

If you are simply concerned about sections 1 and 2, please let me know.



If you object to paragraphs 4 and 5 in 3.6.1, please note that this was added to address an issue raised by reviewers.

However, if I can get an agreement with RTG-DIR review (required for publication) and the Current AD – then I will remove it.





(3) Secure Connection



The requirement for a "secure connection" between BGP Peers is first mentioned in the Introduction but is not properly described anywhere. The text also uses "secure link", which creates confusion with the "SD-WAN Secure Links" use case -- this terminology is what is used in the Security Considerations section (see more there). There are also a couple of mentions of "secure transport" and even "secure transport connection".



Besides not clearly explaining the expectations of a "secure connection", the consequences of not having one are also not explained. Some related text

is present in the Security Considerations, but I would say not enough to enforce a "secure connection" in every deployment.



[Sue-1:] The Text in introduction states the secure connection is “outside the scope of this specification.”

The phrase secure connection or secure connections occurs in the introduction (paragraph 3), section 2.2.3 (paragraph 1 and 2), section 2.4 (step 1), and section 3.2.



So, what do you suggest to resolve this issue:



  1.  Definition of secure connection in the definition – any type of tunnel (logical or physical connection) between RR and the BGP peer?
  2.  Definition of secure transport – as TLS or DTLS or the equivalent.





(4) Consistency



   The many ways of referring to a "secure connection" is just one example of  the lack of consistency throughout the document. There is inconsistency

   concerning the terminology in other documents (rfc4271, for example) and the  use of terms and names defined in this document.

    I made a significant number of related comments inline.



[Sue}: How do I detect what you consider an inconsistent comment.



(5) Normative Text



   I ask several times about text needing to be Normative even in light of the  recent IESG statement because, IMO, Normative language can clarify the

   text...and you're already using similar language (must instead of MUST, for    example).



https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org&t=h.eJxFzkFuwyAQBdCrRKw7xrg4mKxylTEMNjKGCLCiJOrda7rp8s-X3vwPO3Jgtwtba32UG-cWK9aMZqPceaquS3nhNhlezjvtFCt4Kgv8xxTBBMzevXxcoK4ERyFIDmbzACFhoxc8U7aFs68L29qzSPVkRT9OVy0GXlbMVO7RvtfOpJ3bwY5OaXWdSfcOLcpJ6FlIjaNSRhoulPxWolfT2MlBCSmnRlOjT6lixL_t92VHHxrZanvW8Qjh5xeEF04z.MEYCIQC1t7aXfCqn5_7rxn1KmcgZj1AQ3zcTXJGO0p6mMYiabgIhAOxmwYqbJopWsIG7ioVURqQDQytiKvEXS9i_dbD-SLQC>





[Line numbers from idnits.]



...

14                  BGP UPDATE for SD-WAN Edge Discovery

15                 draft-ietf-idr-sdwan-edge-discovery-22



17 Abstract



19   The document describes the BGP mechanisms for SD-WAN edge node

20   property discovery.  These mechanisms include a new tunnel type and

21   subTLVs for the BGP Tunnel-Encapsulation Attribute (RFC9012) and set

22   of NLRI (network layer reachability information) for Software-Defined

23   Wide-Area Network (SD-WAN) underlay information.



[nit] "property discovery" ??



The rest of the document talks about "discovery", not "property discovery".  What is "property discovery"??



[Sue]: “property discovery” – is when the BGP Peer discovers the property of the node.

Can you tell me what is the problem





[nit] The document uses both "subTLV" and "sub-TLV", please settle on one.

IMHO, "sub-TLV" seems the better choice.





[nit] The expansion of SD-WAN is not the first occurrence.





25   In the context of this document, BGP Route Reflector (RR) is the

26   component of the SD-WAN Controller that receives the BGP UPDATE from

27   SD-WAN edges and in turns propagates the information to the intended

28   peers that are authorized to communicate via the SD-WAN overlay

29   network.



[] I hope this will be clarified later, but in general a RR "receives the

BGP UPDATE...and in turns propagates the information to the intended peers

that are authorized..." (for some value of "authorized").  IOW, the text is

not wrong, it just seems to state the obvious.





[nit] s/in turns/in turn







...

138 1.  Introduction



140   BGP [RFC4271] can be used as a control plane for a Software Defined

141   Wide Area Network (SD-WAN) to support Secure VPNs or simply to

142   support a set of Secure links in a network.  A brief definition of

143   these two use cases is given in this section.  Section 2 describes

144   the BGP framework in terms of NLRIs supported, example topologies,

145   and objectives for the BGP mechanisms.  Section 3 describes the BGP

146   mechanisms, and section 4 describes error handling for this

147   mechanism.



[nit] s/definition/description





[minor] §4 is titled "Manageability Considerations", which I can see how it

could be interpreted as "error handling".  But §3.6 (Error handling) seems

to fit the description ("error handling for this mechanism").







149   The BGP mechanisms for SD-WAN support requires a route reflector (RR)

150   to have a secure connection to each BGP Peer participating in the BGP

151   infrastructure support the SD-WAN.  The establishiment of a secure

152   connection between each BGP Peer and the RR is outside the scope of

153   this specification.



[nit] s/support the SD-WAN/supporting the SD-WAN





[nit] s/establishiment/establishment





[major] "requires...a secure connection...establishiment (sic) of a secure

connection...is<https://shared.outlook.inky.com/link?domain=connection..is&t=h.eJwVzEEOgyAQAMCvGM4NuHRxwZNfQUAlRWgUL23698p5kvmy60hs7NhW63sUwpWcg6uxZM55PNmjY6_GOdRyrNArPRiQ4tzsEc4p-8_GXdmFl14tZGiYg-kX6y1qMDOgsYrIoRNA-CToSSuOkgBRtzq0-p6qzZbHUJdp3W1MrWzsb85XSr8_RCYxBg.MEQCID4BeNmHjKw362tPYtWHK7AwUxnd6KMaY_lz3zGi05FyAiAyC2pm44XMJB9EuGLQs4y4s-TAdYESjdYoVQsRTLWdkQ> outside the scope of this specification."



A "secure connection" is not properly described anywhere.  The text also

uses "secure link", which creates confusion with the "SD-WAN Secure Links"

use case -- this terminology is what is used in the Security Considerations

section (see more there).  There are also a couple of mentions of "secure

transport" and even "secure transport connection".  Please be consistent!







155   This document describes the BGP mechanisms for an SD-WAN edge nodes

156   to established a BGP peering with other SD-WAN edge nodes, and pass

157   information in order to establish and update secure overlay tunnels

158   [Net2Cloud].  These mechanisms include a new tunnel type and subTLVs

159   for the BGP Tunnel-Encapsulation Attribute [RFC9012] and a set NLRIs

160   for SD-WAN underlay information.



[nit] s/for an SD-WAN edge nodes/for SD-WAN edge nodes





[minor] [Net2Cloud] doesn't contain the phrase "secure overlay tunnels".



However, it's interesting that the same document says (in §7 - Security

Considerations):



   Solution drafts resulting from this work will address security

   concerns inherent to the solution(s), including both protocol

   aspects and the importance, for example, of securing workloads in

   cloud DCs and the use of secure interconnection mechanisms.



   A full security evaluation will be needed before [MULTI-SEG-SDWAN]

   and [SDWAN-EDGE-DISCOVERY] can be recommended as a solution to some

   problems described in this document.



I don't think this document includes a "full security evaluation".





[nit] s/a set NLRIs/a set of NLRIs







162 1.1.  SD-WAN Secure L3VPNs



164   A SD-WAN network defined in [MEF70.1] and [MEF70.2], refers to a

165   policy-driven network over multiple heterogeneous underlay networks

166   to get better WAN bandwidth management, visibility, and control.

167   This document refers to this network as a SD-WAN Secure L3VPNs.

168   [SD-WAN-BGP-USAGE] defines the five requirements for BGP usage in an

169   SD-WAN Secure L3VPN networks and 3 scenarios for deployment.  The

170   five requirements defined are the following:



[minor] " A SD-WAN network defined in [MEF70.1] and [MEF70.2]...This

document refers to this network as a SD-WAN Secure L3VPNs."



Let me get this straight.  This document uses "SD-WAN Secure L3VPNs" to

refer to "SD-WAN".  If so, what are "SD-WAN Secure Links"?  Are they

"secure links" in "SD-WAN Secure L3VPNs"?  Which sounds redundant: "Secure

L3VPNs with Secure Links".  Note that there are a lot of uses of "SD-WAN"

by itself...



I hope the terminology is better defined elsewhere, but I haven't found

where...





[nit] s/in an SD-WAN Secure L3VPN networks/in an SD-WAN Secure L3VPN network





[major] "[SD-WAN-BGP-USAGE] defines the five requirements for BGP usage"



First of all, the bullets listed below are an oversimplification of the

text in §3.1/SD-WAN-BGP-USAGE.  Second, the requirements in

SD-WAN-BGP-USAGE are not only about "BGP usage" (control plane), but also

about the data plane (traffic segmentation), and other non-related items

(such as ZTP).



Note that the summary of the requirements makes the text more complex (and

incomplete).  Simply reference SD-WAN-BGP-USAGE and, if applicable,

highlight any BGP-specific requirements.





172   *  Support for SD-WAN segmentation - that allows edge noded connected

173      over tunnels to support VPNs.



[nit] s/noded/nodes







175      -  These VPNs can be MPLS VPNS ([RFC4364],[RFC4659] with VRFs,

176         MPLS L2VPN [RFC4761], [RFC4762], L3VPN [RFC4364][RFC4659], or

177         IPsec tunnels.



[nit] The parenthesis is not closed.







179   *  Support for Client Services interfaces on edge nodes (e.g. SD-WAN

180      UNI [MEF70.1]),



182   *  WD-WAN Traffic Segmentation,



184   *  Zero Touch Provisioning, and

185   *  Constrained Propagation of SD-WAN Edge Properities by BGP

186      infrastructure using a Route Reflector.



188   [SD-WAN-BGP-USAGE] describes the three scenarios for SD-WAN networks

189   comprised of a mixture of tunnels over private and public networks:



[] As above, the scenarios (as described here) are orthogonal to the use of

BGP as the characteristics are data plane-specific.





191   *  Homogeneous Encrypted SD-WAN - where edge nodes encrypt data prior

192      to entering the SD-WAN,



194   *  Differential Encrypted SD-WAN - where edge nodes encrypt traffic

195      traversing public networks, but do not encrypt traffic over

196      private secure networks,



198   *  Private VPN PE based SD-WAN - where an existing private VPN is

199      expanded by adding extra ports over the public internet.



201   [SD-WAN-BGP-USAGE] provides descriptions on the use of SD-WAN

202   technology for L3VPNS, the provisioning of SD-WAN nodes, and example

203   BGP topologie and SD-WAN forwarding mechanisms.  This document

204   assumes the reader is familar with SD-WAN use case described in

205   [SD-WAN-BGP-USAGE].



[nit] s/topologie/topologies





[nit] s/familar with SD-WAN use case/familiar with the SD-WAN use cases







207 1.2.  SD-WAN Secure Links

...

216   The traffic is routed via normal IP v4/v6 forwarding without any VPN

217   addition.  The SD-WAN Secure Links provides some link security for

218   some simple cases of the three scenarios from [SD-WAN-BGP-USAGE] that

219   do not require L3VPN addresses (RD, prefix).



[nit] s/ IP v4/v6 / IPv4/IPv6 /g



[] The Introduction said that this section presents a "brief definition of

these two use cases", but it seems to me that "SD-WAN Secure Links" is not

a different use case...  I may of course be confused already.







221 1.3.  Conventions used in this document



223   The following acronyms and terms are used in this document:



225   Authorized BGP peer:  Authorized BGP peer are Peers which a

226      particular BGP Peer has been configured by local policy to connect

227      to.



[] IOW, what every other document would call a "BGP Peer".  Note that this

term is only used one more time in this document (§2.3) coupled with

discovery, which, to me, is different that "configured".







229   Cloud DC:  Off-Premises Data Centers that usually host applications

230      and workload owned by different organizations or tenants.



[major] Some of the definitions are different from the ones in related

drafts.  For example, "Cloud DC" has a slightly different definition in

draft-ietf-rtgwg-net2cloud-problem-statement.  I recommend that you only

define the terms once and then reference them.





[nit] s/workload/workloads







232   Color-EC:  Color Extended Community defined in [RFC9012].



[major] Please don't make up unnecessary terms.  Using the name used in

rfc9012 keeps terminology in sync through out all the RFCs.







234   Controller:  Used interchangeably with SD-WAN controller to manage

235      SD-WAN overlay path creation/deletion and monitor the path

236      conditions between sites.



[major] The definition in draft-ietf-bess-bgp-sdwan-usage is different.







238   CPE (or C-PE):  Customer (Edge) Premises Equipment.  Please note that

239      these two forms are equivalent in this document.  C-PE is used to

240      emphasize the web of Provider Equipment devices.



[major] These terms are defined separately in

draft-ietf-bess-bgp-sdwan-usage.   For the purpose of these documents, it

looks like C-PE is the relevant term.







...

246   Encap-EC:  Encapsulation Extended Community defined in [RFC9012].



[major] Please don't make up unnecessary terms.  Using the name used in

rfc9012 keeps terminology in sync through out all the RFCs.







248   IPsec-SA:  IPsec Security Association.



[] Reference?







250   MP-NLRI:  Multi-Protocol Network Layer Reachability Information

251      (MP_REACH_NLRI) Path Attribute defined in [RFC4760].



[major] Please don't make up unnecessary terms.  Using the name used in

rfc4760 keeps terminology in sync through out all the RFCs.







253   RR:  Route Reflector [RFC4456]



[minor] There's no need to define a term for a well-known names (which are

also expended inline).







255   RT-EC:  Route Target Extended Community [RFC4360]



[major] Please don't make up unnecessary terms.  Using the name used in

rfc4360 keeps terminology in sync through out all the RFCs.







257   SA:  IPsec Security Association



[major] Hmmm... IPsec-SA and SA are the same thing?







259   SD-WAN:  An overlay connectivity service that optimizes transport of

260      IP Packets over one or more Underlay Connectivity Services by

261      recognizing applications (Application Flows) and determining

262      forwarding behavior by applying Policies to them.  [MEF-70.1][MEF-

263      70.2]



[major] This term is defined elsewhere.  In general, instead of repeating

terms and paraphrasing definitions, indicate which terminology the reader

should be familiar with.







265   SD-WAN Endpoint:  can be the SD-WAN edge node address, a WAN port

266      address (logical or physical) of a SD-WAN edge node, or a client

267      port address.



[major] This term is not used anywhere in the document.  Endpoint seems to

only be associated with tunnel...







269   SD-WAN Hybrid tunnel:  A single logical tunnel that combines several

270      links of different encapsulation iinto a single tunnel.  This

271      logical tunnel may exist as part of a SD-WAN Secure L3VPN or

272      simply be a SD-WAN secure link for a flat network.



[nit] s/iinto/into







274   SD-WAN Secure L3VPN:  The mesh of SD-WAN secure tunnels that support

275      the uses cases defined by [SD-WAN-BGP-USAGE] and [MEF-

276      70.1][MEF70.2].  BGP transmits information about SD-WAN Hybrid

277      tunnels in the SD-WAN Secure L3VPN network by sending L3VPN AFI/

278      SAFI with a TEA with a tunnel type of SD WAN Hybrid Tunnel.

279      Information about the IPsec Security Association (IPsec-SA) for

280      the SD-WAN underlay for these SD WAN Hybrid tunnels is passed in

281      the SD-WAN NLRI (AFI 1/74) with a TEA with SD-WAN Hybrid Tunnel.



283      This document defines the BGP mechanisms for the SD-WAN Secure

284      L3VPN, but the [SD-WAN-BGP-USAGE] defines the requirements,

285      scenarios, provisioning model, examples of normal BGP flows, and

286      SD-WAN forwarding.



[] No need to define a term for the use case...







288   SD-WAN Secure Links:  A mesh of SD-WAN Hybrid tunnels may connect

289      several SD-WAN edge nodes in a flat (non-VPN) network.  The SD-WAN

290      Secure Links use case does not support VPN identification, and

291      applies only a simple creation of secure link with support for

292      passing IPsec-SA information regarding the SD-WAN Hybrid Tunnel.

293      BGP sends a Unicast v4/v6 NLRI (AFI/SAFI 1/1 and 2/1) with a TEA

294      for a SD-WAN Hybrid tunnel to announce the existance of the link.

295      Information about the IPsec Security Association (IPsec-SA) for

296      the SD-WAN underlay for these SD WAN Hybrid tunnels is passed in

297      the SD-WAN NLRIs (AFI/SAFI 1/74 and 2/74) with a TEA with SD-WAN

298      Hybrid Tunnel



[] Same comment.







300   TEA:  Tunnel Encapsulation Path Attribute [RFC9012]



[major] Please don't make up unnecessary terms.  Using the name used in

rfc9012 keeps terminology in sync through out all the RFCs.







302   VPN:  Virtual Private Network



[minor] There's no need to define a term for a well-known names (which are

also expended inline).







304   VRF:  VPN Routing and Forwarding instance



[minor] There's no need to define a term for a well-known names (which

should also be expended inline).







306   WAN:  Wide Area Network



[minor] There's no need to define a term for a well-known names (which

should also be expended inline).







..

317 2.1.  Supported Client Routes



319   Tunnel Encapsulation may be attached to the prefixes from the Unicast

320   v4 and v6 ((AFI/SAFI 1/1 and 2/1), and L3VPNs for v4 and v6 (AFI/SAFI

321   1/128 and 2/128) (per [RFC4364], [RFC4659]).



[major] s/Tunnel Encapsulation/The Tunnel Encapsulation Attribute [RFC9012]





[nit] s/v4 and v6/IPv4 and IPv6/g





[major] The statement is about the use of the Tunnel Encapsulation

Attribute is false, in general.  It may be what this specification expects

(when used with a specific tunnel type or NLRI) -- if so, please be

explicit.







323   The document defines SD-WAN Secure L3VPN as the SD-WAN Secure VPN

324   defined in [SD-WAN-BGP-USAGE], [MEF-70.1], and [MEF70.2].  The SD-WAN

325   Secure L3VPN requires the L3VPN for IPv4 [RFC4364] and IPv6 [RFC4659]

326   to be expanded to support SD-WAN Hybrid Tunnels and the passages of

327   IPsec-SA information for the underlay tunnels that support SD-WAN

328   Secure L3VPN.



[] "The document defines SD-WAN Secure L3VPN as the SD-WAN Secure VPN

defined in [SD-WAN-BGP-USAGE], [MEF-70.1], and [MEF70.2]."



One more definition for "SD-WAN Secure L3VPN"...





[] "requires the L3VPN for IPv4 [RFC4364] and IPv6 [RFC4659] to be expanded

to support SD-WAN Hybrid Tunnels"



This wasn't listed when the requirements were mentioned (§1.1).







330   This document defines the SD-WAN Secure Links as links in network

331   that uses SD-WAN tunnels to create secure Hybrid SD-WAN tunnels

332   between SD-WAN End Nodes.  The SD-WAN Secure Links application does

333   not support identification of a VPN via L3VPN NLRI.  The SD-WAN end

334   node uses BGP to pass Unicast v4/v6 prefixes ((AFI/SAFI 1/1 and 2/1)

335   routes with TEA with a SD-WAN Hybrid tunnel TLV.  The SD-WAN secure

336   links application also passes the IPSec-SA information for the

337   underlay tunnels in BGP.



[] One more definition...





[nit] s/via L3VPN NLRI/via the L3VPN NLRI





[minor] Add a reference to "TEA with a SD-WAN Hybrid tunnel TLV".







...

348 2.2.1.  SD-WAN Secure L3VPN Example Topology



350   This section summarizes the BGP requirements from the following three

351   scenarios from [SD-WAN-BGP-USAGE] can be handled by a BGP control

352   plane using BGP Tunnel-Encapsulation attribute [RFC9012]:



[nit] s/summarizes the BGP requirements...using BGP Tunnel-Encapsulation

attribute/summarizes how the BGP requirements...using the BGP Tunnel

Encapsulation attribute







354   *  Homogeneous Encrypted SD-WAN,



356   *  Differential Encrypted SD-WAN, and



358   *  Private VPN PE based SD-WAN.



[] §1.1 listed 5 requirements...





[] Also, these seem to be data plane requirements, not "BGP requirements".

IOW, I understand how BGP can be used to carry the information to achieve

the final goal...but the requirements don't seem specific to the use of BGP