idnits 2.17.1 draft-drao-bgp-l3vpn-virtual-network-overlays-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: With the Virtual-Network Overlay Encapsulation Capability, a VN-capable BGP speaker will detect peers that are not capable of processing VN-ID encapsulation information received in BGP updates. The speaker MUST not send any VPN-IP routes that contain only a VN-ID based encapsulation to such peers. If the route contains both a VN-ID encapsulation and an MPLS-in-GRE encapsulation, the speaker MAY send the route to the legacy peer with only the MPLS encapsulation information, and with the VN-ID encapsulation information removed. -- The document date (July 4, 2014) is 3584 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: 'VXLAN' is mentioned on line 126, but not defined == Missing Reference: 'NVGRE' is mentioned on line 126, but not defined == Missing Reference: 'NVO3' is mentioned on line 127, but not defined == Missing Reference: 'MPLS-in-GRE' is mentioned on line 468, but not defined == Missing Reference: 'RFC5492' is mentioned on line 679, but not defined == Missing Reference: 'RFC5226' is mentioned on line 681, but not defined ** Obsolete undefined reference: RFC 5226 (Obsoleted by RFC 8126) == Unused Reference: 'I-D.mahalingam-dutt-dcops-vxlan' is defined on line 719, but no explicit reference was found in the text == Unused Reference: 'I-D.sridharan-virtualization-nvgre' is defined on line 726, but no explicit reference was found in the text == Unused Reference: 'I-D.fang-l3vpn-virtual-pe' is defined on line 741, but no explicit reference was found in the text == Unused Reference: 'I-D.narten-iana-considerations-rfc2434bis' is defined on line 747, but no explicit reference was found in the text == Unused Reference: 'I-D.vandevelde-idr-remote-next-hop' is defined on line 754, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 759, but no explicit reference was found in the text == Unused Reference: 'RFC3107' is defined on line 762, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 765, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 769, but no explicit reference was found in the text == Unused Reference: 'RFC4364' is defined on line 772, but no explicit reference was found in the text == Unused Reference: 'RFC5512' is defined on line 775, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-mahalingam-dutt-dcops-vxlan (ref. 'I-D.mahalingam-dutt-dcops-vxlan') == Outdated reference: A later version (-08) exists of draft-sridharan-virtualization-nvgre-04 ** Downref: Normative reference to an Informational draft: draft-sridharan-virtualization-nvgre (ref. 'I-D.sridharan-virtualization-nvgre') == Outdated reference: A later version (-09) exists of draft-vandevelde-idr-remote-next-hop-07 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3107 (Obsoleted by RFC 8277) -- Obsolete informational reference (is this intentional?): RFC 5512 (Obsoleted by RFC 9012) Summary: 3 errors (**), 0 flaws (~~), 21 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L3VPN D. Rao 3 Internet-Draft J. Mullooly 4 Intended status: Standards Track R. Fernando 5 Expires: January 5, 2015 Cisco 6 July 4, 2014 8 Layer-3 virtual network overlays based on BGP Layer-3 VPNs 9 draft-drao-bgp-l3vpn-virtual-network-overlays-03 11 Abstract 13 Virtual network overlays are being designed and deployed in various 14 types of networks, including data centers. These network overlays 15 address several requirements including flexible network 16 virtualization and multi-tenancy, increased scale, and support for 17 mobility of virtual machines. Such overlay networks can be used to 18 provide both Layer-2 and Layer-3 network services to hosts at the 19 network edge. New packet encapsulations are being defined and 20 standardized to support these virtual networks. These 21 encapsulations, such as VXLAN and NVGRE, are primarily based on IP 22 and are currently defined to support a Layer-2 forwarding service. 24 BGP based Layer-3 VPNs, as specified in RFC 4364, provide an industry 25 proven and well-defined solution for supporting Layer-3 virtual 26 network services. However, RFC 4364 procedures use MPLS labels to 27 provide the network virtualization capability in the data plane. With 28 the increasing support for IP overlay encapsulations in data center 29 devices, there is a strong preference to utilize this support to 30 deploy Layer-3 virtual networks using the familiarpolicy and 31 operational primitives of Layer-3 VPNs. 33 This document describes the use of BGP Layer-3 VPNs alongwith various 34 IP-based virtual network overlay encapsulations to provide a Layer-3 35 virtualization solution for all IP traffic, and specifies mechanisms 36 to use the new encapsulations while continuing to leverage existing 37 BGP Layer-3 VPN control plane techniques, extensions and 38 implementations. This mechanism provides an efficient incremental 39 solution to support forwarding for IP traffic, irrespective of 40 whether it is destined within or across an IP subnet boundary. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at http://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on January 5, 2015. 59 Copyright Notice 61 Copyright (c) 2014 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 78 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 79 1.3. Control plane signaling requirements . . . . . . . . . . 4 80 1.4. Control plane model . . . . . . . . . . . . . . . . . . . 5 81 1.5. Overlay Encapsulations . . . . . . . . . . . . . . . . . 5 82 2. Virtual Network Identifier . . . . . . . . . . . . . . . . . 5 83 2.1. Virtual Network Identifier Scope . . . . . . . . . . . . 6 84 2.1.1. Domain-scoped provisioned virtual network identifiers 6 85 2.1.2. Per-device scoped allocated virtual network 86 identifiers . . . . . . . . . . . . . . . . . . . . . 6 87 2.1.3. Global unicast table . . . . . . . . . . . . . . . . 7 88 2.1.4. Virtual Network Identifier Specification . . . . . . 7 89 2.2. Signaling Virtual Network Identifiers . . . . . . . . . . 7 90 2.2.1. Signaling Requirements . . . . . . . . . . . . . . . 8 91 2.2.2. Signaling Specification . . . . . . . . . . . . . . . 9 92 3. Overlay Encapsulation specification . . . . . . . . . . . . . 9 93 3.1. Encapsulation for VXLAN and NVGRE . . . . . . . . . . . . 10 94 3.2. Encapsulation for MPLS-in-GRE . . . . . . . . . . . . . . 11 95 3.3. Multiple encapsulations . . . . . . . . . . . . . . . . . 11 96 3.4. Gateway device encapsulation handling . . . . . . . . . . 11 98 4. Forwarding behavior . . . . . . . . . . . . . . . . . . . . . 11 99 5. Overlay Interconnection and Interworking Scenarios . . . . . 12 100 5.1. End-to-end overlay . . . . . . . . . . . . . . . . . . . 12 101 5.2. Virtual-network overlay VPN interworking . . . . . . . . 12 102 5.2.1. Normalized interworking via VRF . . . . . . . . . . . 13 103 5.2.2. Seamless VPN interworking . . . . . . . . . . . . . . 13 104 6. Virtual-Network Overlay Encapsulation Capability . . . . . . 13 105 6.1. Need for Capability Negotiation . . . . . . . . . . . . . 13 106 6.2. Capability Specification . . . . . . . . . . . . . . . . 14 107 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 108 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 109 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 110 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 111 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 112 10.2. Informative References . . . . . . . . . . . . . . . . . 16 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 115 1. Introduction 117 Virtual network overlays are increasingly being designed and deployed 118 in various types of networks, including data center networks. These 119 virtual network overlays can be used to provide both Layer-2 and 120 Layer-3 network services to hosts at the network edge. New 121 encapsulations are being defined and standardized to support these 122 virtual networks. These encapsulations are primarily based on IP 123 transport, such as VXLAN and NVGRE. A significant characteristic of 124 these encapsulations is the presence of an embedded virtual network 125 identifier field that is part of the encapsulation header. The use 126 of these encapsulations is defined in [VXLAN] and [NVGRE] and is 127 being currently worked on as part of the NVO3 architecture [NVO3]. 129 BGP based Layer-3 VPNs, as specified in RFC 4364, provide an industry 130 proven and well-defined solution for supporting Layer-3 virtual 131 network services. The Layer-3 VPN BGP control plane is eminently 132 suitable to provide a Layer-3 network virtualization solution in the 133 data center. 135 However, RFC 4364 mechanisms use MPLS labels as the mechanism to 136 provide the network virtualization capability in the data plane. An 137 MPLS label is signaled by a device advertising a VPN-IP route. This 138 label can identify the virtual network when the device processes 139 packets received with that label. RFC 4364 does allow an MPLS label 140 to be carried in an IP tranport encapsulation such as MPLS-in-GRE. 142 This document specifies procedures to use the new IP-based virtual 143 network overlay encapsulations such as VXLAN and NVGRE, while 144 continuing to leverage the BGP based Layer-3 VPN control plane 145 techniques and extensions. It also describes how virtual network 146 overlays based on these encapsulations can efficiently interconnect 147 with one another and with existing MPLS based L3VPN networks. 149 This document describes the protocol extensions necessary to allow 150 advertising a VPN-IP NLRI with an attached VN-ID as well as an 151 encapsulation attribute indicating the type of enapsulation, for 152 example, VXLAN or NVGRE. 154 There are aspects of the signaling of encapsulation and VN-ID that 155 can be leveraged across different kinds of services. Hence, the 156 generic overlay encapsulation signaling extensions are defined in 157 [remote-next-hop]. The current document provides the necessary 158 context of how these extensions are used with the BGP IP-VPN NLRIs. 160 1.1. Requirements Language 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in RFC 2119 [RFC2119]. 166 1.2. Terminology 168 VM: Virtual Machine 170 Edge device: The edge device is where end-hosts (eg. application VMs) 171 attach to the overlay. This is where the tunnel encapsulation 172 starts. It's called NVE in the NVO3 terminology. The NVE is 173 equivalent to a VPN PE in the context of BGP L3VPNs. 175 1.3. Control plane signaling requirements 177 While considering the leverage of the BGP L3VPN control plane with 178 the IP overlay technologies, the following requirements should be 179 supported. 181 1. Signal VN-ID with VPN-IP routes, that can be used with IP based 182 overlay encapsulations. 184 2. Support signaling of multiple encapsulations per edge device. 186 3. Have flexibility to support single and per-encapsulation VN-ID 187 spaces if needed. 189 4. Support both device-local and domain-global VN-ID/label spaces. 191 5. Support per-prefix granularity for VN-ID/encapsulation. 193 6. Support interoperability with legacy IP-VPN PEs. 195 7. Be efficient in signaling to provide good scalability. 197 8. Minimize protocol and deployment overhead. 199 1.4. Control plane model 201 The virtual network overlay described in this document uses regular 202 BGP peering on the edge devices for policy constrained route 203 distribution. A typical deployment would use Route Reflectors. 205 It is also feasible for an alternative protocol or provisioning 206 framework to be used to control the forwarding plane population and 207 forwarding behavior on the edge devices, as described in [vpe- 208 framework]. 210 The extensions specified here are compatible with both approaches. 212 1.5. Overlay Encapsulations 214 Different tunnel encapsulations may be used to realize an overlay 215 virtual network. Based on the encapsulation type being used, the 216 virtual network identifier is appropriately encoded in the 217 encapsulation header. 219 An overlay network may use the IP based VN-ID encapsulations such as 220 VXLAN and NVGRE. It may also use an MPLS based encapsulation such as 221 MPLS-in-GRE. 223 When VXLAN encapsulation is used, the virtual network identifier is 224 carried as the 24-bit VNI in the VXLAN header. 226 When NVGRE encapsulation is used, the virtual network identifier is 227 carried as the 24-bit VSID in the NVGRE header. 229 When MPLS-in-GRE is used, the regular MPLS VPN label serves as the 230 data plane identifier for the virtual network or a specific 231 destination. 233 A given overlay edge device may support a single encapsulation type 234 or it may support multiple encapsulation types. In the latter case, 235 it may signal the multiple encapsulations so that a receiving device 236 can potentially use the one most suitable to it. An edge device may 237 use the same encapsulation(s) for all routes or for a subset of 238 routes. 240 2. Virtual Network Identifier 241 In RFC 4364 based Layer-3 VPNs, a 20-bit MPLS label is assigned to an 242 VPN-IP route by the device that advertises the route, with itself as 243 the BGP next-hop. This label determines the forwarding behavior in 244 the data plane for traffic being switched as per that route. A 245 device receiving this route will encode this label in the packet 246 header when sending traffic to the advertiser. The advertiser will 247 take a unique forwarding action for traffic received with this label 248 when compared to traffic with other labels. The label may also be 249 used at the granularity of a VPN table and drive an IP lookup in that 250 table. This MPLS VPN label is independent of the transport 251 encapsulation that is used to carry this traffic to this PE from 252 other PEs across a core network. The transport encapsulation may be 253 native MPLS or be IP (eg, MPLS-in-GRE). 255 On the other hand, the various IP overlay encapsulations support a 256 virtual network identifier explicitly within their encapsulation 257 header. A virtual network identifier is a value that at a minimum 258 can identify a specific virtual network table in the forwarding 259 plane, and may be used to perform an IP address lookup. It may also 260 drive a specific forwarding action for packets destined to a 261 particular destination address or prefix. 263 It is typically a 24-bit value which can support upto 16 million 264 individual network segments or end-hosts. For instance, VXLAN 265 defines a 24-bit VNI while NVGRE uses a 24-bit VSID that is carried 266 in the GRE key field of the GRE header. 268 2.1. Virtual Network Identifier Scope 270 The scope of these virtual network identifiers fall into two broad 271 categories. It is important to support both cases, and in doing so, 272 ensure that the scope of the identifier be clear and the values not 273 conflict with each other. 275 2.1.1. Domain-scoped provisioned virtual network identifiers 277 Based on the provisioning mechanism used, a virtual network 278 identifier typically has a domain-wide scope within the network 279 domain, where a unique value is assigned to a given virtual network 280 or a given IP destination route at one or more edge devices. 282 This scope is useful in environments such as data centers where 283 virtual networks and VMs are automatically provisioned by central 284 orchestration systems. The system must support a very large number 285 of VN-IDs given the scope. 287 2.1.2. Per-device scoped allocated virtual network identifiers 288 There are scenarios where it is also necessary for an identifier to 289 have significance local to each network edge device that advertises 290 the route. In this case, the same value may be used by different 291 edge devices to represent different forwarding classes. 293 When it is locally scoped, the virtual network identifier may be 294 dynamically allocated by the advertising device. This allocation 295 follows the same semantics of an MPLS VPN label, and supports similar 296 forwarding behaviors as specified in RFC 4364. The device may, for 297 example, be a DC-WAN edge device that supports L3VPN Inter-AS Option 298 B and use this allocation for routes received from other ASBRs. 300 2.1.3. Global unicast table 302 The overlay encapsulation can also be used to support forwarding for 303 routes in the global or default routing table. A virtual network 304 identifier value can be allocated for the purpose as per the above 305 options. 307 2.1.4. Virtual Network Identifier Specification 309 The above requirements can be achieved in a simple manner by 310 splitting the virtual network ID number space to support both domain- 311 wide and device-local scopes. 313 o Values upto 1 million (or less than 20 bits) SHOULD be treated 314 with the same semantics as MPLS VPN labels and have significance 315 local to the advertiser. 317 For future expansion, this draft stipulates that the 16 numerical 318 values in the end of the VN-ID range be reserved for future use. 319 These special values could be used to indicate the presence of other 320 types of IP payloads. 322 o Values greater than 1 million (greater than 20 bits) SHOULD be 323 treated as per their original definition, ie domain-wide scoped 324 values. 326 These limits are not mandatory, but are recommended defaults. As 327 long as the provisioning system can ensure conflict-free operation, 328 the boundary between local and domain scoped ranges can be adjusted 329 higher or lower by configuration. 331 o A virtual network identifier value of zero SHOULD be used by 332 default to indicate the global or routing table. 334 2.2. Signaling Virtual Network Identifiers 335 2.2.1. Signaling Requirements 337 The Introduction section listed the desirable characteristics of 338 signaling of VN-IDs. This section elaborates on a couple of those 339 requirements. 341 o The device may support a single VN-ID space across all its 342 supported encapsulations. 344 This is expected to be common deployed scenario. A given edge device 345 will be provisioned by a single network orchestrator or controller. 346 The device may support multiple encapsulations in order to 347 interoperate with remote edge devices that support a different 348 encapsulation. However, the single network orchestrator will manage 349 the VN-ID space that will be common across multiple encapsulations on 350 this device. 352 o A device may support an independent VN-ID space per-supported 353 encapsulation. 355 This is expected to be applicable mostly at network gateway devices 356 that interconnect two different overlay domains and support the same 357 virtual network across these domains. These border devices are 358 likely to be managed by two different orchestrators, and hence need 359 to support different VN-ID spaces. In this case, they typically 360 advertise routes of one domain into another. 362 o An edge device may support an independent VN-ID space per- 363 supported encapsulation. 365 This is assumed to not be a commmon scenario, where an edge device 366 within the domain is being shared or managed by multiple 367 orchestration systems. However, in case this scenario must be 368 supported, the edge device must be able to support multiple distinct 369 VN-ID spaces. An alternative scheme would be to divide the VN-ID 370 range among the orchestration systems. 372 o It is required to support prefix-level VN-ID assignment. 374 Supporting prefix-level granularity is useful in various scenarios, 375 for example, at an interworking point between DC (VXLAN) and WAN 376 (MPLS). 378 2.2.2. Signaling Specification 380 This document specifies two options for signaling VN-IDs. 382 1. The VN-ID is encoded within an Virtual-Network Overlay 383 encapsulation attribute that also contains the encapsulation type and 384 associated parameters. 386 This enables the device to signal a VN-ID per encapsulation that it 387 may support. For example, the device may use VN-ID1 for VXLAN and 388 VN-ID2 for NVGRE. The VN-ID is encoded as a 24-bit value in each 389 encapsulation attribute. 391 When multiple VN-IDs need to be signaled, one per overlay 392 encapsulation type, then the VN-ID MUST be included in the overlay 393 encapsulation attribute as defined in [remote-next-hop]. 395 When MPLS-in-GRE is one of the encapsulations, there is no change 396 from current behavior. The VPN label is encoded in the label field in 397 the IP-VPN NLRI. 399 2. The VN-ID is encoded in the label field in the IP-VPN NLRI. 401 This option is used when a device supports a single VN-ID space 402 across all encapsulations. The benefit of this encoding is it's 403 efficiency of packing, even when used for per-prefix VN-ID 404 assignment. With this option, the 24-bit VN-ID for VXLAN and NVGRE 405 is encoded as a 3-byte label field in the IP-VPN NLRI. 407 When a VN-ID or VPN label is to be signaled, the value MUST be 408 encoded in the 3-octet label field in the IP or IP-VPN NLRI. 410 This offers the most efficient packing of prefixes in BGP update 411 messages. The device may still advertise multiple encapsulation 412 types with this route, but they will all use the same VN-ID value. 414 An advertising device will select the suitable option as per the 415 requirements stated above, based on configuration. 417 3. Overlay Encapsulation specification 419 Signaling the VN-ID must be coupled with signaling the appropriate 420 overlay encapsulation type. An overlay encapsulation attribute MUST 421 be carried with each route. 423 The section above specified two options of signaling VN-ID. In both 424 options, the accompanying encapsulation attribute indicates that a 425 24-bit VN-ID is specified with the NLRI and must be encoded in the 426 signaled encapsulation header. 428 The encapsulation attribute also indicates the accompanying 429 parameters to be used in the packet header. 431 RFC 5512 defines a Tunnel Encapsulation Extended Community that can 432 be used to signal different tunnel types. It defines an Encapsulation 433 Sub-TLV that can be used to specify encapsulation parameters. 435 [remote-next-hop] specifies a Remote-Next-Hop attribute which reuses 436 the Encapsulation Sub-TLV from RFC 5512, but adds the flexibility to 437 signal the encapsulation attribute and parameters along with each 438 individual route. The address specified as the remote next-hop 439 identifies the end-point or destination of the encapsulated packets 440 that use the dependent routes as well as the tunnel encapsulation 441 parameters. 443 Hence, the Remote-Next-Hop attribute is used to signal VN-ID 444 encapsulations. New tunnel types are defined for VXLAN, NVGRE and 445 MPLS-in-GRE. The format for the tunnel parameters are specified in 446 [remote-next-hop]. 448 3.1. Encapsulation for VXLAN and NVGRE 450 When VXLAN and NVGRE encapsulations are used, the header by 451 definition contains an Ethernet MAC address within the overlay 452 header. When these encapsulations are used for Layer-3 as specified 453 in this document, the MAC addresses are not relevant. A single well- 454 known MAC address may be specified for the purpose of 455 deterministically driving a Layer-3 lookup based on the inner IP or 456 IPv6 address. 458 Alternatively, an overlay egress edge device device may choose to 459 specify a MAC address as part of the encapsulation header in its 460 route advertisement. In this case, any ingress edge device sending 461 traffic as per this route MUST use the above specified MAC address as 462 the destination MAC address in the header. The egress device may use 463 this address to drive the Layer-3 table lookup or for other purposes. 465 3.2. Encapsulation for MPLS-in-GRE 467 When MPLS-in-GRE is one of the encapsulations, there is no change 468 from current behavior. A tunnel type of [MPLS-in-GRE] as defined in 469 RFC 5512 is used in the Remote-Next-Hop attribute. 471 3.3. Multiple encapsulations 473 A given overlay edge device MAY advertise multiple Encapsulation Sub- 474 TLVs, in order to signal multiple encapsulations. It MAY encode a 475 different VN-ID in each Sub-TLV as per rules specified earlier. 477 A receiving edge device may support one or more encapsulations that 478 are signaled by the advertising edge device. In that case, the 479 receiving device can select any of these encapsulations for sending 480 traffic to the advertiser. If a receiving device supports no 481 encapsulations that were signaled by the advertiser, then it will not 482 send any traffic for these routes to the advertiser. 484 3.4. Gateway device encapsulation handling 486 When an intermediate gateway device changes the BGP next-hop to self 487 before propagating a received route, it may need to advertise a new 488 overlay encapsulation attribute with the local address as the 489 endpoint. While doing so, it MAY use an overlay encapsulation type 490 that is different from the received route. It MAY also signal a 491 different VN-ID or VPN label than what it received, as described in 492 the various VN-ID requirements and rules earlier. 494 4. Forwarding behavior 496 o Locally assigned virtual network identifiers 498 When the virtual network identifier is locally assigned, forwarding 499 based on the identifier at the advertising device follows the 500 semantics of an MPLS VPN label. The VN-ID may either drive an IP 501 table lookup or provide a seamless binding to an output VN-ID or 502 label. 504 o Domain-scoped provisioned virtual network identifiers 506 With a provisioned VN-ID, forwarding behavior at a device which is 507 provisioned with this value is governed by the forwarding action that 508 has been provisioned. As one example, the VN-ID may be set up to 509 represent a specific IP VRF table on all relevant edge devices, 510 causing incoming packets with this VN-ID to undergo an IP lookup. 511 Alternatively, the VN-ID may be configured on only one or two edge or 512 border devices to directly forward incoming packets to an attached 513 end-host, without undergoing an IP lookup. 515 In either case, the forwarding behavior at any ingress edge device 516 (physical or virtual) remains the same. The ingress edge device adds 517 an encapsulation as signaled by the advertising device, and includes 518 the VN-ID in that encapsulation header. 520 5. Overlay Interconnection and Interworking Scenarios 522 Multiple virtual network overlay domains may be inter-connected using 523 a couple of approaches. Both these approaches may co-exist in the 524 same data center, and be used for connectivity to different kinds of 525 external networks. 527 5.1. End-to-end overlay 529 The IP overlay encapsulation or tunnel extends end-to-end between 530 edge devices in different data centers. 532 IP routes for hosts attached to each edge device are exchanged 533 between the overlay domains either via route exchange between BGP 534 speakers in each overlay domain, or via an orchestration/controller 535 framework that manages the domains. The two networks may be located 536 within the same ASN or may extend across ASes. 538 The routes are propogated to various edge device via the control 539 plane mechanism used in the DC, along with the encapsulation and VN- 540 ID or label to be used for sending traffic to a given destination 541 edge device. All intermediate devices in the forwarding path between 542 the two edge devices simply transport the IP encapsulated overlay 543 traffic. 545 The tunnel endpoints, ie the edge devices need to be reachable across 546 the ASes. This reachability may be provided by BGP peering across 547 ASes. 549 5.2. Virtual-network overlay VPN interworking 551 The overlay encapsulation terminates at a border router such as the 552 DC-WAN gateway device. The gateway device may re-encapsulate packets 553 in another header when sending it onwards. This requires an 554 interworking function which can be of multiple types. 556 5.2.1. Normalized interworking via VRF 558 The overlay based virtual network terminates into an L3VPN VRF at the 559 DC-WAN gateway device. Internal routes of the DC as well as the 560 external routes received from the WAN router are installed in the VRF 561 forwarding table at the DC gateway router. The DC gateway will 562 perform an IP lookup and forward traffic after doing the appropriate 563 output MPLS or IP overlay/VPN encapsulation. 565 5.2.2. Seamless VPN interworking 567 In this case, the DC Gateway router performs a direct translation of 568 VN-IDs/labels while switching packets between the DC and WAN 569 interfaces without doing an IP lookup. The forwarding table at the 570 DC Gateway router is set up to do a VN-ID or VPN label lookup and 571 derive the output VN-ID or VPN label. The DC Gateway Router can act 572 as an Inter-AS Option-B ASBR/ABR peering with other ASBRs/ABRs. 574 6. Virtual-Network Overlay Encapsulation Capability 576 6.1. Need for Capability Negotiation 578 When the MP-BGP NLRIs are used along with a VN-ID based 579 encapsulation, the MPLS label field in the NLRI is either not used or 580 is used to indicate the presence of a VN-ID that must be included in 581 the corresponding overlay encapsulation packet header while sending 582 data. A device that supports vanilla RFC 4364 based IP-VPNs but does 583 not understand the extensions specified in this document may not 584 interpret the received MP-BGP NLRI as intended, potentially causing 585 inconsistent forwarding plane behavior. In order to avoid this 586 situation, such devices must not receive the modified NLRIs. The 587 presence of a capability protect against this issue and ensures 588 interoperability with vanilla IP-VPN peers. 590 [RFC5492] defines a mechanism to allow two peering BGP speakers to 591 discover if a particular capability is supported by each other and 592 thus whether it can be used between them. This document defines a 593 new BGP capability that can be advertised using [RFC5492] and is 594 referred to as the Virtual-Network Overlay Encapsulation capability. 596 A BGP speaker MUST only advertise to a BGP peer the corresponding MP- 597 BGP NLRIs alongwith a VN-ID if the BGP speaker has first ascertained 598 via BGP Capability Advertisement that the BGP peer supports the 599 Virtual-Network Overlay Encapsulation capability. 601 With the Virtual-Network Overlay Encapsulation Capability, a VN- 602 capable BGP speaker will detect peers that are not capable of 603 processing VN-ID encapsulation information received in BGP updates. 604 The speaker MUST not send any VPN-IP routes that contain only a VN-ID 605 based encapsulation to such peers. If the route contains both a VN- 606 ID encapsulation and an MPLS-in-GRE encapsulation, the speaker MAY 607 send the route to the legacy peer with only the MPLS encapsulation 608 information, and with the VN-ID encapsulation information removed. 610 If routes are advertised by a speaker via a Route Reflector (RR), 611 then the RR MUST advertise the BGP capability for it to receive 612 routes with VN-ID information from the speaker. 614 When a next-hop address needs to be passed along unchanged (e.g., by 615 an RR), its encoding MUST NOT be changed. If a particular RR client 616 cannot handle that encoding (as determined by the BGP Capability 617 Advertisement), then the NLRI in question cannot be distributed to 618 that client. The RR may, as above, send the route with only the 619 MPLS-in-GRE encapsulation information to such legacy peers. 621 6.2. Capability Specification 623 A BGP speaker that is capable of processing VN-ID based encapsulation 624 information in BGP updates as per this specification MUST use the 625 Capability Advertisement procedures defined in [RFC5492] with the 626 Virtual-Network Overlay Encapsulation Capability. The fields in the 627 Capabilities Optional Parameter MUST be set as follows: 629 o The Capability Code field MUST be set to 71, indicating the 630 capability. 632 o The Capability Length field is set to a variable value that is the 633 length of the Capability Value field (which follows). 635 o The Capability value field has the following format: 637 +-----------------------------------------------------+ 638 | NLRI AFI - 1 (2 octets) | 639 +-----------------------------------------------------+ 640 | NLRI SAFI - 1 (2 octets) | 641 +-----------------------------------------------------+ 642 | ..... | 643 +-----------------------------------------------------+ 644 | NLRI AFI - N (2 octets) | 645 +-----------------------------------------------------+ 646 | NLRI SAFI - N (2 octets) | 647 +-----------------------------------------------------+ 648 where: 650 * each NLRI AFI, NLRI SAFI pair indicates the BGP NLRI address 651 family for which the speaker can process the VN-ID information. 653 * the AFI and SAFI values are defined in the Address Family 654 Identifier and Subsequent Address Family Identifier 655 registries maintained by IANA. 657 Since this document only concerns itself with the advertisement of 658 IP NLRI and VPN-IP NLRIs, this specification specifies the 659 following values in the Capability Value field of the above 660 capability: 662 o NLRI AFI = 1 (IPv4), 2 (IPv6) 664 o NLRI SAFI = 1, 2, 4, or 128 666 It is expected that if new AFI/SAFIs can use this in the future, 667 then these AFI/SAFIs can be included in the Capability values. 669 7. Acknowledgements 671 The authors would like to acknowledge and thank Nabil Bitar, Dave 672 Smith, Maria Napierala, Robert Raszuk, Eric Rosen, Ashok Ganesan and 673 Luyuan Fang for their input and feedback. 675 8. IANA Considerations 677 This document defines, in Section N, a new Capability Code to 678 indicate the Virtual-Network Overlay Encapsulation Capability in the 679 [RFC5492] Capabilities Optional Parameter. The value for this new 680 Capability Code is 71, which is in the range set aside for allocation 681 using the "FCFS" policy defined in [RFC5226]. There are no 682 additional requirements to IANA at this time. A specific VN-ID range 683 may be reserved for future use as applications for carrying payloads 684 different than regular IP/VPN packets emerge in future. 686 9. Security Considerations 688 This draft does not add any additional security implications to the 689 BGP/L3VPN control plane. All existing authentication and security 690 mechanisms for BGP apply here. 692 There are security considerations pertaining to IP based overlay or 693 tunnel encapsulations which are described in the respective overlay 694 encapsulation specifications as well as in RFC 5512. 696 There are certain measures that may be taken by default to increase 697 the level of security provided at the overlay edge devices. 699 When an IP-based overlay encapsulation is used within a domain such 700 as a data center, the network edge devices can enforce a default 701 forwarding access rule to restrict the acceptance of such overlay 702 encapsulated packets on their access interfaces attached to servers 703 or VMs. 705 For example, when VXLAN is being used, an edge device may be directed 706 to filter any VXLAN encapsulated packets (identified by the UDP port 707 number) on their access interfaces. This rule can be further 708 augmented by checking that the destination IP address of such VXLAN 709 packets does not fall in the prefix range allocated to edge device 710 addresses. Similarly, a DC edge device may be directed to not accept 711 any VXLAN encapsulated packets on its interfaces connected to 712 external routers, depending on the interconnectivity option being 713 used. 715 10. References 717 10.1. Normative References 719 [I-D.mahalingam-dutt-dcops-vxlan] 720 Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 721 L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A 722 Framework for Overlaying Virtualized Layer 2 Networks over 723 Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan-09 724 (work in progress), April 2014. 726 [I-D.sridharan-virtualization-nvgre] 727 Sridharan, M., Greenberg, A., Venkataramaiah, N., Wang, 728 Y., Duda, K., Ganga, I., Lin, G., Pearson, M., Thaler, P., 729 and C. Tumuluri, "NVGRE: Network Virtualization using 730 Generic Routing Encapsulation", draft-sridharan- 731 virtualization-nvgre-04 (work in progress), February 732 2014. 734 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 735 Requirement Levels", BCP 14, RFC 2119, March 1997. 737 [min_ref] authSurName, authInitials., "Minimal Reference", 2006. 739 10.2. Informative References 741 [I-D.fang-l3vpn-virtual-pe] 742 Fang, L., Ward, D., Fernando, R., Napierala, M., Bitar, 743 N., Rao, D., Rijsman, B., and S. Ning, "BGP IP VPN Virtual 744 PE", draft-fang-l3vpn-virtual-pe-05 (work in progress), 745 July 2014. 747 [I-D.narten-iana-considerations-rfc2434bis] 749 Narten, T. and H. Alvestrand, "Guidelines for Writing an 750 IANA Considerations Section in RFCs", draft-narten-iana- 751 considerations-rfc2434bis-09 (work in progress), March 752 2008. 754 [I-D.vandevelde-idr-remote-next-hop] 755 Velde, G., Patel, K., Rao, D., Raszuk, R., and R. Bush, 756 "BGP Remote-Next-Hop", draft-vandevelde-idr-remote-next- 757 hop-07 (work in progress), June 2014. 759 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 760 June 1999. 762 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 763 BGP-4", RFC 3107, May 2001. 765 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 766 Text on Security Considerations", BCP 72, RFC 3552, July 767 2003. 769 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 770 Protocol 4 (BGP-4)", RFC 4271, January 2006. 772 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 773 Networks (VPNs)", RFC 4364, February 2006. 775 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 776 Subsequent Address Family Identifier (SAFI) and the BGP 777 Tunnel Encapsulation Attribute", RFC 5512, April 2009. 779 Authors' Addresses 781 Dhananjaya Rao 782 Cisco 783 San Jose 784 USA 786 Email: dhrao@cisco.com 788 John Mullooly 789 Cisco 790 New Jersey 791 USA 793 Email: jmullool@cisco.com 794 Rex Fernando 795 Cisco 796 San Jose 797 USA 799 Email: rex@cisco.com