Internet DRAFT - draft-cai-l2vpn-evpn-vlan-aware-bundling
draft-cai-l2vpn-evpn-vlan-aware-bundling
INTERNET-DRAFT Dennis Cai
Intended Status: Informational Track Sami Boutros
Samer Salam
Reshad Rahman
Expires: December 30, 2012 June 28, 2012
VLAN Aware EVPN services
draft-cai-l2vpn-evpn-vlan-aware-bundling-00.txt
Abstract
This document specifies E-VPN extensions to support the new VLAN
aware bundling service interface type defined in [EVPN-REQ]. The new
service interface type provides advantages in reducing provisioning
overhead as well as E-VPN instances scale in environments where a
large number of VLANs need to be extended over an MPLS/IP network,
while maintaining traffic segregation among those VLANs. The VLAN
aware bundling service interface can handle the high scale
requirements of today's Data Centers by bundling different VLANs over
a single WAN E-VPN instance used to interconnect those Data Center
sites.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Cai Expires December 30, 2012 [Page 1]
INTERNET DRAFT VLAN Aware EVPN Services June 28, 2012
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. VLAN-aware-bundling E-VPN . . . . . . . . . . . . . . . . . . 3
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Packet forwarding, MAC learning, aging and flushing . . . . 5
3.2 Multicast Pruning . . . . . . . . . . . . . . . . . . . . . 5
3.3 OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4 VLAN translation . . . . . . . . . . . . . . . . . . . . . . 5
4 Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1 Normative References . . . . . . . . . . . . . . . . . . . 6
5.2 Informative References . . . . . . . . . . . . . . . . . . 6
6 Appendix Vlan Aware VPLS . . . . . . . . . . . . . . . . . . . . 6
6.1 VLAN-aware-bundling PW . . . . . . . . . . . . . . . . . . . 7
6.2 PW VLAN Vector TLV . . . . . . . . . . . . . . . . . . . . . 7
6.3 LDP Capability Negotiation . . . . . . . . . . . . . . . . . 8
6.4 Multicast Pruning . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Cai Expires December 30, 2012 [Page 2]
INTERNET DRAFT VLAN Aware EVPN Services June 28, 2012
1 Introduction
The high scale requirements of Layer 2 data center interconnect
services mandate the signaling of a large number of WAN E-VPN
instances. As such, network operators are looking for solutions
whereby they can extend multiple Ethernet VLANs over a WAN using a
single E-VPN instance, while maintaining traffic segregation among
these VLANs in the data-plane. This gives rise to a requirement for a
new service interface types: the VLAN aware bundling service
interfaces.
These new VLAN aware bundling service interfaces MUST: - Provide the
ability to bundle multiple customer VLANs - Guarantee customer VLAN
transparency end-to-end.- Maintain data-plane separation between the
customer VLANs by creating a dedicated bridge-domain per VLAN.-
Support customer VLAN translation to handle the scenario where
different VLAN Identifiers (VIDs) are used on different sites to
designate the same customer VLAN.
As discussed in [EVPN-REQ], two new service interface types are
defined for VLAN aware bundling: with and without translation. The
new service interfaces maintain data-plane separation, per VLAN,
while sharing one L2VPN E-VPN instance. This document describes the
use of different E-VPN routes as defined in [E-VPN] for implementing
the VLAN-aware bundling service.
1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
MAC: Media Access Control
MPLS: Multi Protocol Label Switching.
OAM: Operations, Administration and Maintenance.
PE: Provide Edge Node.
CE: Customer Edge device e.g., host or router or switch.
EVI: E-VPN Instance.
2. VLAN-aware-bundling E-VPN
[E-VPN] uses a new BGP NLRI for advertising different route types for
Cai Expires December 30, 2012 [Page 3]
INTERNET DRAFT VLAN Aware EVPN Services June 28, 2012
E-VPN operation.
This document discusses how the Ethernet Tag field in the Ethernet
Auto-Discovery Route, Mac Advertisement route, and inclusive
multicast Ethernet tag route can be used to multiplex several VLANs
over the same EVI.
3. Operation
The following figure shows an example of how a VLAN aware Bundling
service type over E-VPN could be deployed.
+---------------------------------+
| VLAN aware E-VPN PE1 |
| +---------------+ |
| | | |
| +------+ | | |
+--+ | | | | | |
|CE|-|---| BD ==== | | +------+
+--+ | | | 1 | | | | | |
| | +------+ | VLAN aware | | | PE2 | +----+
| | |E-VPN Instance ============| |---| CE |
| | | | | | | +----+
| | +------+ | | | +------+
+--+ | --| BD | | | |
|CE|-|---| 2 ==== | |
+--+ | | | | | |
| +------+ | | |
| +---------------+ |
| |
+---------------------------------+
One E-VPN instance has been set up between two sites to extend
multiple customer VLANs. On each site, multiple CE devices could be
connected to the PE. The link between the CE and the PE could be C-
tag or S-tag interface per [802.1Q], carrying several VLANs.Only a
single E-VPN instance has been set up to carry customer VLANs between
the two sites. The use of two sites in the above figure is for
illustration; however, this could be extended to many sites. In order
to quantify the benefit of the approach, let's assume N data center
sites, with M customer VLANs. With the new VLAN aware service
interface type, the solution would require one E-VPN instance,
instead of M E-VPN instances. To maintain data-plane separation among
the customer VLANs, each PE will create a bridge-domain per customer
VLAN. As well, a customer VLAN on each CE port will represent a
unique bridge port in the customer bridge-domain. Only one E-VPN
instance would be signaled in the core and will be used to carry
multiple customer bridge-domains (or customer VLANs) as long as those
Cai Expires December 30, 2012 [Page 4]
INTERNET DRAFT VLAN Aware EVPN Services June 28, 2012
customer VLANs need to be extended to the same set of sites. On the
egress PE, the E-VPN label + the VLAN-tag would identify the
customer-bridge domain.
3.1 Packet forwarding, MAC learning, aging and flushing
Given the data-plane separation, packet forwarding in the scope of
one bridge-domain will remain unchanged. When sending traffic over
the E-VPN instance, a qualifying VLAN tag MUST be present on the
packet. This VLAN tag has global significance across all sites
connected to the E-VPN instance and is used to identify the customer
bridge domain in all sites. MAC learning, aging and flushing per
bridge-domain will remain un-changed. A mass withdraw for MAC routes
learned over the EVPN instance can be done by withdrawing the
Ethernet AD route with the tag ID corresponding to the bridge domain.
3.2 Multicast Pruning
Efficient multicast replication in the core can be achieved via the
use of the Inclusive Multicast Ethernet Tag Route, to prune the
flooding on a per VLAN basis. It is possible to only replicate
traffic to PEs that have advertised the Inclusive Multicast Ethernet
Tag Route with the Tag value set to the VLAN value. If VLAN value is
set to zero, then a single multicast LSM is setup to be used for all
VLAN traffic for that E-VPN instance. Multicast snooping protocols
such as IGMP and PIM MAY be used to further prune the replication
scope for a given multicast group in one customer bridge-domain.
3.3 OAM
Customer Ethernet OAM frames (e.g. CFM [802.1ag]) will be carried
transparently over the shared E-VPN instance by the customer's
bridge-domains. Current MPLS OAM mechanisms need to be extended to
verify connectivity in the E-VPN instance shared by the customer
bridge-domains, service level OAM monitoring should be performed
according to [RFC-6136], MPLS OAM extensions is out of scope of the
document.
3.4 VLAN translation
As mentioned above, the VLAN tag carried across the E-VPN instance
for the new VLAN aware bundling E-VPN instance MUST have network wide
significance within the scope of the E-VPN instance. As such, VLAN
translation may be performed at each PE attached to the E-VPN
instance to translate between the global VLAN tag identifying the
customer bridge-domain and the local VLAN tag used by the customer
Cai Expires December 30, 2012 [Page 5]
INTERNET DRAFT VLAN Aware EVPN Services June 28, 2012
bridge-domain on this PE.
4 Security Considerations
This document does not introduce any additional security constraints.
4 IANA Considerations
TBD
5 References
5.1 Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April
1 1995.
[TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925,
April 1 1996.
5.2 Informative References
[EVPN-REQ] A. Sajassi, R. Aggarwal et. al., "Requirements for
Ethernet VPN", draft-ietf-l2vpn-evpn-req-00.txt.
[EVPN] A. Sajassi, R. Aggarwal et. al., "BGP MPLS Based Ethernet
VPN", draft-ietf-l2vpn-evpn-00.txt.
[RFC-6136] Layer 2 Virtual Private Network (L2VPN) Operations,
Administration, and Maintenance (OAM) Requirements and
Framework.
6 Appendix Vlan Aware VPLS
It is possible to extend VPLS to support VLAN aware bundling type
service, a new PW VLAN Vector TLV to be included the LDP PW FEC label
mapping messages for the VPLS service, using the mechanisms specified
in RFC 4762, as well as a new LDP capability by which a PE can
specify its ability to support this new VLAN aware bundling service
interface type. The new PW VLAN Vector TLV would allow multiple VLANs
Cai Expires December 30, 2012 [Page 6]
INTERNET DRAFT VLAN Aware EVPN Services June 28, 2012
to share a single VPLS instance, while maintaining data plane
segregation among these VLANs. This document defines extension to the
PWE3 control protocol [RFC4447] to set up the new VLAN aware bundling
type service in MPLS networks. An extension to the MAC Withdrawal
mechanisms would allow per VLAN service MAC flushing for this new
VLAN aware bundling service.
6.1 VLAN-aware-bundling PW
[RFC4447] uses LDP Label Mapping message [RFC5036] for advertising
the FEC-to-PW Label binding. Two types of PW FEC, FEC-128 and FEC-
129, can be used for this purpose. Both types of PW FEC contain a PW
type Field.
PW type port or raw mode will be used for the VLAN aware bundling
interface type service.
Use of control word is optional and frame encapsulation follows the
same rules as in [RFC4448].
A new PW VLAN vector TLV is defined, the new PW VLAN Vector TLV will
be included in LDP PW label mapping messages, as well it can be
included in the MAC flush message.
6.2 PW VLAN Vector TLV
The PW VLAN Vector TLV is described as below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| VLAN Vector(TBD)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|first VLAN Value |NumberOfValues | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| VLANFlushBits[NumberOfValues] |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The U and F bits are set to forward if unknown so that potential
intermediate VPLS PEs unaware of the new TLV can just propagate it
transparently.
The MAC Flush VLAN Vector TLV type is to be assigned by IANA from
the LDP standard [RFC5036] "TLV type name space", as described in
section 7.
The TLV value field is of variable length. The first 12 bits encode
Cai Expires December 30, 2012 [Page 7]
INTERNET DRAFT VLAN Aware EVPN Services June 28, 2012
the starting VLAN value. The second 12 bits contain the number of
values. The VLANFlushBits is an array of bits of length =
NumberOfValues, each bit in the array represents a VLAN flush state
starting from the 1st VLAN value. A bit value of 1 means flush and a
bit value of 0 means don't flush
A Starting VLAN value of 0, SHOULD mean include all VLANs, in this
case the NumberOfValues SHOULD be 0.
The PW VLAN Vector TLV SHOULD be placed after the PW FEC TLV in the
label mapping message as specified in [RFC4447], and SHOULD be placed
after the existing TLVs in MAC Flush message as specified in
[RFC4762].
6.3 LDP Capability Negotiation
The capability of supporting VLAN Aware Bundling interface type
Service MUST be advertised to all LDP peers. This is achieved by
using the methods in [RFC5561] and advertising the LDP "VLAN aware
Bundling Capability" TLV. If an LDP peer supports the dynamic
capability advertisement, it can send a new Capability message with
the S bit set for the VLAN Aware Bundling capability TLV. If the peer
does not supports dynamic capability advertisement, then the VLAN
aware Bundling Capability TLV MUST be included in the LDP
Initialization message during the session establishment. An LSR
having VLAN Aware Bundling capability MUST recognize the new PW VLAN
Vector TLV in LDP label messages.
In line with requirements listed in [RFC5561], the following TLV is
defined to indicate the VLAN Aware Bundling capability:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| VLAN Aware Capability TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: TLV number pending IANA allocation.
* U-bit: SHOULD be 1 (ignore if not understood).
* F-bit: SHOULD be 0 (don't forward if not understood).
* VLAN Aware Bundling Capability TLV Code Point:
The TLV type, which identifies a specific capability. The VLAN
Aware capability code point is requested in the IANA
allocation section below.
Cai Expires December 30, 2012 [Page 8]
INTERNET DRAFT VLAN Aware EVPN Services June 28, 2012
* S-bit:
The State Bit indicates whether the sender is advertising or
withdrawing the VLAN Aware capability. The State bit is used
as follows:
1 - The TLV is advertising the capability specified by the
TLV Code Point.
0 - The TLV is withdrawing the capability specified by the
TLV Code Point.
* Length: MUST be set to 2 (octet).
6.4 Multicast Pruning
Efficient multicast replication in the core can be achieved via the
use of the new VLAN vector TLV, to prune the flooding on a per VLAN
basis. It is possible to only replicate traffic to PEs that have
advertised a given VLAN in their Vector TLV. Multicast snooping
protocols such as IGMP and PIM MAY be used to further prune the
replication scope for a given multicast group in one customer bridge-
domain.
Authors' Addresses
Dennis Cai
Cisco Systems
EMail: dcai@cisco.com
Sami Boutros
Cisco Systems
EMail: sboutros@cisco.com
Samer Salam
Cisco Systems
EMail: ssalam@cisco.com
Reshad Rahman
Cisco Systems
EMail: rrahman@cisco.com
Cai Expires December 30, 2012 [Page 9]
INTERNET DRAFT VLAN Aware EVPN Services June 28, 2012
Cai Expires December 30, 2012 [Page 10]
