idnits 2.17.1 draft-dunbar-idr-sdwan-port-safi-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 4, 2019) is 1635 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'SDWAN-BGP-USAGE' is mentioned on line 97, but not defined == Missing Reference: 'RFC4760' is mentioned on line 255, but not defined == Unused Reference: 'RFC2119' is defined on line 464, but no explicit reference was found in the text == Unused Reference: 'RFC8192' is defined on line 468, but no explicit reference was found in the text == Unused Reference: 'RFC5521' is defined on line 471, but no explicit reference was found in the text == Unused Reference: 'VPN-over-Internet' is defined on line 478, but no explicit reference was found in the text == Unused Reference: 'DMVPN' is defined on line 482, but no explicit reference was found in the text == Unused Reference: 'DSVPN' is defined on line 486, but no explicit reference was found in the text == Unused Reference: 'ITU-T-X1036' is defined on line 490, but no explicit reference was found in the text == Unused Reference: 'Net2Cloud-gap' is defined on line 498, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-rosen-bess-secure-l3vpn-00 == Outdated reference: A later version (-07) exists of draft-dm-net2cloud-problem-statement-02 == Outdated reference: A later version (-04) exists of draft-dm-net2cloud-gap-analysis-02 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-10 Summary: 1 error (**), 0 flaws (~~), 16 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Dunbar 2 Internet Draft Futurewei 3 Intended status: Informational S. Hares 4 Expires: May 4, 2020 Hickory Hill Consulting 6 November 4, 2019 8 SDWAN WAN Ports Property Advertisement in BGP UPDATE 9 draft-dunbar-idr-sdwan-port-safi-05 11 Abstract 13 The document specifies information encoded in BGP UPDATE for 14 advertising WAN ports properties of a SDWAN edge node to its 15 controller. SDWAN edge node's WAN ports may face untrusted networks, 16 such as the public internet, may get assigned IP addresses from the 17 Internet Service Providers (ISPs), may get assigned dynamic IP 18 addresses via DHCP, or may have private addresses (e.g. inside third 19 party Cloud DCs). Packets forwarded through those SDWAN WAN ports 20 might need to be encrypted (depending on the user policies) or need 21 to go through NAT. SDWAN edge nodes need to propagate those WAN 22 ports properties to its controller which in turn distribute to the 23 peers who are authorized to communicate across different types of 24 underlay networks including the untrusted networks. 26 This document assumes the BGP Route Reflectors (RR) as the 27 controller, i.e. SDWAN edges send the WAN ports properties encoded 28 in BGP UPDATE to the RR which in turns propagate the information to 29 a group of authorized SDWAN edges reachable via overlay networks. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as Internet- 39 Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six 42 months and may be updated, replaced, or obsoleted by other documents 43 at any time. It is inappropriate to use Internet-Drafts as 44 reference material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html 52 This Internet-Draft will expire on Dec 3, 2020. 54 Copyright Notice 56 Copyright (c) 2019 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with 64 respect to this document. Code Components extracted from this 65 document must include Simplified BSD License text as described in 66 Section 4.e of the Trust Legal Provisions and are provided without 67 warranty as described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction...................................................3 72 2. Conventions used in this document..............................3 73 2.1. Information to be propagated for SDWAN UPDATE.............4 74 2.2. SAFI under the MP-NLRI....................................6 75 2.3. How about a new Path Attribute under BGP UPDATE?..........6 76 3. SDWAN WAN Port ID encoding in the MP-NLRI Path Attribute.......6 77 4. WAN Port Properties encoding in the Tunnel Path Attribute......8 78 4.1. Port Ext SubTLV...........................................8 79 4.2. IPsec Security Association Property......................10 80 4.3. Remote Endpoint..........................................11 81 5. Manageability Considerations..................................12 82 6. Security Considerations.......................................12 83 7. IANA Considerations...........................................12 84 8. References....................................................12 85 8.1. Normative References.....................................12 86 8.2. Informative References...................................12 87 9. Acknowledgments...............................................13 89 1. Introduction 91 [Net2Cloud-Problem] introduces using SDWAN to reach dynamic 92 workloads in multiple third-party data centers and aggregate 93 multiple underlay paths, including public untrusted networks, 94 provided by different service providers. 96 [SDWAN-BGP-USAGE] describes multiple SDWAN scenarios and how/why 97 using BGP as control plane for the SDWAN networks. [SDWAN-BGP-USAGE] 98 introduced two distinct SDWAN scenarios: Homogeneous SDWAN and 99 Hybrid SDWAN. 101 This document describes multiple options of encoding under the 102 Hybrid SDWAN scenario for SDWAN edge nodes to propagate their WAN 103 Ports properties to their peer SDWAN nodes. 105 2. Conventions used in this document 107 Cloud DC: Off-Premise Data Centers that usually host applications 108 and workload owned by different organizations or 109 tenants. 111 Controller: Used interchangeably with SDWAN controller to manage 112 SDWAN overlay path creation/deletion and monitor the 113 path conditions between sites. 115 CPE-Based VPN: Virtual Private Secure network formed among CPEs. 116 This is to differentiate from most commonly used PE- 117 based VPNs a la RFC 4364. 119 MP-NLRI: The MP_REACH_NLRI Path Attribute defined in RFC4760. 121 SDWAN End-point: An WAN port (logical or physical) of a SDWAN edge 122 node. (If "endpoint" is used, it refers to a SDWAN End- 123 point). 125 OnPrem: On Premises data centers and branch offices 127 SDWAN: Software Defined Wide Area Network. In this document, 128 "SDWAN" refers to the solutions of pooling WAN bandwidth 129 from multiple underlay networks to get better WAN 130 bandwidth management, visibility & control. When the 131 underlay networks are private networks, traffic can be 132 forwarded without additional encryption; when the 133 underlay networks are public, such as Internet, some 134 traffic needs to be encrypted when forwarding through 135 those WAN ports(depending on user provided policies). 137 2.1. Information to be propagated for SDWAN UPDATE 139 [Tunnel-Encap] describes a BGP UPDATE Path Attribute (with Code = 140 23) that advertise endpoints' tunnel encapsulation capabilities for 141 the respective attached client routes, so that the receivers of the 142 BGP UPDATE can establish appropriate tunnels to the endpoints for 143 the aforementioned client routes. The detailed tunnel information 144 encoded in the Tunnel Path Attribute apply to all client routes 145 carried by the UPDATE's MP-NLRI, which refers to the MP_REACH_NLRI 146 Path Attribute described in RFC4760. 148 Following the same approach used by [idr-segment-routing-te-policy] 149 where the SR Policy identifier is encoded in the MP-NLRI Path 150 Attribute and the detailed SR Polices are encoded in the Tunnel Path 151 attribute, SDWAN WAN port UPDATE can have the WAN Port Identifier 152 encoded in the MP-NLRI Path Attribute and the associated WAN Port 153 properties encoded in the Tunnel Path Attribute. Sometimes, a WAN 154 Port identifier can be only locally significant within the SDWAN 155 node. Therefore, it is necessary to include the Node ID and Site ID 156 to identify a SDWAN WAN Port. 158 This approach has the benefit of cleaner implementation when the 159 properties of a SDWAN node's WAN Port changes, such as ISP service 160 agreement changes for the service connected to a WAN Port, a WAN 161 port being disabled, or its IPsec property changes, etc. Since most 162 SDWAN edges only have a small number of WAN ports, the disadvantage 163 of multiple BGP UPDATE messages to advertise properties of those WAN 164 ports is relatively small. 166 For example, a SDWAN edge node with 3 WAN ports (A1/A2/A3) can send 167 3 separate SDWAN UPDATE messages to propagate the properties of its 168 WAN Port A1, A2, and A3. 170 UPDATE message for WAN Port A1: 171 Border Gateway Protocol - UPDATE Message 173 Path Attribute - MP_REACH_NLRI 174 /* independent from the routes attached to the SDWAN node */ 175 - Address family identifier (AFI) 176 - Subsequent address family identifier (SAFI) 177 - /* New: Port Identifier, which can be assigned IPv4/Ipv6 178 address, or locally significant port ID (similar to SR policy ID)*/ 179 - Next hop network address 180 - /* New: the SDWAN node identifier */ 181 - /* New: Site-ID of this SD-WAN node */ 183 Path Attribute - Tunnel-Encap (Type Code=23) 184 /*Detailed properties for WAN Port A1*/ 185 - Tunnel-Type = Untrusted-Internet /* need IANA assignment */ 186 - Encoding of A1's properties in subTLVs 187 /* see later section for detailed encoding */ 188 - Ipsec properties for Ipsec tunnel terminated at A1 189 - NAT properties if A1 has private address 190 - ISP information 192 The SDWAN node identifier (or loopback address) might be only 193 locally significant among its peer group and not routable in the 194 WAN. 196 Receivers of the UPDATE can associate the SDWAN node identifier, 197 site identifier with the node's WAN Port properties. The SDWAN-A can 198 send a regular BGP UPDATE messages to advertise the SDWAN-A node 199 being the NextHop for CN3 & CN2, without attaching the WAN port 200 property. 202 2.2. SAFI under the MP-NLRI 204 It is possible to continue using the same IP SAFI in the MP-NLRI 205 [RFC4760] Path Attribute for advertising the SDWAN WAN port 206 properties. If the same IP SAFI used, receiver needs extra logic to 207 differentiate regular BGP MP-NLRI routes advertisement from the 208 SDWAN WAN port properties advertisement and recognize the extra Site 209 ID field added to the MP-NLRI. The benefit of using the same IP SAFI 210 is that the UPDATE can traverse existing routers without being 211 dropped. However, the SDWAN UPDATE is only between SDWAN edge and 212 the RR, all the intermediate nodes treat the UPDATE message as 213 regular IP data frame. 215 Alternatively, we can follow the same approach used by [idr-segment- 216 routing-te-policy] to have a unique SAFI (IANA assigned SDWAN SAFI = 217 74) mainly to differentiate the SDWAN UPDATE from regular route 218 UPDATE or SR policy UPDATE. 220 This SDWAN SAFI is for a scenario where one SDWAN edge node has 221 multiple WAN ports, some of which connected to private networks and 222 others connected to public untrusted networks [Scenario #2 described 223 in the [SDWAN-BGP-USAGE]]. The same routes attached to the SDWAN can 224 be reached by the private networks without encryption (for better 225 performance) or by the public networks with encryption. 227 2.3. How about a new Path Attribute under BGP UPDATE? 229 It is also possible to have a new Path Attribute, say SDWAN Path 230 Attribute, combined with Tunnel Path Attribute to advertise SDWAN 231 WAN Port properties. Besides having a different Path Attribute ID, 232 everything else is same as using MP-NLRI & Tunnel Path Attributes. 234 3. SDWAN WAN Port ID encoding in the MP-NLRI Path Attribute 236 SDWAN WAN Port Identifier can be encoded in the NLRI field within 237 the MP_REACH_NLRI Path Attribute of RFC4760, under a SDWAN SAFI 238 (code = 74): 240 +------------------+ 241 | NLRI Length | 1 octet 242 +------------------+ 243 | SDWAN-Type | 2 Octets 244 +------------------+ 245 |Port-Distinguisher| 4 octets 246 +------------------+ 247 | SDWAN-Site-ID | 4 octets 248 +------------------+ 249 | SDWAN-Node-ID | 4 or 16 octets 250 +------------------+ 252 where: 254 - NLRI Length: 1 octet of length expressed in bits as defined in 255 [RFC4760]. 256 - SDWAN-Type: to define the encoding of the rest of the SDWAN 257 NLRI. There could be different sub-TLVs for different SDWAN WAN 258 ports and their associated policies. 259 - Port Distinguisher: SDWAN edge node Port identifier, which can 260 be locally significant. Each port can have unique properties. 261 For example, some ports may get ISP or DHCP assigned IP 262 addresses (IPv4 or IPv6), some may have private IP addresses 263 that packets to/from those ports have to traverse NAT. 264 The detailed properties about the port are further encoded in 265 the subTLVs, e.g. Port-subTLV under the Tunnel Path Attribute. 267 - SDWAN-Site-ID: used to identify a common property shared by a 268 set of SDWAN edge nodes, such as the property of a specific 269 geographic location shared by a group of SDWAN edge nodes. The 270 property is used to steer an overlay route to traverse specific 271 geographic locations for various reasons, such as to comply 272 regulatory rules, to utilize specific value added services, or 273 others. 274 - SDWAN EdgeNode ID: the SDWAN edge node identifier, which can be 275 the node's system ID or the loopback address (IPv4 or IPv6) of 276 the SDWAN edge node. 278 4. WAN Port Properties encoding in the Tunnel Path Attribute 280 The content of the SDWAN Port properties is encoded in the Tunnel 281 Encapsulation Attribute defined in [Tunnel-Encap] using a new 282 Tunnel-Type TLV (code point to be assigned by IANA from the "BGP 283 Tunnel Encapsulation Attribute Tunnel Types" registry). 285 Tunnel Encaps Path Attribute (Code = 23) 287 Tunnel Type: SDWAN-WAN-Port 288 Followed by the detailed properties encoded as subTLV, such as 289 SubTLV for NAT 290 SubTLV for IPsec-SA Attribute 291 SubTLV for ISP connected to the WAN port 293 The Tunnel Encaps Attribute are defined as follows: 295 0 1 2 3 296 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Tunnel-Type(=SDWAN-WAN-Port )| Length (2 Octets) | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | | 301 | Value | 302 | | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 SDWAN Tunnel Encapsulation TLV Value Field 306 Where: 307 Tunnel Type is SDWAN-WAN-Port (to be assigned by IANA). 309 4.1. Port Ext SubTLV 311 Port Ext sub-TLV is for describing the NAT property if the port 312 has private address and the network identifier to which the WAN 313 port is connected, etc. 315 A SDWAN edge node can inquire STUN (Session Traversal of UDP 316 Through Network Address Translation RFC 3489) Server to get the 317 NAT property, the public IP address and the Public Port number to 318 pass to peers. 320 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 |Port Ext Type | EncapExt subTLV Length |I|O|R|R|R|R|R|R| 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | NAT Type | Encap-Type |Trans networkID| RD ID | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Local IP Address | 327 32-bits for IPv4, 128-bits for Ipv6 328 ~~~~~~~~~~~~ 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Local Port | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Public IP | 333 32-bits for IPv4, 128-bits for Ipv6 334 ~~~~~~~~~~~~ 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Public Port | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 Where: 341 o Port Ext Type: indicate it is the Port Ext SubTLV. 342 o PortExt subTLV Length: the length of the subTLV. 343 o Flags: 344 - I bit (CPE port address or Inner address scheme) 345 If set to 0, indicate the inner (private) address is IPv4. 346 If set to 1, it indicates the inner address is IPv6. 348 - O bit (Outer address scheme): 349 If set to 0, indicate the public (outer) address is IPv4. 350 If set to 1, it indicates the public (outer) address is 351 IPv6. 353 - R bits: reserved for future use. Must be set to 0 now. 355 o NAT Type.without NAT; 1:1 static NAT; Full Cone; Restricted 356 Cone; Port Restricted Cone; Symmetric; or Unknown (i.e. no 357 response from the STUN server). 359 o Encap Type.the supported encapsulation types for the port 360 facing public network, such as IPsec+GRE, IPsec+VxLAN, IPsec 361 without GRE, GRE (when packets don't need encryption) 362 o Transport Network ID.Central Controller assign a global unique 363 ID to each transport network. 364 o RD ID.Routing Domain ID.Need to be global unique. 365 o Local IP.The local (or private) IP address of the port. 366 o Local Port.used by Remote SDWAN edge node for establishing 367 IPsec to this specific port. 368 o Public IP.The IP address after the NAT. If NAT is not used, 369 this field is set to NULL. 370 o Public Port.The Port after the NAT. If NAT is not used, this 371 field is set to NULL. 373 4.2. IPsec Security Association Property 375 The IPsecSA sub-TLV is for the SDWAN edge node to establish IPsec 376 security association with their peers via the port that face 377 untrusted network: 379 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 |IPsec-SA Type |IPsecSA Length | Flag | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Transform | Transport | AH | ESP | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | SPI | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | key1 length | key1 | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | key2 length | key2 | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | key3 length | key3 | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Duration | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 Where: 398 o IPsec-SA SubTLV Type: to be assigned by IANA. The type value 399 has to be between 128~255 because IPsec-SA subTLV needs 2 bytes 400 for length to carry the needed information. 401 o IPsec-SA subTLV Length (2 Byte): 25 (or more) 402 o Flags: 1 octet of flags. None are defined at this stage. Flags 403 SHOULD be set to zero on transmission and MUST be ignored on 404 receipt. 405 o Transform (1 Byte): the value can be AH, ESP, or AH+ESP. 406 o Transport (1 byte): the value can be Tunnel Mode or Transport 407 mode 408 o AH (1 byte): AH authentication algorithms supported, which can 409 be md5 | sha1 | sha2-256 | sha2-384 | sha2-512 | sm3. Each 410 SDWAN edge node can have multiple authentication algorithms; 411 send to its peers to negotiate the strongest one. 412 o ESP (1 byte): ESP authentication algorithms supported, which 413 can be md5 | sha1 | sha2-256 | sha2-384 | sha2-512 | sm3. Each 414 SDWAN edge node can have multiple authentication algorithms; 415 send to its peers to negotiate the strongest one. Default 416 algorithm is AES-256. 417 o SPI: 4 bytes 418 o Key1.AH authentication key 419 o Key2.ESP authentication key 420 o Key3.ESP encryption "public" key 421 o Duration: SA life span. 423 4.3. Remote Endpoint 425 The Remote Endpoint sub-TLV is not used for SDWAN NLRI because 426 o The SDWAN Node ID and Site ID are already encoded in the SDWAN 427 NLRI, 428 o The network connected by the SDWAN WAN port might have 429 identifier that is more than the AS number. SDWAN controller 430 might use its own specific identifier for the network. 431 o The Transport-Network-ID in the EncapExt sub-TLV represents the 432 SDWAN unique network identifier. 434 If the Remote Endpoint Sub-TLV is present, it is ignored by other 435 SDWAN edge nodes. 437 5. Manageability Considerations 439 TBD - this needs to be filled out before publishing 441 6. Security Considerations 443 The document describes the encoding for SDWAN edge nodes to 444 advertise its SDWAN WAN ports properties to their peers via 445 untrusted & unsecure networks. 447 The secure propagation is achieved by secure channels, such as 448 TLS, SSL, or IPsec, between the SDWAN edge nodes and the local 449 controller RR. 451 [More details need to be filled in here] 453 7. IANA Considerations 455 This document requires the following IANA actions. 457 o SDWAN Overlay SAFI = 74 assigned by IANA 458 o SDWAN Route Type 460 8. References 462 8.1. Normative References 464 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 465 Requirement Levels", BCP 14, RFC 2119, March 1997. 466 8.2. Informative References 468 [RFC8192] S. Hares, et al, "Interface to Network Security Functions 469 (I2NSF) Problem Statement and Use Cases", July 2017 471 [RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation Subsequent 472 Address Family Identifier (SAFI) and the BGP Tunnel 473 Encapsulation Attribute", April 2009. 475 [Tunnel-Encap]E. Rosen, et al, "The BGP Tunnel Encapsulation 476 Attribute", draft-ietf-idr-tunnel-encaps-09, Feb 2018. 478 [VPN-over-Internet] E. Rosen, "Provide Secure Layer L3VPNs over 479 Public Infrastructure", draft-rosen-bess-secure-l3vpn-00, 480 work-in-progress, July 2018 482 [DMVPN] Dynamic Multi-point VPN: 483 https://www.cisco.com/c/en/us/products/security/dynamic- 484 multipoint-vpn-dmvpn/index.html 486 [DSVPN] Dynamic Smart VPN: 487 http://forum.huawei.com/enterprise/en/thread-390771-1- 488 1.html 490 [ITU-T-X1036] ITU-T Recommendation X.1036, "Framework for creation, 491 storage, distribution and enforcement of policies for 492 network security", Nov 2007. 494 [Net2Cloud-Problem] L. Dunbar and A. Malis, "Seamless Interconnect 495 Underlay to Cloud Overlay Problem Statement", draft-dm- 496 net2cloud-problem-statement-02, June 2018 498 [Net2Cloud-gap] L. Dunbar, A. Malis, and C. Jacquenet, "Gap Analysis 499 of Interconnecting Underlay with Cloud Overlay", draft-dm- 500 net2cloud-gap-analysis-02, work-in-progress, Aug 2018. 502 [Tunnel-Encap] E. Rosen, et al "The BGP Tunnel Encapsulation 503 Attribute", draft-ietf-idr-tunnel-encaps-10, Aug 2018. 505 9. Acknowledgments 507 Acknowledgements to Wang Haibo, Hao Weiguo, and ShengCheng for 508 implementation contribution; Many thanks to Jim Guichard, John 509 Scudder, Darren Dukes, Andy Malis, Rachel Huang and Donald Eastlake 510 for their review and contributions. 512 This document was prepared using 2-Word-v2.0.template.dot. 514 Authors' Addresses 516 Linda Dunbar 517 Futurewei 518 Email: ldunbar@futurewei.com 520 Sue Hares 521 Hickory Hill Consulting 522 Email: shares@ndzh.com