Network Working Group Y.L., Jiang Internet Draft Y., Yang Huawei Intended status: Standards Track June 24, 2008 Expires: December 24, 2008 Optimized MAC Address Operations in VPLS with Redundancy draft-jiang-l2vpn-vpls-mac-operation-00.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 December 24, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract The Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling is described in RFC 4762. That document describes a mechanism called MAC Address Withdrawal to remove or unlearn MAC addresses which have been dynamically learned in a VPLS Jiang Expires Dec 2008 [Page 1] Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008 instance. Further work in progress defines an extension to MAC Address Withdrawal procedure which can greatly restrict the scope of MAC flushing. This document provides two mechanisms which completely remove the need for MAC address flushing in VPLS instances. The mechanisms are MAC address switching and MAC address notification. 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...................................................2 2. Scenarios......................................................3 3. Optimized MAC Address Operations...............................5 3.1. MAC Address Switching.....................................6 3.2. MAC Address Notification..................................6 4. LDP Extensions.................................................6 4.1. PW-ID TLV.................................................6 4.2. MAC Address Switching Message.............................9 4.3. MAC Address Notification Message.........................10 5. Signaling MAC Address Operations..............................11 6. Processing Rules..............................................11 6.1. Receipt of MAC Address Switching Message.................11 6.2. Receipt of MAC Address Notification Message..............12 7. Applicability.................................................12 8. Security Considerations.......................................12 9. IANA Considerations...........................................14 9.1. New LDP Message Types....................................14 9.2. New LDP TLV Type.........................................14 10. Acknowledgments..............................................14 11. References...................................................15 11.1. Normative References....................................15 11.2. Informative References..................................15 Author's Addresses...............................................15 Intellectual Property Statement..................................16 Disclaimer of Validity...........................................16 1. Introduction A method of Virtual Private LAN Service (VPLS), also known as Transparent LAN Service (TLS) is described in [RFC4762]. A VPLS is Jiang Expires Dec 2008 [Page 2] Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008 created using a collection of one or more point-to-point pseudowires (PWs) [RFC4664] configured in a flat, full-mesh topology. The mesh topology provides a LAN segment or broadcast domain that is fully capable of learning and forwarding on Ethernet MAC addresses at the PE devices. A MAC Address Withdrawal mechanism is described in [RFC4762] to remove or unlearn MAC addresses for faster convergence on topology change [RFC4762]. But when a PE device in VPLS receives a MAC Flush message it may also flush the MAC addresses which are not affected by the topology change, thus leading to unnecessary flooding and MAC relearning. [MAC-OPT] describes a solution to optimize the MAC flush procedure so that only the MAC addresses affected by topology change are flushed. This can greatly restrict the scope of MAC flushing. Both of the methods provided by [RFC4762] and [MAC-OPT] must flush the MAC addresses first, and then re-learn them by flooding all frames with these MAC addresses as layer 2 destinations. This incurs a waste of bandwidth and may even cause congestions in the MPLS core network. For PW switching scenarios introduced in [MAC-OPT] and [PW-RED], when a working PE switches to a backup PE or a working PW switches to a backup PW, its associated MAC address could be re-utilized rather than flushed. This document provides two mechanisms which completely remove the need for MAC address flushing in VPLS instances. The mechanisms are MAC address switching and MAC address notification. 2. Scenarios Figure 1 demonstrates the VPLS reference model as explained in [RFC4664]. PE devices that are VPLS-capable provide a logical interconnect such that Customer Edge (CE) devices belonging to a specific VPLS appear to be on a single bridged Ethernet. From Figure 1, we see that in a VPLS, a CE device attaches, possibly through an access network, to a "bridge" module of a VPLS PE. Within the VPLS PE, the bridge module attaches, through an "Emulated LAN Interface", to an Emulated LAN. For each VPLS, there is an Emulated LAN instance. Figure 1 shows some internal structure to the Emulated LAN: it consists of "VPLS Forwarder" modules connected by PWs, where the PWs may travel through Packet Switched Network (PSN) tunnels over a routed backbone. A "VPLS instance" consists of a set of VPLS Forwarders (no more than one per PE) connected by the PWs in a full- Jiang Expires Dec 2008 [Page 3] Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008 mesh configuration. Both the "bridge" and the "VPLS Forwarder" should maintain forwarding tables that map MAC addresses to ACs or PWs (they may be combined into a single table). The VPLS "bridge" does MAC Source Address (SA) learning on frames received on ACs, while the "VPLS Forwarder" does SA learning on PWs. |-----Routed Backbone---| | (P Routers) |PSN Tunnels, Emulated LAN | |Pseudowires ..................................................................... . | | . . |---------------------|----| |--------|-----------------| . . | --------------------|--- | | -------|---------------- | . . | VPLS Forwarder | | VPLS Forwarder | . . | ----------|------------- | | ----------|------------- | . ..|...............................................................|.. | | Emulated LAN | | | Emulated LAN | | | Interface |VPLS-PEs | | Interface | | | | <---> | | | | ----------|------------ | | ----------|------------ | | | Bridge | | | | Bridge | | | -|--------|----------|- | | -|--------|----------|- | |--|--------|----------|---| |--|--------|----------|---| | | | | | | | | Access | | | Access | | | Networks | | | Networks | | | | | | | | | | | | | CE devices CE devices Figure 1 VPLS Architecture Figure 2 describes a dual-homed H-VPLS scenario for a VPLS instance where the proposed mechanisms can be applied. In Figure 2, the Multi-Tenant Unit switch (MTU-s) is dual-homed to PE-1 and PE-2. Only the primary spoke PW is active at MTU-s, thus PE-1 acting as the primary device to reach the full mesh in the VPLS instance. The MAC addresses located at customer sites (behind CE1 and CE2) are learned at PE-1 over the primary spoke PW. PE-2, PE-3 and PE-4 learn those MAC addresses on their respective mesh PWs terminating at PE-1 (PW5, PW1, PW3). This is all as described in [RFC4762]. When MTU-s switches to the backup spoke PW and activates it, PE-2 becomes the primary device to reach the full mesh core. Traffic entering the H-VPLS from CE-1 and CE-2 is diverted by MTU-s to the Jiang Expires Dec 2008 [Page 4] Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008 backup spoke PW, and then transferred across the full mesh core to remote PE-3 or PE-4 by way of PW2 or PW4. For faster convergence MTU-s may send a MAC flush message to PE-2 once the backup PW has been made active, and PE-2 forwards the MAC flush message to PE-3 and PE-4. In this way, both [RFC4762] and [MAC-OPT] mechanisms will flush MAC addresses associated with PW1 from PE-3, and those MAC addresses associated with PW3 from PE-4. The addresses will be re- learned by flooding frames with these MAC addresses as their destinations. Additionally, PE-2 will have to re-learn the MAC addresses behind customer sites CE-3 and CE-4 which PE-1 had previously learnt from PW1 and PW3 respectively. PE-1 PE-3 +--------+ +--------+ | | | | | -- | PW1 | -- | CE-3 | / \ |----------------| / \ |---> CE-1 /------| \ s/ | PW2 | \S / | \ primary spoke PW | -- | /------| -- | \ / +--------+ / +--------+ \ (MTU-s)/ | \ / | +--------+/ | \ / | | | | \ / | | -- | | \/ | | / \ | PW5| H-VPLS Full Mesh Core | | \S / | | / \ | | -- | | / \ | /+--------+\ | / \ | / backup spoke PW | / \ PW3 | / \ +--------+ \------+--------+ CE-2 \ | | | | \------| -- | PW4 | -- | CE-4 | / \ |----------------| / \ |---> | \s / | | \S / | | -- | | -- | +--------+ +--------+ PE-2 PE-4 Figure 2 Dual homed MTU-s in two tier hierarchy H-VPLS 3. Optimized MAC Address Operations Two mechanisms for optimized MAC address operation are described in this document, the first is MAC address switching, which can be used by a PE node where both the working PW and the backup PW terminate Jiang Expires Dec 2008 [Page 5] Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008 at the same PE; the other is MAC address notification, which can be used when the working PW and the backup PW originate from two different nodes (i.e. when a primary PE node switches the VPLS service to a backup PE node). With these two mechanisms, flushing of MAC address can be totally avoided under network scenarios such as figure 2. 3.1. MAC Address Switching The basic principle of MAC Address Switching is explained with reference to Figure 2. When PW1 is switched to the backup PW2 (PW switching may be realized in a mechanism described in [PW-RED] or in some other way), PE-1 or PE-2 sends out a ''MAC Address Switching'' message to PE-3, and accordingly PE-3 changes its MAC table items with PW1 as the outgoing PW, to show PW2 as the outgoing PW. In this way, remote VPLS peer node PE-3 needs no MAC flushing and re- learning, and faster convergence is realized. The message format and the procedure of processing are defined in section 4. 3.2. MAC Address Notification The basic principle of MAC Address Notification is explained with reference to Figure 2. When PE-1 notifies PE-2 to transfer the VPLS service, it notifies PE-2 of the MAC addresses it leant over the working pseudowire PW1 and PW3. In this way PE-2 does not need to re-learn them over PW2. To facilitate MAC table maintenance on PE-2, the MAC Address Notification messages should include the outgoing PWs to be associated with the notified MAC addresses. Multiple PWs and their associated MAC addresses may be carried in a single message or in separate messages. 4. LDP Extensions In order to realize MAC address switch and MAC address notification mechanisms, some LDP extensions are defined in this document. 4.1. PW-ID TLV The PW-ID TLV carries the unique identifier of a PW. The encoding of PW-ID TLV follows standard LDP TLV encoding in [RFC5036], its encoding is: Jiang Expires Dec 2008 [Page 6] Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008 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|0| PW-ID TLV (0x0406) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW-ID Element | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 PW-ID TLV U (Unknown) bit of PW-ID TLV MUST be set to 1. If the PW-ID TLV is not understood then it is silently ignored. F (Forward) MUST be set to 0. Since the LDP mechanism used here is targeted, the TLV is not forwarded if it is not understood by the receiving device. The Type field MUST be set to 0x406 (subject to IANA approval). This identifies the TLV type as PW-ID TLV. Length field specifies the total length in octets of the Value in the PW-ID TLV. PW-ID Element encoding depends on the type of the PW-ID Element. A PW-ID Element uniquely identifies a PW. A PW-ID Element value is encoded as 1 octet field that specifies the element type, 1 octet field that identifies the length in octets of the element value, and a variable length field that is a type-dependent element value. The PW-ID Element value encoding is: PW-ID Element Type Length Value Type name FEC-128 specific 0x01 2 octets See below. FEC-129 specific 0x02 Variable See below. The type of PW-ID Element depends on the type of FEC Element used to provision the respective PW. [RFC4447] defines two types of FEC element that may be used for provisioning PWs - PWid FEC (type 128) and the Generalized ID (GID) FEC (type 129). The PWid FEC element includes a fixed-length 32 bit value called the PWid. The same PWid value must be configured on the local and remote PE prior to PW setup. The GID FEC element includes TLV fields for attachment individual identifiers (AII) that, in conjunction with an attachment group identifier (AGI), serve as PW endpoint identifiers. The endpoint Jiang Expires Dec 2008 [Page 7] Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008 identifier on the local PE (denoted as ) is called the source attachment identifier (SAI) and the endpoint identifier on the remote PE (denoted as ) is called the target attachment identifier (TAI). The SAI and TAI can be distinct values. This is useful for provisioning models where the local PE (with a particular SAI) does not know and must somehow learn (e.g. via MP-BGP auto-discovery) of remote TAI values prior to launching PW setup messages towards the remote PE. FEC-128 specific PW-ID Element This sub-type is to be used to identify a PW endpoint only if PWid FEC Element is used for signaling the PW. The encoding of this PW-ID element is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 | Length | PW type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 FEC-128 specific PW-ID Element PW type The PW Type value from PWid FEC element. PW ID The PW ID value from the PWid FEC element. FEC-129 specific PW-ID element This sub-type is to be used to identify a PW only if GID FEC Element is used for signaling the PW. The encoding of this PW-ID element is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x02 | Length | PW type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AGI TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SAII TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TAII TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 FEC-129 specific PW-ID Element Jiang Expires Dec 2008 [Page 8] Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008 PW type The PW Type value from GID FEC element. AGI TLV The AGI from the corresponding GID Element SAII TLV The SAII associated with the PW. TAII TLV The TAII associated with the PW. 4.2. MAC Address Switching Message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Address Switching (0x0302) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MAC List TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | PW-ID TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 MAC Address Switching Message Message Type, this field identifies the type of LDP message "Address Switching" and MUST be set to 0x0302. This value needs IANA approval. Message Length, Specifies the cumulative length in octets of the Message ID, MAC list TLV, and PW-ID TLV. Message ID, a 32-bit value used to identify this message. MAC List TLV, this field is defined in section 6.2.1 of [RFC4762]. Jiang Expires Dec 2008 [Page 9] Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008 PW-ID TLV, this field is defined in section 4.1 of this document. 4.3. MAC Address Notification Message A new "MAC Address Notification" message is defined which includes a MAC List TLV as defined in [RFC4762] and a PW-ID TLV as defined in section 4.1 of this document. Multiple MAC List TLVs and PW-ID TLVs MAY be included, and they MUST appear in pairs with the MAC List TLV first. The detailed MAC Address Notification message is explained here. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|Address Notification (0x0303)| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MAC List TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | PW-ID TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7 MAC Address Notification Message Message Type, this field identifies the type of LDP message "Address Notification" and MUST be set to 0x0303. This value needs IANA approval. Message Length, Specifies the cumulative length in octets of the Message ID, MAC list TLV, and PW-ID TLV. Message ID, 32-bit value used to identify this message. MAC list TLV, this field is defined in section 6.2.1 of [RFC4762]. PW-ID TLV, this field is defined in section 4.1 of this document. Multiple pairs of MAC List and PW-ID TLVs MAY be present. Jiang Expires Dec 2008 [Page 10] Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008 5. Signaling MAC Address Operations MAC address notification and MAC address switching may be signaled separately, or be combined with the PW redundancy signaling defined in [PW-RED], thus when the PE node notifies its PW peer node about its status, it can also carry the MAC address notification and MAC Address Switching messages. When the working PE node (PE-1 in Figure 2) decides to switch its working PW to a standby PW (and the standby PW does not traverse the working PE itself), the working PE node MAY send out a MAC Address Notification message to its backup PE (i.e. PE-2 in Figure 2) with MAC addresses listed in a MAC List TLV and the backup PW identified in the PW-ID TLV, and MAY send out a MAC Address Switching message for the respective working PW for each of the other VPLS peers with MAC addresses in the MAC List TLV and its corresponding backup PW identified in the PW-ID TLV. When the backup PE node triggers PW switching, it MAY send out a MAC Address Switching message for respective backup PW for each of the other VPLS peers with its corresponding working PW in the PW-ID TLV. Under some circumstances, PW endpoints may trigger PW switching in a distributed way, and do the MAC address switching without any signaling message. As no signaling is concerned, this kind of scenario is out of the scope of this document. 6. Processing Rules 6.1. Receipt of MAC Address Switching Message Upon receipt of the MAC address switching message, the peer PE node SHOULD: - Extract the PW-ID from the message; - Verify that the PW identified by PW-ID and the PW from which the message is received are protecting each other, otherwise MUST ignore this message and MAY log an error locally; - Identify the working PW and the backup PW from these two PWs; - If MAC List TLV is null (absent or empty), then for each MAC addresses in the forwarding table which is associated with the working PW: Jiang Expires Dec 2008 [Page 11] Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008 - associate the MAC address with backup PW in the forwarding table - Otherwise, for each MAC address in the MAC List TLV: - associate the MAC address with the backup PW in the forwarding table. 6.2. Receipt of MAC Address Notification Message When a PE node receives a MAC Address Notification Message, after verification it SHOULD add the MAC addresses carried in the message to its FIB and associate them with the PW identified by the PW-ID TLV carried in the message. Upon receipt of a MAC Address Notification message, the peer node SHOULD: - Extract the PW-ID from the message; - Verify that it is the backup PE for the PE from which this message is received, and the PW identified by PW-ID is a backup PW traverse itself, otherwise MUST ignore this message; - For each MAC address in the MAC List TLV in the received message: - associate the MAC address with the PW identified in the PW-ID TLV in the message and store them in the forwarding table. 7. Applicability This document defines the MAC Address Switching and MAC Address Notification procedures and their application in optimized MAC addresses operation in H-VPLS on topology change. These mechanisms MAY also be used in the scenarios described in [PW-RED]. The use of MAC Address Switching and MAC Address Notification procedures is OPTIONAL. 8. Security Considerations This section is to be enhanced in a future revision of this document. - Control plane aspects Jiang Expires Dec 2008 [Page 12] Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008 - LDP security (authentication) methods as described in [RFC5036] are 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. Note that forged switchover messages, such as those defined in this document, represent a significant risk to established PWs and the traffic they carry. If an attack is successful, traffic may be diverted to other destinations which may introduce a denial of service risk (as the traffic may be black-holed or sent on non- optimum paths), and may also represent a risk to the confidentiality of the data being transferred. The use of standard LDP security mechanisms, as described above, will mitigate this risk. Additionally, cross-check mechanisms are included in the procedures described in this document to ensure that the switchover of MAC address information is expected. Jiang Expires Dec 2008 [Page 13] Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008 9. IANA Considerations 9.1. New LDP Message Types IANA maintains a registry of LDP code-points at "Label Distribution Protocol (LDP) Name Spaces". There is a sub-registry for LDP message types called "Message Type Name Space". IANA is requested to allocate two new message types from the range 0x300-0x3ff. The following values are suggested: Message Name Type Address Switching 0x0302 Address Notification 0x0303 9.2. New LDP TLV Type IANA maintains a registry of LDP code-points at "Label Distribution Protocol (LDP) Name Spaces". There is a sub-registry for LDP TLV type values called "Table, Length, and Value (TLV) Type Name Space". IANA is requested to allocate a new value from the range 0x0000- 0x3DFF. The following value is suggested: The TLV type of PW-ID is defined as 0x406 and subject to IANA approval. 10. Acknowledgments The authors would like to thank Adrian Farrel and Dan Li for their valuable comments and suggestions. This document was prepared using 2-Word-v2.0.template.dot. Jiang Expires Dec 2008 [Page 14] Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4447] Martini, L., et al, "Pseudowire Setup and Maintenance Using Label Distribution Protocol (LDP)", RFC 4447, April 2006. [RFC4762] Lasserre, M. and Kompella, V., "Virtual Private LAN Services using LDP", RFC 4762, January 2007. [RFC5036] Andersson, L., Minei, I., et al, "LDP Specification", RFC 5036, October 2007. [PW-RED] Muley, P., et al, "Preferential Forwarding Status bit definition", work in progress. [MAC-OPT] Dutta, P., and Lasserre, M., "LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS", work in progress. 11.2. Informative References [RFC4664] Andersson, L., and Rosen, E., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006. Author's Addresses Yuanlong Jiang Huawei Technologies Co., Ltd. Bantian industry base, Longgang district Shenzhen, China Email: yljiang@huawei.com Yang Yang Huawei Technologies Co., Ltd. Bantian industry base, Longgang district Shenzhen, China Email: healthinghearts@huawei.com Jiang Expires Dec 2008 [Page 15] Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-00.txt June 2008 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 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 (2008). 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. Jiang Expires Dec 2008 [Page 16]