idnits 2.17.1 draft-ietf-l3vpn-end-system-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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 15, 2016) is 2682 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) ** Obsolete normative reference: RFC 5512 (Obsoleted by RFC 9012) ** Downref: Normative reference to an Informational RFC: RFC 7348 -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Mackie 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track L. Fang 5 Expires: June 18, 2017 eBay 6 N. Sheth 7 Juniper Networks 8 M. Napierala 9 AT&T Labs 10 N. Bitar 11 Nokia 12 December 15, 2016 14 BGP-Signaled End-System IP/VPNs 15 draft-ietf-l3vpn-end-system-06 17 Abstract 19 This document describes a solution in which the control plane 20 protocol specified in BGP/MPLS IP VPNs is used and extended via the 21 XMPP protocol to provide a Virtual Network service to end-systems 22 (hosts). These end-systems may be used to provide network services 23 or may host end-user applications. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 18, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Applicability of BGP IP VPNs . . . . . . . . . . . . . . . . 4 63 4. Virtual Network End-Points . . . . . . . . . . . . . . . . . 7 64 5. VPN Forwarder . . . . . . . . . . . . . . . . . . . . . . . . 9 65 6. XMPP signaling protocol . . . . . . . . . . . . . . . . . . . 11 66 7. End-System Route Server behavior . . . . . . . . . . . . . . 21 67 8. Operational Model . . . . . . . . . . . . . . . . . . . . . . 21 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 69 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 70 11. XML schema . . . . . . . . . . . . . . . . . . . . . . . . . 26 71 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 72 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 73 13.1. Normative References . . . . . . . . . . . . . . . . . . 29 74 13.2. Informational References . . . . . . . . . . . . . . . . 30 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 77 1. Introduction 79 This document describes the requirements for a network virtualization 80 solution that provides an IP service to end-system virtual 81 interfaces. It then discusses how the control plane for BGP IP VPNs 82 [RFC4364] can be used and extended via the XMPP protocol to provide a 83 solution that meets these requirements. Subsequent sections provide 84 a detailed discussion of the control and forwarding plane components. 86 In BGP IP VPNs, Customer Edge (CE) interfaces connect to a Provider 87 Edge (PE) device which provides both the control plane and VPN 88 encapsulation functions required to implement a Virtual Network 89 service. This document describes how the control plane and 90 forwarding functionality of a PE device can be decoupled in order to 91 enable the forwarding functionality to be implemented in multiple 92 devices. For instance, the forwarding function can be implemented 93 directly on the operating system of application servers or network 94 appliances. 96 1.1. Terminology 98 This document makes use of the following terms: 100 End-System: A compute node whose primary function is to run 101 applications. It is assumed that end-systems support multiple 102 application instances (e.g., virtual machines), each with its 103 independent network configuration. 105 End-System Route Server: A software application that implements the 106 control plane functionality of a BGP IP VPN PE device and an XMPP 107 server that interacts with VPN Forwarders. 109 Virtual Interface: An interface in an end-system that is used by a 110 virtual machine or by applications. It performs the role of a CE 111 interface in a BGP IP VPN network. This is similar to the concept 112 of Virtual Access Point (VAP) in RFC 7365 [RFC7365]. 114 VPN Forwarder: The forwarding component of a BGP IP VPN PE device. 115 This functionality may be co-located with the virtual interface or 116 implemented by an external device. 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [RFC2119]. 122 2. Requirements 124 Network virtualization is used in both service provider as well as 125 enterprise networks to support multi-tenancy and network-based access 126 control. It may also be used to facilitate application instance 127 mobility. 129 Multi-tenancy allows a physical network to provide services to 130 multiple "customers" or "tenants", whether these are external 131 entities in the case of a Service Provider providing managed VPN 132 services, or internal departments of an enterprise sharing an IT 133 facility. Multi-tenancy requires isolation of traffic and routing 134 information between tenants. 136 Within a tenant, it is often required to create multiple distinct 137 virtual networks, in order to be able to provide network-based access 138 control. In this service model, each virtual network behaves as a 139 "Closed User Group" (CUG) of virtual interfaces that are allowed to 140 exchange traffic freely, while traffic between virtual networks is 141 subject to access controls. This scenario can be found in enterprise 142 campus networks, branch offices and data centers. 144 It is often the case when network access control is used, that the 145 traffic patterns are such that there is significantly more traffic 146 crossing a CUG boundary than staying within such boundary. As an 147 example, in campus networks it is common to segregate users into CUGs 148 based on some classification such as the user's department. Campus 149 networks often see traffic patterns in which almost all the traffic 150 flows northbound to the data center or internet boundaries. Similar 151 traffic patterns can be found in multi-tier applications in IT data 152 centers. 154 Virtual interfaces are often configured to expect the concept of IP 155 subnet to match its closed user group. A network virtualization 156 solution should be able to provide this concept of IP subnet 157 regardless of whether the underlying implementation uses a multi- 158 access network or not. 160 Virtual interfaces should be able to directly access multiple closed 161 user groups without needing to traverse a gateway. Network access 162 policy should allow this access whether the source and destination 163 CUGs for a particular traffic flow belong to the same tenant or 164 different tenants. It is often the case that infrastructure services 165 are provided to multiple tenants. One such example is voice-over-IP 166 gateway services for branch offices. 168 Independently, but often associated with the previous two functions, 169 IP mobility is another network function that can be implemented using 170 network virtualization. By abstracting the externally visible 171 network address from the underlying infrastructure address, mobility 172 can be implemented without having to rely upon home agents or large 173 L2 broadcast domains. 175 IP Mobility requires the ability to "move" a virtual interface 176 without disrupting its TCP (or UDP) transport sessions. This 177 requires a mechanism that can efficiently communicate the mappings 178 between logical and physical addressing. 180 IP Mobility can be a result of devices physically moving (e.g., a 181 WiFi enabled laptop) or workload being diverted between physical 182 systems such as network appliances or application servers. 184 3. Applicability of BGP IP VPNs 186 BGP IP VPNs [RFC4364] is the industry de-facto standard for providing 187 "closed user group" functionality in WAN environments. It is used by 188 service providers in environments where several millions of routes 189 are present. It supports both isolated VPNs as well as overlapping 190 VPNs (often referred to as "extranets"). 192 The BGP IP VPN control plane has been designed to be able to 193 distribute the mapping between virtual address and location (next- 194 hop) to the subset of network nodes for which this information is 195 relevant, whenever that mapping changes. This provides an efficient 196 mechanism to address IP mobility requirements as compared to methods 197 that depend on a (cached) mapping request from the end-systems. 199 In its traditional usage in Service Provider networks, BGP IP VPN 200 functionality is implemented in a Provider Edge (PE) device that 201 combines both BGP signaling as well as VRF-based forwarding 202 functions. In practice, most PE devices in current use are multi- 203 component systems with the signaling and forwarding functionality 204 actually implemented in different processors attached to an internal 205 network. 207 This document assumes a similar separation of functionality in which 208 software appliances, the End-System Route Servers, implement the 209 control plane functionality of a PE device and a VPN Forwarder 210 implements the forwarding function usually found in a PE device 211 "line-card". The VPN Forwarder functionality may be co-located with 212 the end-system (e.g., implemented in the hypervisor switch or host OS 213 network drivers) or it may be external. For instance, residing in a 214 data center switch or specialized appliance. 216 Operationally, BGP IP VPN technology has several important 217 characteristics: 219 o It has a high-level of aggregation between customer interfaces and 220 managed entities (Provider Edge devices). 222 o It defines VPNs as policies, allowing an interface to directly 223 exchange traffic with multiple VPNs and allowing for the topology 224 of the virtual network to be modified by modifying the policy 225 configuration. 227 o It scales horizontally in terms of event propagation. By 228 increasing the number of signaling devices implementing the PE 229 control plane, it is possible to decrease the load on each 230 signaling device for events that originate in a specific location 231 and which must be propagated across the network. 233 The last point is particularly relevant to the convergence 234 characteristics required for large scale deployments. BGP's 235 hierarchical route distribution capabilities allow a deployment to 236 divide the workload by increasing the number of End-System Route 237 Servers. 239 As an example consider a topology in which 100 End-System Route 240 Servers are deployed in a network each serving a subset of the VPN 241 forwarding elements. The Route Servers inter-connect to two top- 242 level BGP Route Reflectors [RFC4456]. 244 If an event (i.e., a VPN route change) needs to be propagated from a 245 specific end-system to 10,000 clients randomly distributed across the 246 network, each of the End-System Route Servers must generate 100 247 updates to its respective downstream clients. 249 By modifying this topology such that another 100 End-System Route 250 Servers are added, each Route Server is now responsible for 251 generating 50 client updates. This example illustrates the linear 252 scaling properties of BGP: doubling the number of Route Servers 253 (i.e., the processing capacity) reduces by half the number of updates 254 generated by each one (i.e. the load at each processing node is 255 halved). 257 The same horizontal scaling techniques can be applied to the Route 258 Reflector layer in the example above by dividing the VPN Route space 259 according to some pre-defined criteria (for instance VPN route 260 target) and using a pair of Route Reflectors per subset. 262 In the previous example we assumed a dense membership in which all 263 Route Servers have local clients that are interested in a particular 264 event. BGP also optimizes the route distribution for sparse events. 265 The Route Target Constraint [RFC4684] extension, builds an optimal 266 distribution tree for XMPP stanza and message propagation based on 267 VPN membership. It ensures that only the PEs with local receivers 268 for a particular event do receive it also decreasing the total load 269 on the upstream BGP speaker. 271 In the WAN environment, BGP IP VPN control plane scaling is not 272 primarily focused on route convergence times, but on the memory 273 footprint of embedded devices. While memory footprint does not have 274 a similar linear scaling behavior as load, memory technology 275 available to software appliances is often at 10x the scale of what is 276 commonly found in WAN environments, and so is not so much of a 277 concern. 279 The functionality present in the BGP IP VPN control plane addresses 280 the requirements specified in the previous section. Specifically, it 281 supports multiple potentially overlapping "groups", regular or "hub 282 and spoke" topologies and the scaling characteristics necessary. 284 The BGP IP VPN control plane supports not only the definition of 285 "closed user-groups" (VPNs in its terminology) but also the 286 propagation of inter-VPN traffic policies [RFC5575]. 288 Note that the signaling protocol itself is rather agnostic of the 289 encapsulation used on the wire as long as this encapsulation has the 290 ability to carry a label of sufficient length to enumerate all the 291 VPNs in an administrative domain (e.g. an MPLS label, which has 20 292 bits). 294 Several network environments use a network infrastructure that is 295 only capable of providing an IP unicast service. In order to support 296 them, implementations of this document should support the MPLS in GRE 297 [RFC4023] encapsulation. Other encapsulations are possible, 298 including UDP-based encapsulations RFC 7510 [RFC7510] and VXLAN 299 [RFC7348]. 301 4. Virtual Network End-Points 303 This document assumes that end-systems support one or more virtual 304 network interfaces in addition to a physical interface that is 305 associated with the underlying network infrastructure. A virtual 306 network interfaces can be associated with a specific application via 307 a OS-dependent mechanisms like a Virtual Machine (VM), or they can be 308 used to provide network connectivity to all user applications in the 309 same way that a "VPN tunnel" interface is used to provide access 310 between an end-system (e.g., a laptop) and a remote corporate 311 network. 313 Each virtual network interface is assigned an IP addresses from a 314 subnet associated with a "closed user group" or VPN, while the 315 physical interface of the machine is addressed in the network 316 infrastructure topology. 318 A virtual network interface is connected to a VPN Forwarder. This 319 VPN Forwarder MAY be co-located in the end-system or external. In 320 cases where the VPN Forwarder is external to the end-system, they can 321 either be directly connected or interconnected with a dedicated 322 802.1Q VLAN on a per virtual interface basis. 324 Both static and dynamic IP address allocation can be supported. The 325 latter assumes that the VPN Forwarder implements DHCP relay or DHCP 326 proxy functionality. 328 Traffic that ingresses or egresses through a virtual network 329 interface is routed at the VPN Forwarder, which acts as the first-hop 330 router (in the virtual topology). The IP configuration on the client 331 side of this virtual network interface (e.g., in the guest OS) can 332 follow one of two models: 334 o Point-to-point interface model 336 o Multipoint interface model 338 In a point-to-point interface model, the VPN client routing table 339 (e.g., on the guest OS) contains the following routing entries: a 340 host route to the local IP address, a host route to the first-hop 341 router via the virtual interface and a default route to the first-hop 342 router. This is the model typically used in "VPN tunnel" 343 configurations or other access technologies such as cable deployments 344 or DSL. When this model is used, the first-hop router IP address is 345 either an address from the tenant's IP address space or a link-local 346 address. This address SHOULD be the same on all first-hop routers 347 across a specific deployment so that it does not change when a 348 virtual interface moves between end systems. 350 In a multi-point interface model, the VPN client routing table (e.g., 351 on the guest OS) contains the following routing entries: a host route 352 to the local IP address, a subnet route to the local interface and 353 optionally a default route to a specific router address within that 354 subnet. In this model, the VPN client IP stack will issue address 355 resolution requests for any IP addresses it considers to be directly 356 attached to the subnet. The VPN Forwarder SHALL answer all address 357 resolution requests via Proxy ARP [RFC1027].The same technique is 358 applicable when Neighbor Discovery is used to resolve IPv6 addresses. 359 Address resolution request SHOULD be answered using a virtual MAC 360 address which SHOULD be the same across all VPN Forwarders in a 361 specific deployment. This virtual MAC address SHALL default to the 362 VRRP [RFC5798] virtual router MAC address for Virtual Router 363 Identifier (VRID) 1. 365 When the virtual topology first-hop router resides on the same 366 physical machine, the host OS is responsible for mapping the virtual 367 interface with a VPN-specific routing table (without taking L2 368 addresses into consideration). In this case the MAC addresses known 369 to the guest OS are not used on the wire. 371 When the virtual topology first-hop router resides in an external 372 system (e.g., the first hop-switch) the virtual interface shall be 373 identified by the physical interface of the end-system and a 802.1Q 374 VLAN tag. The first-hop switch should use a virtual router MAC 375 address to answer any address resolution queries. 377 Whenever external VPN forwarding is used, and resiliency is desired, 378 multiple external VPN Forwarder may be employed in a redundant 379 configuration. It is desirable to use VRRP as a mechanism to control 380 the flow of traffic between the end-system and the external VPN 381 Forwarder. VRRP already defines the necessary procedures to elect a 382 single forwarder for a LAN. 384 This specification uses the VRRP virtual router MAC address as the 385 default L2 address for the VPN Forwarder, in order to support a 386 client virtual interface moving between locations. 388 While the VRRP Virtual Router MAC will be used to answer any address 389 resolution request made by the virtual interface client (e.g., the 390 guest VM) this does not imply that a single default router is elected 391 per virtual IP subnet. The ingress VPN Forwarder will perform an IP 392 forwarding decision based on the destination IP address of the 393 (payload) traffic. 395 VRRP router election is only relevant in selecting the VPN Forwarder 396 associated with a specific machine, when external forwarders are in 397 use. 399 5. VPN Forwarder 401 In this solution, the Host OS/Hypervisor in the end-system must 402 participate in the virtual network service. Given an end-system with 403 multiple virtual interfaces, these virtual interfaces must be mapped 404 onto the network by the end system OS such that applications on one 405 virtual interface cannot send traffic to networks they are not 406 authorized to communicate with or using source addresses not assigned 407 to the virtual interface. 409 When VPN forwarder functionality is implemented by the Host OS/ 410 Hypervisor, intermediate systems in the network do not require any 411 knowledge of the virtual network topology. This can simplify the 412 design and operation of the physical network. 414 When it is not possible or desirable to add the VPN forwarding 415 functionality to the end-system, it may be implemented by an external 416 system, typically located as close as possible to the end-system 417 itself. 419 Both models, co-located and external VPN Forwarder can co-exist in a 420 deployment. 422 In order to implement the BGP IP VPN Forwarder functionality a device 423 MUST implement the following functionality: 425 o Support for multiple "Virtual Routing and Forwarding" (VRF) 426 tables; 428 VRF route entries map prefixes in the virtual network topology 429 to a next-hop containing a infrastructure IP address and a 430 label allocated by the destination Forwarder. The VRF table 431 lookup follows the standard IP lookup (best-match) algorithm. 433 o Associate an end-system virtual interface with a specific VRF 434 table; 436 When the Forwarder is co-located with the end-system, this 437 association is implemented by an internal mechanism. When the 438 Forwarder is external the association is performed using the 439 MAC address of the end-system and an IEEE 802.1Q tag that 440 identifies the virtual interface within the end-system. 442 o Encapsulate outgoing traffic (end-system to network) according to 443 the result of the VRF lookup; 445 o Associate incoming packets (network to end-system) to a virtual 446 interface for direct forwarding, or to a VRF for lookup, according 447 to the label contained in the packet; 449 The VPN Forwarder MAY support the ability to associate multiple 450 virtual interfaces with the same VRF. When that is the case, locally 451 originated routes, that is IP routes to the local virtual interfaces 452 SHALL NOT be used to forward outbound traffic (from the virtual 453 interfaces to the outside) unless a route advertisement has been 454 received that matches that specific IP prefix and next-hop 455 information. This is intended to ensure that the forwarding behavior 456 is the same whether the VRF is shared or between multiple interfaces 457 of the same virtual-network or not. 459 As an example, if a given VRF contains two virtual interfaces, 460 "veth0" and "veth1", with the addresses 203.0.113.1/32 and 461 203.0.113.2/32 respectively, the initial forwarding state must be 462 initialized such that traffic from either of these interfaces does 463 not match the other's routing table entry. It may, for instance, 464 match a default route advertised by a remote system. Traffic 465 received from other VPN Forwarders, however, must be delivered to the 466 correct local interface. If at a subsequent stage a route is 467 received from the Route Server such that 203.0.113.2/32 has a next- 468 hop with the IP address of the local host and the correct label, the 469 system may subsequently install a local routing table entry that 470 delivers traffic directly to the "veth1" interface. This means that 471 forwarding table entries apply to downstream traffic only, by 472 default. This capability can be used to implement a hub-and-spoke 473 topology, if required. 475 The label which is associated with a virtual interface is of local 476 significance only and SHOULD be allocated by the VPN Forwarder. 478 When an external VPN Forwarder is used the end-system MUST associate 479 each virtual interface with a VLAN [IEEE.802-1Q] that is unique on 480 the end-system. The switching infrastructure SHOULD be configured 481 such that multi-destination frames sourced from an end-system are 482 only delivered to VPN Forwarders used by this end-system and not to 483 other end-systems. 485 6. XMPP signaling protocol 487 End-System Route Servers must be aware of VPN membership on each 488 Forwarder as well as what IP addresses are currently associated with 489 each virtual interface. 491 VPN Forwarders receive VPN route information from which to populate 492 their forwarding tables. External VPN Forwarders also need to 493 receive the virtual interface and IP address allocation events for 494 the end-system for which they are VPN forwarders. In this case, the 495 end-system assigns an 802.1Q VLAN tag to each virtual interface and 496 communicates that information to the Forwarder directly, or via the 497 Route Server. 499 In order to exchange this information this specification uses the 500 XMPP [RFC6120] protocol along with the Publish-Subscribe [pubsub] 501 extension. 503 VPN forwarders (both co-located and external) establish XMPP sessions 504 with End-System Route Servers, acting as XMPP clients. When an 505 external VPN Forwarder is used, end-systems MAY establish XMPP 506 sessions with VPN Forwarders. In such cases, external VPN Forwarders 507 act as XMPP servers for end-systems which are associated with them. 509 A VPN Forwarder MAY connect to multiple End-System Route Servers for 510 reliability. In this case it SHOULD publish its information to each 511 of the Route Servers. It MAY choose to subscribe to VPN routing 512 information from only one of the available Route Servers. In this 513 case, the Forwarder is responsible for switching subscriptions over 514 to an alternate Route Server in the case of Route Server failure. 515 Alternatively, it MAY choose to subscribe to VPN routing information 516 from more than one End-System Route Server. In this case, the 517 Forwarder is responsible for selecting which Route Server is 518 authoritative for each forwarding entry. The Route Servers SHOULD 519 produce the same forwarding information for each destination. The 520 VPN Forwarder is expected to select the entry that it deems as more 521 recent for positive updates. It SHOULD NOT consider a forwarding 522 entry to be withdrawn unless it is withdrawn by both Route Servers. 524 Each End-System Route Server MUST monitor the XMPP connection status 525 of each VPN Forwarder that is connected to it. The information 526 advertised by an XMPP client SHOULD be deleted after a configurable 527 timeout, after XMPP session closes. This timeout SHOULD default to 528 60 seconds. 530 An End-System Route Server MAY monitor the status of each VPN 531 Forwarder that is connected to it, using, for example, the BFD 532 [RFC5880] protocol and to delete advertised information after a 533 timeout when a failure is detected. The Route Server MAY choose to 534 immediately reduce the preference of routing information received 535 from an XMPP client for which a failure has been detected, either 536 through an XMPP session close event, or a failure detection mechanism 537 such as BFD. 539 +---------+ +--------+ 540 | RS |--------| BGP | 541 +---------+ +--------+ 542 / \ / 543 XMPP \ / 544 / \ / 545 +--------------------+ \ / 546 | End | VPN | \/ 547 | System | Forwarder | /\ 548 +--------------------+ / \ 549 \ / \ 550 XMPP / \ 551 \ / \ 552 +---------+ +--------+ 553 | RS |--------| BGP | 554 +---------+ +--------+ 556 VPN Forwarder Connected to Two Routing Systems 558 Figure 1 560 The figure above represents a typical configuration in which an end- 561 system with a co-located VPN Forwarder is directly connected to two 562 End-System Route Servers, which are in turn connected to multiple BGP 563 speakers which may be other L3VPN PEs or BGP route reflectors. 565 In deployment, the number of End-System Route Servers used will 566 depend on the desired Route Server to VPN Forwarder ratio which 567 affects the convergence time of event propagation. 569 The XMPP JID used by the client SHALL be a RFC 7622 [RFC7622] 570 compliant address that uniquely identifies it in its administrative 571 domain. The VPN Forwarder SHOULD use its hostname as JID, when 572 available, or a unique IP address within the infrastructure network 573 using its string representation. The same naming convention SHOULD 574 be used for an End System which has an XMPP session with an external 575 VPN Forwarder. 577 The XMPP JID used by an End-System Route Server SHOULD be the 578 constant string 'route-server@ietf.org'. 580 Each VPN shall be identified by an ASCII character string that SHOULD 581 NOT exceed 128 octets and MUST be unique within each administrative 582 domain. The VPN identifier is an attribute of each virtual 583 interface. It is assumed that a configuration management system 584 exists such that it provisions the Route Servers with VPN identifier 585 values and the VPN Forwarders with the mapping of virtual interface 586 to VPN identifier. Such a configuration management system is outside 587 the scope of this document. 589 Each VPN identifier corresponds to a Pub-Sub node in the Route Server 590 XMPP servers. This Pub-Sub nodes SHOULD be configured such that Pub- 591 Sub items are persistent and that event notifications include the 592 item payload. Implementations MAY choose to perform this operation 593 explicitly or implicitly by mapping XMPP subscription requests to an 594 event observer mechanism that tracks the VRF table corresponding to 595 the VPN in question. 597 When an external Forwarder is used, its control software MAY operate 598 as an XMPP server which processes requests from end-systems and SHALL 599 operate as a client of one or more End-System Route Servers. The 600 control software relays to the End-System Route Server(s) VPN 601 membership stanzas it receives from the end-system. VPN routing 602 information received from the Route Server(s) SHOULD NOT be 603 propagated to the end-system unless it specifically requests such 604 information. End systems MAY have sessions directly with the End- 605 System Route Servers, and in this case no XMPP sessions are required 606 with VPN Forwarders. 608 When a virtual interface is created on an end-system, the host End 609 System XMPP client SHALL generate an XMPP Subscribe stanza to its 610 server (a Route Server or the external VPN Forwarder). 612 Each Subscribe stanza SHALL be addressed to the JID of the Route 613 Server (e.g. route-server@ietf.org), using the VPN Identifier as the 614 NodeID. 616 If subsequent Virtual Interfaces are created with the same VPN 617 Identifier, and the previous Pub-Sub subscription is still in effect, 618 then additional XMPP Pub-Sub Subscribe stanzas SHOULD NOT be sent to 619 the End-System Route Server. 621 Example subscription request from co-located VPN Forwarder to Route 622 Server: 624 628 629 630 631 1 632 633 634 636 The above request instructs the End-System Route Server to start 637 populating the client's VRF table with any routing information that 638 is available for this VPN. The XMPP node 'vpn-customer-name' is 639 assumed to be implicitly created by the End-System Route Server. 640 Creation of a virtual interface may precede any IP address becoming 641 active on the interface, as is the case with VM instantiation. 643 The optional "instance-id" element allows the VPN Forwarder to 644 specify a unique 16 bit index that can be used by the Route Server to 645 automatically assign a Route Distinguisher (RD) to any route 646 subsequently advertised by the VPN Forwarder. In a scenario where 647 the VPN Forwarder is advertising reachability information to multiple 648 Route Servers it is desirable for reachability information to have an 649 RD composed of the VPN Forwarder identifier (e.g., IPv4 address) and 650 the "instance-id". 652 Example subscription request from end-system to external VPN 653 Forwarder: 655 659 660 661 662 663 100 664 665 666 667 669 When an external VPN Forwarder is used, the end-system SHOULD include 670 the VLAN identifier it assigned to the virtual interface as a 671 subscription option. This option is represented in the XMPP Pub-Sub 672 Subscribe stanza a data form [xep-0004] field with the name 673 "vpn#vlan_id". The example above uses the 802.1Q tag value of 100. 675 When a Route Server receives a subscription request for a specific 676 VPN identifier it SHALL treat this request as an implicit request for 677 item retrieval for all items in the Pub-Sub node that corresponds to 678 the VPN. 680 If at any point all Virtual Interfaces associated with a given VPN 681 Identifier are removed or deactivated from the End-System, then the 682 End System XMPP client SHOULD generate an XMPP Pub-Sub Unsubscribe 683 stanza to its server for the Pub-Sub node associated with the VPN 684 Identifier. 686 Example unsubscribe request from co-located VPN Forwarder to Route 687 Server: 689 693 694 697 698 700 For a collocated VPN forwarder, and for an external VPN forwarder 701 when there is an XMPP session with the End System, when an IP address 702 is added to a virtual interface and the interface is activated, the 703 end-system SHALL generate an XMPP Pub-Sub Publish request. This 704 request publishes an item containing a single entry element based on 705 the XML Schema Definition in Section 11. The ItemID of this item 706 MUST be generated by the VPN Forwarder such that the value is unique 707 within a Pub-Sub node. The ItemID MAY be formed by combining the VPN 708 Forwarder's IP address, the instance-id value, and the entry address 709 element. This format corresponds to the string representation of a 710 BGP L3VPN NLRI in which the Route Distinguisher is given by the VPN 711 Forwarder IP address and instance-id, and is easily identifiable by 712 network operators. However, the format and/or structure of the 713 ItemID is not stricly defined in this document, so long as uniqueness 714 is guaranteed. 716 Publish request from VPN Forwarder to End-System Route Server: 718 722 723 724 725 726 727 1 728
203.0.113.42
729 730 731 732 1 733
192.0.2.1
734 735 736 gre 737 udp 738 739 740 741 1 742 743 744 745 746 748 In this example, the VPN Forwarder JID is "forwarder@domain.org". 749 The VPN Identifier "vpn-identifier" is used as the value of the node 750 attribute of the subscribe element. The IP address of the Virtual 751 Interface is 203.0.113.42/32. The IP address of the VPN Forwarder is 752 192.0.2.1 and it supports receiving MPLS packets via both GRE and UDP 753 tunneling. Label 10000 has been assigned to this particular Virtual 754 Interface. 756 The End-System Route Server will convert the information received in 757 a 'publish' request into the corresponding BGP route information such 758 that: 760 o It associates the specific request with a local VRF which it 761 resolves by using the Pub-Sub 'node' attribute. 763 o It creates a BGP VPN route with a 'Route Distinguisher' (RD) which 764 contains a unique 32bit value per end-system plus a 16bit 765 instance-id, the specified IP prefix and 'label' received from the 766 VPN Forwarder as the Network Layer Reachability Information 767 (NLRI). The instance-id is either the value specified by the XMPP 768 client in the subscribe stanza for the specific pubsub node or a 769 locally generated value when that parameter is omitted. 771 o The BGP next-hop address is set to the address of the VPN 772 Forwarder. 774 o A BGP Tunnel Encapsulation Attribute [RFC5512] is generated for 775 each 'tunnel-encapsulation' element specified in the XMPP message. 777 o The route is optionally associated with a MAC Mobility extended 778 community [RFC7432] containing a sequence number for the route 779 advertisement. 781 Conversely, when an interface operational status is determined to be 782 down or an IP address is unconfigured the VPN forwarder generates an 783 XMPP retract message to withdraw the route advertisement. 785 Retract request from VPN Forwarder to End-System Route Server: 787 791 792 793 794 795 796 798 The retract stanza uses the ItemId to identify the item being 799 retracted. The example retract stanza above uses the L3VPN NLRI 800 string representation ItemId format used in the publish example. 802 Consistent with XMPP Pub-Sub [pubsub], event notifications will be 803 generated whenever a VPN route is added, modified or deleted. This 804 is true for VPN routes learned via XMPP clients as well as routes 805 learned via BGP. For VPN routes that are learned via BGP (rather 806 than XMPP clients) the Route Server SHOULD create XMPP Pub-Sub 807 Publish stanzas or otherwise take steps to publish a persistent item 808 under the NodeID associated with the VPN Identifier of the 809 appropriate VRF(s). Thus the Pub-Sub node will contain items for 810 every route for the associated VPN. Upon successfully publishing a 811 Pub-Sub item the XMPP server SHALL generate event notification 812 messages and send them to all VPN Forwarders that are actively 813 subscribed to that node. These event notification messages SHOULD be 814 sent as soon as possible (without delay) in order to facilitate 815 convergence and consistent reachability. 817 Example update notification message from Route Server to VPN 818 Forwarder: 820 821 822 823 824 825 826 1 827
203.0.113.42/32
828 829 830 831 1 832
192.0.2.1
833 834 835 gre 836 udp 837 838 839 840 1 841 842 843 844 ... 845 846 847 848 850 Notification messages SHOULD be generated whenever a VPN route is 851 added, modified or deleted. These notification messages SHOULD 852 contain only items that have been added, modified or deleted since 853 any previous information that was sent to the VPN Forwarder. 854 Notification messages can be segmented at the convenience of the 855 Route Server. 857 Note that the Update from the Route Server to the VPN Forwarder does 858 not contain the JID of the destination end-system. The "from" 859 attribute in the 'message' element contains the Route Server JID. 860 The XMPP messages are point-to-point in nature, between a Forwarder 861 and Route Server, even in the case when one XMPP publish request from 862 a Forwarder may cause the Route Server to generate one or more event 863 notifications. 865 When multiple possible routes exist for a given VPN IP address within 866 a VRF it is the responsibility of the Route Server to select the best 867 path to advertise to the VPN Forwarders. The routing entries 868 published by the Route Server to VPN Forwarders MAY include multiple 869 next-hops for the same forwarding entry. While BGP L3VPN NLRI 870 encodes a single next-hop, multiple NLRI with different RDs may 871 result in a single forwarding entry in a VRF with multiple next-hops. 872 This functionality is known as "vrf multipath" in standard BGP L3VPN 873 implementations. This "vrf multipath" behavior can be applied to 874 both BGP and XMPP learned routing information. The criteria used for 875 multipath selection is outside the scope of this document but SHOULD 876 be consistent between the Route Servers within an administrative 877 domain. 879 A VPN Forwarder uses locally originated information to generate MPLS 880 label forwarding state, and this used to forward downstream traffic 881 (i.e., traffic received from the network). Upstream traffic (i.e., 882 received from a virtual interface) is forwarded according to the 883 routing information received from one or more Route Servers that the 884 VPN forwarder has an XMPP session with. In the case where multiple 885 Router Servers are providing routing information for a specific NLRI 886 the VPN Forwarder SHOULD select the following algorithm: 888 o Prefer the highest local-preference value 890 o Prefer the highest sequence-number 892 o Tie-break on the Route Server IP address 894 When routes are withdrawn, the End-System Route Server generates an 895 item "retract" request. 897 Route advertisements can have an optional sequence-number which help 898 the route server determine the most recent route advertisement. The 899 sequence number is determined by a mechanism outside the scope of 900 this document. One option is to use time synchronization between 901 compute nodes in order to have a globally coordinated timestamp. 902 This timestamp can be used to identify the time of interface creation 903 on the compute node. 905 Routes can also be associated with a "local-preference" attribute. 906 This attribute maps to the BGP attribute of the same name for the 907 purposes of route selection. 909 7. End-System Route Server behavior 911 End-System Route Servers SHALL support the BGP address families: VPN- 912 IPv4 (1, 128), VPN-IPv6 (2, 128) and RT-Constraint (1, 132) 913 [RFC4684]. 915 When an End-System Route Server receives a request to create or 916 modify a VPN route it SHALL generate a BGP VPN route advertisement 917 with the corresponding information. 919 It is assumed that the End-System Route Servers have information 920 regarding the mapping between the tuple ('end-system', 'vpn-name') 921 and the BGP Route Targets used to import and export information from 922 associated VRFs. This mapping is known via an out-of-band mechanism 923 not specified in this document. 925 Whenever the End-System Route Server receives an XMPP subscription 926 request, it SHALL consult its RT-Constraint Routing Information Base 927 (RIB). If the Route Server does not have a locally originated RT- 928 Constraint route that corresponds to the vpn-name present in the 929 request, it SHALL create one and generate the corresponding BGP route 930 advertisement. This route advertisement should only be withdrawn 931 when there are no more downstream XMPP clients subscribed to the VPN. 933 End-System Route Servers SHOULD automatically assign a BGP route 934 distinguisher per VPN routing table. 936 8. Operational Model 938 In the simplest case, a VPN is a collection of systems that are 939 allowed to exchange traffic with each other, and only with each 940 other. Since all the forwarding tables in this VPN have the same 941 routing entries they are often referred to as symmetrical VPNs. 943 In order to better illustrate the operation of the protocol, we 944 consider a simple example in which host H1 and host H2 both contain a 945 virtual interface that is a member of the same VPN. 947 .------. 948 +----+ +-----+ / \ +-----+ +----+ 949 | H1 | <===> | RS1 | <===> ( BGP mesh ) <===> | RS2 | <===> | H2 | 950 +----+ +-----+ \ / +-----+ +----+ 951 `------' 953 Example Network with Two Hosts and Two Route Servers 955 Figure 2 957 Each of these hosts has a collocated VPN forwarder that has an XMPP 958 session with an End-System Route Server, RS1 and RS2 our example, and 959 these Route Servers are part of the same BGP mesh. 961 When a virtual interface is created on host H1, the local XMPP client 962 generates an XMPP subscription stanza to its respective Route Server. 963 This stanza contains a VPN identifier that has been assigned by the 964 provisioning system. The Route Server maps that identifier to a BGP 965 IP VPN configuration which contains the list of import and export 966 route targets to be used for that particular VRF. 968 Once the interface is operational, host H1 will publish any IP 969 addresses that are configured on the respective virtual interface. 970 This will in turn cause the End-System Route Server to advertise 971 these (directly or indirectly) to any other BGP speaker on the 972 network which is connected to an attachment point of that VPN. 974 The following table represents the contents of the VRF routing table 975 on RS1 after the IPv4 address 203.0.113.42 has been added to the 976 virtual interface on H1. 978 +-----------------+---------------+-------+-----------+ 979 | VPN IP address | NEXT-HOP | label | Known via | 980 +-----------------+---------------+-------+-----------+ 981 | 203.0.113.42/32 | 192.0.2.1 | 16 | XMPP | 982 | | | | | 983 | 203.0.113.48/32 | 198.51.100.10 | 20 | BGP | 984 +-----------------+---------------+-------+-----------+ 986 It assumes that there is an attachment point for this VPN with the 987 IPv4 address of 203.0.113.48 which is advertising a route to the IP 988 address of an application running on H2 (203.0.113.48/32). Host H1 989 has an infrastructure IP address of 192.0.2.1 configured on its 990 physical interface while host H2 has IP address 198.51.100.10. 992 The contents of the VRF routing table in the End-System Route Servers 993 are advertised via XMPP Update notifications sent to H1, and a route 994 update for the IP address of H1 will be sent into the BGP mesh on to 995 Route Server RS2 and from there, via XMPP to H2. 997 This information is used by the host to populate the forwarding table 998 associated with that VPN. The following shows the VRF table on host 999 H1 1001 +-----------------+---------------+-------+ 1002 | VPN IP address | Host address | label | 1003 +-----------------+---------------+-------+ 1004 | 203.0.113.42/32 | localhost | 16 | 1005 | | | | 1006 | 203.0.113.48/32 | 198.51.100.10 | 20 | 1007 +-----------------+---------------+-------+ 1009 When an application that uses the virtual interface on host H1 1010 generates packets with a destination IP address of 203.0.113.48 these 1011 are routed by the VPN Forwarder implemented in the Host OS. The 1012 packets are encapsulated with a header that contains a label assigned 1013 by host H2, as shown in the figure, below. 1015 +--------+ +--------+ 1016 app -- veth0 --| H1 |=== [network] ===| H2 |-- veth0 -- app 1017 +--------+ +--------+ 1019 IP pkt ===> encap (GRE + label) ===> [IP net] ===> decap ===> IP pkt 1020 [192.51.100.10, 20] map 20 to veth0 1022 Packet Flow from Application in H1 to Application in H2 1024 Figure 3 1026 In the case that the virtual interface on the host is associated with 1027 a guest OS, this guest OS has had its address resolution queries 1028 answered with the Virtual Router MAC address, or the MAC address of 1029 the destination MAY be supplied if it is in the same IP subnet 1030 (broadcast domain). When the Virtual Router MAC address is supplied, 1031 this is the address the guest OS uses as the destination MAC address 1032 in packets it originates that are outside its IP subnet. The VPN 1033 forwarder will replace the its MAC address with the MAC address of 1034 the next hop in the tenant virtual network (another End System or 1035 default gateway, for instance) before encapsulating the packet. 1036 packet. 1038 End-System Route Servers are software applications that implement 1039 both the BGP IP VPN PE control plane as well as XMPP server 1040 functionality. These applications are not in the forwarding plane 1041 and MAY not be co-located with a network device. 1043 Network devices MAY have direct BGP sessions to the End-System Route 1044 Servers. For instance, a router or security appliance that supports 1045 BGP/MPLS IP VPNs over GRE may use its existing functionality to 1046 inter-operate directly with a collection of Virtual Machines or other 1047 network appliances that support this specification. 1049 End-System Route Servers implement the VRF import policy and export 1050 policy functionality that is associated with PE routers in standard 1051 BGP IP/VPN deployments. VPN Forwarders receive forwarding 1052 information after policy and route selection is applied. These are 1053 unqualified routes in a specific VRF rather than VPN routing 1054 information qualified by a Route Distinguisher and with a set of 1055 Route Targets. 1057 A symmetrical VPN uses a vrf import and vrf export polices that 1058 contain a single route target, where the route target used for both 1059 import and export is the same. 1061 Different VPN topologies can be created by manipulating the vrf 1062 import and export configuration including "hub-and-spoke" topologies 1063 or overlapping VPNs. 1065 An example of a hub-and-spoke VPN configuration is one where all the 1066 traffic from the VPN clients must be redirected though a middle-box 1067 for inspection. Assume that the virtual interfaces of a particular 1068 user are configured to be in the VPN "tenant1". At an initial stage 1069 this "tenant1" VPN is symmetrical and uses a single Route Target in 1070 both its import and export policies. The middle-box functionality 1071 can be incrementally deployed by defining a new VPN, "tenant1-hub", 1072 and an associated Route Target. The End-System Route Server 1073 configuration is changed such that VPN "tenant1" only imports routes 1074 with the Route Target associated with the hub. The "hub" VPN is 1075 assumed to advertise a prefix that covers all the VPN clients IP 1076 addresses. The "hub" VPN imports the VPN routes in order for it to 1077 be able to generate the XMPP updates to the "hub" end-system. This 1078 information is required for the return traffic from the hub to the 1079 spokes (the VPN clients). In such a scenario, a single physical 1080 interface can connect the middle-box to the clients in a given VPN 1081 which appear logically as downstream from it. Such a middle-box 1082 would often require connectivity to multiple VPNs, such as, for 1083 instance, an "outside" VPN which provides external connectivity to 1084 one or more "inside" VPNs. 1086 The functionality defined in this document in which the BGP IP VPN PE 1087 functionality is split into its control (End-System Route Servers) 1088 and forwarding (VPN Forwarder) components is fully interoperable with 1089 existing BGP IP VPN PEs. 1091 This makes it possible to reuse existing systems. For example, at 1092 the edge of a data center facility it may be desirable to use an 1093 existing router or appliance that aggregates IP VPN routing 1094 information and/or provides IP based services such as stateful packet 1095 inspection. 1097 Such a system can be configured, based on existing functionality, to 1098 suppress more specific routes than a specified aggregate while 1099 advertising the aggregate with a BGP NEXT_HOP containing the PE's IP 1100 address and a locally assigned label corresponding to a VRF where the 1101 more specific routes are present. 1103 9. IANA Considerations 1105 IANA has allocated the value 13 corresponding to "MPLS in UDP 1106 Encapsulation" from the "BGP Tunnel Encapsulation Attribute Tunnel 1107 Types" registry, using this document as reference. We request that 1108 this allocation be made permanent. 1110 This document defines a URN namespace used to encode L3VPN Unicast 1111 routing information compliant with the registration procedure define 1112 in [RFC3688]. 1114 URI: urn:ietf:params:xml:ns:bgp:l3vpn:unicast 1116 Description: This is the XML namespace name for L3VPN Unicast 1117 routing information. 1119 Registrant Contact: IETF BESS Working Group 1121 10. Security Considerations 1123 As with BGP/MPLS L3VPN, we assume that the tenant networks have no 1124 direct reachability to the infrastructure network. The threat models 1125 to consider are: 1127 o The possibility that an attacker on a tenant network may inject 1128 traffic to a different network (for instance belonging to a 1129 different tenant). 1131 o Denial of service attacks from within a tenant network. 1133 o Attacks from a tenant network to the infrastructure via 1134 unauthorized or malicious control traffic. 1136 o Attacks from within the infrastructure network. 1138 Traffic in BGP/MPLS L3VPNs is forwarded based on the contents of VRF 1139 tables, calculated according to configured routing policy (route- 1140 target import/export policies). It is assumed that the configuration 1141 management system responsible for provisioning these policies only 1142 accepts requests that are correctly authenticated, and follow a pre- 1143 defined access policy. It is also assumed that an attacker doesn't 1144 have the ability to inject packets in the infrastructure that mimic 1145 the encapsulated used between PE devices. This specification 1146 recommends that operators ensure that MPLS over GRE and MPLS over UDP 1147 traffic is not allowed to enter the infrastructure network. VPN 1148 forwarders MAY also choose to perform a reverse path forwarding 1149 lookup (i.e., lookup the source IP address of the payload packet) and 1150 discard traffic that doesn't match the expected next-hop(s) for the 1151 reverse route. 1153 As with BGP/MPLS L3VPN, an attacker on a tenant network may inject 1154 packets that consume a disproportional share of infrastructure 1155 resources, either in terms of bandwidth or CE packet forwarding 1156 capacity. VPN forwarders SHOULD provide the ability to rate limit 1157 traffic from a specific virtual interface. When the VPN forwarder 1158 uses other finite resources on a per traffic basis, such as internal 1159 tables used to cache the result access control validation, it SHOULD 1160 provide a mechanism to limit the usage of these resources on a per 1161 virtual interface basis. 1163 The control protocol exchanges between application instances (e.g., 1164 the virtual machine) behind a virtual interface and the VPN forwarder 1165 are typically limited to ARP/ND exchanges and the proxying of 1166 services such as DHCP and DNS. The ARP/ND information received from 1167 the application instance SHOULD NOT be used to populate routing or 1168 forwarding tables directly. The control of what MACs and IP 1169 addresses are accepted by a virtual interface SHOULD reside in the 1170 configuration management system that creates said virtual interface. 1172 The XMPP session between end-systems and the Route Servers SHOULD use 1173 TLS with mutual authentication. One possible strategy is to 1174 distribute pre-signed certificates to end-systems which are presented 1175 as proof of authorization to the Route Server. BGP sessions SHOULD 1176 be authenticated. This document recommends that BGP speaking systems 1177 filter traffic on port 179 such that only IP addresses which are 1178 known to participate in the BGP signaling protocol are allowed. 1180 11. XML schema 1182 The following schema defines the XML elements that are used to 1183 communicate unicast reachability information between the Route Server 1184 and VPN Forwarder: 1186 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1201 1202 1203 1206 1207 1209 1210 1211 1212 1213 1214 1216 1217 1219 1220 1221 1223 1224 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1242 1243 1244 1245 1246 1248 1249 1250 1252 1253 1255 1257 1259 12. Acknowledgements 1261 Pedro Marques contributed much of the original content of this 1262 document. 1264 Yakov Rekhter has contributed to this document by providing detailed 1265 feedback and suggestions. 1267 The authors would also like to thank Thomas Morin for his comments. 1269 Amit Shukla and Ping Pan contributed to earlier versions of this 1270 document. 1272 Benson Schliesser provided a detailed review of the document and 1273 helped clarify several sections. 1275 13. References 1276 13.1. Normative References 1278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1279 Requirement Levels", BCP 14, RFC 2119, 1280 DOI 10.17487/RFC2119, March 1997, 1281 . 1283 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1284 DOI 10.17487/RFC3688, January 2004, 1285 . 1287 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 1288 "Encapsulating MPLS in IP or Generic Routing Encapsulation 1289 (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, 1290 . 1292 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1293 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1294 2006, . 1296 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 1297 Reflection: An Alternative to Full Mesh Internal BGP 1298 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 1299 . 1301 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 1302 R., Patel, K., and J. Guichard, "Constrained Route 1303 Distribution for Border Gateway Protocol/MultiProtocol 1304 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 1305 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 1306 November 2006, . 1308 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 1309 Subsequent Address Family Identifier (SAFI) and the BGP 1310 Tunnel Encapsulation Attribute", RFC 5512, 1311 DOI 10.17487/RFC5512, April 2009, 1312 . 1314 [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) 1315 Version 3 for IPv4 and IPv6", RFC 5798, 1316 DOI 10.17487/RFC5798, March 2010, 1317 . 1319 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1320 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1321 March 2011, . 1323 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1324 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1325 eXtensible Local Area Network (VXLAN): A Framework for 1326 Overlaying Virtualized Layer 2 Networks over Layer 3 1327 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 1328 . 1330 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1331 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1332 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1333 2015, . 1335 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 1336 "Encapsulating MPLS in UDP", RFC 7510, 1337 DOI 10.17487/RFC7510, April 2015, 1338 . 1340 [RFC7622] Saint-Andre, P., "Extensible Messaging and Presence 1341 Protocol (XMPP): Address Format", RFC 7622, 1342 DOI 10.17487/RFC7622, September 2015, 1343 . 1345 [xep-0004] 1346 Eatmon, R., Hildebrand, J., Miller, J., Muldowney, T., and 1347 P. Saint-Andre, "Data Forms", XEP 0004, August 2007. 1349 [pubsub] Millard, P., Saint-Andre, P., and R. Meijer, "Publish- 1350 Subscribe", XEP 0060, July 2010. 1352 13.2. Informational References 1354 [RFC1027] Carl-Mitchell, S. and J. Quarterman, "Using ARP to 1355 implement transparent subnet gateways", RFC 1027, 1356 DOI 10.17487/RFC1027, October 1987, 1357 . 1359 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1360 and D. McPherson, "Dissemination of Flow Specification 1361 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1362 . 1364 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1365 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 1366 . 1368 [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 1369 Rekhter, "Framework for Data Center (DC) Network 1370 Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 1371 2014, . 1373 [IEEE.802-1Q] 1374 Institute of Electrical and Electronics Engineers, "Local 1375 and Metropolitan Area Networks: Virtual Bridged Local Area 1376 Networks", IEEE Std 802.1Q-2005, May 2006. 1378 Authors' Addresses 1380 Stuart Mackie 1381 Juniper Networks 1382 1133 Innovation Way 1383 Sunnyvale, CA 94089 1385 Email: wsmackie@juniper.net 1387 Luyuan Fang 1388 eBay 1389 2025 Hamilton Avenue 1390 San Jose, CA 95125 1392 Email: lufang@ebay.com 1394 Nischal Sheth 1395 Juniper Networks 1396 1133 Innovation Way 1397 Sunnyvale, CA 94089 1399 Email: nsheth@juniper.net 1401 Maria Napierala 1402 AT&T Labs 1403 200 Laurel Avenue 1404 Middletown, NJ 07748 1406 Email: mnapierala@att.com 1408 Nabil Bitar 1409 Nokia 1411 Email: nabil.bitar@nokia.com