Network working group X. Xu Internet Draft Huawei Technologies Category: Standard Track H. Shah Ciena Corp Expires: March 2012 September 6, 2011 Virtual Private LAN Service (VPLS) Using IS-IS draft-xu-l2vpn-vpls-isis-01 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 March 6, 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 March 6, 2012 [Page 1] Internet-Draft VPLS Using IS-IS September 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 ................................................. 3 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...................................... 6 4.1.1. Unicast ........................................... 6 4.1.2. Multicast/Broadcast................................ 6 4.2. Data Forwarding......................................... 7 4.3. MAC Address Learning.................................... 7 5. Security Considerations...................................... 8 6. IANA Considerations ......................................... 8 7. Acknowledgements ............................................ 8 8. References .................................................. 8 8.1. Normative References.................................... 8 8.2. Informative References.................................. 9 Authors' Addresses ............................................. 9 Xu & Shah Expires March 6, 2012 [Page 2] Internet-Draft VPLS Using IS-IS September 2011 1. Introduction To support virtual machine (VM) mobility and cluster services in a cloud data center, a scalable L2VPN solution is essential for interconnecting those millions of servers within that data center. 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 isolate a large number of tenants. 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 for VPLS auto-discovery and signaling to be deployed besides IGP which is already deployed; second, full-meshed pseudo- wires(PW)introduces more burden and complex on maintenance; third, head-end replication for multicast and broadcast 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 of VPLS while overcoming the shortages of VPLS mentioned above. In IS-IS VPLS, the already deployed IS-IS protocol as IGP in a data center network is extended to realize VPLS auto-discovery and signaling functions with a new extended IS-IS TLV, 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 and broadcast traffic, 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. 2. Terminology This memo makes use of the terms defined in [RFC4664], [VPLS-MCAST], [RFC4761] and [RFC4762]. Xu & Shah Expires March 6, 2012 [Page 3] Internet-Draft VPLS Using IS-IS September 2011 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TLV Type code for VPLS: TBD. Length Xu & Shah Expires March 6, 2012 [Page 4] Internet-Draft VPLS Using IS-IS September 2011 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 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 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 Xu & Shah Expires March 6, 2012 [Page 5] Internet-Draft VPLS Using IS-IS September 2011 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. If the globally unique label assignment can not be met in some cases, such multicast mode SHOULD be prohibited. 4. Data Plane 4.1. Data Encapsulation 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). 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. 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 Xu & Shah Expires March 6, 2012 [Page 6] Internet-Draft VPLS Using IS-IS September 2011 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. 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. 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. 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. More details about the P-Multicast tree mode, especially the aggregative P-Multicast tree mode would be discussed in the future. 4.2. Data Forwarding In IS-IS VPLS, there is almost no difference from BGP VPLS and LDP VPLS from the aspect of data forwarding. 4.3. 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 Xu & Shah Expires March 6, 2012 [Page 7] Internet-Draft VPLS Using IS-IS September 2011 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. Alternatively, MAC addresses of remote CE hosts can also be learnt on the control plane by using IS-IS for MAC address reachability announcement. Details about how to learn remote CE MAC addresses on the control plane would be specified in the later version of this document. 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. Xu & Shah Expires March 6, 2012 [Page 8] Internet-Draft VPLS Using IS-IS September 2011 [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006. [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005. 8.2. Informative References [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. [RFC4664] Andersson, L. and Rosen, E. (Editors),"Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, Sept 2006. [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. 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 March 6, 2012 [Page 9]