Network working group X. Xu Internet Draft Huawei Technologies Category: Standard Track H. Shah Ciena Corp Expires: April 2012 October 13, 2011 Virtual Private LAN Service (VPLS) Using IS-IS draft-xu-l2vpn-vpls-isis-02 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 13, 2012. Copyright Notice Copyright (c) 2009 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. Xu & Shah Expires April 13, 2012 [Page 1] Internet-Draft VPLS Using IS-IS October 2011 Abstract This document describes a light-weight Virtual Private LAN Service (VPLS) which uses IS-IS for auto-discovery and signaling. Conventions used in this document 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]. Table of Contents 1. Introduction ................................................ 3 2. Terminology ................................................. 4 3. Control Plane ............................................... 4 3.1. Extended IS-IS TLV for VPLS............................. 4 3.2. Auto-Discovery ......................................... 5 3.3. Signaling .............................................. 5 4. Data Plane .................................................. 6 4.1. Data Encapsulation and Forwarding .......................6 4.1.1. Unicast ........................................... 6 4.1.2. Multicast/Broadcast................................ 6 4.2. MAC Address Learning.................................... 8 4.2.1. MAC Address Reachability Announcement ..............8 5. Security Considerations...................................... 9 6. IANA Considerations ......................................... 9 7. Acknowledgements ............................................ 9 8. References .................................................. 9 8.1. Normative References.................................... 9 8.2. Informative References................................. 10 Authors' Addresses ............................................ 10 Xu & Shah Expires April 13, 2012 [Page 2] Internet-Draft VPLS Using IS-IS October 2011 1. Introduction To support virtual machine (VM) mobility and cluster services at scale in a cloud data center which accommodates multiple tenants over a shared physical infrastructure, a scalable L2VPN solution is essential for interconnecting those millions of servers/VMs while isolating tens of thousands of tenants within that virtualized data center environment. Such L2VPN solution SHOULD be able to support the shortest path forwarding and the Equal Cost Multi-Path (ECMP) forwarding capabilities so as to maximize the bandwidth capacity between servers. Besides, it SHOULD be able to provide enough VPN instances in order to securely isolate a large number of tenants from each other. VPLS seems as a good L2VPN solution for cloud data centers since it can almost meet all of the above requirements. However, the existing VPLS solutions including BGP VPLS [RFC4761] and LDP VPLS [RFC4762] are a bit heavy-weight for cloud data center operators due to the following reasons: first, the existing VPLS solutions require one or more separate protocols dedicated for VPLS auto-discovery and signaling to be deployed besides IGP which has been already deployed in data centers; second, full-meshed pseudo- wires(PWs)associated with the existing VPLS solutions introduce much burden and complexity for maintenance; third, head-end replication for multicast and broadcast that is used by the existing VPLS solutions is sub-optimal from the bandwidth utilization perspective. Hence, this document describes a IS-IS [IS-IS][RFC1195] based light- weight VPLS solution which retains the scalability features while overcoming the shortages of the existing VPLS solutions as mentioned above. In IS-IS VPLS, the IS-IS routing protocol which has been already deployed within the data center is extended to realize VPLS, in addition, there is no full-meshed PWs anymore between PE routers. To achieve better bandwidth utilization, PIM multicast trees could be used for delivering multicast, broadcast, and even unknown unicast traffic. Note that, in IS-IS VPLS, the VPLS label contained in the L2VPN data packets (e.g., MAC-in-MPLS-in-IP) is only used for identifying a particular VPLS instance, rather than identifying both a particular VPLS instance and a particular ingress PE router as the PW label does. Therefore, IP-based tunnel is required to be used as the PE- to-PE tunnel technology in IS-IS VPLS so that the egress PE router could determine the ingress PE routers of the received L2VPN data packets from the source address of the tunnel header when performing MAC address learning. Xu & Shah Expires April 13, 2012 [Page 3] Internet-Draft VPLS Using IS-IS October 2011 2. Terminology This memo makes use of the terms defined in [RFC4664], [VPLS-MCAST], [RFC4761] and [RFC4762]. 3. Control Plane There are two primary functions of the VPLS control plane: auto- discovery and signaling. In IS-IS VPLS, these two functions are accomplished simultaneously by using a single IS-IS TLV advertisement. One concern of using IS-IS to distribute the VPLS membership information is that the VPLS membership information would be exposed to P routers unnecessarily. However, in today's cloud data center networks which are becoming more and more flat, the number of P routers within a data center network would not be too large, furthermore, the extended IS-IS TLV for VPLS is partially transparent to P routers, that is to say, P routers don't need to process the VPLS membership information contained in that IS-IS TLV, but only need to synchronize the Link State PDUs (LSP) with their adjacent IS-IS neighbors. 3.1. Extended IS-IS TLV for VPLS 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 +-+-+-+-+-+-+-+-+ | Type=VPLS | +-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | PE's IPv4 or IPv6 Address | | (128 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resv (12 bits) | VPLS ID (20 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resv (12 bits) | VPLS Label (20 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resv (12 bits) | VPLS ID (20 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resv (12 bits) | VPLS Label (20 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Xu & Shah Expires April 13, 2012 [Page 4] Internet-Draft VPLS Using IS-IS October 2011 Type TLV Type code for VPLS: TBD. Length Total number of bytes contained in the value field. PE's IPv4 or IPv6 Address This 128-bit field is filled with one of the PE router's IP addresses which are reachable across the backbone. The address filled in this field SHOULD be used as tunnel destination addresses by remote PE routers when sending a customer packet to such PE router. If the IP address is IPv4, the last four octets of this field are filled with the IPv4 address while the remaining part is set to zero. In other words, it is filled with an IPv4-mapped IPv6 address. VPLS ID This field is filled with a 20-bit globally unique VPLS ID for a particular attached VPLS instance. In case that a larger VPLS ID space is required, the leftmost 12-bit reserved field could be used together with the VPLS ID field as an extended VPLS ID filed. That is to say, the whole 32 bits are filled with a 32-bit long VPLS ID value. VPLS Label This field is filled with a 20-bit MPLS label corresponding to the VPLS instance which is identified by the VPLS ID. 3.2. Auto-Discovery In IS-IS VPLS, each PE router could automatically discover which other PE routers are part of a given VPLS instance that is identified by the globally unique VPLS ID. This allows each PE router's configuration to consist only of the identity of the VPLS instance established on this PE router, not the identity of every other PE router in that VPLS instance. 3.3. Signaling In IS-IS VPLS, it is REQUIRED that a PE router SHOULD assign the same MPLS label for a given VPLS instance to any other PE router. In other words, this VPLS label is used for identifying a particular Xu & Shah Expires April 13, 2012 [Page 5] Internet-Draft VPLS Using IS-IS October 2011 VPLS instance, rather than identifying both a particular VPLS instance and the corresponding ingress PE router as the PW label does. The VPLS label in IS-IS VPLS just needs to be locally unique, rather than globally unique for most cases except the aggregate P-Multicast tree based VPLS multicast case where a single P-Multicast tree is shared by more than one VPLS instance and the ability to use upstream-assigned labels [RFC5331] is not available. For example, in unicast and ingress-replication multicast cases [VPLS-MCAST], it is no necessary for the VPLS label to be globally unique. Besides, in the non-aggregative P-Multicast tree [VPLS-MCAST] based VPLS multicast case where a single P-Multicast tree is exclusively used by no more than one VPLS instance, the MAC-in-IP encapsulation is used since the multicast address itself in the IP based tunnel header is enough for identifying a particular VPLS instance. Therefore, it doesn't require the VPLS label to be globally unique either. In the aggregate P-Multicast tree [VPLS-MCAST] based VPLS multicast mode, the globally unique labels could be used if the ability to use upstream-assigned labels is not available. In this case, the VPLS label for a given VPLS instance directly equals the VPLS ID of that VPLS instance. 4. Data Plane 4.1. Data Encapsulation and Forwarding 4.1.1. Unicast MAC-in-MPLS-in-IP encapsulation [RFC4448][RFC4023] SHOULD be used for unicast. The IP here means any of IP based encapsulations, such as MPLS-in-IP and MPLS-in-GRE (Generic Routing Encapsulation). There is almost no difference from BGP VPLS and LDP VPLS from the aspect of data forwarding. For unknown unicast, the encapsulation and forwarding is the same as that for multicast/broadcast described in the following section. 4.1.2. Multicast/Broadcast There are two major multicast modes for IS-IS VPLS: ingress replication mode and P-Multicast tree mode. The encapsulation corresponding to each mode is described in the following sub-sections. Xu & Shah Expires April 13, 2012 [Page 6] Internet-Draft VPLS Using IS-IS October 2011 4.1.2.1. Ingress Replication Mode In the ingress replication mode, an ingress PE router forward the CE multicast/broadcast frames received via its attachment circuits towards each remote PE router of the same VPLS instance in the separate IP based tunnels destined for each remote PE router. Hence, the encapsulation in this mode has no difference from that for unicast. 4.1.2.2. Non-aggregative P-Multicast Tree Mode In the non-aggregative P-Multicast tree mode where a single P- Multicast distribution tree in the backbone is exclusively used by one VPLS instance, the MAC-in-IP encapsulation is used directly since the destination IP address (i.e., multicast address) contained in the IP-based tunnel header is enough for the egress PE routers to determine which VPLS instance the encapsulated customer packets received from a remote PE router belongs to. 4.1.2.3. Aggregative P-Multicast Tree Mode For aggregative P-Multicast tree mode in which a single P-Multicast tree is shared by more than one VPLS instance, MAC-in-MPLS-IP encapsulation SHOULD be used. The upstream-assigned MPLS label contained in the inner MPLS header would be used by the egress PE routers to identify the particular VPLS instance that the received customer packets belong to. The locally unique VPLS labels which are advertised in the IS-IS TLVs for VPLS could actually be used as upstream labels in this mode as well besides being used for known unicast forwarding. For example, assume PE-1 advertises a locally unique label L for VPLS instance X with that IS-IS TLV, PE-1 could send a multicast packet for VPLS X containing label L as an upstream-assigned label. The egress PE routers could distinguish whether the MPLS label contained in the encapsulated VPLS packet is an upstream-assigned label or a downstream-assigned label according to the "MPLS label type" information contained in the encapsulated VPLS packets, taken the MPLS-in-GRE encapsulation as an example, the protocol type field in the GRE header would be set to 0x8847 for MPLS unicast and 0x8848 for multicast. Alternatively, to avoid using the complex upstream MPLS label assignment mechanism [RFC5331], operators could also use the globally unique VPLS labels provided this usage is doable in such particular network environment (i.e., a relatively close data center network environment). Thus, the VPN ID value for a given VPLS instance would be equal to its corresponding VPLS Label value. Xu & Shah Expires April 13, 2012 [Page 7] Internet-Draft VPLS Using IS-IS October 2011 More details about the aggregative P-Multicast tree mode are for further study. 4.2. MAC Address Learning MAC addresses of local CE hosts can be learnt by a PE router as a normal bridge does. As for learning MAC addresses of remote CE hosts, data-driven MAC learning is still available in IS-IS VPLS. For example, upon receiving an encapsulated customer packet from a remote PE router, the MPLS label contained in the MPLS header of the data packet (or the destination multicast IP address contained in the IP-based tunnel header in the case of using non-aggregative P-Multicast trees for delivering unknown unicast packets)is used to determine the particular VPLS instance that the data packet belongs to, while the source IP address contained in the IP-based tunnel header is used to tell from which ingress PE router the data packet is sent. Besides, MAC addresses of remote CE hosts can also be learnt on the control plane by using IS-IS for MAC address reachability announcement. The following sub-section describes the basic idea of such alternative. 4.2.1. MAC Address Reachability Announcement To alleviate the impact on the control plane of P routers, CE MAC address reachability information SHOULD be fully transparent to P routers as if the packets containing that information were encapsulated customer packets. Furthermore, the CE MAC address reachability information of a given VPLS instance SHOULD only be distributed to those PE routers of that VPLS instance. Upon learning the MAC addresses of their local CE hosts, PE routers would immediately advertise these MAC addresses to other PE routers of the same VPN instance by using the MAC-Reachability TLV defined in [RFC6165]. One or more MAC-Reachability TLVs are carried in a LSP which in turn is encapsulated with an Ethernet header. The source MAC address is the originating PE router's MAC address whereas the destination MAC address is a to-be-defined multicast MAC address specifically identifying IS-IS VPLS PE routers. Such LSPs are forwarded towards remote PE routers as customer packets by ingress PE routers. Egress PE routers receiving the above packets SHOULD intercept them and accordingly process them. It is obvious that these ISPs are fully transparent to P routers because they are forwarded by P routers as if they were encapsulated customer packets. The next-hop information associated with these MAC routes could be Xu & Shah Expires April 13, 2012 [Page 8] Internet-Draft VPLS Using IS-IS October 2011 derived from the "IP Interface Address" field contained in the corresponding LSPs. More details about how to learn remote CE MAC addresses on the control plane are for further study. 5. Security Considerations This document doesn't introduce additional security risk to IS-IS and VPLS, nor does it provide any additional security feature for IS-IS and VPLS. 6. IANA Considerations The IS-IS TLV code for VPLS is required to be defined by IANA. 7. Acknowledgements Thanks to Tony Li, Peter Ashwood-Smith, Phil Bedard, Kris Price, Shahram Davari, Adrian Farrel, Giles Heron and other people for their valuable comments on this proposal. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [IS-IS] ISO/IEC 10589, "Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", 2005. [RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments", 1990. [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", 2008. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006. Xu & Shah Expires April 13, 2012 [Page 9] Internet-Draft VPLS Using IS-IS October 2011 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005. [RFC6165] A. Banerjee., D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC6165, February 2011. [VPLS-MCAST] R. Aggarwal., Y. Kamite., L. Fang, "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-08 (work in progress), October 2010. [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008. 8.2. Informative References [RFC4664] Andersson, L. and Rosen, E. (Editors),"Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, Sept 2006. [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007. [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007. Authors' Addresses Xiaohu Xu Huawei Technologies, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085, P.R. China Phone: +86 10 82882573 Email: xuxh@huawei.com Himanshu Shah Ciena Corp Email: hshah@ciena.com Xu & Shah Expires April 13, 2012 [Page 10]