idnits 2.17.1 draft-dunbar-idr-sdwan-port-safi-03.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 : ---------------------------------------------------------------------------- No issues found here. 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 (June 27, 2019) is 1764 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'SDWAN-BGP-USAGE' is mentioned on line 117, but not defined == Missing Reference: 'RFC4760' is mentioned on line 218, but not defined == Unused Reference: 'RFC2119' is defined on line 475, but no explicit reference was found in the text == Unused Reference: 'RFC8192' is defined on line 479, but no explicit reference was found in the text == Unused Reference: 'RFC5521' is defined on line 482, but no explicit reference was found in the text == Unused Reference: 'VPN-over-Internet' is defined on line 489, but no explicit reference was found in the text == Unused Reference: 'DMVPN' is defined on line 493, but no explicit reference was found in the text == Unused Reference: 'DSVPN' is defined on line 497, but no explicit reference was found in the text == Unused Reference: 'ITU-T-X1036' is defined on line 501, but no explicit reference was found in the text == Unused Reference: 'Net2Cloud-gap' is defined on line 509, 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: 0 errors (**), 0 flaws (~~), 16 warnings (==), 1 comment (--). 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: Experimental S. Hares 4 Expires: December 27, 2019 Hickory Hill Consulting 6 June 27, 2019 8 Subsequent Address Family Indicator for SDWAN Ports 9 draft-dunbar-idr-sdwan-port-safi-03 11 Abstract 13 The document specifies a new BGP NLRI and SAFI for advertising WAN 14 ports properties of a SDWAN edge node. SDWAN edge node's WAN ports 15 may face untrusted networks, such as the public internet, may get 16 assigned IP addresses from the Internet Service Providers (ISPs), 17 may get assigned dynamic IP addresses via DHCP, or may have private 18 addresses (e.g. inside third party Cloud DCs). Packets forwarded 19 through those SDWAN WAN ports might need to be encrypted (depending 20 on the user policies) or need to go through NAT. SDWAN edge nodes 21 need to propagate those WAN ports properties to the peers who are 22 authorized to communicate across different types of underlay 23 networks including the untrusted networks. 25 BGP Route Reflectors (RR) are proposed as the entities to propagate 26 the WAN ports properties of SDWAN edge nodes to a controlled group 27 of edges reachable via overlay networks. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six 40 months and may be updated, replaced, or obsoleted by other documents 41 at any time. It is inappropriate to use Internet-Drafts as 42 reference material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 50 This Internet-Draft will expire on December 27, 2019. 52 Copyright Notice 54 Copyright (c) 2019 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with 62 respect to this document. Code Components extracted from this 63 document must include Simplified BSD License text as described in 64 Section 4.e of the Trust Legal Provisions and are provided without 65 warranty as described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction...................................................3 70 2. Conventions used in this document..............................5 71 3. SDWAN NLRI Format..............................................5 72 3.1. SDWAN Route Type..........................................8 73 3.2. Port Distinguisher........................................8 74 3.3. SDWAN Site ID.............................................8 75 3.4. Extended Port Property....................................8 76 3.5. IPsec Security Association Property......................10 77 3.6. Remote Endpoint..........................................11 78 4. Manageability Considerations..................................12 79 5. Security Considerations.......................................12 80 6. IANA Considerations...........................................12 81 7. References....................................................13 82 7.1. Normative References.....................................13 83 7.2. Informative References...................................13 84 8. Acknowledgments...............................................14 86 1. Introduction 88 [Net2Cloud-Problem] introduces using SDWAN to reach dynamic 89 workloads in multiple third-party data centers and aggregate 90 multiple underlay paths, including public untrusted networks, 91 provided by different service providers. 93 [SDWAN-BGP-USAGE] describes multiple SDWAN scenarios and how/why 94 using BGP as control plane for the SDWAN networks. 96 [Tunnel-Encap] describes how to construct a BGP UPDATE messages that 97 advertise endpoints' tunnel encapsulation capabilities and the 98 respective attached client routes, so that the receivers of the BGP 99 UPDATE can establish appropriate tunnels to the endpoints for the 100 aforementioined client routes. [Tunnel-Encap] has a "Remote endpoint 101 subTLV" for one node to advertise another node's encapsulation 102 capabilities. The receivers of the Tunnel UPDATE would construct the 103 encapsulation header with the Outer Destination Address equal to the 104 address carried in the "Remote Endpoint sub-TLV". All those have 105 nothing to do with the SDWAN Edge WAN ports properties registration. 107 This document describes a new BGP NLRI and SAFI for SDWAN edge nodes 108 to register (or propagate) their WAN ports properties. This new SAFI 109 & NLRI is for a scenario where one SDWAN edge node has multiple WAN 110 ports, some of which connected to private networks and others 111 connected to public untrusted networks [Scenario #2 described in the 112 [SDWAN-BGP-USAGE]]. The same routes attached to the SDWAN can be 113 sent/received over the private networks without encryption (for 114 better performance) and sent/received over the public networks with 115 encryption. 117 The [SDWAN-BGP-USAGE] document describes the following functional 118 components of the control plane for the scenario (i.e. the SDWAN 119 Scenario #2): 121 . Each Edge SDWAN edge node is informed of its SDWAN controller, 122 either burned in the node or configured, which is the BGP RR in 123 this document. 124 . Each SDWAN edge node needs to advertise its WAN ports properties 125 via the secure channel with the RR. RR then propagates the 126 received WAN ports properties to the authorized peers based on 127 appropriate policies. Because the connection among SDWAN edges 128 and the RR can be public untrusted networks, the communication 129 session between RR and SDWAN edges MUST run over a secure 130 channel (e.g. TLS, DTLS, or others). 132 . SDWAN edges pairwise secure channel establishment, such as IPsec 133 parameters negotiation, public key exchange, etc, and 135 . Client routes distribution, just like EVPN or L3VPN using 136 [Tunnel-Encap] to advertise all possible tunnels for clients 137 routes. 139 The new SDWAN NLRI and SAFI can also include information such as WAN 140 port's NAT information, SDWAN-SITE-ID, SDWAN EdgeNode-ID, and IPsec 141 related information. 143 Centralized----------------------------------------------- 144 controller | 145 | | 146 | +---+ | 147 | Peer Group 1 |RR | Peer Group 2 | 148 | +======+====+=+ +======+====+=====+ | 149 | / / | +---+ | \ \ | 150 | / / | | | \ | 151 | +-+-+ +-+--+ +-+-+ +-+-+ +-+-+ +-+-+ | 152 | |CPE| | CPE|--|CPE| |CPE| |CPE| |CPE| | 153 ---| 1 | | 2 | | 3 | |4 | | 5 | | 6 |----| 154 +---+ +----+ +---+ +---+ +---+ +---+ 155 Tenant 1 Tenant 2 157 Figure 1: SDWAN WAN Port Properties Advertisement via RR 159 Note: All CPEs (CPE1, CPE2, CPE, CPE4, CPE5, and CPE) connect to the 160 centralized controller, but only 2 connections are show in this 161 diagram. 163 2. Conventions used in this document 165 Cloud DC: Off-Premise Data Centers that usually host applications 166 and workload owned by different organizations or 167 tenants. 169 Controller: Used interchangeably with SDWAN controller to manage 170 SDWAN overlay path creation/deletion and monitor the 171 path conditions between sites. 173 CPE-Based VPN: Virtual Private Secure network formed among CPEs. 174 This is to differentiate from most commonly used PE- 175 based VPNs a la RFC 4364. 177 SDWAN End-point: An WAN port (logical or physical) of a SDWAN edge 178 node. (If "endpoint" is used, it refers to a SDWAN End- 179 point). 181 OnPrem: On Premises data centers and branch offices 183 SDWAN: Software Defined Wide Area Network. In this document, 184 "SDWAN" refers to the solutions of pooling WAN bandwidth 185 from multiple underlay networks to get better WAN 186 bandwidth management, visibility & control. When the 187 underlay networks are private networks, traffic can be 188 forwarded without additional encryption; when the 189 underlay networks are public, such as Internet, some 190 traffic needs to be encrypted when forwarding through 191 those WAN ports(depending on user provided policies). 193 3. SDWAN NLRI Format 195 The new SAFI code point 74 has been assigned by IANA as the 196 Subsequent Address Family Identifier for advertising properties of 197 WAN ports that face untrusted networks. Depending on user policies, 198 some packets sent through those WAN ports will need encryption. 200 The SDWAN SAFI (code point 74 assigned by IANA) uses a new NLRI 201 defined as follows: 203 +------------------+ 204 | NLRI Length | 1 octet 205 +------------------+ 206 | SDWAN-Type | 2 Octets 207 +------------------+ 208 |Port-Distinguisher| 4 octets 209 +------------------+ 210 | SDWAN-Site-ID | 4 octets 211 +------------------+ 212 | SDWAN-Node-ID | 4 or 16 octets 213 +------------------+ 215 where: 217 - NLRI Length: 1 octet of length expressed in bits as defined in 218 [RFC4760]. 219 - SDWAN-Type: to define the encoding of the rest of the SDWAN 220 NLRI. 221 - Port Distinguisher: SDWAN edge node Port identifier. There can 222 be many ports on a SDWAN edge node; each port can have different 223 properties. For example, some ports may get ISP or DHCP assigned 224 IP addresses (IPv4 or IPv6), some may have private IP addresses 225 that packets to/from those ports have to traverse NAT. 226 The detailed properties about the port are further encoded in 227 the subsequent subTLVs, e.g. Port-subTLV. 229 - SDWAN-Site-ID: used to identify a common property shared by a 230 set of SDWAN edge nodes, such as the property of a specific 231 geographic location shared by a group of SDWAN edge nodes. 232 - SDWAN EdgeNode ID: the SDWAN edge node identifier, which can be 233 the node's system ID or the loopback address (IPv4 or IPv6) of 234 the SDWAN edge node. 236 The content of the SDWAN Port properties is encoded in the Tunnel 237 Encapsulation Attribute originally defined in [Tunnel-Encap] using a 238 new Tunnel-Type TLV (code point to be assigned by IANA from the "BGP 239 Tunnel Encapsulation Attribute Tunnel Types" registry). 241 SDWAN SAFI (=74) NLRI: < SDWAN-Type, Length, Port-distinguisher, 242 SDWAN-Site-ID, SDWAN-Node-ID> 243 Attributes: 244 Tunnel Encaps Attribute 245 Tunnel Type: SDWAN Port Property 246 NAT SubTLV 247 IPsec-SA Attribute SubTLV 248 Port-subTLV 250 Where 251 - NAT SubTLV is for describing additional information about the 252 SDWAN tunnel end-points, such as NAT property. 253 - IPsec-SA SubTLV is for the node to establish IPsec SA with 254 other peers. 255 - Port-subTLV is for additional properties of the WAN port. 257 The Tunnel Encaps Attribute are defined as follows: 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Tunnel-Type(2 Octets) | Length (2 Octets) | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | | 265 | Value | 266 | | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 Figure 1: SDWAN Tunnel Encapsulation TLV Value Field 270 Where: 271 Tunnel Type is SDWAN Port Property (to be assigned by IANA). 273 3.1. SDWAN Route Type 275 A new Route Type that defines the encoding of the rest of the SDWAN 276 NLRI, and a set of sub-TLVs to specify its end-point attributes, 277 policies associated with the Ports: 279 3.2. Port Distinguisher 281 One (SDWAN Edge) node can have multiple ports, and each port can 282 support multiple IPsec SA to different peers. The Port Distinguisher 283 is to uniquely identify a port (or link). 285 The property of the port are encoded in the subTLV attached to the 286 SDWAN NLRI: 288 a) The IP address (IPv4 or IPv6) & AS number of the Port 289 b) NAT information for ports with Private IP address 290 c) IPsec Security Association related information if the port is 291 facing public network and traffic through which have to be 292 encrypted. 293 Detailed encoding for those properties is described in Section 3.4 & 294 Section 3.5 respectively. 296 3.3. SDWAN Site ID 298 SDWAN Site ID is used to identify a common property shared by a set 299 of SDWAN edge nodes/ports, such as the property of a specific 300 geographic location. The property is used to steer an overlay route 301 to traverse specific geographic locations for various reasons, such 302 as to comply regulatory rules, to utilize specific value added 303 services, or others. 305 3.4. Extended Port Property 307 EncapExt sub-TLV is for describing additional information about a 308 SDWAN port, such as the NAT property if the port has private 309 address, the network identifier that the port is part of, etc. 311 A SDWAN edge node can inquire STUN (Session Traversal of UDP Through 312 Network Address Translation RFC 3489) Server to get the NAT 313 property, the public IP address and the Public Port number to pass 314 to peers. 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 |EncapExt Type | EncapExt subTLV Length |I|O|R|R|R|R|R|R| 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | NAT Type | Encap-Type |Trans networkID| RD ID | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Local IP Address | 323 32-bits for IPv4, 128-bits for Ipv6 324 ~~~~~~~~~~~~ 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Local Port | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Public IP | 329 32-bits for IPv4, 128-bits for Ipv6 330 ~~~~~~~~~~~~ 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Public Port | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 Where: 337 o EncapExt Type: indicate it is the EncapExt SubTLV. 338 o EncapExt subTLV Length: the length of the subTLVE. 339 o Flags: 340 - I bit (CPE port address or Inner address scheme) 341 If set to 0, indicate the inner (private) address is IPv4. 342 If set to 1, it indicates the inner address is IPv6. 344 - O bit (Outer address scheme): 345 If set to 0, indicate the public (outer) address is IPv4. 346 If set to 1, it indicates the public (outer) address is 347 IPv6. 349 - R bits: reserved for future use. Must be set to 0 now. 351 o NAT Type.without NAT; 1:1 static NAT; Full Cone; Restricted 352 Cone; Port Restricted Cone; Symmetric; or Unknown (i.e. no 353 response from the STUN server). 355 o Encap Type.the supported encapsulation types for the port 356 facing public network, such as IPsec+GRE, IPsec+VxLAN, IPsec 357 without GRE, GRE (when packets don't need encryption) 358 o Transport Network ID.Central Controller assign a global unique 359 ID to each transport network. 360 o RD ID.Routing Domain ID.Need to be global unique. 361 o Local IP.The local (or private) IP address of the port. 362 o Local Port.used by Remote SDWAN edge node for establishing 363 IPsec to this specific port. 364 o Public IP.The IP address after the NAT. If NAT is not used, 365 this field is set to NULL. 366 o Public Port.The Port after the NAT. If NAT is not used, this 367 field is set to NULL. 369 3.5. IPsec Security Association Property 371 The IPsecSA sub-TLV is for the SDWAN edge node to establish IPsec 372 security association with their peers via the port that face 373 untrusted network: 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 |IPsec-SA Type |IPsecSA Length | Flag | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Transform | Transport | AH | ESP | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | SPI | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | key1 length | key1 | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | key2 length | key2 | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | key3 length | key3 | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Duration | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Where: 394 o IPsec-SA SubTLV Type: to be assigned by IANA. The type value 395 has to be between 128~255 because IPsec-SA subTLV needs 2 bytes 396 for length to carry the needed information. 397 o IPsec-SA subTLV Length (2 Byte): 25 (or more) 398 o Flags: 1 octet of flags. None are defined at this stage. Flags 399 SHOULD be set to zero on transmission and MUST be ignored on 400 receipt. 401 o Transform (1 Byte): the value can be AH, ESP, or AH+ESP. 402 o Transport (1 byte): the value can be Tunnel Mode or Transport 403 mode 404 o AH (1 byte): AH authentication algorithms supported, which can 405 be md5 | sha1 | sha2-256 | sha2-384 | sha2-512 | sm3. Each 406 SDWAN edge node can have multiple authentication algorithms; 407 send to its peers to negotiate the strongest one. 408 o ESP (1 byte): ESP authentication algorithms supported, which 409 can 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. Default 412 algorithm is AES-256. 413 o SPI: 4 bytes 414 o Key1.AH authentication key 415 o Key2.ESP authentication key 416 o Key3.ESP encryption "public" key 417 o Duration: SA life span. 419 3.6. Remote Endpoint 421 The Remote Endpoint sub-TLV is not used for SDWAN NLRI because 422 o The SDWAN EdgeNode ID and Site ID are already encoded in the 423 SDWAN NLRI, 424 o The network connected by the SDWAN WAN port might have 425 identifier that is more than the AS number. SDWAN controller 426 might use its own specific identifier for the network. 427 o The Transport-Network-ID in the EncapExt sub-TLV represents the 428 SDWAN unique network identifier. 430 If the Remote Endpoint Sub-TLV is present, it is ignored by other 431 SDWAN edge nodes. 433 4. Operation of SDWAN Edge Node: 435 Using Figure 1 as illustration, the processing steps to announce the 436 SDWAN combination of routes, NAT and IPsec information via BGP are: 438 1) Advertise the SDWAN port properties, such as Port identifiers 439 and supported properties etc. to RR via the SDWAN SAFI NLRI. 441 2) RR propagate the information to CPE2 & CPE 3. 442 3) CPE2 and CPE3 can choose to establish IPsec SA with the CPE1 443 after receiving the CPE1 WAN properties from RR. 445 Note: Tenant separation is achieved by peer group policies on the 446 RR. 448 4. Manageability Considerations 450 TBD - this needs to be filled out before publishing 452 5. Security Considerations 454 The document describes the encoding for SDWAN edge nodes to 455 advertise its SDWAN WAN ports properties to their peers via 456 untrusted & unsecure networks. 458 The secure propagation is achieved by secure channels, such as 459 TLS, SSL, or IPsec, between the SDWAN edge nodes and the local 460 controller RR. 462 [More details need to be filled in here] 464 6. IANA Considerations 466 This document requires the following IANA actions. 468 o SDWAN Overlay SAFI = 74 assigned by IANA 469 o SDWAN Route Type 471 7. References 473 7.1. Normative References 475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 476 Requirement Levels", BCP 14, RFC 2119, March 1997. 477 7.2. Informative References 479 [RFC8192] S. Hares, et al, "Interface to Network Security Functions 480 (I2NSF) Problem Statement and Use Cases", July 2017 482 [RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation Subsequent 483 Address Family Identifier (SAFI) and the BGP Tunnel 484 Encapsulation Attribute", April 2009. 486 [Tunnel-Encap]E. Rosen, et al, "The BGP Tunnel Encapsulation 487 Attribute", draft-ietf-idr-tunnel-encaps-09, Feb 2018. 489 [VPN-over-Internet] E. Rosen, "Provide Secure Layer L3VPNs over 490 Public Infrastructure", draft-rosen-bess-secure-l3vpn-00, 491 work-in-progress, July 2018 493 [DMVPN] Dynamic Multi-point VPN: 494 https://www.cisco.com/c/en/us/products/security/dynamic- 495 multipoint-vpn-dmvpn/index.html 497 [DSVPN] Dynamic Smart VPN: 498 http://forum.huawei.com/enterprise/en/thread-390771-1- 499 1.html 501 [ITU-T-X1036] ITU-T Recommendation X.1036, "Framework for creation, 502 storage, distribution and enforcement of policies for 503 network security", Nov 2007. 505 [Net2Cloud-Problem] L. Dunbar and A. Malis, "Seamless Interconnect 506 Underlay to Cloud Overlay Problem Statement", draft-dm- 507 net2cloud-problem-statement-02, June 2018 509 [Net2Cloud-gap] L. Dunbar, A. Malis, and C. Jacquenet, "Gap Analysis 510 of Interconnecting Underlay with Cloud Overlay", draft-dm- 511 net2cloud-gap-analysis-02, work-in-progress, Aug 2018. 513 [Tunnel-Encap] E. Rosen, et al "The BGP Tunnel Encapsulation 514 Attribute", draft-ietf-idr-tunnel-encaps-10, Aug 2018. 516 8. Acknowledgments 518 Acknowledgements to Wang Haibo, Hao Weiguo, and ShengCheng for 519 implementation contribution; Many thanks to Jim Guichard, John 520 Scudder, Darren Dukes, Andy Malis, Rachel Huang and Donald Eastlake 521 for their review and contributions. 523 This document was prepared using 2-Word-v2.0.template.dot. 525 Authors' Addresses 527 Linda Dunbar 528 Futurewei 529 Email: ldunbar@futurewei.com 531 Sue Hares 532 Hickory Hill Consulting 533 Email: shares@ndzh.com