idnits 2.17.1 draft-dunbar-idr-sdwan-port-safi-00.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 4, 2019) is 1880 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 221, but not defined == Unused Reference: 'RFC2119' is defined on line 477, but no explicit reference was found in the text == Unused Reference: 'RFC8192' is defined on line 481, but no explicit reference was found in the text == Unused Reference: 'RFC5521' is defined on line 484, but no explicit reference was found in the text == Unused Reference: 'VPN-over-Internet' is defined on line 491, but no explicit reference was found in the text == Unused Reference: 'DMVPN' is defined on line 495, but no explicit reference was found in the text == Unused Reference: 'DSVPN' is defined on line 499, but no explicit reference was found in the text == Unused Reference: 'ITU-T-X1036' is defined on line 503, but no explicit reference was found in the text == Unused Reference: 'Net2Cloud-gap' is defined on line 511, 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 4, 2019 Independent 5 H. Wang 6 W. Hao 7 Huawei 8 March 4, 2019 10 Subsequent Address Family Indicator for SDWAN Ports 11 draft-dunbar-idr-sdwan-port-safi-00 13 Abstract 15 The document specifies a new BGP NLRI and SAFI for advertising 16 properties of a SD-WAN 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. SD-WAN 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 4, 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. SD-WAN NLRI Format.............................................5 73 3.1. SD-WAN Route Type.........................................8 74 3.2. Port Distinguisher........................................8 75 3.3. SD-WAN Color..............................................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....................................................13 83 7.1. Normative References.....................................13 84 7.2. Informative References...................................13 85 8. Acknowledgments...............................................14 87 1. Introduction 89 [Net2Cloud-Problem] introduces using SD-WAN 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 SD-WAN 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 SD-WAN): Each Edge SD-WAN router 117 registers with the SD-WAN 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 SD-WAN 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, SD-WAN-SITE-ID, SD-WAN 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: SD-WAN 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 SD-WAN controller to manage 173 SD-WAN 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 SD-WAN End-point: An WAN port (logical or physical) of a SD-WAN 181 node. (If "endpoint" is used, it refers to a SD-WAN 182 End-point). 184 OnPrem: On Premises data centers and branch offices 186 SD-WAN: Software Defined Wide Area Network. In this document, 187 "SDWAN" refers to the solutions of pooling WAN bandwidth 188 from multiple underlay networks to get better WAN 189 bandwidth management, visibility & control. When the 190 underlay networks are private networks, traffic can 191 traverse without additional encryption; when the 192 underlay networks are public, such as Internet, some 193 traffic needs to be encrypted when traversing through 194 (depending on user provided policies). 196 3. SD-WAN NLRI Format 198 The new SAFI code point 74 has been assigned by IANA as the 199 Subsequent Address Family Identifier for advertising properties of 200 WAN ports that face untrusted networks. Depending on user policies, 201 some packets through those WAN ports will need encryption. 203 The SD-WAN SAFI (code point 74 assigned by IANA) uses a new NLRI 204 defined as follows: 206 +------------------+ 207 | NLRI Length | 1 octet 208 +------------------+ 209 | SDWAN-Type | 2 Octets 210 +------------------+ 211 |Port-Distinguisher| 4 octets 212 +------------------+ 213 | SD-WAN-Site-ID | 4 octets 214 +------------------+ 215 | SD-WAN-Node-ID | 4 or 16 octets 216 +------------------+ 218 where: 220 - NLRI Length: 1 octet of length expressed in bits as defined in 221 [RFC4760]. 222 - SDWAN-Type: to define the encoding of the rest of the SD-WAN 223 NLRI. 224 - Port Distinguisher: SDWAN node Port identifier. There can be 225 many ports on a SD-WAN node; each port can have different 226 properties. For example, some ports may get ISP or DHCP assigned 227 IP addresses (IPv4 or IPv6), some may have private IP addresses 228 that packets to/from those ports have to traverse NAT. 229 The detailed properties about the port are further encoded in 230 the subsequent subTLVs, e.g. Port-subTLV. 232 - SDWAN-Site-ID: used to identify a common property shared by a 233 set of SD-WAN nodes, such as the property of a specific 234 geographic location shared by a group of SDWAN nodes. 235 - SDWAN Node ID: the SDWAN node identifier, which can be the 236 node's system ID or the loopback address (IPv4 or IPv6) of the 237 SD-WAN node. 239 The content of the SDWAN Port properties is encoded in the Tunnel 240 Encapsulation Attribute originally defined in [Tunnel-Encap] using a 241 new Tunnel-Type TLV (code point to be assigned by IANA from the "BGP 242 Tunnel Encapsulation Attribute Tunnel Types" registry). 244 SDWAN SAFI (=74) NLRI: < SDWAN-Type, Length, Port-distinguisher, SD- 245 WAN-color, SD-WAN-Node-ID> 246 Attributes: 247 Tunnel Encaps Attribute 248 Tunnel Type: SDWAN Port Property 249 NAT SubTLV 250 IPsec-SA Attribute SubTLV 251 Port-subTLV 253 Where 254 - NAT SubTLV is for describing additional information about the 255 SD-WAN tunnel end-points, such as NAT property. 256 - IPsec-SA SubTLV is for the node to establish IPsec SA with 257 other peers. 258 - Port-subTLV is for additional properties of the WAN port. 260 The Tunnel Encaps Attribute are defined as follows: 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Tunnel-Type(2 Octets) | Length (2 Octets) | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | | 268 | Value | 269 | | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Figure 1: SD-WAN Tunnel Encapsulation TLV Value Field 273 Where: 274 Tunnel Type is SD-WAN Port Property (to be assigned by IANA). 276 3.1. SD-WAN Route Type 278 A new Route Type that defines the encoding of the rest of the SD-WAN 279 NLRI, and a set of sub-TLVs to specify its end-point attributes, 280 policies associated with the Ports: 282 3.2. Port Distinguisher 284 One (SD-WAN) node can have multiple ports, and each port can support 285 multiple IPsec SA to different peers. The Port Distinguisher is to 286 uniquely identify a port (or link). 288 The property of the port are encoded in the subTLV attached to the 289 SDWAN NLRI: 291 a) The IP address (IPv4 or IPv6) & AS number of the Port 292 b) NAT information for ports with Private IP address 293 c) IPsec Security Association related information if the port is 294 facing public network and traffic through which have to be 295 encrypted. 296 Detailed encoding for those properties are described in Section 3.4 297 & Section 3.5 respectively. 299 3.3. SD-WAN Color 301 SD-WAN Color is used to identify a common property shared by a set 302 of SD-WAN nodes/ports, such as the property of a specific geographic 303 location. The property is used to steer an overlay route to traverse 304 specific geographic locations for various reasons, such as to comply 305 regulatory rules, to utilize specific value added services, or 306 others. 308 3.4. Extended Port Property 310 EncapExt sub-TLV is for describing additional information about a 311 SD-WAN port, such as the NAT property if the port has private 312 address, the network identifier that the port is part of, etc. 314 A SD-WAN edge node can inquire STUN (Session Traversal of UDP 315 Through Network Address Translation RFC 3489) Server to get the NAT 316 property, the public IP address and the Public Port number to pass 317 to peers. 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 |EncapExt Type | EncapExt subTLV Length |I|O|R|R|R|R|R|R| 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | NAT Type | Encap-Type |Trans networkID| RD ID | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Local IP Address | 326 32-bits for IPv4, 128-bits for Ipv6 327 ~~~~~~~~~~~~ 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Local Port | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Public IP | 332 32-bits for IPv4, 128-bits for Ipv6 333 ~~~~~~~~~~~~ 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Public Port | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 Where: 340 o EncapExt Type: indicate it is the EncapExt SubTLV. 341 o EncapExt subTLV Length: the length of the subTLVE. 342 o Flags: 343 - I bit (CPE port address or Inner address scheme) 344 If set to 0, indicate the inner (private) address is IPv4. 345 If set to 1, it indicates the inner address is IPv6. 347 - O bit (Outer address scheme): 348 If set to 0, indicate the public (outer) address is IPv4. 349 If set to 1, it indicates the public (outer) address is 350 IPv6. 352 - R bits: reserved for future use. Must be set to 0 now. 354 o NAT Type.without NAT; 1:1 static NAT; Full Cone; Restricted 355 Cone; Port Restricted Cone; Symmetric; or Unknown (i.e. no 356 response from the STUN server). 358 o Encap Type.the supported encapsulation types for the port 359 facing public network, such as IPsec+GRE, IPsec+VxLAN, IPsec 360 without GRE, GRE (when packets don't need encryption) 361 o Transport Network ID.Central Controller assign a global unique 362 ID to each transport network. 363 o RD ID.Routing Domain ID.Need to be global unique. 364 o Local IP.The local (or private) IP address of the port. 365 o Local Port.used by Remote SD-WAN node for establishing IPsec to 366 this specific port. 367 o Public IP.The IP address after the NAT. If NAT is not used, 368 this field is set to NULL. 369 o Public Port.The Port after the NAT. If NAT is not used, this 370 field is set to NULL. 372 3.5. IPsec Security Association Property 374 The IPsecSA sub-TLV is for the SD-WAN node to establish IPsec 375 security association with their peers via the port that face 376 untrusted network: 378 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 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 |IPsec-SA Type |IPsecSA Length | Flag | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Transform | Transport | AH | ESP | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | SPI | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | key1 length | key1 | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | key2 length | key2 | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | key3 length | key3 | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Duration | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 Where: 397 o IPsec-SA SubTLV Type: to be assigned by IANA. The type value 398 has to be between 128~255 because IPsec-SA subTLV needs 2 bytes 399 for length to carry the needed information. 400 o IPsec-SA subTLV Length (2 Byte): 25 (or more) 401 o Flags: 1 octet of flags. None are defined at this stage. Flags 402 SHOULD be set to zero on transmission and MUST be ignored on 403 receipt. 404 o Transform (1 Byte): the value can be AH, ESP, or AH+ESP. 405 o Transport (1 byte): the value can be Tunnel Mode or Transport 406 mode 407 o AH (1 byte): AH authentication algorithms supported, which can 408 be md5 | sha1 | sha2-256 | sha2-384 | sha2-512 | sm3. Each SD- 409 WAN node can have multiple authentication algorithms; send to 410 its peers to negotiate the strongest one. 411 o ESP (1 byte): ESP authentication algorithms supported, which 412 can be md5 | sha1 | sha2-256 | sha2-384 | sha2-512 | sm3. Each 413 SD-WAN node can have multiple authentication algorithms; send 414 to its peers to negotiate the strongest one. Default algorithm 415 is AES-256. 416 o SPI: 4 bytes 417 o Key1.AH authentication key 418 o Key2.ESP authentication key 419 o Key3.ESP encryption "public" key 420 o Duration: SA life span. 422 3.6. Remote Endpoint 424 The Remote Endpoint sub-TLV is not used for SDWAN NLRI because 425 o The network to which a SDWAN port is connected might have 426 identifier that is more than the AS number. SDWAN controller 427 might use its own specific identifier for the network. 428 o The Transport-Network-ID in the EncapExt sub-TLV represents the 429 SDWAN unique network identifier. 431 If the Remote Endpoint Sub-TLV is present, it is ignored by other 432 SDWAN nodes. 434 4. Operation of SDWAN routers: 436 The processing steps on CPE1 to announce the SD-WAN combination of 437 routes, NAT and IPsec information via BGP are: 439 1. Advertise the SD-WAN capability information and port properties, 440 such as Port identifiers and supported properties etc. to RR via the 441 SD-WAN SAFI NLRI. 443 2. RR propagate the information to CPE2 & CPE 3. 445 3. CPE2 and CPE3 can choose to establish IPsec SA with the CPE1 446 after receiving the CPE1 WAN properties from RR. 448 Note: Tenant separation is achieved by different SD-WAN nodes being 449 added to different Peer Group. 451 4. Manageability Considerations 453 TBD - this needs to be filled out before publishing 455 5. Security Considerations 457 The document is to address how SD-WAN nodes advertise its SD-WAN 458 capability to their peers via untrusted & unsecure networks. 460 The secure propagation is achieved by secure channels, such as 461 TLS, SSL, or IPsec, between the SD-WAN nodes and the local 462 controller RR. 464 [More details need to be filled in here] 466 6. IANA Considerations 468 This document requires the following IANA actions. 470 o SD-WAN Overlay SAFI = 74 assigned by IANA 471 o SD-WAN Type 473 7. References 475 7.1. Normative References 477 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 478 Requirement Levels", BCP 14, RFC 2119, March 1997. 479 7.2. Informative References 481 [RFC8192] S. Hares, et al, "Interface to Network Security Functions 482 (I2NSF) Problem Statement and Use Cases", July 2017 484 [RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation Subsequent 485 Address Family Identifier (SAFI) and the BGP Tunnel 486 Encapsulation Attribute", April 2009. 488 [Tunnel-Encap]E. Rosen, et al, "The BGP Tunnel Encapsulation 489 Attribute", draft-ietf-idr-tunnel-encaps-09, Feb 2018. 491 [VPN-over-Internet] E. Rosen, "Provide Secure Layer L3VPNs over 492 Public Infrastructure", draft-rosen-bess-secure-l3vpn-00, 493 work-in-progress, July 2018 495 [DMVPN] Dynamic Multi-point VPN: 496 https://www.cisco.com/c/en/us/products/security/dynamic- 497 multipoint-vpn-dmvpn/index.html 499 [DSVPN] Dynamic Smart VPN: 500 http://forum.huawei.com/enterprise/en/thread-390771-1- 501 1.html 503 [ITU-T-X1036] ITU-T Recommendation X.1036, "Framework for creation, 504 storage, distribution and enforcement of policies for 505 network security", Nov 2007. 507 [Net2Cloud-Problem] L. Dunbar and A. Malis, "Seamless Interconnect 508 Underlay to Cloud Overlay Problem Statement", draft-dm- 509 net2cloud-problem-statement-02, June 2018 511 [Net2Cloud-gap] L. Dunbar, A. Malis, and C. Jacquenet, "Gap Analysis 512 of Interconnecting Underlay with Cloud Overlay", draft-dm- 513 net2cloud-gap-analysis-02, work-in-progress, Aug 2018. 515 [Tunnel-Encap] E. Rosen, et al "The BGP Tunnel Encapsulation 516 Attribute", draft-ietf-idr-tunnel-encaps-10, Aug 2018. 518 8. Acknowledgments 520 Acknowledgements to Jim Guichard, John Scudder, Darren Dukes, Andy 521 Malis and Donald Eastlake for their review and contributions. 523 This document was prepared using 2-Word-v2.0.template.dot. 525 Authors' Addresses 527 Linda Dunbar 528 Huawei 529 Email: Linda.Dunbar@huawei.com 531 Sue Hares 532 Independent 533 Email: shares@ndzh.com 535 Haibo Wang 536 Huawei 537 Email: rainsword.wang@huawei.com 539 WeiGuo Hao 540 Huawei Technologies Co.,Ltd. 541 Email: haoweiguo@huawei.com