idnits 2.17.1 draft-dunbar-idr-sdwan-port-safi-06.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 (November 21, 2019) is 1618 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'SDWAN-BGP-USAGE' is mentioned on line 87, but not defined == Missing Reference: 'RFC4760' is mentioned on line 257, but not defined == Unused Reference: 'RFC2119' is defined on line 467, but no explicit reference was found in the text == Unused Reference: 'RFC8192' is defined on line 472, but no explicit reference was found in the text == Unused Reference: 'RFC5521' is defined on line 475, but no explicit reference was found in the text == Unused Reference: 'VPN-over-Internet' is defined on line 486, but no explicit reference was found in the text == Unused Reference: 'DMVPN' is defined on line 490, but no explicit reference was found in the text == Unused Reference: 'DSVPN' is defined on line 494, but no explicit reference was found in the text == Unused Reference: 'ITU-T-X1036' is defined on line 498, but no explicit reference was found in the text == Unused Reference: 'Net2Cloud-gap' is defined on line 506, 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: Informational S. Hares 4 Expires: May 21, 2020 Hickory Hill 5 Consulting 7 November 21, 2019 9 SDWAN WAN Ports Property Advertisement in BGP UPDATE 10 draft-dunbar-idr-sdwan-port-safi-06 12 Abstract 14 The document describes how the SDWAN SAFI, which is assigned by IANA 15 in the First Come First Server range, is used for SDWAN edge nodes 16 to propagate its WAN port properties to its controller. 18 In the context of this document, BGP Route Reflectors (RR) is the 19 component of the SDWAN Controller that receives the BGP UPDATE from 20 SDWAN edges and in turns propagate the information to a group of 21 authorized SDWAN edges reachable via overlay networks. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other documents 35 at any time. It is inappropriate to use Internet-Drafts as 36 reference material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on Dec 5, 2020. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with 55 respect to this document. Code Components extracted from this 56 document must include Simplified BSD License text as described in 57 Section 4.e of the Trust Legal Provisions and are provided without 58 warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction...................................................3 63 2. Conventions used in this document..............................3 64 2.1. Information to be propagated for SDWAN UPDATE.............4 65 2.2. SAFI under the MP-NLRI....................................6 66 2.3. How about a new Path Attribute under BGP UPDATE?..........6 67 3. SDWAN WAN Port Identifer encoding in the MP-NLRI Path Attribute6 68 4. WAN Port Properties encoding in the Tunnel Path Attribute......8 69 4.1. Port Ext SubTLV for NAT...................................9 70 4.2. IPsec Security Association Property......................10 71 4.3. Remote Endpoint..........................................11 72 5. Manageability Considerations..................................12 73 6. Security Considerations.......................................12 74 7. IANA Considerations...........................................12 75 8. References....................................................12 76 8.1. Normative References.....................................12 77 8.2. Informative References...................................13 78 9. Acknowledgments...............................................14 80 1. Introduction 82 [Net2Cloud-Problem] introduces using SDWAN to reach dynamic 83 workloads in multiple third-party data centers and aggregate 84 multiple underlay paths, including public untrusted networks, 85 provided by different service providers. 87 [SDWAN-BGP-USAGE] describes multiple SDWAN scenarios and illustrates 88 how BGP is used as control plane for the SDWAN networks. 90 The document describes BGP UPDATE for SDWAN edge nodes to propagate 91 its WAN port properties to RR. 93 2. Conventions used in this document 95 Cloud DC: Off-Premise Data Centers that usually host applications 96 and workload owned by different organizations or 97 tenants. 99 Controller: Used interchangeably with SDWAN controller to manage 100 SDWAN overlay path creation/deletion and monitor the 101 path conditions between sites. 103 CPE-Based VPN: Virtual Private Secure network formed among CPEs. 104 This is to differentiate from most commonly used PE- 105 based VPNs a la RFC 4364. 107 MP-NLRI: The MP_REACH_NLRI Path Attribute defined in RFC4760. 109 SDWAN End-point: An WAN port (logical or physical) of a SDWAN edge 110 node. (If "endpoint" is used, it refers to a SDWAN End- 111 point). 113 OnPrem: On Premises data centers and branch offices 115 SDWAN: Software Defined Wide Area Network. In this document, 116 "SDWAN" refers to the solutions of pooling WAN bandwidth 117 from multiple underlay networks to get better WAN 118 bandwidth management, visibility & control. When the 119 underlay networks are private networks, traffic can be 120 forwarded without additional encryption; when the 121 underlay networks are public, such as Internet, some 122 traffic needs to be encrypted when forwarding through 123 those WAN ports (depending on user provided policies). 125 2.1. Information to be propagated for SDWAN UPDATE 127 Figure below shows the Hybrid SDWAN scenario: 129 +---+ 130 +--------------|RR |----------+ 131 / Untrusted +-+-+ \ 132 / \ 133 / \ 134 +----+ +---------+ packets encrypted over +------+ +----+ 135 | CN3|--| A1-----+ Untrusted +------ B1 |--| CN1| 136 +----+ | C-PE A2-\ | C-PE | +----+ 137 +----+ | 1 A3--+--+ +---+---B2 2 | +----+ 138 | CN2|--| | |PE+--------------+PE |---B3 |--| CN3| 139 +----+ +---------+ +--+ trusted +---+ +------+ +----+ 140 | WAN | 141 +----+ +---------+ +--+ packets +---+ +------+ +----+ 142 | CN1|--| C1--|PE| go natively |PE |-- D1 |--| CN1| 143 +----+ | C-PE C2--+--+ without encry+---+ | C-PE | +----+ 144 | 3 | +--------------+ | 4 | 145 | | | | 146 +----+ | | without encrypt over | | +----+ 147 | CN2|--| C3--+---- Untrusted --+------D2 |--| CN2| 148 +----+ +---------+ +------+ +----+ 150 CN: Client Network 151 Figure 1: Hybrid SDWAN 153 Using C-PE2 for illustration, C-PE2 needs to send out two separate 154 BGP UPDATE messages. 156 BGP UPDATE #1 is to propagate C-PE2 attached routes, which are the 157 regular VPN (L3VPN or EVPN) BGP Route UPDATE message, 159 MP-NLRI Path Attribute 160 Nexthop (C-PE2) 161 NLRI 162 10.1.x.x. 163 VLAN 15 164 12.1.1x 165 Tunnel-Encap Path Attribute 166 Details of any tunnels that applicable to the routes carried 167 by the MP-NLRI Path Attribute 169 BGP UPDATE #2 is to propagate C-PE2's WAN port properties to RR, 170 which should include: 172 - Identifier for the WAN Port 173 - The NAT property for the WAN Port 174 - The minimum IPsec information for establishing Port based 175 IPsec. 177 Separating WAN port properties UPDATE from client routes UPDATE 178 makes the implementation simpler, because the properties of a SDWAN 179 node's WAN Port can change independent from the client routes 180 attached to the C-PE2. WAN port properties change can be caused by 181 many factors, such as ISP service agreement changes for the service 182 connected to the WAN Port, the WAN port being disabled, or its IPsec 183 property changes, etc. Since most SDWAN edges only have a small 184 number of WAN ports, the disadvantage of multiple BGP UPDATE 185 messages to advertise properties of those WAN ports is relatively 186 small. 188 Following the same approach used by [idr-segment-routing-te-policy] 189 where the SR Policy identifier is encoded in the MP-NLRI Path 190 Attribute and the detailed SR Polices are encoded in the Tunnel Path 191 attribute, the BGP UPDATE for SDWAN WAN port can have the WAN Port 192 identifier encoded in the MP-NLRI Path Attribute and the associated 193 WAN Port properties encoded in the Tunnel Path Attribute. 195 Receivers of the UPDATE can associate the SDWAN node identifier, 196 site identifier with the node's WAN Port properties. 198 2.2. SAFI under the MP-NLRI 200 It is possible to continue using the same IP SAFI in the MP-NLRI 201 [RFC4760] Path Attribute for advertising the SDWAN WAN port 202 properties. If the same IP SAFI used, receiver needs extra logic to 203 differentiate regular BGP MP-NLRI routes advertisement from the 204 SDWAN WAN port properties advertisement and recognize the extra Site 205 ID field added to the MP-NLRI. The benefit of using the same IP SAFI 206 is that the UPDATE can traverse existing routers without being 207 dropped. However, the SDWAN UPDATE is only between SDWAN edge and 208 the RR, all the intermediate nodes treat the UPDATE message as 209 regular IP data frame. 211 That is why it is simpler to follow the same approach used by [idr- 212 segment-routing-te-policy] to have a unique SAFI (IANA assigned 213 SDWAN SAFI = 74) mainly to differentiate the SDWAN UPDATE from 214 regular route UPDATE. 216 This SDWAN SAFI is for a scenario where one SDWAN edge node has 217 multiple WAN ports, some of which connected to private networks and 218 others connected to public untrusted networks [Scenario #2 described 219 in the [SDWAN-BGP-USAGE]]. The same routes attached to the SDWAN can 220 be reached by the private networks without encryption (for better 221 performance) or by the public networks with encryption. 223 2.3. How about a new Path Attribute under BGP UPDATE? 225 It is also possible to have a new Path Attribute, say SDWAN Path 226 Attribute, combined with Tunnel Path Attribute to advertise SDWAN 227 WAN Port properties. Besides having a different Path Attribute ID, 228 everything else is same as using MP-NLRI & Tunnel Path Attributes. 230 3. SDWAN WAN Port Identifer encoding in the MP-NLRI Path Attribute 232 SDWAN WAN Port Identifier needs the following attributes 234 - locally significant port number, 235 - the location of the SDWAN device, and 236 - the globally routable address for the WAN Port. 238 Here is the encoding for those attributes in the NLRI field within 239 the MP_REACH_NLRI Path Attribute of RFC4760, under a SDWAN SAFI 240 (code = 74): 242 +------------------+ 243 | NLRI Length | 1 octet 244 +------------------+ 245 | SDWAN-Type | 2 Octets 246 +------------------+ 247 | Port-Local-ID | 4 octets 248 +------------------+ 249 | SDWAN-Site-ID | 4 octets 250 +------------------+ 251 | SDWAN-Node-ID | 4 or 16 octets 252 +------------------+ 254 where: 256 - NLRI Length: 1 octet of length expressed in bits as defined in 257 [RFC4760]. 258 - SDWAN-Type: to define the encoding of the rest of the SDWAN 259 NLRI. There could be different sub-TLVs for different SDWAN WAN 260 ports and their associated policies. 261 - Port local ID: SDWAN edge node Port identifier, which can be 262 locally significant. Each port can have unique properties. For 263 example, some ports may get ISP or DHCP assigned IP addresses 264 (IPv4 or IPv6), some may have private IP addresses that packets 265 to/from those ports have to traverse NAT. 266 The detailed properties about the port are further encoded in 267 the subTLVs, e.g. Port-subTLV under the Tunnel Path Attribute. 269 - SDWAN-Site-ID: used to identify a common property shared by a 270 set of SDWAN edge nodes, such as the property of a specific 271 geographic location shared by a group of SDWAN edge nodes. The 272 property is used to steer an overlay route to traverse specific 273 geographic locations for various reasons, such as to comply 274 regulatory rules, to utilize specific value added services, or 275 others. 276 - SDWAN EdgeNode ID: the SDWAN edge node identifier, which has to 277 be a routable address (IPv4 or IPv6) within the WAN. 279 4. WAN Port Properties encoding in the Tunnel Path Attribute 281 The content of the SDWAN Port properties is encoded in the Tunnel 282 Encapsulation Attribute defined in [Tunnel-Encap] using a new 283 Tunnel-Type TLV (code point to be assigned by IANA from the "BGP 284 Tunnel Encapsulation Attribute Tunnel Types" registry). 286 Tunnel Encaps Path Attribute (Code = 23) 288 Tunnel Type: SDWAN-WAN-Port 289 Followed by the detailed properties encoded as subTLV, such as 290 SubTLV for NAT 291 SubTLV for IPsec-SA Attribute 292 SubTLV for ISP connected to the WAN port 294 The Tunnel Encaps Attribute are defined as follows: 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Tunnel-Type(=SDWAN-WAN-Port )| Length (2 Octets) | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | | 302 | Value | 303 | | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 SDWAN Tunnel Encapsulation TLV Value Field 307 Where: 308 Tunnel Type is SDWAN-WAN-Port (to be assigned by IANA). 310 4.1. Port Ext SubTLV for NAT 312 NAT information is encoded is the Port Ext sub-TLV is for 313 describing the NAT property if the port has private address and 314 the network identifier to which the WAN port is connected, etc. 316 A SDWAN edge node can inquire STUN (Session Traversal of UDP 317 Through Network Address Translation RFC 3489) Server to get the 318 NAT property, the public IP address and the Public Port number to 319 pass to peers. 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 |Port Ext Type | EncapExt subTLV Length |I|O|R|R|R|R|R|R| 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | NAT Type | Encap-Type |Trans networkID| RD ID | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Local IP Address | 328 32-bits for IPv4, 128-bits for Ipv6 329 ~~~~~~~~~~~~ 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Local Port | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Public IP | 334 32-bits for IPv4, 128-bits for Ipv6 335 ~~~~~~~~~~~~ 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Public Port | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Where: 342 o Port Ext Type: indicate it is the Port Ext SubTLV. 343 o PortExt subTLV Length: the length of the subTLV. 344 o Flags: 345 - I bit (CPE port address or Inner address scheme) 346 If set to 0, indicate the inner (private) address is IPv4. 347 If set to 1, it indicates the inner address is IPv6. 349 - O bit (Outer address scheme): 350 If set to 0, indicate the public (outer) address is IPv4. 352 If set to 1, it indicates the public (outer) address is 353 IPv6. 355 - R bits: reserved for future use. Must be set to 0 now. 357 o NAT Type.without NAT; 1:1 static NAT; Full Cone; Restricted 358 Cone; Port Restricted Cone; Symmetric; or Unknown (i.e. no 359 response from the STUN server). 360 o Encap Type.the supported encapsulation types for the port 361 facing public network, such as IPsec+GRE, IPsec+VxLAN, IPsec 362 without GRE, GRE (when packets don't need encryption) 363 o Transport Network ID.Central Controller assign a global unique 364 ID to each transport network. 365 o RD ID.Routing Domain ID.Need to be global unique. 366 o Local IP.The local (or private) IP address of the port. 367 o Local Port.used by Remote SDWAN edge node for establishing 368 IPsec to this specific port. 369 o Public IP.The IP address after the NAT. If NAT is not used, 370 this field is set to NULL. 371 o Public Port.The Port after the NAT. If NAT is not used, this 372 field is set to NULL. 374 4.2. IPsec Security Association Property 376 The IPsecSA sub-TLV is for the SDWAN edge node to establish IPsec 377 security association with their peers via the port that face 378 untrusted network. The minimum set of the IPsec information is 379 from [CONTROLLER-IKE]. 381 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 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 |IPsec-SA Type |IPsecSA Length | Flag | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Transform | Transport | AH | ESP | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Key Counter | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | key1 length | Public Key | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | key2 length | Nonce | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | key3 length | key3 (for potential other keys | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Duration | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 Where: 400 o IPsec-SA SubTLV Type: to be assigned by IANA. The type value 401 has to be between 128~255 because IPsec-SA subTLV needs 2 bytes 402 for length to carry the needed information. 403 o IPsec-SA subTLV Length (2 Byte): 25 (or more) 404 o Flags: 1 octet of flags. None are defined at this stage. Flags 405 SHOULD be set to zero on transmission and MUST be ignored on 406 receipt. 407 o Transform (1 Byte): the value can be AH, ESP, or AH+ESP. 408 o Transport (1 byte): the value can be Tunnel Mode or Transport 409 mode 410 o AH (1 byte): AH authentication algorithms supported, which can 411 be md5 | sha1 | sha2-256 | sha2-384 | sha2-512 | sm3. Each 412 SDWAN edge node can have multiple authentication algorithms; 413 send to its peers to negotiate the strongest one. 414 o ESP (1 byte): ESP authentication algorithms supported, which 415 can be md5 | sha1 | sha2-256 | sha2-384 | sha2-512 | sm3. Each 416 SDWAN edge node can have multiple authentication algorithms; 417 send to its peers to negotiate the strongest one. Default 418 algorithm is AES-256. 419 o Rekay Counter: 4 bytes 420 o Public Key: IPsec public key 421 o Nonce.IPsec Nonce 422 o Key3.other potential key 423 o Duration: SA life span. 425 4.3. Remote Endpoint 427 The Remote Endpoint sub-TLV is not used for SDWAN NLRI because 428 o The SDWAN Node ID and Site ID are already encoded in the SDWAN 429 NLRI, 430 o The network connected by the SDWAN WAN port might have 431 identifier that is more than the AS number. SDWAN controller 432 might use its own specific identifier for the network. 434 o The Transport-Network-ID in the EncapExt sub-TLV represents the 435 SDWAN unique network identifier. 437 If the Remote Endpoint Sub-TLV is present, it is ignored by other 438 SDWAN edge nodes. 440 5. Manageability Considerations 442 TBD - this needs to be filled out before publishing 444 6. Security Considerations 446 The document describes the encoding for SDWAN edge nodes to 447 advertise its SDWAN WAN ports properties to their peers via 448 untrusted & unsecure networks. 450 The secure propagation is achieved by secure channels, such as 451 TLS, SSL, or IPsec, between the SDWAN edge nodes and the local 452 controller RR. 454 [More details need to be filled in here] 456 7. IANA Considerations 458 This document requires the following IANA actions. 460 o SDWAN Overlay SAFI = 74 assigned by IANA 461 o SDWAN Route Type 463 8. References 465 8.1. Normative References 467 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 468 Requirement Levels", BCP 14, RFC 2119, March 1997. 470 8.2. Informative References 472 [RFC8192] S. Hares, et al, "Interface to Network Security Functions 473 (I2NSF) Problem Statement and Use Cases", July 2017 475 [RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation Subsequent 476 Address Family Identifier (SAFI) and the BGP Tunnel 477 Encapsulation Attribute", April 2009. 479 [CONTROLLER-IKE] D. Carrel, et al, "IPsec Key Exchange using a 480 Controller", draft-carrel-ipsecme-controller-ike-01, work- 481 in-progress. 483 [Tunnel-Encap]E. Rosen, et al, "The BGP Tunnel Encapsulation 484 Attribute", draft-ietf-idr-tunnel-encaps-09, Feb 2018. 486 [VPN-over-Internet] E. Rosen, "Provide Secure Layer L3VPNs over 487 Public Infrastructure", draft-rosen-bess-secure-l3vpn-00, 488 work-in-progress, July 2018 490 [DMVPN] Dynamic Multi-point VPN: 491 https://www.cisco.com/c/en/us/products/security/dynamic- 492 multipoint-vpn-dmvpn/index.html 494 [DSVPN] Dynamic Smart VPN: 495 http://forum.huawei.com/enterprise/en/thread-390771-1- 496 1.html 498 [ITU-T-X1036] ITU-T Recommendation X.1036, "Framework for creation, 499 storage, distribution and enforcement of policies for 500 network security", Nov 2007. 502 [Net2Cloud-Problem] L. Dunbar and A. Malis, "Seamless Interconnect 503 Underlay to Cloud Overlay Problem Statement", draft-dm- 504 net2cloud-problem-statement-02, June 2018 506 [Net2Cloud-gap] L. Dunbar, A. Malis, and C. Jacquenet, "Gap Analysis 507 of Interconnecting Underlay with Cloud Overlay", draft-dm- 508 net2cloud-gap-analysis-02, work-in-progress, Aug 2018. 510 [Tunnel-Encap] E. Rosen, et al "The BGP Tunnel Encapsulation 511 Attribute", draft-ietf-idr-tunnel-encaps-10, Aug 2018. 513 9. Acknowledgments 515 Acknowledgements to Wang Haibo, Hao Weiguo, and ShengCheng for 516 implementation contribution; Many thanks to Jim Guichard, John 517 Scudder, Darren Dukes, Andy Malis, Rachel Huang and Donald Eastlake 518 for their review and contributions. 520 This document was prepared using 2-Word-v2.0.template.dot. 522 Authors' Addresses 524 Linda Dunbar 525 Futurewei 526 Email: ldunbar@futurewei.com 528 Sue Hares 529 Hickory Hill Consulting 530 Email: shares@ndzh.com