L2VPN Working Group Florin Balus Internet Draft Pranjal Dutta Intended Status: Proposed Standard Alcatel-Lucent Expires: January 2010 July 6, 2009 Extensions to LDP Signaling for PBB-VPLS draft-balus-l2vpn-pbb-ldp-ext-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. 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 September 6, 2009. 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Balus, et al. Expires January 6, 2010 [Page 1] Internet-Draft Extensions to LDP Signaling for PBB-VPLS July 2009 Abstract Extensions to VPLS PE model to accommodate PBB components where discussed in [PBB-VPLS Model]. This draft discusses optional extensions to the LDP Signaling procedures in [RFC4762] required to further enhance the PBB-VPLS solution. Table of Contents 1. Introduction...................................................2 2. General terminology............................................3 2.1. Conventions used in this document.........................4 3. PBB Blackholing issue..........................................4 4. PBB-VPLS Extensions to LDP.....................................5 5. Security Considerations........................................8 6. IANA Considerations............................................8 7. References.....................................................8 7.1. Normative References......................................8 7.2. Informative References....................................8 8. Acknowledgments................................................8 1. Introduction [PBB-VPLS Model] describes how PBB can be integrated with VPLS to allow for useful PBB capabilities while continuing to avoid the use of MSTP in the backbone. The combined solution referred as PBB-VPLS results in better scalability in terms of number of service instances, PWs and C-MACs that need to be handled in the VPLS PEs. This document describes optional extensions to LDP Signaling procedures described in [RFC4762] required to add desirable capabilities to PBB-VPLS solution. Section 2 gives a quick terminology reference. Section 3 covers the problem space. Section 4 describes the solution and required TLV extensions. Balus, et al. Expires January 6, 2010 [Page 2] Internet-Draft Extensions to LDP Signaling for PBB-VPLS July 2009 2. General terminology Some general terminology is defined here; most of the terminology used is from [IEEE802.1ah], [RFC4762] and [RFC4026]. Terminology specific to this memo is introduced as needed in later sections. 802.1ah: IEEE specification for "MAC tunneling" encapsulation and bridging of frames across a provider backbone bridged network. PBB: Provider Backbone Bridge BEB: A backbone edge bridge positioned at the edge of a provider backbone bridged network. It can contain an I-component, B-component or both I and B components. BCB: A backbone core bridge positioned at the core of a provider backbone bridged network. It contains only B-component. B-TAG: field defined in the 802.1ah provider MAC encapsulation header that conveys the backbone VLAN identifier information. The format of the B-TAG field is the same as that of an 802.1ad S-TAG field. B-MAC: The backbone source or destination MAC address fields defined in the 802.1ah provider MAC encapsulation header. B-component, referred here also as B-VPLS: A bridging component contained in BEBs and BCBs that bridges in the provider backbone space based on B-MAC and B-TAG information I-TAG: A field defined in the 802.1ah provider MAC encapsulation header that conveys the service instance information (I-SID) associated with the frame. I-SID: The 24-bit service instance field carried inside the I-TAG. I- SID defines the service instance that the frame should be "mapped to". S-TAG: A field defined in the 802.1ad QinQ encapsulation header that conveys the service VLAN identifier information (S-VLAN). S-VLAN: The specific service VLAN identifier carried inside an S-TAG I-component: A bridging component contained in a backbone edge bridge that bridges in the customer space based on customer MAC addresses and S-TAG information Balus, et al. Expires January 6, 2010 [Page 3] Internet-Draft Extensions to LDP Signaling for PBB-VPLS July 2009 2.1. 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. 3. PBB Blackholing issue In PBB-VPLS solution a B-component VPLS (B-VPLS) may be used as infrastructure for one or more I-component instances. B-VPLS control plane (LDP Signaling) replaces I-component control plane throughout the MPLS core. This is raising an additional challenge related to blackhole avoidance in the I-component domain as described in this section. Figure 1 describes the case of a CE device (node A) dual- homed to two I-component instances located on two PBB-VPLS PEs (PE1 and PE2). IP/MPLS Core +--------------+ |PE2 | +----+ | |PBB | +-+ | _ |VPLS|---|P| | S/+----+ /+-+\ |PE3 / +----+ / \+----+ +---+/ |PBB |/ +-+ |PBB | +---+ CMAC X--|CE |---|VPLS|---|P|--|VPLS|---|CE |--CMAC Y +---+ A +----+ +-+ +----+ +---+ A |PE1 | B | | +--------------+ Figure 1: PBB Blackholing Issue - CE Dual-Homing use case The link between PE1 and CE A is active (marked with A) while the link between CE A and PE2 is in Standby/Blocked status. In the network diagram CMAC X is one of the MAC addresses located behind CE A in the customer domain, CMAC Y is behind CE B and the BVPLS instances on PE1 are associated with backbone MAC (BMAC) B1 and PE2 with BMAC B2. As the packets flow from CMAC X to CMAC Y through PE1 of BMAC B1, the remote PEs participating in the IVPLS (for example, PE3) will learn the CMAC X associated with BMAC B1 on PE1. Under failure of the link between CE A and PE1 and activation of link to PE2, the remote PEs Balus, et al. Expires January 6, 2010 [Page 4] Internet-Draft Extensions to LDP Signaling for PBB-VPLS July 2009 (for example, PE3) will black-hole the traffic destined for customer MAC X to BMAC B1 until the aging timer expires or a packet flows from X to Y through the PE B2. This may take a long time (default aging timer is 5 minutes) and may affect a large number of flows across multiple I-components. A possible solution to this issue is to use the existing LDP MAC Flush as specified in [RFC4762] to flush in the BVPLS domain the BMAC associated with the PE where the failure occurred. This will automatically flush the CMAC to BMAC association in the remote PEs. This solution though has the disadvantage of producing a lot of unnecessary MAC flush in the B-VPLS domain as there was no failure or topology change affecting the Backbone domain. A better solution is required to propagate the I-component events through the backbone infrastructure (B-VPLS) in order to flush only the customer MAC to BMAC entries in the remote PBB-VPLS PEs. As there are no IVPLS control plane exchanges across the PBB backbone, extensions to B-VPLS control plane are required to propagate the I- component MAC Flush events across the B-VPLS. 4. PBB-VPLS Extensions to LDP The use of Address Withdraw message with MAC List TLV is proposed in [RFC4762] as a way to expedite removal of MAC addresses as the result of a topology change (e.g. failure of a primary link of a VPLS PE and implicitly the activation of an alternate link in a dual-homing use case). These existing procedures apply to B-VPLS and I-component domains. When it comes to reflecting topology changes in access networks connected to I-component across the B-VPLS domain certain additions should be considered as described below. MAC Switching in PBB is based on the mapping of Customer MACs (CMACs) to Backbone MAC(s) (BMACs). A topology change in the access (I- domain) should just invoke the flushing of CMAC entries in PBB PEs' FIB(s) associated with the I-component(s) impacted by the failure. There is a need to indicate the PBB PE (BMAC source) that originated the MAC Flush message. These goals can be achieved by adding a PBB TLV in the LDP Address Withdraw message to indicate the particular domain(s) requiring MAC flush. At the other end, the receiving PBB PEs may use the Balus, et al. Expires January 6, 2010 [Page 5] Internet-Draft Extensions to LDP Signaling for PBB-VPLS July 2009 information from the PBB TLV to flush only the related FIB entry/entries in the I-component instance(s). A suggested PBB TLV structure is depicted 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| PBB TLV (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV Type | Sub-TLV Length | Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length Value | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The UF bits are set to forward unknown so that potential intermediate VPLS PEs that are unaware of PBB can just forward the TLV towards the PBB aware PEs. The PBB TLV type values are to be assigned by IANA. The Length field is used to define the length of the PBB TLV including the type and the length itself. Processing of the sub-TLVs should continue when unknown ones are encountered, and they MUST be silently ignored. The following sub-TLVs MUST be included in the PBB TLV: - PBB BMAC List sub-TLV: Type: 0x0001 Length: value length in octets. At least one BMAC address must be present in the list. Flags: 1 Byte Flag field is required. Only the last flag N is used for now to indicate whether a positive (N=0, Flush-all-but-mine) or negative (N=1 Flush-all-from-me) MAC Flush is required. The rest of the flags should be set to zero on transmission and ignored on reception. Value: one or a list of 48 bits BMAC address(es). These are the source BMAC addresses associated with the B-VPLS instance(s) that originated the MAC Withdraw message. It will be used to identify the CMAC(s) mapped to the BMACs listed in the sub-TLV. Balus, et al. Expires January 6, 2010 [Page 6] Internet-Draft Extensions to LDP Signaling for PBB-VPLS July 2009 - PBB ISID List sub-TLV: Type: 0x0002 Length: value length in octets. Zero indicates an empty ISID list. An empty ISID list means that the flush applies to all the ISIDs mapped to the B-VPLS indicated by the FEC TLV. Value: one or a list of 24 bits ISIDs that represent the I-VSI FIB(s) where the MAC Flush needs to take place. The following steps describe the details of the processing for the related LDP Address Withdraw message: . The LDP MAC Withdraw Message, including the PBB TLV is initiated by the PBB PE(s) experiencing a Topology Change event. . On reception of the LDP message, the B-VPLS instances related to the FEC TLV from the LDP Address Withdraw message must interpret the presence of the PBB TLV as an indication of a PBB Flush message. As a result, the BCBs should not flush their BMAC FIBs. If required the B-VPLS control plane may propagate the MAC Flush indication following the split-horizon grouping and the established BVPLS topology. . The receiving BEBs use the sub-TLVs from the PBB TLV as follows: o The PBB ISID List is used to determine the particular ISID FIBs that need to be flushed. If the ISID List is empty all the ISID FIBs associated with the receiving B-VPLS are flushed. o The PBB BMAC List is used to identify from the ISID FIBs selected in the previous step just the entries that map CMACs to the BMACs that are not listed in the sub-TLV. . Next, depending on the N flag value the following actions apply: o N=0, all the CMACs in the selected ISID FIBs should be flushed with the exception of the resulted CMAC list ("Flush all but the CMACs associated with the BMAC(s) in the BMAC List Sub-TLV from the FIBs associated with the ISID list"). o N=1, the resulted CMAC list should be flushed ("Flush all the CMACs associated with the BMAC(s) in the BMAC List Sub- TLV from the FIBs associated with the ISID list") Balus, et al. Expires January 6, 2010 [Page 7] Internet-Draft Extensions to LDP Signaling for PBB-VPLS July 2009 5. Security Considerations No new security issues are introduced beyond those that are described in [RFC4762]. 6. IANA Considerations IANA needs to assign PBB TLV type values. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4762] Lasserre, M. and Kompella, V. (Editors), "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007. 7.2. Informative References [IEEE802.1ah] IEEE 802.1ah "Virtual Bridged Local Area Networks, Amendment 6: Provider Backbone Bridges", Approved Standard June 12th, 2008 [RFC4026] Andersson, L. et Al., "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005. [PBB-VPLS Model] F. Balus, et Al. "Extensions to VPLS PE model for Provider Backbone Bridging", draft-ietf-l2vpn-pbb-vpls-pe- model-00.txt, May 2009 (work in progress) 8. Acknowledgments The authors would like to thank Wim Henderickx, Dimitri Papadimitriou, Dutta Pranjal, Jorge Rabadan and Maarten Vissers for their insightful comments and probing questions. Balus, et al. Expires January 6, 2010 [Page 8] Internet-Draft Extensions to LDP Signaling for PBB-VPLS July 2009 Authors' Addresses Florin Balus Alcatel-Lucent 701 E. Middlefield Road Mountain View, CA, USA 94043 Email: florin.balus@alcatel-lucent.com Dutta Pranjal Alcatel-Lucent 701 E. Middlefield Road Mountain View, CA, USA 94043 Email: florin.balus@alcatel-lucent.com Balus, et al. Expires January 6, 2010 [Page 9]