idnits 2.17.1 draft-dunbar-idr-sdwan-port-safi-01.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 (March 6, 2019) is 1877 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SDWAN-BGP-USAGE' is mentioned on line 113, but not defined == Missing Reference: 'RFC4760' is mentioned on line 220, 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 ** Downref: Normative reference to an Informational RFC: RFC 8192 == Outdated reference: A later version (-01) exists of draft-rosen-bess-secure-l3vpn-00 ** Downref: Normative reference to an Informational draft: draft-rosen-bess-secure-l3vpn (ref. 'VPN-over-Internet') -- Possible downref: Non-RFC (?) normative reference: ref. 'DMVPN' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSVPN' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T-X1036' == Outdated reference: A later version (-07) exists of draft-dm-net2cloud-problem-statement-02 ** Downref: Normative reference to an Informational draft: draft-dm-net2cloud-problem-statement (ref. 'Net2Cloud-Problem') == Outdated reference: A later version (-04) exists of draft-dm-net2cloud-gap-analysis-02 ** Downref: Normative reference to an Informational draft: draft-dm-net2cloud-gap-analysis (ref. 'Net2Cloud-gap') == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-10 Summary: 4 errors (**), 0 flaws (~~), 16 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Dunbar 2 Internet Draft Huawei 3 Intended status: Standards Track S. Hares 4 Expires: September 6, 2019 Independent 5 H. Wang 6 W. Hao 7 Huawei 8 March 6, 2019 10 Subsequent Address Family Indicator for SDWAN Ports 11 draft-dunbar-idr-sdwan-port-safi-01 13 Abstract 15 The document specifies a new BGP NLRI and SAFI for advertising 16 properties of a SDWAN edge node WAN ports that face untrusted 17 networks, such as the public internet. Those WAN ports may get 18 assigned IP addresses from the Internet Service Providers (ISPs), 19 may get assigned dynamic IP addresses via DHCP, or may have private 20 addresses (e.g. inside third party Cloud DCs). Packets sent over 21 those SDWAN WAN ports might need to be encrypted (depending on the 22 user policies) or need to go through NAT. SDWAN edge need to 23 propagate those WAN ports properties to its SDWAN controller, which 24 propagates to the authorized peers and manage the IPsec SAs among 25 those peers for encrypting traffic via the untrusted networks. 27 BGP Route Reflectors (RR) are proposed as points of combination for 28 this information in order to allow scaling of the SDWAN. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as Internet- 38 Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six 41 months and may be updated, replaced, or obsoleted by other documents 42 at any time. It is inappropriate to use Internet-Drafts as 43 reference material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/ietf/1id-abstracts.txt 48 The list of Internet-Draft Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html 51 This Internet-Draft will expire on September 6, 2019. 53 Copyright Notice 55 Copyright (c) 2019 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with 63 respect to this document. Code Components extracted from this 64 document must include Simplified BSD License text as described in 65 Section 4.e of the Trust Legal Provisions and are provided without 66 warranty as described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction...................................................3 71 2. Conventions used in this document..............................5 72 3. SDWAN NLRI Format..............................................5 73 3.1. SDWAN Route Type..........................................7 74 3.2. Port Distinguisher........................................8 75 3.3. SDWAN Site ID.............................................8 76 3.4. Extended Port Property....................................8 77 3.5. IPsec Security Association Property......................10 78 3.6. Remote Endpoint..........................................11 79 4. Manageability Considerations..................................12 80 5. Security Considerations.......................................12 81 6. IANA Considerations...........................................12 82 7. References....................................................12 83 7.1. Normative References.....................................13 84 7.2. Informative References...................................13 85 8. Acknowledgments...............................................14 87 1. Introduction 89 [Net2Cloud-Problem] introduces using SDWAN to reach workloads in 90 dynamic third party data centers and aggregate multiple underlay 91 paths, including public untrusted networks, provided by different 92 service providers. However, scaling the combination of routes and 93 IPsec SAs key management can be an issue when the number of nodes 94 interconnected by the SDWAN overlay paths reaches 10,000 to 100,000 95 nodes. 97 [SDWAN-BGP-USAGE] describes multiple SDWAN scenarios and how/why 98 using BGP as control plane for the SDWAN networks. 100 This document describes a new BGP NLRI and SAFI to advertise 101 properties of WAN ports facing the public internet. This new SAFI & 102 NLRI is for the Scenario #2 of the [SDWAN-BGP-USAGE] where one 103 "SDWAN" edge node having multiple ports some of which connected to 104 private networks and others connected to public untrusted networks. 105 The packets sent over the private networks can go natively without 106 encryption (for better performance), only the packets sent over the 107 public networks needs IPsec SA. 109 The new SAFI and NLRI are for advertising the properties of WAN 110 ports facing public untrusted networks, through which data packets 111 have to be encrypted using IPsec. 113 The [SDWAN-BGP-USAGE] document describes the three functional tiers 114 for the control plane of SDWAN Scenario #2: 116 . Tier 1 (Edge Router of SDWAN): Each Edge SDWAN router 117 registers with the SDWAN Controller using a secure connection 118 (e.g. TLS). During the registration process, the controller 119 may suggest a specific BGP RR peer for the Edge SDWAN router 120 to exchange BGP route with. 122 After registering, each Edge Router sends routes + SDWAN WAN 123 ports information (NAT and security information) via the SDWAN 124 SAFI + NLRI to the BGP RR. Due to the sensitivity of the 125 information, the BGP peering session MUST be configured to run 126 over a Secure TCP (TLS). 128 . Tier 2: Route Reflector that combines information from the 129 security information from the SDWAN controller, the WAN ports 130 properties from SDWAN edge routers, and 132 . Tier 3: Client routes distribution, just like EVPN or L3VPN, 133 except including additional paths over the WAN ports facing 134 the public Internet. 136 Traffic go through the private networks links natively without 137 encryption and are encrypted when sent out the WAN ports facing 138 public Internet. 140 The BGP peers use a new BGP NLRI and SAFI to pass the SDWAN Internet 141 WAN ports properties, such as NAT and security association (SA). 142 This information includes the Port-ID and port related NAT 143 information, SDWAN-SITE-ID, SDWAN Node-ID, and IPsec security 144 information. 146 Centralized----------------------------------------------- 147 controller | 148 | | 149 | +---+ | 150 | Peer Group 1 |RR | Peer Group 2 | 151 | +======+====+=+ +======+====+=====+ | 152 | / / | +---+ | \ \ | 153 | / / | | | \ | 154 | +-+-+ +-+--+ +-+-+ +-+-+ +-+-+ +-+-+ | 155 | |CPE| | CPE|--|CPE| |CPE| |CPE| |CPE| | 156 ---| 1 | | 2 | | 3 | |4 | | 5 | | 6 |----| 157 +---+ +----+ +---+ +---+ +---+ +---+ 158 Tenant 1 Tenant 2 160 Figure 1: SDWAN Capability Advertisement via RR 162 Note: All CPEs (CPE1, CPE2, CPE, CPE4, CPE5, and CPE) connect to the 163 centralized controller, but only 2 connections are show in this 164 diagram. 166 2. Conventions used in this document 168 Cloud DC: Off-Premise Data Centers that usually host applications 169 and workload owned by different organizations or 170 tenants. 172 Controller: Used interchangeably with SDWAN controller to manage 173 SDWAN overlay path creation/deletion and monitor the 174 path conditions between sites. 176 CPE-Based VPN: Virtual Private Secure network formed among CPEs. 177 This is to differentiate from most commonly used PE- 178 based VPNs a la RFC 4364. 180 SDWAN End-point: An WAN port (logical or physical) of a SDWAN node. 181 (If "endpoint" is used, it refers to a SDWAN End-point). 183 OnPrem: On Premises data centers and branch offices 185 SDWAN: Software Defined Wide Area Network. In this document, 186 "SDWAN" refers to the solutions of pooling WAN bandwidth 187 from multiple underlay networks to get better WAN 188 bandwidth management, visibility & control. When the 189 underlay networks are private networks, traffic can 190 traverse without additional encryption; when the 191 underlay networks are public, such as Internet, some 192 traffic needs to be encrypted when traversing through 193 (depending on user provided policies). 195 3. SDWAN NLRI Format 197 The new SAFI code point 74 has been assigned by IANA as the 198 Subsequent Address Family Identifier for advertising properties of 199 WAN ports that face untrusted networks. Depending on user policies, 200 some packets through those WAN ports will need encryption. 202 The SDWAN SAFI (code point 74 assigned by IANA) uses a new NLRI 203 defined as follows: 205 +------------------+ 206 | NLRI Length | 1 octet 207 +------------------+ 208 | SDWAN-Type | 2 Octets 209 +------------------+ 210 |Port-Distinguisher| 4 octets 211 +------------------+ 212 | SDWAN-Site-ID | 4 octets 213 +------------------+ 214 | SDWAN-Node-ID | 4 or 16 octets 215 +------------------+ 217 where: 219 - NLRI Length: 1 octet of length expressed in bits as defined in 220 [RFC4760]. 221 - SDWAN-Type: to define the encoding of the rest of the SDWAN 222 NLRI. 223 - Port Distinguisher: SDWAN node Port identifier. There can be 224 many ports on a SDWAN node; each port can have different 225 properties. For example, some ports may get ISP or DHCP assigned 226 IP addresses (IPv4 or IPv6), some may have private IP addresses 227 that packets to/from those ports have to traverse NAT. 228 The detailed properties about the port are further encoded in 229 the subsequent subTLVs, e.g. Port-subTLV. 231 - SDWAN-Site-ID: used to identify a common property shared by a 232 set of SDWAN nodes, such as the property of a specific 233 geographic location shared by a group of SDWAN nodes. 234 - SDWAN Node ID: the SDWAN node identifier, which can be the 235 node's system ID or the loopback address (IPv4 or IPv6) of the 236 SDWAN node. 238 The content of the SDWAN Port properties is encoded in the Tunnel 239 Encapsulation Attribute originally defined in [Tunnel-Encap] using a 240 new Tunnel-Type TLV (code point to be assigned by IANA from the "BGP 241 Tunnel Encapsulation Attribute Tunnel Types" registry). 243 SDWAN SAFI (=74) NLRI: < SDWAN-Type, Length, Port-distinguisher, 244 SDWAN-Site-ID, SDWAN-Node-ID> 245 Attributes: 246 Tunnel Encaps Attribute 247 Tunnel Type: SDWAN Port Property 248 NAT SubTLV 249 IPsec-SA Attribute SubTLV 250 Port-subTLV 252 Where 253 - NAT SubTLV is for describing additional information about the 254 SDWAN tunnel end-points, such as NAT property. 255 - IPsec-SA SubTLV is for the node to establish IPsec SA with 256 other peers. 257 - Port-subTLV is for additional properties of the WAN port. 259 The Tunnel Encaps Attribute are defined as follows: 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Tunnel-Type(2 Octets) | Length (2 Octets) | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | | 267 | Value | 268 | | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Figure 1: SDWAN Tunnel Encapsulation TLV Value Field 272 Where: 273 Tunnel Type is SDWAN Port Property (to be assigned by IANA). 275 3.1. SDWAN Route Type 277 A new Route Type that defines the encoding of the rest of the SDWAN 278 NLRI, and a set of sub-TLVs to specify its end-point attributes, 279 policies associated with the Ports: 281 3.2. Port Distinguisher 283 One (SDWAN) node can have multiple ports, and each port can support 284 multiple IPsec SA to different peers. The Port Distinguisher is to 285 uniquely identify a port (or link). 287 The property of the port are encoded in the subTLV attached to the 288 SDWAN NLRI: 290 a) The IP address (IPv4 or IPv6) & AS number of the Port 291 b) NAT information for ports with Private IP address 292 c) IPsec Security Association related information if the port is 293 facing public network and traffic through which have to be 294 encrypted. 295 Detailed encoding for those properties are described in Section 3.4 296 & Section 3.5 respectively. 298 3.3. SDWAN Site ID 300 SDWAN Site ID is used to identify a common property shared by a set 301 of SDWAN nodes/ports, such as the property of a specific geographic 302 location. The property is used to steer an overlay route to traverse 303 specific geographic locations for various reasons, such as to comply 304 regulatory rules, to utilize specific value added services, or 305 others. 307 3.4. Extended Port Property 309 EncapExt sub-TLV is for describing additional information about a 310 SDWAN port, such as the NAT property if the port has private 311 address, the network identifier that the port is part of, etc. 313 A SDWAN edge node can inquire STUN (Session Traversal of UDP Through 314 Network Address Translation RFC 3489) Server to get the NAT 315 property, the public IP address and the Public Port number to pass 316 to peers. 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 |EncapExt Type | EncapExt subTLV Length |I|O|R|R|R|R|R|R| 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | NAT Type | Encap-Type |Trans networkID| RD ID | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Local IP Address | 325 32-bits for IPv4, 128-bits for Ipv6 326 ~~~~~~~~~~~~ 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Local Port | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Public IP | 331 32-bits for IPv4, 128-bits for Ipv6 332 ~~~~~~~~~~~~ 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Public Port | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Where: 339 o EncapExt Type: indicate it is the EncapExt SubTLV. 340 o EncapExt subTLV Length: the length of the subTLVE. 341 o Flags: 342 - I bit (CPE port address or Inner address scheme) 343 If set to 0, indicate the inner (private) address is IPv4. 344 If set to 1, it indicates the inner address is IPv6. 346 - O bit (Outer address scheme): 347 If set to 0, indicate the public (outer) address is IPv4. 348 If set to 1, it indicates the public (outer) address is 349 IPv6. 351 - R bits: reserved for future use. Must be set to 0 now. 353 o NAT Type.without NAT; 1:1 static NAT; Full Cone; Restricted 354 Cone; Port Restricted Cone; Symmetric; or Unknown (i.e. no 355 response from the STUN server). 356 o Encap Type.the supported encapsulation types for the port 357 facing public network, such as IPsec+GRE, IPsec+VxLAN, IPsec 358 without GRE, GRE (when packets don't need encryption) 360 o Transport Network ID.Central Controller assign a global unique 361 ID to each transport network. 362 o RD ID.Routing Domain ID.Need to be global unique. 363 o Local IP.The local (or private) IP address of the port. 364 o Local Port.used by Remote SDWAN node for establishing IPsec to 365 this specific port. 366 o Public IP.The IP address after the NAT. If NAT is not used, 367 this field is set to NULL. 368 o Public Port.The Port after the NAT. If NAT is not used, this 369 field is set to NULL. 371 3.5. IPsec Security Association Property 373 The IPsecSA sub-TLV is for the SDWAN node to establish IPsec 374 security association with their peers via the port that face 375 untrusted network: 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 |IPsec-SA Type |IPsecSA Length | Flag | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Transform | Transport | AH | ESP | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | SPI | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | key1 length | key1 | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | key2 length | key2 | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | key3 length | key3 | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Duration | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 Where: 396 o IPsec-SA SubTLV Type: to be assigned by IANA. The type value 397 has to be between 128~255 because IPsec-SA subTLV needs 2 bytes 398 for length to carry the needed information. 399 o IPsec-SA subTLV Length (2 Byte): 25 (or more) 400 o Flags: 1 octet of flags. None are defined at this stage. Flags 401 SHOULD be set to zero on transmission and MUST be ignored on 402 receipt. 403 o Transform (1 Byte): the value can be AH, ESP, or AH+ESP. 404 o Transport (1 byte): the value can be Tunnel Mode or Transport 405 mode 406 o AH (1 byte): AH authentication algorithms supported, which can 407 be md5 | sha1 | sha2-256 | sha2-384 | sha2-512 | sm3. Each 408 SDWAN node can have multiple authentication algorithms; send to 409 its peers to negotiate the strongest one. 410 o ESP (1 byte): ESP authentication algorithms supported, which 411 can be md5 | sha1 | sha2-256 | sha2-384 | sha2-512 | sm3. Each 412 SDWAN node can have multiple authentication algorithms; send to 413 its peers to negotiate the strongest one. Default algorithm is 414 AES-256. 415 o SPI: 4 bytes 416 o Key1.AH authentication key 417 o Key2.ESP authentication key 418 o Key3.ESP encryption "public" key 419 o Duration: SA life span. 421 3.6. Remote Endpoint 423 The Remote Endpoint sub-TLV is not used for SDWAN NLRI because 424 o The network to which a SDWAN port is connected 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 nodes. 433 4. Operation of SDWAN routers: 435 The processing steps on CPE1 to announce the SDWAN combination of 436 routes, NAT and IPsec information via BGP are: 438 1. Advertise the SDWAN capability information and port properties, 439 such as Port identifiers and supported properties etc. to RR via the 440 SDWAN SAFI NLRI. 442 2. RR propagate the information to CPE2 & CPE 3. 444 3. CPE2 and CPE3 can choose to establish IPsec SA with the CPE1 445 after receiving the CPE1 WAN properties from RR. 447 Note: Tenant separation is achieved by different SDWAN nodes being 448 added to different Peer Group. 450 4. Manageability Considerations 452 TBD - this needs to be filled out before publishing 454 5. Security Considerations 456 The document is to address how SDWAN nodes advertise its SDWAN 457 capability to their peers via untrusted & unsecure networks. 459 The secure propagation is achieved by secure channels, such as 460 TLS, SSL, or IPsec, between the SDWAN nodes and the local 461 controller RR. 463 [More details need to be filled in here] 465 6. IANA Considerations 467 This document requires the following IANA actions. 469 o SDWAN Overlay SAFI = 74 assigned by IANA 470 o SDWAN Route Type 472 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 ShengCheng for implementation contribution; Many 519 thanks to Jim Guichard, John Scudder, Darren Dukes, Andy Malis, 520 Rachel Huang and Donald Eastlake for their review and contributions. 522 This document was prepared using 2-Word-v2.0.template.dot. 524 Authors' Addresses 526 Linda Dunbar 527 Huawei USA 528 Email: Linda.Dunbar@huawei.com 530 Sue Hares 531 Independent 532 Email: shares@ndzh.com 534 Haibo Wang 535 Huawei 536 Email: rainsword.wang@huawei.com 538 WeiGuo Hao 539 Huawei Technologies Co.,Ltd. 540 Email: haoweiguo@huawei.com