INTERNET DRAFT Pranjal Kumar Dutta Network Working Group Marc Lasserre Expires: September 5, 2007 Alcatel-Lucent March 3, 2007 LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS draft-pdutta-l2vpn-vpls-ldp-mac-opt-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 5, 2007. Abstract [RFC4762] defines a mechanism to remove or unlearn MAC addresses that have been dynamically learned in a VPLS Instance for faster convergence on topology change. The MAC addresses removed in this procedure also include the MAC addresses learned in a VSI that are not affected due to such topology change. This document defines an extension to LDP Address Withdraw Message with empty MAC List defined in [RFC4762], that enables a Provider Edge(PE) device receiving the message to remove only the MAC addresses that are affected and need to be relearned. 1. Conventions 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]. Dutta, et. al. Expires September 5, 2007 [Page 1] Internet Draft draft-pdutta-l2vpn-vpls-ldp-mac-opt-02.txt March 2007 2. Terminology This document uses terminology described in [RFC3036], [L2VPN-FRWK], [L2VPN-SIG], [RFC4447], [RFC4761], [RFC4364], [MSPW-ARCH] and [802.1w] . 3. Table of Contents 1. Conventions..................................................1 2. Terminology..................................................2 3. Table of Contents............................................2 4. Introduction.................................................2 4.1 Flushing of MACs learned from unaffected PW(s)...........3 5. Mechanism to avoid flushing of MACs from unaffected PW(s)....4 5.1 LDP Extension on PE-ID...................................5 5.1.1 Generic PE-ID Element..............................6 5.2 Processing of PE-ID......................................7 5.3 MAC Address Withdrawal Procedure with PE-ID..............8 5.4 Applicability of PE-ID...................................9 6. Security Considerations......................................10 7. IANA Considerations..........................................10 8. Acknowledgements.............................................10 9. References...................................................10 10. Authors' Addresses...........................................11 4. Introduction MAC Address Withdrawal is a mechanism defined in [RFC4762] to remove or unlearn MAC addresses within a VPLS instance for faster convergence on topology change in H-VPLS. One example where MAC Address Withdrawal is required is in dual homed H-VPLS described in [RFC4762] where a u-PE (termed as MTU-s) is dual homed to two n-PE devices via primary spoke Pseudowire(PW) and backup spoke PW respectively. Such redundancy is designed to protect against the failure of primary spoke PW or primary n-PE at the edge of the provider domain. Therefore, when MTU-s switches over to backup PW it is required to flush customer MAC addresses in the H-VPLS full mesh core to avoid black holing of customer frames in the VPLS instance. When backup PW is made active by MTU-s, it triggers LDP Address Withdraw Message with list of MAC addresses to be flushed and the message is forwarded over the LDP session associated with the backup PW. In order to minimize the impact on LDP convergence time when MAC List TLV contains a large number of MAC Addresses, it may be preferable to send a LDP Address Withdraw Message with an empty MAC List. The rule for processing the LDP Address Withdraw Message with empty MAC List is defined in [RFC4762] as follows: - Remove all the MAC addresses associated with the VPLS instance (specified by FEC TLV) except the MAC addresses learned over the PW associated with this signaling session over which the message was received. Dutta, et. al. Expires September 5, 2007 [Page 2] Internet Draft draft-pdutta-l2vpn-vpls-ldp-mac-opt-02.txt March 2007 This method of MAC flushing is modeled after Topology Change Notification (TCN) in Rapid Spanning Tree Protocol (RSTP) defined in [802.1w]. When a bridge switches from failed link to the backup link, then the bridge sends out a TCN message over the newly activated link. The upstream bridge upon receiving this message flushes all its MAC addresses except the ones received over this link and sends the TCN message out of its other ports in that spanning tree instance. The message is further relayed along the spanning tree by the other bridges. This document identifies one problem related to MAC Address Withdrawal triggered through LDP Address Withdraw Message with empty MAC List and a solution is proposed. Throughout this document the term “MAC Withdrawal Message” is used to specify LDP Address Withdraw Message with empty MAC List unless specified otherwise. Figure.1 describes a dual-homed H-VPLS scenerio for a VPLS instance where the problem is explained. n-PE1 n-PE3 +--------+ +--------+ | | | | | -- | | -- | Customer Site 1 | / \ |------------------| / \ |-> CE-1 /------| \ s/ | | \S / | \ primary spoke PW | -- | /------| -- | \ / +--------+ / +--------+ \u-PE(MTU-s)/ | \ / | +--------+/ | \ / | | | | \ / | | -- | | \ / | | / \ | | H-VPLS Full Mesh Core| | \S / | | / \ | | -- | | / \ | /+--------+\ | / \ | / backup spoke PW | / \ | / \ +--------+ \--------+--------+ CE-2 \ | | | | Customer Site 2 \------| -- | | -- | | / \ |------------------| / \ |-> | \s / | | \S / | | -- | | -- | +--------+ +--------+ n-PE2 n-PE4 Figure 1: Dual homed MTU-s in 2 tier hierarchy H-VPLS 4.1 Flushing of MACs learned from unaffected PW(s) In figure.1, only the primary spoke PW is active at MTU-s and n-PE1 is acting as the primary device for the dual homed MTU-s in the VPLS Dutta, et. al. Expires September 5, 2007 [Page 3] Internet Draft draft-pdutta-l2vpn-vpls-ldp-mac-opt-02.txt March 2007 instance. The MAC addresses located at customer sites (beyond CE1 and CE2) are learned by n-PE1 over the primary spoke PW. n-PE2, n-PE3 and n-PE4 learn those MAC addresses on their respective core PWs terminating at n-PE1. When MTU-s switches to the backup spoke PW, n-PE2 becomes the primary device and traffic in the VPLS instance from CE1 and CE2 is diverted to the backup spoke PW. MTU-s may desire to unlearn or remove the MAC addresses that were learned across the VPLS instance earlier through n-PE1 for faster convergence. MTU-s may send MAC Withdrawal Message to n-PE2 once the backup PW has been made active. As per the processing rules defined in [RFC4762] n-PE2 should flush all the MAC addresses learned in the VSI from the PWs terminating at n-PE1, n-PE3 and n-PE4. In the H-VPLS core, n-PE devices are connected in full mesh for a VPLS instance unlike the spanning tree connectivity in bridges. So the actual MAC addresses that require flushing and relearning at the VSI in n-PE2 are only the MAC addresses that have been learned on the PW connected to the VSI in n-PE1. MAC address flushing and relearning are resource intensive processes at n-PE devices when there is a large number of MAC addresses associated in the VPLS instance. After processing the MAC Withdrawal Message at n-PE2, it triggers MAC Withdrawal Messages to all other n-PE devices in the full mesh core. Same processing rule applies at all other n-PE devices. For example, at n-PE3 all the MAC addresses learned from PWs connected to the VSIs in n-PE1 and n-PE4 are flushed and relearned subsequently. As the number of n-PE devices in the full- mesh increases, the number of unaffected MAC addresses flushed in a VPLS instance also increases. With large number of VPLS instances provisioned in the H-VPLS domain the amount of unnecessary MAC address flushing and learning increases. This document defines an extension to the existing MAC Withdrawal Mechanism in [RFC4672] that enables an n-PE device in full-mesh to flush only MAC addresses that need relearning due to topology change. 5. Mechanism to avoid flushing of MACs from unaffected PW(s) The basic principle of the mechanism defined in this document is explained with reference to Figure 1. When MTU-s switches over to backup spoke PW of a VPLS instance, it triggers MAC withdrawal Message and within the Message it also communicates the unique identifier of the VSI residing in n-PE1. Each n-PE in the full-mesh that receives the message identifies its respective PW in the VPLS instance that terminates at the VSI in n-PE1 and flushes the MAC addresses learned from that PW. The extension defined in this document is generic and is applicable to various VPLS provisioning models described in [L2VPN-SIG]. Dutta, et. al. Expires September 5, 2007 [Page 4] Internet Draft draft-pdutta-l2vpn-vpls-ldp-mac-opt-02.txt March 2007 5.1 LDP Extension on PE-ID A new optional PE-ID TLV is defined that MAY be propagated within MAC Withdrawal Message to n-PE device(s) in the VPLS instance. The PE-ID TLV in combination with the FEC TLV in the MAC Withdrawal Message forms the unique identification info of a VSI in an n-PE device in the VPLS instance. The encoding of PE-ID TLV follows standard LDP TLV encoding in [RFC3036] and is defined as follows: 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| Type (PE-ID) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PE-ID Element | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U bit: Unknown bit. This bit MUST be set to 1. If the PE-ID Format is not understood then the TLV MUST be ignored. F bit: Forward bit. This bit MUST be set to 0. Since the LDP mechanism used here is targeted, the TLV MUST NOT be forwarded. Type : Type field. This field MUST be set to 0x405 (subject to IANA approval). This identifies the TLV type as PE-ID TLV. Length : Length field. This field specifies the total length in octets of the PE-ID Element in the TLV. The length varies depending on the type of PE-ID Element. The PE-ID TLV MUST contain a single PE-ID Element. A VPLS instance may span across a single AS or across multiple Autonomous Systems (AS) and BGP based or other auto-discovery procedures may be used to associate the VSIs in a VPLS. The PWs used to connect VSIs may be Single Segment PWs(SS-PW) or may be Multi-segment PWs(MS-PW) in inter-AS environments. MS-PW is defined in [MSPW-ARCH] and its signaling signaling procedures are defined in [SEG-PW],[DYN-MSPW]. The encoding rules for PE-ID Element MUST ensure that collisions do not occur with other providers in inter-AS VPLS case and a VSI can be uniquely identified across the domains by combination of PE-ID and FEC-TLV. Dutta, et. al. Expires September 5, 2007 [Page 5] Internet Draft draft-pdutta-l2vpn-vpls-ldp-mac-opt-02.txt March 2007 The PE-ID Element encoding is as follows: 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 (PE-ID Element Type)| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PE Identifier (Variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Field of size 2 octets that contains the type of PE-ID Element. Length Field of size 2 octets that contains the length of the PE Identifier in number of octets. PE Identifier Variable length field that contains the value of PE Identifier based on specific types. There can be several types of PE-ID Elements. In this version of the document one PE-ID Element type is defined and is termed as “Generic PE-ID Element”. The value of type is 0x01. 5.1.1 Generic PE-ID Element The Generic PE-ID Element value encoding is based on the semantics of end point identifiers of VSIs for VPLS defined in [L2VPN-SIG]. If BGP based auto discovery for VPLS is used then each VSI endpoint needs to have a unique identifier that is encodable as a BGP NLRI. [L2VPN-SIG] defines the unique VSI Identifier by prepending the Route Distinguisher (RD) to an IP address of the n-PE (RD:PE_addr) containing the VSI. Note that the role of PE_addr is simply as a readily available unique identifier for the VSIs within a VPLS Instance; it does not need to be globally routable, but it must be unique within the VPLS instance as defined in [L2VPN-SIG]. An alternate scheme to assign unique identifiers to each VSI within a VPLS instance (e.g. numbering the VSIs of a single VPN from 1 to n) could be used if desired. The Generic PE-ID Element encoding is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PE-ID Element Type(0x01) | Length(4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PE_addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Dutta, et. al. Expires September 5, 2007 [Page 6] Internet Draft draft-pdutta-l2vpn-vpls-ldp-mac-opt-02.txt March 2007 PE_addr : This is any 4 byte identifier of a n-PE device and follows the PE_addr encoding in [L2VPN-SIG]. [RFC4447] defines two types of FEC Elements – Pwid Element (type 0x80) and Generalized PWid (GPWid) Element (type 0x81) that may be used for provisioning PWs in a VPLS instance. If PWid Element is used for signaling PWs then combination of PW ID field in the PWid Element and PE_addr field encoded in the PE-ID TLV carried in the MAC Withdrawal Message uniquely identifies a remote VSI in an n-PE. In this case PE_addr may contain the loopback address of an n-PE used in its LDP signaling sessions. This information would enable any receiving n-PE to uniquely identify the PW that terminates on the VSI at a remote n-PE. Deployments may use GPWid Element to signal the PWs in both intra-AS as well as inter-AS VPLS environments with autodiscovery. In GPWid Element, the AGI field (of type I) carries the RD and PE-ID TLV carries the PE_addr field. The combination of RD:PE_addr is used by receiving n-PE to lookup the remote VSI in provisioning or autodiscovery information and the PW terminating in that remote VSI can be uniquely identified. Definitions and usage environments of other types of PE-ID Elements is a subject for future study. 5.2 Processing of PE-ID This section defines the processing rules of PE-ID TLV with Generic PE-ID Element (type 0x01). The PE-ID TLV is applicable ONLY in LDP Address Withdraw Message with empty MAC List as defined in [RFC4762] and MAY be sent as an optional parameter. In Figure 1. when a MTU-s triggers MAC Address Withdrawal after failover of spoke PW to a n-PE device, it MAY send the PE-ID TLV with PE Identifier that identifies the PE_addr part of the VSI in the formerly active n-PE device. In cases where n-PE devices initiate MAC Address Withdrawal in a VSI, MAC Address Withdrawal message may contain PE_addr associated with its own VSI in that VPLS instance. Irrespective of whether it is the MTU-s or n-PE device that initiates the MAC Address Withdrawal, an n-PE device receiving the option follows the same processing rules as defined in this section. If MS-PW is used in VPLS then a MAC Withdrawal Message will only be processed at the T-PE nodes. It is to note that MS-PW is transparent to VPLS. In this section an n-PE device signifies only T-PE in MS-PW case unless specified otherwise. When an n-PE device receives a MAC Withdrawal Message with PE-ID TLV, the n-PE SHOULD flush all the MAC addresses in the VSI learned from the PW that terminates in the remote VSI identified by the combination of FEC Element and PE-ID Element. Dutta, et. al. Expires September 5, 2007 [Page 7] Internet Draft draft-pdutta-l2vpn-vpls-ldp-mac-opt-02.txt March 2007 If an n-PE device receives a LDP Address Withdraw Message with the PE-ID option included when there is a valid MAC address list then it SHOULD ignore the option and deal with MAC addresses explicitly as per corresponding procedures defined in [RFC4762]. When an n-PE device that doesn't support PE-ID TLV receives MAC Withdrawal Message with this option then it SHOULD ignore the option and SHOULD follow the processing rules as per [RFC4762]. 5.3 MAC Address Withdrawal Procedure with PE-ID This section explains the MAC Address Withdrawal Procedure in the scenerio in figure.1 when PE-ID TLV is used with Generic PE-ID Element. In the scenerio, n-PE1 is the primary device for the dual homed MTU-s. The traffic received in the VSI from CE1 and CE2 is forwarded by MTU-s to n-PE1 and the MAC addresses are learned by n- PE1 over the primary spoke PW. Accordingly other n-PE devices in the VSI in full mesh core learn those MAC addresses on their respective PWs from their VSIs terminating in n-PE1. After a PW switchover takes place at MTU-s to backup spoke PW, n-PE2 is selected as primary device and MTU-s diverts the traffic from CE1 and CE2 to n- PE2. MTU-s may send a MAC Withdrawal Message for the VSI with the optional PE-ID TLV. The corresponding Generic PE-ID Element field may contain the PE Identifier of the VSI in n-PE1. When the message is received at n-PE2, it removes all MAC addresses in the VSI learned on the PW that terminates on the VSI identified by PE-ID TLV and FEC TLV, that is the VSI in n-PE1. n-PE2 then triggers MAC Withdrawal Messages with PE-ID to all its peer n-PE devices. n-PE2 sends the same PE Identifier in the PE-ID TLV as the one received in the message sent by MTU-s. Same processing rules are applied at all other n-PE devices. For example, when the message is received at n-PE3 it identifies the PW that terminates in the remote VSI in n-PE1, So n-PE3 removes all MAC addresses learned on the PW that terminated in n-PE1. There may be redundancy scenerios where an n-PE may be required to initiate optimized MAC Address Withdrawal when topology changes in a VPLS instance. Figure 2. shows a redundant H-VPLS topology to protect against failure of a u-PE device. Provider RSTP may be used as selection algorithm for active and backup PWs in order to maintain the connectivity between u-PEs and n-PEs. It is assumed that n-PEs can detect failure on PWs in either direction through OAM mechanisms such as VCCV procedures etc. u-PE1===============n-PE3===============PE5 || || \ /|| || Redundancy || \ / || || Provider RSTP || Full-Mesh . || || || / \ || || || / \|| u-PE2---------------n-PE4==============PE6 Backup PW Figure 2. Redundancy with Provider RSTP Dutta, et. al. Expires September 5, 2007 [Page 8] Internet Draft draft-pdutta-l2vpn-vpls-ldp-mac-opt-02.txt March 2007 The devices u-PE1, u-PE2, n-PE3 and n-PE4 participates in provider RSTP. By configuration in RSTP it is ensured that the PW between u-PE1 and n-PE3 is active and the PW between u-PE2 and n-PE4 is blocked (made backup) at u-PE2 end. When the active PW failure is detected by RSTP, it makes the PW between between u-PE2 and n-PE4 as active. When n-PE3 detects the failing PW to u-PE1 it may trigger MAC Address Withdrawal into the full mesh with PE-ID TLV that carries its own VSI identfier in the VPLS instance. Other n-PE devices in the full mesh that receives the MAC Address Withdrawal message identifies the PW terminating on n-PE3 and flushes all the MAC addresses learned from it. By default, u-PE2 should still trigger MAC Address Withdrawal as currently defined in [RFC4762] after the backup PW is made active by RSTP. Mechanisms to prevent two copies of MAC withdraws to be sent (one by u-PE2 and another one by n-PE3) in such scenerios is out of scope of this document. One point to note is that n-PE initiated MAC Withdrawal is unlike the TCN based MAC flushing in bridges that is triggered only after a backup link becomes active. [RFC4762] describes multi-domain VPLS service where fully meshed VPLS networks (domains) are connected together by a single spoke PW per VPLS service between the VPLS "border" PE devices. To provide redundancy against failure of the inter-domain spoke, full mesh of inter-domain spokes can be setup between border n-PE devices and provider RSTP may be used for selection of the active inter-domain spoke. In case of inter-domain spoke PW failure, n-PE initiated MAC withdrawal may be used for optimized MAC flushing within individual domains. 5.4 Applicability of PE-ID This document defines the PE-ID TLV and its application in optimized flushing of MAC addresses in full mesh H-VPLS core. The mechanism is OPTIONAL and has been demonstrated with scenerios of MTU-s trigerred MAC Withdrawal and n-PE triggered MAC Withdrawal. This document does not specify various other H-VPLS redundancy scenerios that may be possible within the provider domain and is out of scope. The document doesn't specify the device that should trigger MAC Address Withdrawal and the method to be used to select the appropriate PE-ID in various redundancy scenarios is out of scope of the solution proposed here. Section 5.1 in [VPLS-BRIDGE] specifies backdoor connectivity of CE devices to the VPLS provider domain. Such network topologies are designed to protect against the failure or removal of network components with the customer network and it is assumed that the customer leverages the spanning tree protocol to protect against these cases. Therefore, in such scenarios, it is important to flush customer MAC addresses in the provider network upon the customer topology change to avoid black holing of customer frames. The mechanism defined in this document is not applicable to such redundancies in CE network and is limited to redundancies of u-PE devices within the provider domain only. Dutta, et. al. Expires September 5, 2007 [Page 9] Internet Draft draft-pdutta-l2vpn-vpls-ldp-mac-opt-02.txt March 2007 6. Security Considerations - Control plane aspects - LDP security (authentication) methods as described in [RFC3036] is applicable here. Further this document implements security considerations as in [RFC4447] and [RFC4762]. - Data plane aspects - This specification does not have any impact on the VPLS forwarding plane. 7. IANA Considerations The Type field in PE-ID TLV is defined as 0x405 in section 5.1 and is subject to IANA approval. 8. Acknowledgments The authors wish to thank Ali Sajassi for his valuable contributions in this version of the document. The authors wish to thank John Rigby, Prashanth Ishwar and Vipin Jain for valuable suggestions, both technical and editorial, for correcting and improving the document. 9. References 9.1 Normative References [RFC4762] Lasserre, M. and Kompella, V., "Virtual Private LAN Services using LDP", RFC4762, January 2007. [RFC3036] Andersson, L., et al. "LDP Specification",RFC3036, January 2001. 9.2 Informative References [L2VPN-SIG] Rosen, E., et al. “Provisioning, Autodiscovery, and Signaling in L2VPNs”, work in progress. [L2VPN-FRWK] Andersson, L., et al. "Framework for Layer 2 Virtual Private Networks (L2VPNs)", work in progress. [VPLS-BRIDGE] Sajassi, A., et al. “VPLS Interoperability with CE Bridges”, work in progress. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. Dutta, et. al. Expires September 5, 2007 [Page 10] Internet Draft draft-pdutta-l2vpn-vpls-ldp-mac-opt-02.txt March 2007 [RFC4761] Kompella, K. and Rekhtar, Y., “Virtual Private LAN Service (VPLS)Using BGP for Auto-Discovery and Signaling”, RFC 4761, January 2007. [RFC4447] Martini,L. and et al., "Pseudowire Setup and Maintenance Using Label Distribution Protocol (LDP)", RFC 4447, April 2006. [MSPW-ARCH] Bocci, M. and et al. "An Architecture for Multi- Segment Pseudo Wire Emulation Edge-to-Edge", work in progress. [DYN-MSPW] Martini,L. and et al., “Dynamic Placement of Multi Segment Pseudo Wires”, work in progress. [SEG-PW] Martini,L. and et al., “Segmented Pseudowire”, Work in progress. [802.1w] "IEEE Standard for Local and metropolitan area networks. Common specifications Part 3: Media Access Control (MAC) Bridges. Amendment 2: Rapid Reconfiguration", IEEE Std 802.1w-2001. 10. Author's Address Pranjal Kumar Dutta Alcatel-Lucent Email: pdutta@alcatel-lucent.com Marc Lasserre Alcatel-Lucent E-mail: mlasserre@alcatel-lucent.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this Dutta, et. al. Expires September 5, 2007 [Page 11] Internet Draft draft-pdutta-l2vpn-vpls-ldp-mac-opt-02.txt March 2007 specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Dutta, et. al. Expires September 5, 2007 [Page 12]