Network Working Group L. Yong Internet Draft D. Eastlake Intended status: Informational S. Aldrin Huawei J. Hudson Brocade Expires: April 2012 October 23, 2011 Transparent Interconnection of Lots of Links (TRILL) over an MPLS PSN (Packet Switched Network) draft-yong-trill-trill-o-mpls-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Distribution of this document is unlimited. Comments should be sent to the DNSEXT working group mailing list: . 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 Notice Copyright (c) 2011 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 Yong & Eastlake Expires April 23, 2012 [Page 1] Internet-Draft TRILL over MPLS October 2011 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 BSD License. Abstract This informational document describes ways to interconnect TRILL RBridges over WAN connections by using MPLS Pseudo Wire (PW) or Virtual Private LAN Service (VPLS) with existing TRILL and MPLS standards. It also describes the combination of RBridge and MPLS to provide a hierarchical scalable L2VPN. Table of Contents 1. Introduction...................................................2 2. Use Cases......................................................3 2.1. Point-To-Point Interconnection............................3 2.2. Multi-Access Link Interconnection.........................6 2.3. Hierarchical L2VPN with RBridges and MPLS.................8 3. RBridge Behavior for MPLS Pseudo Wire.........................10 4. Security Considerations.......................................11 5. IANA Considerations...........................................11 6. Acknowledgements..............................................11 7. References....................................................11 7.1. Normative References.....................................11 7.2. Informative References...................................13 1. Introduction The IETF TRILL (Transparent Interconnection of Lots of Links) standard [RFC6325] [RFC6326] provides optimal pair-wise data frame forwarding without configuration in multi-hop networks with arbitrary topology, and support for multipathing of both unicast and multicast traffic. TRILL enables a new method to construct a campus or data center network. Devices that implement TRILL are called RBridges. This document describes the use cases of TRILL over an MPLS PW or VPLS, and introduces a new hierarchical L2VPN architecture that uses RBridges and IP/MPLS and documents the related configurations and references for the proper interworking. Yong & Eastlake Expires April 23, 2012 [Page 2] Internet-Draft TRILL over MPLS October 2011 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 [RFC2119]. Acronyms used in this document include the following: AC - Attachment Circuit CE - Customer Edge IS-IS - Intermediate System to Intermediate System MPLS - Multi-Protocol Label Switching PE - Provider Edge PPP - Point to Point Protocol PW - Pseudo Wire RBridge - Routing Bridge TRILL - Transparent Interconnection of Lots of Links VPLS - Virtual Private LAN Service VSI - Virtual Service Instance 2. Use Cases RBridge campuses at different locations may interconnect by networks that are implemented with different technologies to form one RBridge campus. This section describes use cases assuming that IP/MPLS technology is available. From the MPLS network view, an RBridge device acts as a Customer Edge (CE) device and connects to PE via an attachment circuit (AC). RBridges [RFC6325] support both point-to- point links and multi-access links. Section 2.1 describes point-to- point link, i.e. TRILL over either Ethernet or PPP point-to-point link that is over an MPLS network. Section 2.2 describes TRILL over a bridged LAN that is implemented by MPLS/VPLS. Section 2.3 introduces a new hierarchical L2VPN solution that uses the RBridges and MPLS tiered architecture. 2.1. Point-To-Point Interconnection Two RBridges are interconnected by either Ethernet or PPP link that is over a MPLS network. A Pseudo wire (PW) is configured between a Yong & Eastlake Expires April 23, 2012 [Page 3] Internet-Draft TRILL over MPLS October 2011 pair of PEs to provide part of the point-to-point link between two RBridges. Figure 1 illustrates this architecture. Each RBridge device connects to a PE via AC and acts as a CE device. MPLS PSN is bordered at the PEs. The TRILL link across the IP/MPLS PSN makes the left site and right site into one RBridge campus. MPLS already supports many pseudo wire transport encapsulations. [RFC4446] Two types of TRILL links between RBridges have been standardized: Ethernet [RFC6325] and PPP [RFC6361]. PW encapsulations for these two interfaces are specified in [RFC4448] and [RFC4618], respectively. When an RBridge port connecting to AC is configured with a point-to-point Ethernet link type, two PEs can be configured as a PW with Ethernet encapsulation [RFC4448]. The PW between two PEs can be auto-configured [RFC4447] or manually configured; the two RBridges then appear directly interconnected with an Ethernet link. When an RBridge port connecting to AC is configured with the PPP link type, two PEs MUST be configured as a PW with PPP encapsulation.[RFC4618] After the PW is established between two PEs, the two RBridges then appear directly interconnected with a PPP link. The TRILL link is automatically configured over an Ethernet link or PPP link. The PW provides transparent transport between ACs. Note: 1) For Ethernet link configuration, PE SHOULD use the Raw mode and non-service-delimiting, which provides a transparent transport. 2) The PPP link configuration will be more efficient than the Ethernet point-to-point configuration; it saves about 16 bytes per frame by replacing the TRILL Outer.MacDA, Outer.MacSA, Outer.VLAN, and outer Ethertype with a PPP code point. [RFC6361] <----------TRILL Link----------> *-------* <----------PW----------> *-------* | | AC +----+ +---+ +----+ AC | | | RB +----| PE |----| P |---| PE |----+ RB | |Site A | +----+ +---+ +----+ |Site B | | | { PSN } | | *-------* *-------* { One RBridge Campus } Figure 1 P2P TRILL Link over IP/MPLS PSN Use Case I An RBridge is a router and could support PE capabilities. As the networks converg, it is possible that one operator runs both an RBridge campus as well as the core MPLS network. Figure 2 Yong & Eastlake Expires April 23, 2012 [Page 4] Internet-Draft TRILL over MPLS October 2011 illustrates this use case, in which RBridges are also MPLS PE enabled devices. The interworking between the RBridge network and the MPLS PSN is within the device. This has a similar architecture to MPLS/VPLS [RFC4762]. In this case, a virtual Ethernet interface is configured at the RBridge component; an Ethernet encapsulated PW is configured between two interfaces, which brings up an TRILL link between two RBridge components. The outer MAC address can be a local Ethernet address. In this case, the Campus RBridges run in the client layer and MPLS runs in the Server Layer; RB/PE devices support both client and server layer control plane and data plane functions. *---------* *---------* | |<---- TRILL Link------->| | |RB Site A| (Client Layer) |RB Site B| | +-------+ +---+ +-------+ | | | RB/PE |-----| P |------| PE/RB | | | +-------+ +---+ +-------+ | | |<---------PW ---------->| | | | (Server Layer) | | *---------* *---------* { PSN } { One RBridge Campus } Figure 2 P2P TRILL-Link over IP/MPLS PSN Use Case II In both case I and II, the PE treats an RBridge as a generic CE and has no awareness of TRILL capability on the CE. Use case I enables the business models when the RBridge campus and Core MPLS may be operated by different operators or the same operator. In the case of different operators, the core MPLS operator can sell a VPWS service to RBridge operator. Use case II provides the model when the RBridge campus and the core network are operated by the same operator but use different technologies in each network. Technically speaking, it is possible to create a specially designated TRILL encapsulated pseudo wire for point-to-point TRILL over MPLS. However, the authors think that this is not worth the effort because of available technologies as mentioned above, particularly the highly-efficient PPP link technology. A PW may cross multiple MPLS domains.[RFC5659] In this case, RBridges connect to T-PEs and it works in the same way as a single domain. The PSN can provide transport resiliency for a PW. The dual homing (two ACs) can be used for AC protection. In this case, two Yong & Eastlake Expires April 23, 2012 [Page 5] Internet-Draft TRILL over MPLS October 2011 TRILL links are established; RBridge device perform load balance over two links. 2.2. Multi-Access Link Interconnection Multiple RBridges may interconnect via an 802.1Q Bridged LAN that acts as a hub. The bridged LAN simply forwards on the outer Ethernet header of the TRILL frames. This configuration creates what appears to each connected RBridge as a multi-access link. In other words, each RBridge connecting to a bridged LAN has connectivity to every other RBridges connecting to the same LAN. MPLS/VPLS can provide the same capability when multiple parts of an RBridge campus are interconnected over an IP/MPLS PSN and make each RBridge attaching to the VPLS to appear as having a multi-access TRILL link. Figure 3 shows the use of MPLS/VPLS for RBridge interconnection. One RBridge campus is split between three different sites. One VPLS instance is configured on three PEs and the PWs are configured for the VPLS instance. Each RBridge Site connects to the VSI on a PE via an AC (Ethernet Type). The VSI on a PE forwards TRILL frames based on the outer Ethernet header of the frames. [RFC6325] Either BGP [RFC4761] or LDP [RFC4762] protocol can be used to automatically construct the VPLS instance on the PEs. A PE may connect to several different RBridge campuses that belong to different customers. Separated VPLS instances are configured for individual customers and customer traffic is completely isolated by VPLS instance. The PE treats an RBridge as a generic CE and has no awareness of TRILL. Yong & Eastlake Expires April 23, 2012 [Page 6] Internet-Draft TRILL over MPLS October 2011 *-------* ........................... *-------* | | . MPLS/VPLS . | | | RB |AC +----+ PW +----+AC| RB | | Site 1+---|VSI ********************** VSI|--+ Site 2| | | | PE ***** ***** PE | | | | | +----+ **** **** +----+ | | | | . +*--*+ . *-------* *-------* ..........|VSI |........... | PE | +----+ |AC | *---------* | | |RB Site 3| | | *---------* Figure 3 Multi-Access TRILL Link over MPLS/VPLS The outer Ethernet MAC of TRILL frames may be either a next-hop RBridge MAC address (for unicast frames) or one of TRILL defined multicast addresses (ALL-IS-IS-RBridges and All-RBridges).[RFC6325] The VSI at each PE learns the source MAC addresses on each VSI interface and forward the frame based on the destination MAC. For the multicast frames, the VSI replicates the frames to all PWs it associates. If a VPLS is configured with some optimization capability [VPLS-BCAST], the multicast frames can be delivered over a point-to-multipoint PW while unicast frames are carried over a point-to-point PW. The scenario in Figure 3 can also be extended to multiple RBridges interconnections when a device serves both RBridge and PE functions. This use case is discussed in the following section. Note: If the CEs associated with one VPLS instances happen to include some RBridges and some end stations or IEEE 802.1Q bridges to end stations, TRILL will, by default, be able to handle this by providing both through service and end station service. However, the end station addresses will be visible to the VPLS instance. If, in such a case, all the RBridge ports connected to the VPLS are configured as trunk ports (see Section 4.9.2 of [RFC6325]), then they will not provide any end station service. Yong & Eastlake Expires April 23, 2012 [Page 7] Internet-Draft TRILL over MPLS October 2011 2.3. Hierarchical L2VPN with RBridges and MPLS H-VPLS in [RFC4762] describes a two-tier hierarchical solution for the purpose of pseudo wire (PW) scalability improvement. This improvement is achieved by reducing the number of PE devices connected in a full-mesh topology through connecting CE devices via the lower-tier access network, which in turn is connected to the top-tier core network. However, H-VPLS solutions in [RFC4762] require learning and forwarding based on customer MAC addresses, which poses scalability issues as the number of VPLS instances and customer MAC addresses increase. [PBB-VPLS] describes how to use PBB (Provider Backbone Bridges) at the lower-tier access network to solve the scalability issue, in which the transit network nodes only learn and forward on PBB port MAC addresses instead of customer MAC addresses. RBridges over IP/MPLS provide an alternative solution for a scalable L2VPN over WAN networks. Figure 4 depicts the hierarchical L2VPN architecture with RBridge/MPLS technologies. An IP/MPLS network serves as the top-tier core network function while an RBridge campus serves as the low-tier access network function. A RB/PE enabled device is placed at the boundary between the two-tier networks. A PW is configured between each pair of PE components in the top-tier IP/MPLS network, which constructs a full mesh TRILL links among the RB/PE devices. The RBridge component on a RB/PE device and other RBridges at the same site serves as the low-tier access network. Customer CEs connect to RBridges at each site directly. This architecture provides E-LAN or E-VLAN connectivity among customer CEs connecting to the RBridge campus sites. The transit RBridge node only forwards and learns other RBridge addresses and the number of PWs in the top-tier core network is not relate to the number of devices connecting to Customer CEs. This makes the solution scale very well. In addition, TRILL technology already supports multi- TRILL links from one RBridge to one or multiple RBridges and prevents loops, which provides the flexibility to construct the networks based on their network condition. Figure 4 shows that one RBridge in site 1 connects two RB/PE devices and one RB/PE device connects two RBridges at Site 2 via Ethernet links. Yong & Eastlake Expires April 23, 2012 [Page 8] Internet-Draft TRILL over MPLS October 2011 +---------+ ........................... +--------+ | | . IP/MPLS Core . | | | | . . | +-- CE--+ |Eth+----+ PW +----+ | | | RBridge +---| RB/|********************| RB/|--+RBridge |CEs . --+ +-+ | PE |**** ****| PE |\ | +-- . | Site 1 | | +----+ **** **** +----+ -+ Site 2 | . --+ | | . +*--*+ . | | | | | ..........| RB/|........... +--------+ CE--+ | +--------------| PE | | | Eth. Itfc +----+ +---------+ |Eth. Itfc | +---------+ | RBrdige | | | | Site 3 | +-+----+--+ |... | CEs Figure 4 Hierarchical L2VPN with RBridge and MPLS The following advantages of using RBridge/MPLS based L2VPN: 1) Scalability improvement; 2) Auto-configuration; 3) Good efficiency and loop prevention; and 4) Multipath support. The solution also has the following advantages: 1) Since RBridge terminates customer spanning tree protocol (STP), individual STPs in attached customer bridged LANs will be separated and will converge faster. 2) low over head per frame in number of added bytes and scalable routing computations; 3) MPLS just provides P2P PWs, MAC forwarding and learning does not exist within the MPLS network, thus multi-homing issue does not exist. Note: it is good to mention another scenario when the device has both RB/PE capabilities, i.e. configure a VPLS instance among PE components in the top-tier network to provide a multi-access link to RBridge component on the RB/PE devices. Although this solution can also provide scalability, it requires both the RBridge component and VSI/PE component on a device to perform the same MAC forwarding and learning functions, which is redundant. The number of PWs configured in this case is the same as of the number of PWs in Figure 4. Thus, authors do not recommend this configuration. For the same reason, the use case in Section 2.2 is not viewed as the recommended L2VPN solution for the WAN networks. Instead, it is useful when a Core Yong & Eastlake Expires April 23, 2012 [Page 9] Internet-Draft TRILL over MPLS October 2011 Service Provider provides a VPLS service to the customer who needs to interconnect the RBridge campus sites over IP/MPLS PSN. It is possible to construct a Tiered L2VPN in the combination of Figure 4 and 3, i.e. some locations use RB/PE enabled device and some location use separated RBridge and PE devices in a Hierarchical L2VPN. When using separated RBridge and PE devices at some locations, the MPLS network has to run a VPLS instance, which makes RB/PE devices perform MAC forwarding and learning function two times. In addition, it becomes operator responsibility to ensure that the top tiered MPLS core is fully surrounded by an RBridge campus. Missing configuration may increase the scalability problem in the core network. Auto configuration for the Hierarchical L2VPN will be addressed in another draft. 3. RBridge Behavior for MPLS Pseudo Wire This section describes RBridge behaviors for TRILL Ethernet or TRILL PPP links over MPLS pseudo wire (PW) as described in Sections 2.1 . 1. For two RBridge ports connecting via a PPP PW, the ports MUST be configured as IS-IS point-to-point. Thus TRILL will use IS-IS P2P Hellos that, per "Point-to-Point IS to IS Hello PDU" (section 9.7 of [IS-IS]), do not use Neighbor TLVs in the same manner as on a multi-access link. However, per section 4.2.4.1 of [RFC6325], three-way IS-IS handshake using extended circuit IDs is required. 2. For two RBridge ports connecting via an Ethernet PW, it is RECOMMENED that the ports be configured as IS-IS point-to-point for the same reason able. Note: an RBridge port by default supports multi-access links. 3. Any MPLS forwarder within an MPLS PSN does not change the TRILL Header Hop Count. RBridges is never aware of the packet forwarders in MPLS PSN. 4. If it is desired for MPLS PSN to perform QoS in the same way as in the RBridge campus, RBridges MUST be configured to send an Outer.VLAN tag on the RBridge port. The PE can then copy the priority value from the Outer.VLAN tag to the COS filed of the PW label prior to the forwarding. [RFC5462] Yong & Eastlake Expires April 23, 2012 [Page 10] Internet-Draft TRILL over MPLS October 2011 5. TRILL MTU-probe and TRILL MTU-ack messages (section 4.3.2 of [RFC6325]) are not needed on a pseudo wire link. Implementations MUST NOT send MTU-probe and SHOULD NOT reply to these messages. The MTU pseudo wire interface parameter SHOULD be used instead. PE Must configure the MTU size as the originating RBridges Size specified in Section 4.3.1 of [RFC6325]. 4. Security Considerations The IS-IS authentication mechanism [RFC5304] [RFC5310], at the TRILL IS-IS layer, can be used to prevent fabrication of link-state control messages over TRILL links including those discussed in this document. For general TRILL protocol security considerations, see [RFC6325]. The use case does not introduce any security considerations for MPLS network. 5. IANA Considerations No IANA action is required by this document. 6. Acknowledgements The authors sincerely acknowledge the contributions of Ben Mack- Crane and Sue Hares. 7. References 7.1. Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," BCP 14 and RFC 2119, March 1997 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006. [RFC4447] Martini, L., etc, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC4447, April 2006. [RFC4448] Martini, L., "Encapsulation Methods for Transport of Ethernet over MPLS Networks", BCP 116, RFC 4446, April 2006. Yong & Eastlake Expires April 23, 2012 [Page 11] Internet-Draft TRILL over MPLS October 2011 [RFC4618] Martini, L., "Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks", BCP 116, RFC 4618, September 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 Kompella, V, "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC4762, January 2007 [RFC5304] Li, T. and Atkinson, R, "IS-IS Cryptographic Authentication," RFC 5304, October 2008 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009 [RFC5462] Andersson, L. and Asati, R., "Multiprotocol Label Switching (MPLS)Label Stack entry: "Exp" Field Rename to "Traffic Class" Field", RFC5462, February 2009 [RFC5659] Bocci, M and Bryant, S, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009. [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC6325, July 2011. [RFC6326] Eastlake 3rd, D., Banerjee, A., Dutt, D., Perlman, R., and Ghanwani, A. "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC6326, July 2011. [RFC6361] Carlson, J., and D. Eastlake, "PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol", RFC6361, August 2011. Yong & Eastlake Expires April 23, 2012 [Page 12] Internet-Draft TRILL over MPLS October 2011 7.2. Informative References [IS-IS] International Organization for Standardization, "Intermediate system to Intermediate system intra-domain routing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, Nov 2002 [VPLS-BCAST] Delord, S, and Key, R., "Extension to LDP-VPLS for Ethernet Broadcast and Multicast", draft-ietf-l2vpn-ldp- vpls-broadcast-exten-02, work in progress, 2011. [PBB-VPLS] Sajarssi, A, etc, "VPLS Interoperability with Provider Backbone Bridges", draft-ietf-l2vpn-pbb-vpls-interop, work in progress, 2011 Yong & Eastlake Expires April 23, 2012 [Page 13] Internet-Draft TRILL over MPLS October 2011 Authors' Addresses Lucy Yong Huawei Technologies (USA) 5340 Legacy Drive Plano, TX 75025 Phone: +1-469-277-5837 Email: lucy.yong@huawei.com Donald E. Eastlake, 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA Phone: +1-508-333-2270 Email: d3e3e3@gmail.com Sam Aldrin Huawei Technologies 2330 Centeral Expressway Santa Clara, CA 95050 Phone: +1-408-330-4517 Email: sam.aldrin@huawei.com Jon Hudson Brocade 130 Holger Way San Jose, CA 95134 Phone: +1-408-333-4062 jon.hudson@brocade.com Yong & Eastlake Expires April 23, 2012 [Page 14]