INTERNET-DRAFT Dennis Cai Intended Status: Standard Track Sami Boutros Samer Salam Reshad Rahman Expires: April 16, 2013 October 13, 2012 VLAN Aware VPLS services draft-cai-l2vpn-vpls-vlan-aware-bundling-00.txt Abstract This document specifies VPLS extensions to support the new VLAN aware bundling service interface type. The new service interface type provides advantages in reducing the provisioning overhead, as well as pseudowire scalability 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 VPLS instance used to interconnect sites. Furthermore, this document specifies an extension to the LDP MAC Withdrawal mechanisms to allow per-VLAN MAC flushing for the new service interface type. 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 Cai Expires April 16, 2013 [Page 1] INTERNET DRAFT VLAN Aware VPLS Services October 13, 2012 Copyright and License Notice 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 PW . . . . . . . . . . . . . . . . . . . . 4 3. PW VLAN Vector TLV . . . . . . . . . . . . . . . . . . . . . . 4 4. LDP Capability Negotiation . . . . . . . . . . . . . . . . . . 5 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Packet forwarding, MAC learning, aging and flushing . . . . 7 5.2. Multicast Pruning . . . . . . . . . . . . . . . . . . . . . 7 5.3. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.4. VLAN translation . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1 Normative References . . . . . . . . . . . . . . . . . . . 8 8.2 Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Cai Expires April 16, 2013 [Page 2] INTERNET DRAFT VLAN Aware VPLS Services October 13, 2012 1 Introduction The high scale requirements of Layer 2 data center interconnect services mandate the signaling of a large number of WAN VPLS instances. As such, network operators are looking for solutions whereby they can extend multiple Ethernet VLANs over a WAN using a single VPLS instance, while maintaining traffic segregation among these VLANs in the data-plane. This gives rise to a requirement for 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 VPN instance. In this document, we focus on the scenario where VPLS is the L2VPN technology. This document defines a new PW VLAN Vector TLV to be included in 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. Furthermore, This document defines extension to the PWE3 control protocol [RFC4447] to set up the new VLAN aware bundling type service in MPLS networks. The document specifies as well an extension to the MAC Withdrawal mechanisms to allow per VLAN service MAC flushing for this new 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]. LDP: Label Distribution Protocol. MAC: Media Access Control MPLS: Multi Protocol Label Switching. OAM: Operations, Administration and Maintenance. PE: Provide Edge Node. PW: PseudoWire. TLV: Type, Length, and Value. VPLS: Virtual Private LAN Services. Cai Expires April 16, 2013 [Page 3] INTERNET DRAFT VLAN Aware VPLS Services October 13, 2012 2. 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 MAY be included in the MAC flush message. 3. 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 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. Cai Expires April 16, 2013 [Page 4] INTERNET DRAFT VLAN Aware VPLS Services October 13, 2012 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]. 4. 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 support 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 the 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. * 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. Cai Expires April 16, 2013 [Page 5] INTERNET DRAFT VLAN Aware VPLS Services October 13, 2012 0 - The TLV is withdrawing the capability specified by the TLV Code Point. * Length: MUST be set to 2 (octet). 5. Operation The following figure shows the VPLS PE model for supporting the VLAN aware service interface. +---------------------------------+ | VLAN aware VPLS PE1 | | +---------------+ | | | | | | +------+ | | | +--+ | | | | | | |CE|-|---| BD ==== | | +------+ +--+ | | | 1 | | | | | | | | +------+ | VLAN aware | | | PE2 | +----+ | | | PW Fwdr ===== PW ===| |---| CE | | | | | | | | +----+ | | +------+ | | | +------+ +--+ | --| BD | | | | |CE|-|---| 2 ==== | | +--+ | | | | | | | +------+ | | | | +---------------+ | | | +---------------------------------+ One VPLS 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 802.1q or 802.1ad, setup with multiple VLANs. Unlike a classic VPLS solution that requires a dedicated VPLS instance for each customer VLAN, only a single VPLS 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. Classic VPLS full mesh solution would require M VPLS instances and M*(N-1) PWs on each PE. While with the new VLAN aware interface service type, the solution would require one VPLS instance and will only require (N-1) PWs on each PE. To maintain data-plane separation per customer VLAN, with the new VLAN aware interface service, 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 VPLS instance would be signaled in the core and will be used to carry multiple customer bridge-domains (or customer VLANs) as long as Cai Expires April 16, 2013 [Page 6] INTERNET DRAFT VLAN Aware VPLS Services October 13, 2012 those customer VLANs need to be extended to the same set of sites. Unlike classic VPLS, where the VPLS PW is presented as a bridge port, the VFI and the customer VLAN would map to the customer bridge- domain. 5.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 PW, a qualifying VLAN tag MUST be present on the packet. This VLAN tag has global significance across all sites connected to the VPLS 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. Extensions to MAC withdrawal mechanisms, as described in section 4, would allow the MAC flushing to occur on a subset of the customer bridge-domains. 5.2. 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. 5.3. OAM Customer Ethernet OAM frames (e.g. CFM [802.1ag]) will be carried transparently over the shared VPLS instance by the customers bridge- domains. Current VCCV mechanisms can be used to verify PWs connectivity in the VPLS instance shared by the customer bridge- domains. VPLS OAM framework as defined in [RFC6136] applies to this new service with no changes. 5.4. VLAN translation As mentioned above, the VLAN tag carried across the PWs for the new VLAN aware bundling VPLS instance MUST have network global significance within the scope of the VPLS instance. As such, VLAN translation can happen at each PE attached to the VPLS instance to translate between the global VLAN tag identifying the customer bridge-domain and the local VLAN tag used by the customer bridge- domain on this PE. 6. Security Considerations Cai Expires April 16, 2013 [Page 7] INTERNET DRAFT VLAN Aware VPLS Services October 13, 2012 This document does not introduce any additional security constraints. 7. IANA Considerations Two new types field for the VLAN Vector TLV type and VLAN aware Bundling Capability TLV type are to be assigned by IANA from the LDP standard [RFC5036] "TLV type name space". 8 References 8.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. 8.2 Informative References [RFC 4762] Mark Lassere, et. al, "Virtual Private LAN Service (LAN) Using Label Distribution Protocol (LDP) Signaling", RFC4762, January 2007. [RFC 5036] Andersson, L., et al. "LDP Specification", RFC5036, October 2007. [RFC 4447] Martini. and et al., "Pseudowire Setup and Maintenance Using Label Distribution Protocol (LDP)", RFC 4447, April 2006. [RFC 4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006. [EVPN-REQ] A. Sajassi, R. Aggarwal et. al., "Requirements for Ethernet VPN", draft-ietf-l2vpn-evpn-req-00.txt. [RFC5561] B.Thomas, K.Raza, S.Aggarwal, R.Agarwal, JL. Le Roux, "LDP Capabilities", RFC 5561, July 2009. [RFC-6136] Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Cai Expires April 16, 2013 [Page 8] INTERNET DRAFT VLAN Aware VPLS Services October 13, 2012 Framework. 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 April 16, 2013 [Page 9]