draft-ietf-l3vpn-end-system-05.txt   draft-ietf-l3vpn-end-system-06.txt 
Network Working Group P. Marques Network Working Group S. Mackie
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track L. Fang Intended status: Standards Track L. Fang
Expires: April 10, 2016 Microsoft Expires: June 18, 2017 eBay
N. Sheth N. Sheth
Juniper Networks Juniper Networks
M. Napierala M. Napierala
AT&T Labs AT&T Labs
N. Bitar N. Bitar
Verizon Nokia
October 8, 2015 December 15, 2016
BGP-signaled end-system IP/VPNs. BGP-Signaled End-System IP/VPNs
draft-ietf-l3vpn-end-system-05 draft-ietf-l3vpn-end-system-06
Abstract Abstract
This document describes a solution in which the control plane This document describes a solution in which the control plane
protocol specified in BGP/MPLS IP VPNs is used and extended via the protocol specified in BGP/MPLS IP VPNs is used and extended via the
XMPP protocol to provide a Virtual Network service to end-systems. XMPP protocol to provide a Virtual Network service to end-systems
These end-systems may be used to provide network services or may (hosts). These end-systems may be used to provide network services
directly host end-to-end applications. or may host end-user applications.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 10, 2016. This Internet-Draft will expire on June 18, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability of BGP IP VPNs . . . . . . . . . . . . . . . . 4 3. Applicability of BGP IP VPNs . . . . . . . . . . . . . . . . 4
4. Virtual network end-points . . . . . . . . . . . . . . . . . 7 4. Virtual Network End-Points . . . . . . . . . . . . . . . . . 7
5. VPN Forwarder . . . . . . . . . . . . . . . . . . . . . . . . 9 5. VPN Forwarder . . . . . . . . . . . . . . . . . . . . . . . . 9
6. XMPP signaling protocol . . . . . . . . . . . . . . . . . . . 11 6. XMPP signaling protocol . . . . . . . . . . . . . . . . . . . 11
7. End-System Route Server behavior . . . . . . . . . . . . . . 20 7. End-System Route Server behavior . . . . . . . . . . . . . . 21
8. Operational Model . . . . . . . . . . . . . . . . . . . . . . 20 8. Operational Model . . . . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
11. XML schema . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. XML schema . . . . . . . . . . . . . . . . . . . . . . . . . 26
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
13.1. Normative References . . . . . . . . . . . . . . . . . . 27 13.1. Normative References . . . . . . . . . . . . . . . . . . 29
13.2. Informational References . . . . . . . . . . . . . . . . 29 13.2. Informational References . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
This document describes the requirements for a network virtualization This document describes the requirements for a network virtualization
solution that provides an IP service to end-system virtual solution that provides an IP service to end-system virtual
interfaces. It then discusses how the BGP IP VPNs [RFC4364] control interfaces. It then discusses how the control plane for BGP IP VPNs
plane can be used and extended via the XMPP protocol to provide a [RFC4364] can be used and extended via the XMPP protocol to provide a
solution that meets these requirements. Subsequent sections provide solution that meets these requirements. Subsequent sections provide
a detailed discussion of the control and forwarding plane components. a detailed discussion of the control and forwarding plane components.
In BGP IP VPNs, Customer Edge (CE) interfaces connect to a Provider In BGP IP VPNs, Customer Edge (CE) interfaces connect to a Provider
Edge (PE) device which provides both the control plane and VPN Edge (PE) device which provides both the control plane and VPN
encapsulation functions required to implement a Virtual Network encapsulation functions required to implement a Virtual Network
service. This document decouples the control plane and forwarding service. This document describes how the control plane and
functionality of the PE device in order to enable the forwarding forwarding functionality of a PE device can be decoupled in order to
functionality to be implemented in multiple devices. For instance, enable the forwarding functionality to be implemented in multiple
the forwarding function can be implemented directly on the operating devices. For instance, the forwarding function can be implemented
system of application servers or network appliances. directly on the operating system of application servers or network
appliances.
1.1. Terminology 1.1. Terminology
This document makes use of the following terms: This document makes use of the following terms:
End-System: A compute node whose primary function is to run End-System: A compute node whose primary function is to run
applications. It is assumed that end-systems support multiple applications. It is assumed that end-systems support multiple
application instances (e.g., virtual machines), each with its application instances (e.g., virtual machines), each with its
independent network configuration. independent network configuration.
skipping to change at page 3, line 33 skipping to change at page 3, line 33
VPN Forwarder: The forwarding component of a BGP IP VPN PE device. VPN Forwarder: The forwarding component of a BGP IP VPN PE device.
This functionality may be co-located with the virtual interface or This functionality may be co-located with the virtual interface or
implemented by an external device. implemented by an external device.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Requirements 2. Requirements
Network Virtualization is used in both service provider as well as Network virtualization is used in both service provider as well as
enterprise networks to support multi-tenancy and network-based access enterprise networks to support multi-tenancy and network-based access
control. It may also be used to facilitate application instance control. It may also be used to facilitate application instance
mobility. mobility.
Multi-tenancy allows a physical network to provide services to Multi-tenancy allows a physical network to provide services to
multiple "customers" or "tenants", whether these are external multiple "customers" or "tenants", whether these are external
entities in the case of a Service Provider providing managed VPN entities in the case of a Service Provider providing managed VPN
services or internal departments sharing an IT facility. Multi- services, or internal departments of an enterprise sharing an IT
tenancy requires isolation of traffic and routing information between facility. Multi-tenancy requires isolation of traffic and routing
tenants. information between tenants.
Within a tenant, it is often required to create multiple distinct Within a tenant, it is often required to create multiple distinct
virtual networks, in order to be able to provide network-based access virtual networks, in order to be able to provide network-based access
control. In this service model, each virtual network behaves as a control. In this service model, each virtual network behaves as a
"Closed User Group" (CUG) of virtual interfaces that are allowed to "Closed User Group" (CUG) of virtual interfaces that are allowed to
exchange traffic freely, while traffic between virtual networks is exchange traffic freely, while traffic between virtual networks is
subject to access controls. This scenario can be found in both subject to access controls. This scenario can be found in enterprise
enterprise campus networks, branch offices and data centers. campus networks, branch offices and data centers.
It is often the case when network access control is used, that the It is often the case when network access control is used, that the
traffic patterns are such that there is significantly more traffic traffic patterns are such that there is significantly more traffic
crossing a CUG boundary than staying within such boundary. As an crossing a CUG boundary than staying within such boundary. As an
example, in campus networks it is common to segregate users into CUGs example, in campus networks it is common to segregate users into CUGs
based on some classification such as the user's department. Campus based on some classification such as the user's department. Campus
networks often see traffic patterns in which almost all the traffic networks often see traffic patterns in which almost all the traffic
flows northbound to the data center or internet boundaries. Similar flows northbound to the data center or internet boundaries. Similar
traffic patterns can be found in multi-tier applications in IT data traffic patterns can be found in multi-tier applications in IT data
centers. centers.
skipping to change at page 5, line 32 skipping to change at page 5, line 32
control plane functionality of a PE device and a VPN Forwarder control plane functionality of a PE device and a VPN Forwarder
implements the forwarding function usually found in a PE device implements the forwarding function usually found in a PE device
"line-card". The VPN Forwarder functionality may be co-located with "line-card". The VPN Forwarder functionality may be co-located with
the end-system (e.g., implemented in the hypervisor switch or host OS the end-system (e.g., implemented in the hypervisor switch or host OS
network drivers) or it may be external. For instance, residing in a network drivers) or it may be external. For instance, residing in a
data center switch or specialized appliance. data center switch or specialized appliance.
Operationally, BGP IP VPN technology has several important Operationally, BGP IP VPN technology has several important
characteristics: characteristics:
It has a high-level of aggregation between customer interfaces and o It has a high-level of aggregation between customer interfaces and
managed entities (Provider Edge devices). managed entities (Provider Edge devices).
It defines VPNs as policies, allowing an interface to directly o It defines VPNs as policies, allowing an interface to directly
exchange traffic with multiple VPNs and allowing for the topology exchange traffic with multiple VPNs and allowing for the topology
of the virtual network to be modified by modifying the policy of the virtual network to be modified by modifying the policy
configuration. configuration.
It scales horizontally in terms of event propagation. By o It scales horizontally in terms of event propagation. By
increasing the number of signaling devices implementing the PE increasing the number of signaling devices implementing the PE
control plane, it is possible to decrease the load on each control plane, it is possible to decrease the load on each
signaling device when it comes to propagating events that signaling device for events that originate in a specific location
originate in a specific location and must be propagated across the and which must be propagated across the network.
network.
The last point is particularly relevant to the convergence The last point is particularly relevant to the convergence
characteristics required for large scale deployments. BGP's characteristics required for large scale deployments. BGP's
hierarchical route distribution capabilities allow a deployment to hierarchical route distribution capabilities allow a deployment to
divide the workload by increasing the number of End-System Route divide the workload by increasing the number of End-System Route
Servers. Servers.
As an example consider a topology in which 100 End-System Route As an example consider a topology in which 100 End-System Route
Servers are deployed in a network each serving a subset of the VPN Servers are deployed in a network each serving a subset of the VPN
forwarding elements. The Route Servers inter-connect to two top- forwarding elements. The Route Servers inter-connect to two top-
level BGP Route Reflectors [RFC4456]. level BGP Route Reflectors [RFC4456].
If an event (i.e., a VPN route change) needs to be propagated from a If an event (i.e., a VPN route change) needs to be propagated from a
specific end-system to 10,000 clients randomly distributed across the specific end-system to 10,000 clients randomly distributed across the
network, each of the End-System Route Servers must generate 100 network, each of the End-System Route Servers must generate 100
updates to its respective downstream clients. updates to its respective downstream clients.
By modifying this topology such that another 100 End-System Route By modifying this topology such that another 100 End-System Route
Servers are added, each Route Server is now responsible to generate Servers are added, each Route Server is now responsible for
50 client updates. This example illustrates the linear scaling generating 50 client updates. This example illustrates the linear
properties of BGP: doubling the number of Route Servers (i.e., the scaling properties of BGP: doubling the number of Route Servers
processing capacity) reduces in half the number of updates generated (i.e., the processing capacity) reduces by half the number of updates
by each (i.e., load at each processing node). generated by each one (i.e. the load at each processing node is
halved).
The same horizontal scaling techniques can be applied to the Route The same horizontal scaling techniques can be applied to the Route
Reflector layer in the example above by subsetting the VPN Route Reflector layer in the example above by dividing the VPN Route space
space according to some pre-defined criteria (for instance VPN route according to some pre-defined criteria (for instance VPN route
target) and using a pair of Route Reflectors per subset. target) and using a pair of Route Reflectors per subset.
In the previous example we assumed a dense membership in which all In the previous example we assumed a dense membership in which all
Route Servers have local clients that are interested in a particular Route Servers have local clients that are interested in a particular
event. BGP also optimizes the route distribution for sparse events. event. BGP also optimizes the route distribution for sparse events.
The Route Target Constraint [RFC4684] extension, builds an optimal The Route Target Constraint [RFC4684] extension, builds an optimal
distribution tree for message propagation based on VPN membership. distribution tree for XMPP stanza and message propagation based on
It ensures that only the PEs with local receivers for a particular VPN membership. It ensures that only the PEs with local receivers
event do receive it also decreasing the total load on the upstream for a particular event do receive it also decreasing the total load
BGP speaker. on the upstream BGP speaker.
In the WAN environment, BGP IP VPN control plane scaling is focused In the WAN environment, BGP IP VPN control plane scaling is not
not primarily on route convergence times but on memory footprint of primarily focused on route convergence times, but on the memory
embedded devices. While memory footprint does not have a similar footprint of embedded devices. While memory footprint does not have
linear scaling behavior, memory technology available to software a similar linear scaling behavior as load, memory technology
appliances is often at 10x the scale of what is commonly found in WAN available to software appliances is often at 10x the scale of what is
environments. commonly found in WAN environments, and so is not so much of a
concern.
The functionality present in the BGP IP VPN control plane addresses The functionality present in the BGP IP VPN control plane addresses
the requirements specified in the previous section. Specifically, it the requirements specified in the previous section. Specifically, it
supports multiple potentially overlapping "groups", regular or "hub supports multiple potentially overlapping "groups", regular or "hub
and spoke" topologies and the scaling characteristics necessary. and spoke" topologies and the scaling characteristics necessary.
The BGP IP VPN control plane supports not only the definition of The BGP IP VPN control plane supports not only the definition of
"closed user-groups" (VPNs in its terminology) but also the "closed user-groups" (VPNs in its terminology) but also the
propagation of inter-VPN traffic policies [RFC5575]. propagation of inter-VPN traffic policies [RFC5575].
Note that the signaling protocol itself is rather agnostic of the Note that the signaling protocol itself is rather agnostic of the
encapsulation used on the wire as long as this encapsulation has the encapsulation used on the wire as long as this encapsulation has the
ability to carry a 20 bit label. ability to carry a label of sufficient length to enumerate all the
VPNs in an administrative domain (e.g. an MPLS label, which has 20
bits).
Several network environments use a network infrastructure that is Several network environments use a network infrastructure that is
only capable of providing an IP unicast service. In order to support only capable of providing an IP unicast service. In order to support
them, implementations of this document should support the MPLS in GRE them, implementations of this document should support the MPLS in GRE
[RFC4023] encapsulation. Other encapsulations are possible, [RFC4023] encapsulation. Other encapsulations are possible,
including UDP based encapsulations [RFC7510]. including UDP-based encapsulations RFC 7510 [RFC7510] and VXLAN
[RFC7348].
4. Virtual network end-points 4. Virtual Network End-Points
This document assumes that end-systems support one or more virtual This document assumes that end-systems support one or more virtual
network interfaces in addition to a physical interface that is network interfaces in addition to a physical interface that is
associated with the underlying network infrastructure. Virtual associated with the underlying network infrastructure. A virtual
network interfaces can be associated with a restricted list of network interfaces can be associated with a specific application via
applications via OS-dependent mechanisms, a Virtual Machine (VM), or a OS-dependent mechanisms like a Virtual Machine (VM), or they can be
they can be used to provide network connectivity to all user used to provide network connectivity to all user applications in the
applications in the same way that a "VPN tunnel" interface is used to same way that a "VPN tunnel" interface is used to provide access
provide access between an end-system (e.g., a laptop) and a remote between an end-system (e.g., a laptop) and a remote corporate
corporate network. network.
From an IP address assignment point of view, a virtual network Each virtual network interface is assigned an IP addresses from a
interface is addressed out of the virtual IP topology and associated subnet associated with a "closed user group" or VPN, while the
with a "closed user group" or VPN, while the physical interface of physical interface of the machine is addressed in the network
the machine is addressed in the network infrastructure topology. infrastructure topology.
A virtual network interface is connected to a VPN Forwarder. This A virtual network interface is connected to a VPN Forwarder. This
VPN Forwarder MAY be co-located in the end-system or external. In VPN Forwarder MAY be co-located in the end-system or external. In
cases where the VPN Forwarder is external to the end-system, they can cases where the VPN Forwarder is external to the end-system, they can
either be directly connected or interconnected with a dedicated either be directly connected or interconnected with a dedicated
802.1Q VLAN on a per virtual interface basis. 802.1Q VLAN on a per virtual interface basis.
Both static and dynamic IP address allocation can be supported. The Both static and dynamic IP address allocation can be supported. The
latter assumes that the VPN Forwarder implements a DHCP relay or DHCP latter assumes that the VPN Forwarder implements DHCP relay or DHCP
proxy functionality. proxy functionality.
Traffic that ingresses or egresses through a virtual network Traffic that ingresses or egresses through a virtual network
interface is routed at the VPN Forwarder which acts as the first-hop interface is routed at the VPN Forwarder, which acts as the first-hop
router (in the virtual topology). The IP configuration on the client router (in the virtual topology). The IP configuration on the client
side of this virtual network interface (e.g., in the guest OS) can side of this virtual network interface (e.g., in the guest OS) can
follow one of two models: follow one of two models:
point-to-point interface model. o Point-to-point interface model
multipoint interface model. o Multipoint interface model
In a point-to-point interface model, the VPN client routing table In a point-to-point interface model, the VPN client routing table
(e.g., on the guest OS) contains the following routing entries: a (e.g., on the guest OS) contains the following routing entries: a
host route to the local IP address, a host route to the first-hop host route to the local IP address, a host route to the first-hop
router via the virtual interface and a default route to the first-hop router via the virtual interface and a default route to the first-hop
router. This is the model typically used in "VPN tunnel" router. This is the model typically used in "VPN tunnel"
configurations or other access technologies such as cable deployments configurations or other access technologies such as cable deployments
or DSL. When this model is used, the first-hop router IP address is or DSL. When this model is used, the first-hop router IP address is
either an address from the tenant's IP address space or a link-local either an address from the tenant's IP address space or a link-local
address. This address SHOULD be the same on all first-hop routers address. This address SHOULD be the same on all first-hop routers
across a specific deployment so that it does not change when a across a specific deployment so that it does not change when a
virtual interface moves between end systems. virtual interface moves between end systems.
In a multi-point interface model, the VPN client routing table (e.g., In a multi-point interface model, the VPN client routing table (e.g.,
on the guest OS) contains the following routing entries: a host route on the guest OS) contains the following routing entries: a host route
to the local IP address, a subnet route to the local interface and to the local IP address, a subnet route to the local interface and
optionally a default route to a specific router address within that optionally a default route to a specific router address within that
subnet. In this model, the VPN client IP stack will issue address subnet. In this model, the VPN client IP stack will issue address
resolution requests for any IP addresses it considers to be directly resolution requests for any IP addresses it considers to be directly
attached to the subnet. The VPN Forwarder shall answer all address attached to the subnet. The VPN Forwarder SHALL answer all address
resolution requests via Proxy ARP [RFC1027].The same technique is resolution requests via Proxy ARP [RFC1027].The same technique is
applicable when Neighbor Discovery is used to resolve IPv6 addresses. applicable when Neighbor Discovery is used to resolve IPv6 addresses.
Address resolution request should be answered using a virtual MAC Address resolution request SHOULD be answered using a virtual MAC
address which SHOULD be the same across all VPN Forwarders in a address which SHOULD be the same across all VPN Forwarders in a
specific deployment. This virtual MAC address SHALL default to the specific deployment. This virtual MAC address SHALL default to the
VRRP [RFC5798] virtual router MAC address for Virtual Router VRRP [RFC5798] virtual router MAC address for Virtual Router
Identifier (VRID) 1. Identifier (VRID) 1.
When the virtual topology first-hop router resides on the same When the virtual topology first-hop router resides on the same
physical machine, the host OS is responsible to map the virtual physical machine, the host OS is responsible for mapping the virtual
interface with a VPN specific routing table (without taking L2 interface with a VPN-specific routing table (without taking L2
addresses into consideration). In this case the MAC addresses known addresses into consideration). In this case the MAC addresses known
to the guest OS are not used on the wire. to the guest OS are not used on the wire.
When the virtual topology first-hop router resides in an external When the virtual topology first-hop router resides in an external
system (e.g., the first hop-switch) the virtual interface shall be system (e.g., the first hop-switch) the virtual interface shall be
identified by the physical interface of the end-system and a 802.1Q identified by the physical interface of the end-system and a 802.1Q
VLAN tag. The first-hop switch should use a virtual router MAC VLAN tag. The first-hop switch should use a virtual router MAC
address to answer any address resolution queries. address to answer any address resolution queries.
Whenever an external VPN Forwarder is used and resiliency is desired, Whenever external VPN forwarding is used, and resiliency is desired,
the external VPN Forwarder should be redundant. It is desirable to multiple external VPN Forwarder may be employed in a redundant
use VRRP as a mechanism to control the flow of traffic between the configuration. It is desirable to use VRRP as a mechanism to control
end-system and the external VPN Forwarder. VRRP already defines the the flow of traffic between the end-system and the external VPN
necessary procedures to elect a single forwarder for a LAN. Forwarder. VRRP already defines the necessary procedures to elect a
single forwarder for a LAN.
This specification uses the VRRP virtual router MAC address as the This specification uses the VRRP virtual router MAC address as the
default L2 address for the VPN Forwarder as a client virtual default L2 address for the VPN Forwarder, in order to support a
interface may move between locations where redundancy may not be client virtual interface moving between locations.
present.
While the VRRP Virtual Router MAC will be used to answer any address While the VRRP Virtual Router MAC will be used to answer any address
resolution request made by the virtual interface client (e.g., the resolution request made by the virtual interface client (e.g., the
guest VM) this does not imply that a single default router is elected guest VM) this does not imply that a single default router is elected
per virtual IP subnet. The ingress VPN Forwarder will perform an IP per virtual IP subnet. The ingress VPN Forwarder will perform an IP
forwarding decision based on the destination IP address of the forwarding decision based on the destination IP address of the
(payload) traffic. (payload) traffic.
VRRP router election is only relevant in selecting the VPN Forwarder VRRP router election is only relevant in selecting the VPN Forwarder
associated with a specific machine, when external forwarders are in associated with a specific machine, when external forwarders are in
skipping to change at page 9, line 44 skipping to change at page 10, line 8
functionality to the end-system, it may be implemented by an external functionality to the end-system, it may be implemented by an external
system, typically located as close as possible to the end-system system, typically located as close as possible to the end-system
itself. itself.
Both models, co-located and external VPN Forwarder can co-exist in a Both models, co-located and external VPN Forwarder can co-exist in a
deployment. deployment.
In order to implement the BGP IP VPN Forwarder functionality a device In order to implement the BGP IP VPN Forwarder functionality a device
MUST implement the following functionality: MUST implement the following functionality:
Support for multiple "Virtual Routing and Forwarding" (VRF) o Support for multiple "Virtual Routing and Forwarding" (VRF)
tables; tables;
VRF route entries map prefixes in the virtual network topology VRF route entries map prefixes in the virtual network topology
to a next-hop containing a infrastructure IP address and a to a next-hop containing a infrastructure IP address and a
20-bit label allocated by the destination Forwarder. The VRF label allocated by the destination Forwarder. The VRF table
table lookup follows the standard IP lookup (best-match) lookup follows the standard IP lookup (best-match) algorithm.
algorithm.
Associate an end-system virtual interface with a specific VRF o Associate an end-system virtual interface with a specific VRF
table; table;
When the Forwarder is co-located with the end-system, this When the Forwarder is co-located with the end-system, this
association is implemented by an internal mechanism. When the association is implemented by an internal mechanism. When the
Forwarder is external the association is performed using the Forwarder is external the association is performed using the
MAC address of the end-system and an IEEE 802.1Q tag that MAC address of the end-system and an IEEE 802.1Q tag that
identifies the virtual interface within the end-system. identifies the virtual interface within the end-system.
Encapsulate outgoing traffic (end-system to network) according to o Encapsulate outgoing traffic (end-system to network) according to
the result of the VRF lookup; the result of the VRF lookup;
Associate incoming packets (network to end-system) to a VRF o Associate incoming packets (network to end-system) to a virtual
according to the 20-bit label contained in the packet; interface for direct forwarding, or to a VRF for lookup, according
to the label contained in the packet;
The VPN Forwarder MAY support the ability to associate multiple The VPN Forwarder MAY support the ability to associate multiple
virtual interfaces with the same VRF. When that is the case, locally virtual interfaces with the same VRF. When that is the case, locally
originated routes, that is IP routes to the local virtual interfaces originated routes, that is IP routes to the local virtual interfaces
SHALL NOT be used to forward outbound traffic (from the virtual SHALL NOT be used to forward outbound traffic (from the virtual
interfaces to the outside) unless a route advertisement has been interfaces to the outside) unless a route advertisement has been
received that matches that specific IP prefix and next-hop received that matches that specific IP prefix and next-hop
information. This is intended to ensure that the forwarding behavior information. This is intended to ensure that the forwarding behavior
is the same whether the VRF is shared or between multiple interfaces is the same whether the VRF is shared or between multiple interfaces
of the same virtual-network or not. of the same virtual-network or not.
As an example, if a given VRF contains two virtual interfaces, As an example, if a given VRF contains two virtual interfaces,
"veth0" and "veth1", with the addresses 203.0.113.1/32 and "veth0" and "veth1", with the addresses 203.0.113.1/32 and
203.0.113.2/32 respectively, the initial forwarding state must be 203.0.113.2/32 respectively, the initial forwarding state must be
initialized such that traffic from either of these interfaces does initialized such that traffic from either of these interfaces does
not match the other's routing table entry. It may for instance match not match the other's routing table entry. It may, for instance,
a default route advertised by a remote system. Traffic received from match a default route advertised by a remote system. Traffic
other VPN Forwarders, however, must be delivered to the correct local received from other VPN Forwarders, however, must be delivered to the
interface. If at a subsequent stage a route is received from the correct local interface. If at a subsequent stage a route is
Route Server such that 203.0.113.2/32 has a next-hop with the IP received from the Route Server such that 203.0.113.2/32 has a next-
address of the local host and the correct label, the system may hop with the IP address of the local host and the correct label, the
subsequently install a local routing table entry that delivers system may subsequently install a local routing table entry that
traffic directly to the "veth1" interface. This means that delivers traffic directly to the "veth1" interface. This means that
forwarding table entries apply to downstream only by default. This forwarding table entries apply to downstream traffic only, by
capability can be used to implement a hub-and-spoke topology, if default. This capability can be used to implement a hub-and-spoke
required. topology, if required.
The 20-bit label which is associated with a virtual interface is of The label which is associated with a virtual interface is of local
local significance only and SHOULD be allocated by the VPN Forwarder. significance only and SHOULD be allocated by the VPN Forwarder.
When an external VPN Forwarder is used the end-system MUST associate When an external VPN Forwarder is used the end-system MUST associate
each virtual interface with a VLAN [IEEE.802-1Q] that is unique on each virtual interface with a VLAN [IEEE.802-1Q] that is unique on
the end-system. The switching infrastructure MUST be configured such the end-system. The switching infrastructure SHOULD be configured
that multi-destination frames sourced from an end-system are only such that multi-destination frames sourced from an end-system are
delivered to VPN Forwarders used by this end-system and not to other only delivered to VPN Forwarders used by this end-system and not to
end-systems. other end-systems.
6. XMPP signaling protocol 6. XMPP signaling protocol
End-System Route Servers must be aware of VPN membership on each End-System Route Servers must be aware of VPN membership on each
Forwarder as well as what IP addresses are currently associated with Forwarder as well as what IP addresses are currently associated with
each virtual interface. each virtual interface.
VPN Forwarders must receive VPN route information from which to VPN Forwarders receive VPN route information from which to populate
populate their forwarding tables. External VPN Forwarders also need their forwarding tables. External VPN Forwarders also need to
to receive the virtual interface and IP address events from the end- receive the virtual interface and IP address allocation events for
system for which they are VPN forwarders. In this case the end- the end-system for which they are VPN forwarders. In this case, the
system assigns an 802.1Q VLAN tag to each virtual interface and end-system assigns an 802.1Q VLAN tag to each virtual interface and
communicates that information to the Forwarder. communicates that information to the Forwarder directly, or via the
Route Server.
In order to exchange this information this specification uses the In order to exchange this information this specification uses the
XMPP [RFC6120] protocol along with the Publish-Subscribe [pubsub] XMPP [RFC6120] protocol along with the Publish-Subscribe [pubsub]
extension. extension.
VPN forwarders (both co-located and external) establish XMPP sessions VPN forwarders (both co-located and external) establish XMPP sessions
with End-System Route Servers, acting as XMPP clients. When an with End-System Route Servers, acting as XMPP clients. When an
external VPN Forwarder is used, end-systems establish XMPP sessions external VPN Forwarder is used, end-systems MAY establish XMPP
with VPN Forwarders. External VPN Forwarders act as XMPP servers for sessions with VPN Forwarders. In such cases, external VPN Forwarders
end-systems which are associated with them. act as XMPP servers for end-systems which are associated with them.
A VPN Forwarder MAY connect to multiple End-System Route Servers for A VPN Forwarder MAY connect to multiple End-System Route Servers for
reliability. In this case it SHOULD publish its information to each reliability. In this case it SHOULD publish its information to each
of the Route Servers. It MAY choose to subscribe to VPN routing of the Route Servers. It MAY choose to subscribe to VPN routing
information once only from one of the available gateways. In this information from only one of the available Route Servers. In this
case the Forwarder is responsible for switching subscriptions over to case, the Forwarder is responsible for switching subscriptions over
alternate Route Servers in the case of Route Server failures. to an alternate Route Server in the case of Route Server failure.
Alternatively, it MAY choose to subscribe to VPN routing information Alternatively, it MAY choose to subscribe to VPN routing information
from each End-System Route Server. In this latter case the Forwarder from more than one End-System Route Server. In this case, the
is responsible for selecting which Route Server is authoritative for Forwarder is responsible for selecting which Route Server is
a specific forwarding entry. The Route Servers are expected to authoritative for each forwarding entry. The Route Servers SHOULD
produce the same forwarding information with no delta other than the produce the same forwarding information for each destination. The
one introduced by processing and communication delays. The VPN VPN Forwarder is expected to select the entry that it deems as more
Forwarder is expected to select the entry that it deems as more
recent for positive updates. It SHOULD NOT consider a forwarding recent for positive updates. It SHOULD NOT consider a forwarding
entry to be withdrawn unless it is withdrawn by both Route Servers. entry to be withdrawn unless it is withdrawn by both Route Servers.
The Route Server MUST monitor the XMPP connection status of each VPN Each End-System Route Server MUST monitor the XMPP connection status
Forwarder that is connected to it. The information advertised by an of each VPN Forwarder that is connected to it. The information
XMPP client SHOULD be deleted after a configurable timeout, after advertised by an XMPP client SHOULD be deleted after a configurable
XMPP session closes. This timeout should default to 60 seconds. timeout, after XMPP session closes. This timeout SHOULD default to
60 seconds.
The End-System Route Server MAY monitor the status of each VPN An End-System Route Server MAY monitor the status of each VPN
Forwarder, for instance, through the use of the BFD [RFC5880] Forwarder that is connected to it, using, for example, the BFD
protocol. The Route Server MAY choose to immediately reduce the [RFC5880] protocol and to delete advertised information after a
preference of routing information received from an XMPP client for timeout when a failure is detected. The Route Server MAY choose to
which a failure has been detected either through an session close immediately reduce the preference of routing information received
event or an external failure detection mechanism such as BFD. . from an XMPP client for which a failure has been detected, either
through an XMPP session close event, or a failure detection mechanism
such as BFD.
+---------+ +--------+ +---------+ +--------+
| RS | ----------- | BGP | | RS |--------| BGP |
+---------+ +--------+ +---------+ +--------+
// \ / / \ /
XMPP \ / XMPP \ /
// \ / / \ /
+------------+ \ / +--------------------+ \ /
| end-system | \ / | End | VPN | \/
+------------+ \/ | System | Forwarder | /\
\\ /\ +--------------------+ / \
XMPP / \ \ / \
\\ / \ XMPP / \
+---------+ / \ +--------+ \ / \
| RS | ----------- | BGP | +---------+ +--------+
+---------+ +--------+ | RS |--------| BGP |
+---------+ +--------+
VPN Forwarder Connected to Two Routing Systems
Figure 1 Figure 1
The figure above represents a typical configuration in which an end- The figure above represents a typical configuration in which an end-
system with a co-located VPN Forwarder is directly connected to two system with a co-located VPN Forwarder is directly connected to two
End-System Route Servers, which are in turn connected to multiple BGP End-System Route Servers, which are in turn connected to multiple BGP
speakers which may be other L3VPN PEs or BGP route reflectors. speakers which may be other L3VPN PEs or BGP route reflectors.
In deployment the number of End-System Route Servers used will depend In deployment, the number of End-System Route Servers used will
on the desired Route Server to VPN Forwarder ratio which affects the depend on the desired Route Server to VPN Forwarder ratio which
convergence time of event propagation. affects the convergence time of event propagation.
The XMPP JID used by the client SHALL be a RFC 7622 [RFC7622] The XMPP JID used by the client SHALL be a RFC 7622 [RFC7622]
compliant address that uniquely identifies it in its administrative compliant address that uniquely identifies it in its administrative
domain. The VPN Forwarder SHOULD use as JID its hostname, when domain. The VPN Forwarder SHOULD use its hostname as JID, when
available, or an unique IP address within the infrastructure network available, or a unique IP address within the infrastructure network
win its string representation. using its string representation. The same naming convention SHOULD
be used for an End System which has an XMPP session with an external
VPN Forwarder.
The XMPP JID used by an End-System Route Server SHOULD be the The XMPP JID used by an End-System Route Server SHOULD be the
constant string 'route-server@ietf.org'. constant string 'route-server@ietf.org'.
Each VPN shall be identified by an ASCII character string that SHOULD Each VPN shall be identified by an ASCII character string that SHOULD
NOT exceed 128 octets and MUST be unique within a specific NOT exceed 128 octets and MUST be unique within each administrative
administrative domain. The VPN identifier is an attribute of each domain. The VPN identifier is an attribute of each virtual
virtual interface. It is assumed that a configuration management interface. It is assumed that a configuration management system
system exists such that it provisions the Route Servers with VPN exists such that it provisions the Route Servers with VPN identifier
identifier values and the VPN Forwarders with the mapping of virtual values and the VPN Forwarders with the mapping of virtual interface
interface to VPN identifier. Such configuration management system is to VPN identifier. Such a configuration management system is outside
outside the scope of this document. the scope of this document.
Each VPN identifier corresponds to a Pub-Sub node in the Route Server Each VPN identifier corresponds to a Pub-Sub node in the Route Server
XMPP servers. This Pub-Sub nodes SHOULD be configured such that Pub- XMPP servers. This Pub-Sub nodes SHOULD be configured such that Pub-
Sub items are persistent and that event notifications include the Sub items are persistent and that event notifications include the
item payload. Implementations MAY choose to perform this operation item payload. Implementations MAY choose to perform this operation
explicitly or implicitly by mapping XMPP subscription requests to an explicitly or implicitly by mapping XMPP subscription requests to an
event observer mechanism that tracks the VRF table corresponding to event observer mechanism that tracks the VRF table corresponding to
the VPN in question. the VPN in question.
When external Forwarders are used, its control software operates as When an external Forwarder is used, its control software MAY operate
an XMPP server processing requests from end-systems and as a client as an XMPP server which processes requests from end-systems and SHALL
of one or more End-System Route Servers. The control software relays operate as a client of one or more End-System Route Servers. The
to the End-System Route Server(s) VPN membership messages it receives control software relays to the End-System Route Server(s) VPN
from the end-system. VPN routing information received from the Route membership stanzas it receives from the end-system. VPN routing
Server(s) SHOULD NOT be propagated to the end-system. information received from the Route Server(s) SHOULD NOT be
propagated to the end-system unless it specifically requests such
information. End systems MAY have sessions directly with the End-
System Route Servers, and in this case no XMPP sessions are required
with VPN Forwarders.
When a virtual interface is created on a end-system, the host When a virtual interface is created on an end-system, the host End
operating-system software shall generate an XMPP Subscribe message to System XMPP client SHALL generate an XMPP Subscribe stanza to its
its server (the End-System Route Server or external VPN Forwarder). server (a Route Server or the external VPN Forwarder).
Each Subscribe message SHALL be addressed to the JID of the End-
System Route Server (route-server@ietf.org), using the VPN Identifier Each Subscribe stanza SHALL be addressed to the JID of the Route
as the NodeID. If subsequent Virtual Interfaces are created with the Server (e.g. route-server@ietf.org), using the VPN Identifier as the
same VPN Identifier, and the previous Pub-Sub subscription is still NodeID.
in effect, then extraneous XMPP Pub-Sub Subscribe messages SHOULD NOT
be sent to the End-System Route Server. If at any point all Virtual If subsequent Virtual Interfaces are created with the same VPN
Interfaces associated with a given VPN Identifier are removed or Identifier, and the previous Pub-Sub subscription is still in effect,
deactivated from the End-System, then the host operating-system then additional XMPP Pub-Sub Subscribe stanzas SHOULD NOT be sent to
SHOULD generate an XMPP Pub-Sub Unsubscribe message to its server for the End-System Route Server.
the Pub-Sub node associated with the VPN Identifier.
Example subscription request from co-located VPN Forwarder to Route Example subscription request from co-located VPN Forwarder to Route
Server: Server:
<iq type='set' <iq type='set'
from='forwarder.domain.org' from='forwarder@domain.org'
to='route-server@ietf.org' to='route-server@ietf.org'
id='sub1'> id='sub1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'> <pubsub xmlns='http://jabber.org/protocol/pubsub'>
<subscribe node='vpn-customer-name' jid='route-server@ietf.org'/> <subscribe node='vpn-customer-name' jid='fowarder@domain.org'/>
<options> <options>
<instance-id>1</instance-id> <instance-id>1</instance-id>
</options> </options>
</pubsub> </pubsub>
</iq> </iq>
The request above, instructs the End-System Route Server to start
The above request instructs the End-System Route Server to start
populating the client's VRF table with any routing information that populating the client's VRF table with any routing information that
is available for this VPN. The XMPP node 'vpn-customer-name' is is available for this VPN. The XMPP node 'vpn-customer-name' is
assumed to be implicitly created by the End-System Route Server. assumed to be implicitly created by the End-System Route Server.
Creation of a virtual interface may precede any IP address becoming Creation of a virtual interface may precede any IP address becoming
active on the interface, as it is the case with VM instantiation. active on the interface, as is the case with VM instantiation.
The optional "instance-id" element allows the VPN Forwarder to The optional "instance-id" element allows the VPN Forwarder to
specify a unique 16 bit index that can be used by the Route Server to specify a unique 16 bit index that can be used by the Route Server to
automatically assign a Route Distinguisher (RD) to any route automatically assign a Route Distinguisher (RD) to any route
subsequently advertised by the VPN Forwarder. In a scenario where subsequently advertised by the VPN Forwarder. In a scenario where
the VPN Forwarder is advertising reachability information to multiple the VPN Forwarder is advertising reachability information to multiple
Route Servers it is desirable for reachability information to have an Route Servers it is desirable for reachability information to have an
RD composed of the VPN Forwarder identifier (e.g., IPv4 address) and RD composed of the VPN Forwarder identifier (e.g., IPv4 address) and
the "instance-id". the "instance-id".
Example subscription request from end-system to external VPN Example subscription request from end-system to external VPN
Forwarder: Forwarder:
<iq type='set' <iq type='set'
from='end-system.domain.org' from='end-system@domain.org'
to='route-server@ietf.org' to='forwarder@domain.org'
id='sub1'> id='sub1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'> <pubsub xmlns='http://jabber.org/protocol/pubsub'>
<subscribe node='vpn-customer-name' jid='route-server@ietf.org'/> <subscribe node='vpn-customer-name' jid='forwarder@domain.org'/>
<options> <options>
<x xmlns='jabber:x:data' type='submit'> <x xmlns='jabber:x:data' type='submit'>
<field var='vpn#vlan_id'><value>100</value></field> <field var='vpn#vlan_id'><value>100</value></field>
</x> </x>
</options> </options>
</pubsub> </pubsub>
</iq> </iq>
When an external VPN Forwarder is used, the end-system SHOULD include When an external VPN Forwarder is used, the end-system SHOULD include
the VLAN identifier it assigned to the virtual interface as a the VLAN identifier it assigned to the virtual interface as a
subscription option. This option is represented in the XMPP Pub-Sub subscription option. This option is represented in the XMPP Pub-Sub
Subscribe message as a data form [xep-0004] field with the name Subscribe stanza a data form [xep-0004] field with the name
"vpn#vlan_id". The example above uses the 802.1Q tag value of 100. "vpn#vlan_id". The example above uses the 802.1Q tag value of 100.
When a Route Server receives a subscription request for a specific When a Route Server receives a subscription request for a specific
VPN identifier it SHALL treat this request as an implicit request for VPN identifier it SHALL treat this request as an implicit request for
item retrieval for all items in the Pub-Sub node that corresponds to item retrieval for all items in the Pub-Sub node that corresponds to
the VPN. the VPN.
If at any point all Virtual Interfaces associated with a given VPN
Identifier are removed or deactivated from the End-System, then the
End System XMPP client SHOULD generate an XMPP Pub-Sub Unsubscribe
stanza to its server for the Pub-Sub node associated with the VPN
Identifier.
Example unsubscribe request from co-located VPN Forwarder to Route Example unsubscribe request from co-located VPN Forwarder to Route
Server: Server:
<iq type='set' <iq type='set'
from='forwarder.domain.org' from='forwarder@domain.org'
to='route-server@ietf.org' to='route-server@ietf.org'
id='unsub1'> id='unsub1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'> <pubsub xmlns='http://jabber.org/protocol/pubsub'>
<unsubscribe <unsubscribe
node='vpn-identifier' node='vpn-identifier'
jid='route-server@ietf.org' /> jid='forwarder@domain.org'/>
</pubsub> </pubsub>
</iq> </iq>
When a IP address is added to a virtual interface and the interface For a collocated VPN forwarder, and for an external VPN forwarder
is activated, the end-system SHALL generate an XMPP Pub-Sub Publish when there is an XMPP session with the End System, when an IP address
request. This request publishes an item containing a single entry is added to a virtual interface and the interface is activated, the
element based on the XML Schema Definition in Section 11. The ItemID end-system SHALL generate an XMPP Pub-Sub Publish request. This
of this item MUST be generated by the VPN Forwarder such that the request publishes an item containing a single entry element based on
value is unique within a Pub-Sub node. The ItemID MAY be formed by the XML Schema Definition in Section 11. The ItemID of this item
combining the VPN Forwarder's IP address, the instance-id value, and MUST be generated by the VPN Forwarder such that the value is unique
the entry address element. This format corresponds to the string within a Pub-Sub node. The ItemID MAY be formed by combining the VPN
representation of a BGP L3VPN NLRI in which the Route Distinguisher Forwarder's IP address, the instance-id value, and the entry address
is given by the VPN Forwarder IP address and instance-id and is element. This format corresponds to the string representation of a
easily identifiable by network operators. However, the format and/or BGP L3VPN NLRI in which the Route Distinguisher is given by the VPN
structure of the ItemID is not meaningful in the context of this Forwarder IP address and instance-id, and is easily identifiable by
document as long as uniqueness is guarantied. network operators. However, the format and/or structure of the
ItemID is not stricly defined in this document, so long as uniqueness
is guaranteed.
Publish request from VPN Forwarder to End-System Route Server: Publish request from VPN Forwarder to End-System Route Server:
<iq type='set' <iq type='set'
from='forwarder.domain.org' from='forwarder@domain.org'
to='route-server@ietf.org' to='route-server@ietf.org'
id='request1'> id='request1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'> <pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='vpn-customer-name'> <publish node='vpn-customer-name'>
<item id='192.0.2.1:1:203.0.113.42/32'> <item id='192.0.2.1:1:203.0.113.42/32'>
<entry xmlns='urn:ietf:params:xml:ns:bgp:l3vpn:unicast'> <entry xmlns='urn:ietf:params:xml:ns:bgp:l3vpn:unicast'>
<nlri> <nlri>
<af>1</af> <af>1</af>
<address>203.0.113.42</address> <address>203.0.113.42</address>
</nlri> </nlri>
<next-hops> <next-hops>
<next-hop> <next-hop>
<af>1</af> <af>1</af>
<address>192.0.2.1</address> <address>192.0.2.1</address>
<label>10000</label> <label>10000</label>
<tunnel-encapsulation-list> <tunnel-encapsulation-list>
<tunnel-encapsulation>gre</tunnel-encapsulation> <tunnel-encapsulation>gre</tunnel-encapsulation>
<tunnel-encapsulation>udp</tunnel-encapsulation> <tunnel-encapsulation>udp</tunnel-encapsulation>
</tunnel-encapsulation-list> </tunnel-encapsulation-list>
</next-hop> </next-hop>
</next-hops> </next-hops>
<sequence-number>1</sequence-number> <sequence-number>1</sequence-number>
</entry> </entry>
</item> </item>
</publish> </publish>
</pubsub> </pubsub>
</iq> </iq>
In this example, the VPN Forwarder JID is "forwarder.domain.org". In this example, the VPN Forwarder JID is "forwarder@domain.org".
The VPN Identifier "vpn-identifier" is used as the value of the node The VPN Identifier "vpn-identifier" is used as the value of the node
attribute of the subscribe element. The IP address of the Virtual attribute of the subscribe element. The IP address of the Virtual
Interface is 203.0.113.42/32. The IP address of the VPN Forwarder is Interface is 203.0.113.42/32. The IP address of the VPN Forwarder is
192.0.2.1 and it supports receiving MPLS packets via both GRE and UDP 192.0.2.1 and it supports receiving MPLS packets via both GRE and UDP
tunneling. Label 10000 has been assigned to this particular Virtual tunneling. Label 10000 has been assigned to this particular Virtual
Interface. Interface.
The End-System Route Server will convert the information received in The End-System Route Server will convert the information received in
a 'publish' request into the corresponding BGP route information such a 'publish' request into the corresponding BGP route information such
that:. that:
It associates the specific request with a local VRF which it o It associates the specific request with a local VRF which it
resolves by using the Pub-Sub 'node' attribute. resolves by using the Pub-Sub 'node' attribute.
It creates a BGP VPN route with a 'Route Distinguisher' (RD) which o It creates a BGP VPN route with a 'Route Distinguisher' (RD) which
contains a unique 32bit value per end-system plus a 16bit contains a unique 32bit value per end-system plus a 16bit
instance-id, the specified IP prefix and 'label' received from the instance-id, the specified IP prefix and 'label' received from the
VPN Forwarder as the Network Layer Reachability Information VPN Forwarder as the Network Layer Reachability Information
(NLRI). The instance-id is either the value specified by the XMPP (NLRI). The instance-id is either the value specified by the XMPP
client in the subscribe message for the specific pubsub node or a client in the subscribe stanza for the specific pubsub node or a
locally generated value when that parameter is omitted. locally generated value when that parameter is omitted.
The BGP next-hop address is set to the address of the VPN o The BGP next-hop address is set to the address of the VPN
Forwarder. Forwarder.
A BGP Tunnel Encapsulation Attribute [RFC5512] is generated for o A BGP Tunnel Encapsulation Attribute [RFC5512] is generated for
each 'tunnel-encapsulation' element specified in the XMPP message. each 'tunnel-encapsulation' element specified in the XMPP message.
It optionally associates the route with a MAC Mobility extended o The route is optionally associated with a MAC Mobility extended
community [RFC7432] containing a sequence number of the route community [RFC7432] containing a sequence number for the route
advertisement. advertisement.
Conversely, when an interface operational status is determined to be Conversely, when an interface operational status is determined to be
down or an IP address is unconfigured the VPN forwarder generates an down or an IP address is unconfigured the VPN forwarder generates an
XMPP retract message to withdraw the route advertisement. XMPP retract message to withdraw the route advertisement.
Retract request from VPN Forwarder to End-System Route Server: Retract request from VPN Forwarder to End-System Route Server:
<iq type='set' <iq type='set'
from='forwarder.domain.org' from='forwarder@domain.org'
to='route-server@ietf.org' to='route-server@ietf.org'
id='retract1'> id='retract1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'> <pubsub xmlns='http://jabber.org/protocol/pubsub'>
<retract node='vpn-customer-name'> <retract node='vpn-customer-name'>
<item id='192.0.2.1:1:203.0.113.42/32'/> <item id='192.0.2.1:1:203.0.113.42/32'/>
</retract> </retract>
</pubsub> </pubsub>
</iq> </iq>
The retract message uses the ItemId to identify the item being The retract stanza uses the ItemId to identify the item being
retracted. The example retract message above uses the L3VPN NLRI retracted. The example retract stanza above uses the L3VPN NLRI
string representation ItemId format used in the publish example. string representation ItemId format used in the publish example.
Consistent with XMPP Pub-Sub [pubsub] Event notifications will be Consistent with XMPP Pub-Sub [pubsub], event notifications will be
generated whenever a VPN route is added, modified or deleted. This generated whenever a VPN route is added, modified or deleted. This
is true for VPN routes learned via XMPP clients as well as routes is true for VPN routes learned via XMPP clients as well as routes
learned via BGP. For VPN routes that are learned via BGP (rather learned via BGP. For VPN routes that are learned via BGP (rather
than XMPP clients) the Route Server SHOULD create XMPP Pub-Sub than XMPP clients) the Route Server SHOULD create XMPP Pub-Sub
Publish messages or otherwise take steps to publish a persistent item Publish stanzas or otherwise take steps to publish a persistent item
under the NodeID associated with the VPN Identifier of the under the NodeID associated with the VPN Identifier of the
appropriate VRF(s). Thus the Pub-Sub node will contain items for appropriate VRF(s). Thus the Pub-Sub node will contain items for
every route for the associated VPN. Upon successfully publishing a every route for the associated VPN. Upon successfully publishing a
Pub-Sub item the XMPP server SHALL generate event notification Pub-Sub item the XMPP server SHALL generate event notification
messages and send them to all VPN Forwarders that are actively messages and send them to all VPN Forwarders that are actively
subscribed to that node. These event notifications SHOULD be sent as subscribed to that node. These event notification messages SHOULD be
soon as possible (without delay) in order to facilitate convergence sent as soon as possible (without delay) in order to facilitate
and consistent reachability. convergence and consistent reachability.
Example update notification from Route Server to VPN Forwarder: Example update notification message from Route Server to VPN
Forwarder:
<message to='forwarder.domain.org' from='route-server@ietf.org'> <message to='forwarder@domain.org' from='route-server@ietf.org'>
<event xmlns='http://jabber.org/protocol/pubsub#event'> <event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='vpn-customer-name'> <items node='vpn-customer-name'>
<item id='192.0.2.1:1:203.0.113.42/32'> <item id='192.0.2.1:1:203.0.113.42/32'>
<entry xmlns='urn:ietf:params:xml:ns:bgp:l3vpn:unicast'> <entry xmlns='urn:ietf:params:xml:ns:bgp:l3vpn:unicast'>
<nlri> <nlri>
<af>1</af> <af>1</af>
<address>203.0.113.42/32</address> <address>203.0.113.42/32</address>
</nlri> </nlri>
<next-hops> <next-hops>
<next-hop> <next-hop>
<af>1</af> <af>1</af>
<address>192.0.2.1</address> <address>192.0.2.1</address>
<label>10000</label> <label>10000</label>
<tunnel-encapsulation-list> <tunnel-encapsulation-list>
<tunnel-encapsulation>gre</tunnel-encapsulation> <tunnel-encapsulation>gre</tunnel-encapsulation>
<tunnel-encapsulation>udp</tunnel-encapsulation> <tunnel-encapsulation>udp</tunnel-encapsulation>
</tunnel-encapsulation-list> </tunnel-encapsulation-list>
</next-hop> </next-hop>
</next-hops> </next-hops>
<sequence-number>1</sequence-number> <sequence-number>1</sequence-number>
</entry> </entry>
</item> </item>
<item > <item >
... ...
</item> </item>
</items> </items>
</event> </event>
</message> </message>
Notifications should be generated whenever a VPN route is added, Notification messages SHOULD be generated whenever a VPN route is
modified or deleted. These notification messages contain only items added, modified or deleted. These notification messages SHOULD
that have been added, modified or deleted since the previous contain only items that have been added, modified or deleted since
information sent to the VPN Forwarder. Notification messages can be any previous information that was sent to the VPN Forwarder.
segmented at the convenience of the Router Server. Notification messages can be segmented at the convenience of the
Route Server.
Note that the Update from the Route Server to the VPN Forwarder does Note that the Update from the Route Server to the VPN Forwarder does
not contain the JID of the destination end-system. The "from" not contain the JID of the destination end-system. The "from"
attribute in the 'message' element contains the Route Server JID. attribute in the 'message' element contains the Route Server JID.
The XMPP messages are point-to-point in nature, between a Forwarder The XMPP messages are point-to-point in nature, between a Forwarder
and Route Server, even in the case when one XMPP publish request from and Route Server, even in the case when one XMPP publish request from
a Forwarder may cause the Route Server to generate one or more event a Forwarder may cause the Route Server to generate one or more event
notifications. notifications.
The ItemId used in publish and retract messages MUST be unique within
the context of an XMPP pubsub node as required by [pubsub].
When multiple possible routes exist for a given VPN IP address within When multiple possible routes exist for a given VPN IP address within
a VRF it is the responsibility of the Route Server to select the best a VRF it is the responsibility of the Route Server to select the best
path to advertise to the VPN Forwarders. The routing entries path to advertise to the VPN Forwarders. The routing entries
published by the Route Server to VPN Forwarders MAY include multiple published by the Route Server to VPN Forwarders MAY include multiple
next-hop for the same forwarding entry. While BGP L3VPN NLRI encode next-hops for the same forwarding entry. While BGP L3VPN NLRI
a single next-hop, multiple NLRI with different RDs may result in a encodes a single next-hop, multiple NLRI with different RDs may
single forwarding entry in a VRF with multiple next-hops. This result in a single forwarding entry in a VRF with multiple next-hops.
functionality is known as "vrf multipath" in standard BGP L3VPN This functionality is known as "vrf multipath" in standard BGP L3VPN
implementations. This "vrf multipath" behavior can be applied to implementations. This "vrf multipath" behavior can be applied to
both BGP and XMPP learned routing information. The criteria used for both BGP and XMPP learned routing information. The criteria used for
multipath selection is outside the scope of this document but SHOULD multipath selection is outside the scope of this document but SHOULD
be consistent between the Route Servers within an administrative be consistent between the Route Servers within an administrative
domain. domain.
A VPN Forwarder uses locally originated information to generate MPLS A VPN Forwarder uses locally originated information to generate MPLS
label forwarding state, used to forward downstream traffic (i.e., label forwarding state, and this used to forward downstream traffic
traffic received from the network). Upstream traffic (i.e., received (i.e., traffic received from the network). Upstream traffic (i.e.,
from a virtual interface) is forwarded according to the routing received from a virtual interface) is forwarded according to the
information received from one or more Route Servers that the VPN routing information received from one or more Route Servers that the
forwarder has an XMPP session with. In the case where multiple VPN forwarder has an XMPP session with. In the case where multiple
Router Servers are providing routing information for a specific NLRI Router Servers are providing routing information for a specific NLRI
the VPN Forwarder SHOULD select the following algorithm: the VPN Forwarder SHOULD select the following algorithm:
Prefer the highest local-preference value; o Prefer the highest local-preference value
Prefer the highest sequence-number; o Prefer the highest sequence-number
Tie-break on the Route Server IP address. o Tie-break on the Route Server IP address
When routes are withdrawn, the End-System Route Server generates an When routes are withdrawn, the End-System Route Server generates an
item "retract" request. item "retract" request.
Route advertisements can have an optional sequence-number which help Route advertisements can have an optional sequence-number which help
the route server determine the most recent route advertisement. The the route server determine the most recent route advertisement. The
sequence number is determined by a mechanism external to this sequence number is determined by a mechanism outside the scope of
document. One example is to use time synchronization between compute this document. One option is to use time synchronization between
nodes to have a globally coordinated timestamp. This timestamp can compute nodes in order to have a globally coordinated timestamp.
be used to identify the time of interface creation on the compute This timestamp can be used to identify the time of interface creation
node. on the compute node.
Routes can also be associated with a "local-preference" attribute. Routes can also be associated with a "local-preference" attribute.
This attribute maps to the BGP attribute of the same name for the This attribute maps to the BGP attribute of the same name for the
purposes of route selection. purposes of route selection.
7. End-System Route Server behavior 7. End-System Route Server behavior
End-System Route Servers SHALL support the BGP address families: VPN- End-System Route Servers SHALL support the BGP address families: VPN-
IPv4 (1, 128), VPN-IPv6 (2, 128) and RT-Constraint (1, 132) IPv4 (1, 128), VPN-IPv6 (2, 128) and RT-Constraint (1, 132)
[RFC4684]. [RFC4684].
When an End-System Route Server receives a request to create or When an End-System Route Server receives a request to create or
modify a VPN route it SHALL generate a BGP VPN route advertisement modify a VPN route it SHALL generate a BGP VPN route advertisement
with the corresponding information. with the corresponding information.
It is assumed that the End-System Route Servers have information It is assumed that the End-System Route Servers have information
regarding the mapping between the tuple ('end-system', 'vpn-customer- regarding the mapping between the tuple ('end-system', 'vpn-name')
names') and BGP Route Targets used to import and export information and the BGP Route Targets used to import and export information from
from the associated VRFs. This mapping is known via an out-of-band associated VRFs. This mapping is known via an out-of-band mechanism
mechanism not specified in this document. not specified in this document.
Whenever the End-System Route Server receives an XMPP subscription Whenever the End-System Route Server receives an XMPP subscription
request, it SHALL consult its RT-Constraint Routing Information Base request, it SHALL consult its RT-Constraint Routing Information Base
(RIB). If the Route Server does not have a locally originated RT- (RIB). If the Route Server does not have a locally originated RT-
Constraint route that corresponds to the vpn-name present in the Constraint route that corresponds to the vpn-name present in the
request, it SHALL create one and generate the corresponding BGP route request, it SHALL create one and generate the corresponding BGP route
advertisement. This route advertisement should only be withdrawn advertisement. This route advertisement should only be withdrawn
when there are no more downstream XMPP clients subscribed to the VPN. when there are no more downstream XMPP clients subscribed to the VPN.
End-System Route Servers SHOULD automatically assign a BGP route End-System Route Servers SHOULD automatically assign a BGP route
distinguisher per VPN routing table. distinguisher per VPN routing table.
8. Operational Model 8. Operational Model
In the simplest case, a VPN is a collection of systems that are In the simplest case, a VPN is a collection of systems that are
allowed to exchange traffic with each other and only with each other. allowed to exchange traffic with each other, and only with each
Since all the forwarding tables in this VPN have the same routing other. Since all the forwarding tables in this VPN have the same
entries they are often referred to as symmetrical VPNs. routing entries they are often referred to as symmetrical VPNs.
In order to better illustrate the operation of the protocol we In order to better illustrate the operation of the protocol, we
consider a simple example in which "host 1" and "host 2" both contain consider a simple example in which host H1 and host H2 both contain a
a virtual interface that is a member of the same VPN. virtual interface that is a member of the same VPN.
Each of these hosts has an XMPP session with an End-System Route .------.
Server, RS1 and RS2 our example, and these Route Servers are part of +----+ +-----+ / \ +-----+ +----+
the same BGP mesh. | H1 | <===> | RS1 | <===> ( BGP mesh ) <===> | RS2 | <===> | H2 |
+----+ +-----+ \ / +-----+ +----+
`------'
When a virtual interface is created on "host 1", the local XMPP Example Network with Two Hosts and Two Route Servers
client generates an XMPP subscription message to its respective Route
Server. This message contains a VPN identifier that has been
assigned by the provisioning system. The Route Server maps that
identifier to a BGP IP VPN configuration which contains the list of
import and export route targets to be used for that particular VRF.
Once the interface is operational, "host 1" will publish any IP Figure 2
Each of these hosts has a collocated VPN forwarder that has an XMPP
session with an End-System Route Server, RS1 and RS2 our example, and
these Route Servers are part of the same BGP mesh.
When a virtual interface is created on host H1, the local XMPP client
generates an XMPP subscription stanza to its respective Route Server.
This stanza contains a VPN identifier that has been assigned by the
provisioning system. The Route Server maps that identifier to a BGP
IP VPN configuration which contains the list of import and export
route targets to be used for that particular VRF.
Once the interface is operational, host H1 will publish any IP
addresses that are configured on the respective virtual interface. addresses that are configured on the respective virtual interface.
This will in turn cause the End-System Route Server to advertise This will in turn cause the End-System Route Server to advertise
these (directly or indirectly) to any other BGP speaker on the these (directly or indirectly) to any other BGP speaker on the
network which is connected to an attachment point of that VPN. network which is connected to an attachment point of that VPN.
+--------+ +------------+ +----------+ The following table represents the contents of the VRF routing table
| host 1 | <===> | End-System | <===> | BGP mesh | on RS1 after the IPv4 address 203.0.113.42 has been added to the
+--------+ |Route Server| +----------+ virtual interface on H1.
+------------+
Figure 2
+-----------------+---------------+-------+-----------+ +-----------------+---------------+-------+-----------+
| VPN IP address | NEXT-HOP | label | Known via | | VPN IP address | NEXT-HOP | label | Known via |
+-----------------+---------------+-------+-----------+ +-----------------+---------------+-------+-----------+
| 203.0.113.42/32 | 192.0.2.1 | 16 | XMPP | | 203.0.113.42/32 | 192.0.2.1 | 16 | XMPP |
| | | | | | | | | |
| 203.0.113.48/32 | 198.51.100.10 | 20 | BGP | | 203.0.113.48/32 | 198.51.100.10 | 20 | BGP |
+-----------------+---------------+-------+-----------+ +-----------------+---------------+-------+-----------+
VPN Routing table on Route Server It assumes that there is an attachment point for this VPN with the
IPv4 address of 203.0.113.48 which is advertising a route to the IP
Table 1 address of an application running on H2 (203.0.113.48/32). Host H1
has an infrastructure IP address of 192.0.2.1 configured on its
The figure above represents the contents of the VRF routing table on physical interface while host H2 has IP address 198.51.100.10.
RS1 after the IPv4 address 203.0.113.42 has been added to the virtual
interface on host 1. It assumes that there is another attachment
point for this VPN with the IPv4 address of 203.0.113.48. Host 1 has
an infrastructure IP address of 192.0.2.1 configured on its physical
interface while host 2 has IP address 198.51.100.10.
The contents of the VRF routing table in the End-System Route Servers The contents of the VRF routing table in the End-System Route Servers
are advertised via XMPP Update notifications sent to host 1. This are advertised via XMPP Update notifications sent to H1, and a route
information is the used by the host to populate the forwarding table update for the IP address of H1 will be sent into the BGP mesh on to
associated with that VPN. Route Server RS2 and from there, via XMPP to H2.
+--------+ +--------+
app -- veth0 --| host 1 |=== [network] ===| host 2 |-- veth0 -- app
+--------+ +--------+
IP pkt ===> encap (GRE + label) ===> [IP net] ===> decap ===> IP pkt
[192.51.100.10, 20] map 20 to veth0
Figure 3 This information is used by the host to populate the forwarding table
associated with that VPN. The following shows the VRF table on host
H1
+-----------------+---------------+-------+ +-----------------+---------------+-------+
| VPN IP address | Host address | label | | VPN IP address | Host address | label |
+-----------------+---------------+-------+ +-----------------+---------------+-------+
| 203.0.113.42/32 | localhost | 16 | | 203.0.113.42/32 | localhost | 16 |
| | | | | | | |
| 203.0.113.48/32 | 198.51.100.10 | 20 | | 203.0.113.48/32 | 198.51.100.10 | 20 |
+-----------------+---------------+-------+ +-----------------+---------------+-------+
VRF table on host1 When an application that uses the virtual interface on host H1
Table 2
When an application that uses the virtual interface on host 1
generates packets with a destination IP address of 203.0.113.48 these generates packets with a destination IP address of 203.0.113.48 these
are routed by the VPN Forwarder implemented in the Host OS. The are routed by the VPN Forwarder implemented in the Host OS. The
packets are encapsulated with a header that contains a 20-bit label packets are encapsulated with a header that contains a label assigned
assigned by host 2. by host H2, as shown in the figure, below.
In the case the virtual interface on the host is associated with a +--------+ +--------+
guest OS, this guest OS has had its address resolution queries app -- veth0 --| H1 |=== [network] ===| H2 |-- veth0 -- app
answered with the Virtual Router MAC address. As a result, that is +--------+ +--------+
the address it uses as the destination MAC address in packets it
originates. This MAC address is not present on the encapsulated IP pkt ===> encap (GRE + label) ===> [IP net] ===> decap ===> IP pkt
[192.51.100.10, 20] map 20 to veth0
Packet Flow from Application in H1 to Application in H2
Figure 3
In the case that the virtual interface on the host is associated with
a guest OS, this guest OS has had its address resolution queries
answered with the Virtual Router MAC address, or the MAC address of
the destination MAY be supplied if it is in the same IP subnet
(broadcast domain). When the Virtual Router MAC address is supplied,
this is the address the guest OS uses as the destination MAC address
in packets it originates that are outside its IP subnet. The VPN
forwarder will replace the its MAC address with the MAC address of
the next hop in the tenant virtual network (another End System or
default gateway, for instance) before encapsulating the packet.
packet. packet.
End-System Route Servers are software applications that implement End-System Route Servers are software applications that implement
both the BGP IP VPN PE control plane as well as XMPP server both the BGP IP VPN PE control plane as well as XMPP server
functionality. These applications are not in the forwarding plane functionality. These applications are not in the forwarding plane
and do not need to be co-located with a network device. and MAY not be co-located with a network device.
Network devices MAY have direct BGP sessions to the End-System Route Network devices MAY have direct BGP sessions to the End-System Route
Servers. For instance, a router or security appliance that supports Servers. For instance, a router or security appliance that supports
BGP/MPLS IP VPNs over GRE may use its existing functionality to BGP/MPLS IP VPNs over GRE may use its existing functionality to
inter-operate directly with a collection of Virtual Machines or other inter-operate directly with a collection of Virtual Machines or other
network appliances that support this specification. network appliances that support this specification.
End-System Route Servers implement the VRF import policy and export End-System Route Servers implement the VRF import policy and export
policy functionality that is associated with PE routers in standard policy functionality that is associated with PE routers in standard
BGP IP/VPN deployments. VPN Forwarders receive forwarding BGP IP/VPN deployments. VPN Forwarders receive forwarding
skipping to change at page 23, line 24 skipping to change at page 24, line 34
import and export configuration including "hub-and-spoke" topologies import and export configuration including "hub-and-spoke" topologies
or overlapping VPNs. or overlapping VPNs.
An example of a hub-and-spoke VPN configuration is one where all the An example of a hub-and-spoke VPN configuration is one where all the
traffic from the VPN clients must be redirected though a middle-box traffic from the VPN clients must be redirected though a middle-box
for inspection. Assume that the virtual interfaces of a particular for inspection. Assume that the virtual interfaces of a particular
user are configured to be in the VPN "tenant1". At an initial stage user are configured to be in the VPN "tenant1". At an initial stage
this "tenant1" VPN is symmetrical and uses a single Route Target in this "tenant1" VPN is symmetrical and uses a single Route Target in
both its import and export policies. The middle-box functionality both its import and export policies. The middle-box functionality
can be incrementally deployed by defining a new VPN, "tenant1-hub", can be incrementally deployed by defining a new VPN, "tenant1-hub",
and an associated Route Target. Accompanied with a change in the and an associated Route Target. The End-System Route Server
End-System Route Server configuration such that VPN "tenant1" only configuration is changed such that VPN "tenant1" only imports routes
imports routes with the Route Target associated with the hub. The with the Route Target associated with the hub. The "hub" VPN is
"hub" VPN is assumed to advertise a prefix that covers all the VPN assumed to advertise a prefix that covers all the VPN clients IP
clients IP addresses. The "hub" VPN imports the VPN routes in order addresses. The "hub" VPN imports the VPN routes in order for it to
for it to be able to generate the XMPP updates to the "hub" end- be able to generate the XMPP updates to the "hub" end-system. This
system. This information is required for the return traffic from the information is required for the return traffic from the hub to the
hub to the spokes (the VPN clients). In such a scenario a single spokes (the VPN clients). In such a scenario, a single physical
physical interface can connect the middle-box to the clients in a interface can connect the middle-box to the clients in a given VPN
given VPN which appear logically as downstream from it. Such a which appear logically as downstream from it. Such a middle-box
middle-box would often require connectivity to multiple VPNs, such as would often require connectivity to multiple VPNs, such as, for
for instance an "outside" VPN which provides external connectivity to instance, an "outside" VPN which provides external connectivity to
one or more "inside" VPNs. one or more "inside" VPNs.
The functionality defined in this document in which the BGP IP VPN PE The functionality defined in this document in which the BGP IP VPN PE
functionality is split into its control (End-System Route Servers) functionality is split into its control (End-System Route Servers)
and forwarding (VPN Forwarder) components is fully interoperable with and forwarding (VPN Forwarder) components is fully interoperable with
existing BGP IP VPN PEs. existing BGP IP VPN PEs.
This makes it possible to reuse existing systems. For example, at This makes it possible to reuse existing systems. For example, at
the edge of a data center facility it may be desirable to use an the edge of a data center facility it may be desirable to use an
existing router or appliance that aggregates IP VPN routing existing router or appliance that aggregates IP VPN routing
skipping to change at page 24, line 31 skipping to change at page 25, line 41
routing information. routing information.
Registrant Contact: IETF BESS Working Group <bess@ietf.org> Registrant Contact: IETF BESS Working Group <bess@ietf.org>
10. Security Considerations 10. Security Considerations
As with BGP/MPLS L3VPN, we assume that the tenant networks have no As with BGP/MPLS L3VPN, we assume that the tenant networks have no
direct reachability to the infrastructure network. The threat models direct reachability to the infrastructure network. The threat models
to consider are: to consider are:
The possibility that an attacker on a tenant network may inject o The possibility that an attacker on a tenant network may inject
traffic to a different network (for instance belonging to a traffic to a different network (for instance belonging to a
different tenant). different tenant).
Denial of service attacks from within a tenant network. o Denial of service attacks from within a tenant network.
Attacks from a tenant network to the infrastructure via o Attacks from a tenant network to the infrastructure via
unauthorized or malicious control traffic. unauthorized or malicious control traffic.
Attacks from within the infrastructure network. o Attacks from within the infrastructure network.
BGP/MPLS L3VPN forwards traffic based on the contents of VRF tables, Traffic in BGP/MPLS L3VPNs is forwarded based on the contents of VRF
calculated according to configured routing policy (route-target tables, calculated according to configured routing policy (route-
import/export policies). It is assumed that the configuration target import/export policies). It is assumed that the configuration
management system responsible to provision this policies only accepts management system responsible for provisioning these policies only
requests that are correctly authenticated and follow a pre-defined accepts requests that are correctly authenticated, and follow a pre-
access policy. It is also assumed that an attacker doesn't have the defined access policy. It is also assumed that an attacker doesn't
ability to inject packets in the infrastructure that mimic the have the ability to inject packets in the infrastructure that mimic
encapsulated used between PE devices. This specification recommends the encapsulated used between PE devices. This specification
that operators ensure that MPLS over GRE and MPLS over UDP traffic is recommends that operators ensure that MPLS over GRE and MPLS over UDP
not allowed to enter the infrastructure network. VPN forwarders MAY traffic is not allowed to enter the infrastructure network. VPN
also choose to perform a reverse path forwarding lookup (i.e., lookup forwarders MAY also choose to perform a reverse path forwarding
the source IP address of the payload packet) and discard traffic that lookup (i.e., lookup the source IP address of the payload packet) and
doesn't match the expected next-hop(s) for the reverse route. discard traffic that doesn't match the expected next-hop(s) for the
reverse route.
As with BGP/MPLS L3VPN, an attacker on a tenant network may inject As with BGP/MPLS L3VPN, an attacker on a tenant network may inject
packets that consume a disproportional share of infrastructure packets that consume a disproportional share of infrastructure
resources, either in terms of bandwidth or CE packet forwarding resources, either in terms of bandwidth or CE packet forwarding
capacity. VPN forwarders SHOULD provide the ability to rate limit capacity. VPN forwarders SHOULD provide the ability to rate limit
traffic from a specific virtual interface. When the VPN forwarder traffic from a specific virtual interface. When the VPN forwarder
uses other finite resources on a per traffic basis such as internal uses other finite resources on a per traffic basis, such as internal
tables used to cache the result access control validation, it SHOULD tables used to cache the result access control validation, it SHOULD
provide a mechanism to limit the usage of these resources on a per provide a mechanism to limit the usage of these resources on a per
virtual interface basis. virtual interface basis.
The control protocol exchanges between application instances (e.g., The control protocol exchanges between application instances (e.g.,
the virtual machine) behind a virtual interface and the VPN forwarder the virtual machine) behind a virtual interface and the VPN forwarder
are typically limited to ARP/ND exchanges and the proxying of are typically limited to ARP/ND exchanges and the proxying of
services such as DHCP and DNS. The ARP/ND information received from services such as DHCP and DNS. The ARP/ND information received from
the application instance SHOULD NOT be used to populate routing or the application instance SHOULD NOT be used to populate routing or
forwarding tables directly. The control of what MACs and IP forwarding tables directly. The control of what MACs and IP
addresses are accepted by a virtual interface SHOULD reside on the addresses are accepted by a virtual interface SHOULD reside in the
configuration management system that creates said virtual interface. configuration management system that creates said virtual interface.
The XMPP session between end-systems and the Route Servers SHOULD use The XMPP session between end-systems and the Route Servers SHOULD use
TLS with mutual authentication. One possible strategy is to TLS with mutual authentication. One possible strategy is to
distribute pre-signed certificates to end-systems which are presented distribute pre-signed certificates to end-systems which are presented
as proof of authorization to the Route Server. BGP sessions SHOULD as proof of authorization to the Route Server. BGP sessions SHOULD
be authenticated. This document recommends that BGP speaking systems be authenticated. This document recommends that BGP speaking systems
filter traffic on port 179 such that only IP addresses which are filter traffic on port 179 such that only IP addresses which are
known to participate in the BGP signaling protocol are allowed. known to participate in the BGP signaling protocol are allowed.
skipping to change at page 25, line 50 skipping to change at page 27, line 14
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace= targetNamespace=
"urn:ietf:params:xml:ns:bgp:l3vpn:unicast"> "urn:ietf:params:xml:ns:bgp:l3vpn:unicast">
<xsd:simpleType name="TunnelEncapsulationType"> <xsd:simpleType name="TunnelEncapsulationType">
<xsd:restriction base="xsd:string"> <xsd:restriction base="xsd:string">
<xsd:enumeration value="gre"/> <xsd:enumeration value="gre"/>
<!-- RFC 4023 --> <!-- RFC 4023 -->
<xsd:enumeration value="udp"/> <xsd:enumeration value="udp"/>
<!-- draft-ietf-mpls-in-udp --> <!-- RFC 7510 -->
<xsd:enumeration value="vxlan"/>
<!-- RFC 7348 -->
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
<xsd:complexType name="TunnelEncapsulationListType"> <xsd:complexType name="TunnelEncapsulationListType">
<xsd:sequence> <xsd:sequence>
<xsd:element name="tunnel-encapsulation" <xsd:element name="tunnel-encapsulation"
type="TunnelEncapsulationType" type="TunnelEncapsulationType"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
skipping to change at page 27, line 20 skipping to change at page 28, line 32
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
<xsd:element name="items" type="ItemsType"/> <xsd:element name="items" type="ItemsType"/>
</xsd:schema> </xsd:schema>
12. Acknowledgements 12. Acknowledgements
Pedro Marques contributed much of the original content of this
document.
Yakov Rekhter has contributed to this document by providing detailed Yakov Rekhter has contributed to this document by providing detailed
feedback and suggestions. The authors would also like to thank feedback and suggestions.
Thomas Morin for his comments.
The authors would also like to thank Thomas Morin for his comments.
Amit Shukla and Ping Pan contributed to earlier versions of this Amit Shukla and Ping Pan contributed to earlier versions of this
document. document.
Benson Schliesser provided a detailed review of the document and help Benson Schliesser provided a detailed review of the document and
clarify several sections. helped clarify several sections.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>. <http://www.rfc-editor.org/info/rfc3688>.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
"Encapsulating MPLS in IP or Generic Routing Encapsulation "Encapsulating MPLS in IP or Generic Routing Encapsulation
(GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,
<http://www.rfc-editor.org/info/rfc4023>. <http://www.rfc-editor.org/info/rfc4023>.
skipping to change at page 28, line 19 skipping to change at page 29, line 38
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route R., Patel, K., and J. Guichard, "Constrained Route
Distribution for Border Gateway Protocol/MultiProtocol Distribution for Border Gateway Protocol/MultiProtocol
Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
November 2006, <http://www.rfc-editor.org/info/rfc4684>. November 2006, <http://www.rfc-editor.org/info/rfc4684>.
[RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP Subsequent Address Family Identifier (SAFI) and the BGP
Tunnel Encapsulation Attribute", RFC 5512, DOI 10.17487/ Tunnel Encapsulation Attribute", RFC 5512,
RFC5512, April 2009, DOI 10.17487/RFC5512, April 2009,
<http://www.rfc-editor.org/info/rfc5512>. <http://www.rfc-editor.org/info/rfc5512>.
[RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP)
Version 3 for IPv4 and IPv6", RFC 5798, DOI 10.17487/ Version 3 for IPv4 and IPv6", RFC 5798,
RFC5798, March 2010, DOI 10.17487/RFC5798, March 2010,
<http://www.rfc-editor.org/info/rfc5798>. <http://www.rfc-editor.org/info/rfc5798>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
March 2011, <http://www.rfc-editor.org/info/rfc6120>. March 2011, <http://www.rfc-editor.org/info/rfc6120>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<http://www.rfc-editor.org/info/rfc7348>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <http://www.rfc-editor.org/info/rfc7432>. 2015, <http://www.rfc-editor.org/info/rfc7432>.
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
"Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/ "Encapsulating MPLS in UDP", RFC 7510,
RFC7510, April 2015, DOI 10.17487/RFC7510, April 2015,
<http://www.rfc-editor.org/info/rfc7510>. <http://www.rfc-editor.org/info/rfc7510>.
[RFC7622] Saint-Andre, P., "Extensible Messaging and Presence [RFC7622] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Address Format", RFC 7622, DOI 10.17487/ Protocol (XMPP): Address Format", RFC 7622,
RFC7622, September 2015, DOI 10.17487/RFC7622, September 2015,
<http://www.rfc-editor.org/info/rfc7622>. <http://www.rfc-editor.org/info/rfc7622>.
[xep-0004] [xep-0004]
Eatmon, R., Hildebrand, J., Miller, J., Muldowney, T., and Eatmon, R., Hildebrand, J., Miller, J., Muldowney, T., and
P. Saint-Andre, "Data Forms", XEP 0004, August 2007. P. Saint-Andre, "Data Forms", XEP 0004, August 2007.
[pubsub] Millard, P., Saint-Andre, P., and R. Meijer, "Publish- [pubsub] Millard, P., Saint-Andre, P., and R. Meijer, "Publish-
Subscribe", XEP 0060, July 2010. Subscribe", XEP 0060, July 2010.
13.2. Informational References 13.2. Informational References
[RFC1027] Carl-Mitchell, S. and J. Quarterman, "Using ARP to [RFC1027] Carl-Mitchell, S. and J. Quarterman, "Using ARP to
implement transparent subnet gateways", RFC 1027, DOI implement transparent subnet gateways", RFC 1027,
10.17487/RFC1027, October 1987, DOI 10.17487/RFC1027, October 1987,
<http://www.rfc-editor.org/info/rfc1027>. <http://www.rfc-editor.org/info/rfc1027>.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
<http://www.rfc-editor.org/info/rfc5575>. <http://www.rfc-editor.org/info/rfc5575>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<http://www.rfc-editor.org/info/rfc5880>. <http://www.rfc-editor.org/info/rfc5880>.
skipping to change at page 29, line 33 skipping to change at page 31, line 17
Virtualization", RFC 7365, DOI 10.17487/RFC7365, October Virtualization", RFC 7365, DOI 10.17487/RFC7365, October
2014, <http://www.rfc-editor.org/info/rfc7365>. 2014, <http://www.rfc-editor.org/info/rfc7365>.
[IEEE.802-1Q] [IEEE.802-1Q]
Institute of Electrical and Electronics Engineers, "Local Institute of Electrical and Electronics Engineers, "Local
and Metropolitan Area Networks: Virtual Bridged Local Area and Metropolitan Area Networks: Virtual Bridged Local Area
Networks", IEEE Std 802.1Q-2005, May 2006. Networks", IEEE Std 802.1Q-2005, May 2006.
Authors' Addresses Authors' Addresses
Pedro Marques Stuart Mackie
Juniper Networks Juniper Networks
1133 Innovation Way 1133 Innovation Way
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: roque@juniper.net Email: wsmackie@juniper.net
Luyuan Fang Luyuan Fang
Microsoft eBay
5600 148th Ave NE 2025 Hamilton Avenue
Redmond, WA 98052 San Jose, CA 95125
Email: lufang@ebay.com
Email: lufang@microsoft.com
Nischal Sheth Nischal Sheth
Juniper Networks Juniper Networks
1133 Innovation Way 1133 Innovation Way
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: nsheth@juniper.net Email: nsheth@juniper.net
Maria Napierala Maria Napierala
AT&T Labs AT&T Labs
200 Laurel Avenue 200 Laurel Avenue
Middletown, NJ 07748 Middletown, NJ 07748
Email: mnapierala@att.com Email: mnapierala@att.com
Nabil Bitar Nabil Bitar
Verizon Nokia
40 Sylvan Rd.
Waltham, MA 02145
Email: nabil.bitar@verizon.com Email: nabil.bitar@nokia.com
 End of changes. 136 change blocks. 
381 lines changed or deleted 425 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/