Network Working Group L. Jin Internet-Draft ZTE Intended status: Standards Track K. Liu Expires: January 3, 2011 Nokia Siemens July 2, 2010 Leaf discovery mechanism for mLDP based P2MP/MP2MP LSP draft-jin-mpls-mldp-leaf-discovery-01.txt Abstract This document describes a mechanism for a root node to discover the leaf nodes of an mLDP based P2MP/MP2MP LSP. Such kind of function can then be used for multiplexing/aggregating various applications relying on mLDP as the P2MP/MP2MP LSP setup. Examples of such applications are P2MP PW [I-D.draft-martini-pwe3-p2mp-pw], VPLS multicast [I-D.draft-ietf-l2vpn-vpls-mcast], L3VPN multicast [I-D.draft-ietf-l3vpn-2547bis-mcast]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 3, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Jin & Liu Expires January 3, 2011 [Page 1] Internet-Draft draft-jin-mpls-mldp-leaf-discovery July 2010 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 Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation and problem statement . . . . . . . . . . . . . . . 3 2.1. mLDP Problem . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Application using MP-BGP . . . . . . . . . . . . . . . . . 3 2.3. Application using T-LDP . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Leaf discovery mechanism . . . . . . . . . . . . . . . . . . . 5 4.1. Leaf discovery mechanism based on T-LDP . . . . . . . . . 6 4.1.1. Leaf node identifier encoding . . . . . . . . . . . . 6 4.1.2. Leaf operation status TLV encoding . . . . . . . . . . 6 4.1.3. LDP notification messages . . . . . . . . . . . . . . 7 4.1.4. Node operation . . . . . . . . . . . . . . . . . . . . 8 4.2. Leaf discovery mechanism based on MP-BGP . . . . . . . . . 9 4.2.1. mLDP leaf NLRI . . . . . . . . . . . . . . . . . . . . 9 4.2.2. Node operation . . . . . . . . . . . . . . . . . . . . 10 5. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.2. MP-BGP . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative references . . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Jin & Liu Expires January 3, 2011 [Page 2] Internet-Draft draft-jin-mpls-mldp-leaf-discovery July 2010 1. Introduction This draft describes a mechanism for a root node to discover the leaf nodes of an mLDP based P2MP/MP2MP LSP. Such kind of function can then be used for multiplexing/aggregating various applications relying on mLDP as the P2MP/MP2MP LSP setup. Examples of such applications are P2MP PW [I-D.draft-martini-pwe3-p2mp-pw], VPLS multicast [I-D.draft-ietf-l2vpn-vpls-mcast], L3VPN multicast [I-D.draft-ietf-l3vpn-2547bis-mcast]. In order to impact the mLDP scalability as little as possible, this draft provides a discovery mechanism based on a signaling session between each leaf and root node. Each leaf node will report the leaf node information to root node through this signaling session. There will be two signaling protocols to be used for leaf node discovery, targeted LDP [RFC5036] or BGP auto-discovery using BGP Multiprotocol Extensions [RFC4760]. This document will introduce both signaling protocols for mLDP leaf discovery, and it depends on the application to choose the signaling protocol to use. 2. Motivation and problem statement 2.1. mLDP Problem [I-D.draft-ietf-mpls-ldp-p2mp] describes the mechanism for setting up mLDP based P2MP/MP2MP LSP. One limitation for mLDP is that none of the members belonging to a P2MP/MP2MP LSP topology knows all the other members of the P2MP/MP2MP LSP. This means that the root node cannot get the whole P2MP/MP2MP LSP membership information. For example, with static mLDP based P2MP LSP, a leaf node is configured to join one P2MP LSP, but the root node does not know which of the leaf nodes are member of this P2MP LSP. This problem may cause some limitation for multiplexing/aggregation applications using mLDP LSPs. 2.2. Application using MP-BGP [I-D.draft-ietf-l2vpn-vpls-mcast] describes the mechanism of setting up multicast tree in VPLS. When setting up a inclusive P-Multicast tunnel, BGP A-D is used to do the VPLS membership auto-discovery. The mLDP based P2MP/MP2MP LSP will be set up when receiving auto- discovery routes through BGP A-D. The root node will only know the mLDP LSP leaf node information which is triggered by the specific BGP A-D mechanism. Let!_s assume that an mLDP based P2MP/MP2MP LSP_a already exist, (this LSP may have been set up by other mean, e.g, static configuration) on the root node, and that LSP_a has the same leaf nodes as the P2MP LSP that VPLS multicast BGP A-D tries to set up. The root node does not know the original mLDP based LSP_a leaf Jin & Liu Expires January 3, 2011 [Page 3] Internet-Draft draft-jin-mpls-mldp-leaf-discovery July 2010 node information, and will set up mLDP based LSP_b triggered by BGP A-D with same root and leaf nodes. This causes mLDP based LSP resources waste in the network as it may not be necessary to setup two mLDP LSPs with the same root and leaves in the same network. Then multicast VPLS can only aggregate to mLDP P2MP/MP2MP LSP which is triggered by its own BGP A-D mechanism. There is a similar problem for [I-D.draft-ietf-l3vpn-2547bis-mcast] and L3VPN multicast that can only use mLDP P2MP/MP2MP LSPs to do aggregation which are triggered by their own BGP A-D mechanism on condition that all PEs advertise BGP A-D. Because for L3VPN multicast, the PE should not originate an Intra-AS I-PMSI A-D route in one case described in [I-D.draft-ietf-l3vpn-2547bis-mcast] section 9.1.1. 2.3. Application using T-LDP [I-D.draft-martini-pwe3-p2mp-pw] describes the P2MP PW setup and signaling mechanism. P2MP PW needs P2MP LSP to do multiplexing/ demultiplexing [I-D.draft-ietf-pwe3-p2mp-pw-requirements], then root node should determine whether this P2MP PW can multiplex to one of the already existing P2MP LSP. If mLDP is used to setup P2MP LSP, the root node is required to know leaf node information of mLDP based P2MP LSP, then it can determine if there is some leaf overlap between P2MP PW and P2MP LSP. According to the draft, the mLDP based P2MP LSP will be triggered by label mapping message on leaf node, hence root node will get the mLDP based P2MP LSP leaf nodes information through LDP label mapping message. However, root node of mLDP based P2MP LSP does not know any of the leaf node information if the P2MP LSP is setup by other application, e.g, static configuration. Then P2MP PW can only multiplex to mLDP P2MP/MP2MP LSP which is triggered by LDP label mapping message. According to the above analysis, the mLDP based P2MP/MP2MP LSP setup by various applications may not be shared for multiplexing/ aggregation with each other. The introduction of a leaf discovery mechanism for mLDP based P2MP/MP2MP LSP will assist various applications to share one P2MP/MP2MP LSP for multiplexing/ aggregation, especially for the P2MP/MP2MP LSP setup by static configuration. 3. Terminology mLDP: Multicast LDP. T-LDP: Target LDP. Jin & Liu Expires January 3, 2011 [Page 4] Internet-Draft draft-jin-mpls-mldp-leaf-discovery July 2010 P2MP LSP: An LSP that has one Ingress LSR and one or more Egress LSRs. MP2MP LSP: An LSP that connects a set of nodes, such that traffic sent by any node in the LSP is delivered to all others. Bud LSR: An LSR that is an egress but also has one or more directly connected downstream LSRs. Ingress LSR: Source of the P2MP LSP, also referred to as root node. Egress LSR: One of potentially many destinations of an LSP, also referred to as leaf node in the case of P2MP and MP2MP LSPs. Transit LSR: An LSR that has one or more directly connected downstream LSRs. Leaf node: A Leaf node can be either an Egress or Bud LSR when referred in the context of a P2MP LSP. In the context of a MP2MP LSP, an LSR is both Ingress and Egress for the same MP2MP LSP and can also be a Bud LSR. P2MP FEC: The P2MP FEC Element consists of the address of the root of the P2MP LSP and an opaque value. MP2MP FEC: MP2MP FEC consists of MP2MP downstream FEC and upstream FEC Element. MP FEC: Includes both P2MP FEC and MP2MP FEC. 4. Leaf discovery mechanism It would be beneficial if the mLDP leaf discovery mechanism can reuse the same signaling session as the application. Based on this point, this document defines two leaf discovery mechanisms, one is based on T-LDP, the other is based on MP-BGP. Which mechanism will be used really depends on the application that mLDP P2MP/MP2MP LSP serves. Generally, the application with LDP as the main signaling mechanism, e.g, P2MP PW, may use leaf discovery mechanism based on T-LDP, while application with MP-BGP as main signaling mechanism, e.g, VPLS Multicast[I-D.draft-ietf-l2vpn-vpls-mcast], L3VPN Multicast[I-D.draft-ietf-l3vpn-2547bis-mcast] may use leaf discovery mechanism based on MP-BGP. Jin & Liu Expires January 3, 2011 [Page 5] Internet-Draft draft-jin-mpls-mldp-leaf-discovery July 2010 4.1. Leaf discovery mechanism based on T-LDP This section will introduce the discovery mechanism based on T-LDP session. Each leaf node will report the leaf node information to root through this T-LDP session. It is required that there is a T-LDP session existed between each leaf node and root node. mLDP leaf discovery function will share the same mLDP P2MP capability described in section 2.1 of draft [I-D.draft-ietf-mpls-ldp-p2mp]. 4.1.1. Leaf node identifier encoding A leaf node identifier TLV will uniquely identify a leaf node in the MPLS network. A new TLV should be defined to attach with P2MP/MP2MP FEC Element to identify the leaf node, see the figure 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(TBD) | Length | Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Family |Address Length | Leaf Node Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Leaf Node Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 Type: this type of opaque value is to be assigned by IANA. Length: The length of address value, determined by the address type. Address Family: two octet quantity containing a value from ADDRESS FAMILY NUMBERS in [RFC 3232] that encodes the address family. Address Length: Length of the Leaf Node Address in octets. Leaf Node Address: A host address encoded according to the Address Family field. The leaf node identifier MUST be sent in LDP notification together with P2MP/MP2MP FEC Element. 4.1.2. Leaf operation status TLV encoding There will be two operations for leaf node, add and delete. It is necessary to define a new "leaf node identifier" operation status TLV for LDP notification messages. The operation status TLV is defined Jin & Liu Expires January 3, 2011 [Page 6] Internet-Draft draft-jin-mpls-mldp-leaf-discovery July 2010 from the LDP MP Status Value Element, see the figure 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(TBD) | Length | add/delete | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Type: this type of LDP MP status value element is to be assigned by IANA. Length: 1 octet for the value. Value: 0x01 (to be assigned by IANA): means add operation of "leaf node identifier"; 0x02 (to be assigned by IANA): means delete operation of "leaf node identifier"; When the notification message contains the "leaf node identifier" operation status TLV, the Leaf Node Identifier TLV and LDP MP FEC TLV MUST also be included in the message. When the node receives the notification with "leaf node identifier" operation status TLV, but without Leaf Node Identifier TLV or LDP MP FEC TLV, an LDP notification with "missing message parameters" status (code 0x16) should be generated. 4.1.3. LDP notification messages The Leaf Node Identifier TLV and Leaf operation status TLV SHOULD appear in a LDP notification message. The general format of the Notification Message with a Leaf Node Identifier TLV and Leaf operation status TLV is: Jin & Liu Expires January 3, 2011 [Page 7] Internet-Draft draft-jin-mpls-mldp-leaf-discovery July 2010 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| Notification (0x0001) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Leaf operation status TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LDP MP FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Leaf Node Identifier TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 The Status TLV status code is used to indicate that LDP MP status TLV. Depending on the actual contents of the LDP MP status TLV, an LDP P2MP or MP2MP FEC TLV SHOULD be present to provide the identifier of P2MP/MP2MP LSP. 4.1.4. Node operation The mLDP based P2MP/MP2MP LSP leaf discovery mechanism can be operated as follows. For every leaf node, there will be a T-LDP session to be setup between root and leaf node. This T-LDP session can be setup automatically or manually, which depends on specific implementation. The leaf node can automatically initiate T-LDP session with root node. When root node receives target-hello, it can actively send target-hello to leaf node, so as to setup T-LDP session automatically. When the leaf node is triggered to join one P2MP/MP2MP LSP, by various applications, the leaf node sends label mapping message to its upstream node (root or transit node). At the same time, the leaf node sends LDP notification message with MP FEC attached with "leaf node identifiers" and operation status TLV "add" to its root node. When the root node receives the LDP notification message with MP FEC attached with "leaf node identifiers" and operation status TLV "add", it will store the leaf node information associated with the specified P2MP/MP2MP LSP locally. When the leaf node is triggered to leave one P2MP/MP2MP LSP, by various applications, the leaf node sends label withdraw message to Jin & Liu Expires January 3, 2011 [Page 8] Internet-Draft draft-jin-mpls-mldp-leaf-discovery July 2010 its upstream node (root or transit node). At the same time, the leaf node sends LDP notification message with MP FEC attached with "leaf node identifiers" and operation status TLV "delete" to its root node. When the root node receives the LDP notification message with MP FEC attached with "leaf node identifiers" and operation status TLV "delete", it will delete the leaf node information associated with the specified P2MP/MP2MP LSP locally. If the LSR receives the label mapping/withdraw message with "leaf node identifiers", it will ignore this opaque value or send an LDP notification message to the downstream node with "Unknown TLV" status (code 0x06). 4.2. Leaf discovery mechanism based on MP-BGP This section will introduce the discovery mechanism based on MP- BGP[RFC4760]. Each leaf node will report the leaf node information to root through this BGP session. 4.2.1. mLDP leaf NLRI This document defines a new BGP NLRI, called mLDP leaf NLRI. Following is the format of the mLDP leaf NLRI: +-------------------------------------------+ | mLDP MP FEC Element Length (1 octet) | +-------------------------------------------+ | mLDP MP FEC Element (Variable) | +-------------------------------------------+ | Leaf Node Address Length (1 octet) | +-------------------------------------------+ | Leaf Node Address (Variable) | +-------------------------------------------+ Figure 4 mLDP MP FEC Element may either contain P2MP FEC or MP2MP FEC element. Leaf Node Address field contains the leaf node IP address, and the value of length is 32 if it is IPv4 address, or 128 if it is IPv6 address. The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a mLDP MP FEC Element attached with Leaf Node Address. The mLDP leaf NLRI is advertised in BGP UPDATE messages using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. The [AFI, SAFI] value pair used to identify this NLRI is (AFI=26(AFI for MPLS Multicast, pending, IANA allocation), SAFI=8(SAFI for mLDP leaf discovery, pending IANA allocation)). Jin & Liu Expires January 3, 2011 [Page 9] Internet-Draft draft-jin-mpls-mldp-leaf-discovery July 2010 In order for two BGP speakers to exchange mLDP leaf NLRI, they must use BGP Capabilities Advertisement to ensure that they both are capable of properly processing such NLRI. This is done as specified in [RFC4760], by using capability code 1 (multiprotocol BGP) with an AFI of 26 and an SAFI of mLDP leaf discovery. The Next Hop field of MP_REACH_NLRI attribute shall be interpreted as an IPv4 address, whenever the length of the NextHop address is 4 octets, and as a IPv6 address, whenever the length of the NextHop address is 16 octets. 4.2.2. Node operation The mLDP based P2MP/MP2MP LSP leaf discovery mechanism can be operated as follows. When the leaf node is triggered to join one P2MP/MP2MP LSP, by various applications, the leaf node sends label mapping message to its upstream node (root or transit node). At the same time, the leaf node sends BGP UPDATE messages with MP_REACH_NLRI to its root node. The mLDP leaf NLRI will set Leaf Node Address to leaf node IP address, and next hop field to leaf node identifier. When the root node receives BGP UPDATE messages with MP_REACH_NLRI, it will store the leaf node information associated with the specified P2MP/MP2MP LSP locally. When the leaf node is triggered to leave one P2MP/MP2MP LSP, by various applications, the leaf node sends label withdraw message to its upstream node (root or transit node). At the same time, the leaf node sends BGP UPDATE messages with MP_UNREACH_NLRI to its root node. The mLDP leaf NLRI will set Leaf Node Address to leaf node IP address, and next hop field to leaf node identifier. When the root node receives BGP UPDATE messages with MP_UNREACH_NLRI, it will delete the leaf node information associated with the specified P2MP/ MP2MP LSP locally. To constrain distribution of the mLDP leaf NLRI to the AS of the advertising PE the BGP Update message originated by the advertising PE SHOULD carry the NO_EXPORT Community [RFC1997]. 5. Scalability For the application that uses T-LDP to do leaf discovery, all the leaf nodes have to setup T-LDP session to root node. There may be too many T-LDP sessions that have to be setup on the root node in the network, which will cause some scalability problem. This problem is caused by the application and out of scope of this draft. Jin & Liu Expires January 3, 2011 [Page 10] Internet-Draft draft-jin-mpls-mldp-leaf-discovery July 2010 6. Security Considerations The same security considerations apply as for the multicast LDP specification, as described in [I-D. draft-ietf-mpls-ldp-p2mp], and MP-BGP, as described in [RFC4760]. 7. IANA Considerations 7.1. LDP This document creates a new name space (the LDP MP Opaque Value Element type) that is to be managed by IANA, and the allocation of the value for leaf operation status "add/delete". This document requires allocation of one opaque value type: 1. Leaf node identifier type "C requested value 0x03 This document requires allocation of one LDP MP status TLV type: 1. Leaf operation status TLV "C requested value 0x01 7.2. MP-BGP This document requires allocation of a new BGP AFI and SAFI. A new AFI is allocated for MPLS Multicast function, the requested value has been pre-allocated as 26. A new BGP SAFI for "Network Layer Reachability Information used for mLDP leaf discovery" from the IANA "Subsequence Address Family Identifiers (SAFI)" registry. The requested value has been pre- allocated as 8. 8. Acknowledgement The author would like to thank Rahul Aggarwal, Dimitri Papadimitriou, IJsbrand Wijnands, Sandeep Bishnoi, Frederic Jounay and Simon DeLord for their valuable comments. 9. References 9.1. Normative references [RFC1997] Traina, P., "BGP Communities Attribute", RFC 1997 , August 1996. Jin & Liu Expires January 3, 2011 [Page 11] Internet-Draft draft-jin-mpls-mldp-leaf-discovery July 2010 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232 , January 2002. [RFC4760] Bates, T., "Multiprotocol Extensions for BGP-4", RFC4760 , January 2007. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036 , October 2007. 9.2. Informative References [I-D. draft-ietf-l2vpn-vpls-mcast] Aggarwal, R., Kamite, Y., and L. Fang, "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-05 (work in progress), July 2009. [I-D. draft-ietf-l3vpn-2547bis-mcast] Rosen, E. and R. Aggarwal, "Multicast in 2547 VPNs", draft-ietf-l3vpn-2547bis-mcast-08 (work in progress), November 2009. [I-D. draft-ietf-mpls-ldp-p2mp] Minei, I., Kompella, K., and I. Wijnands, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", draft-ietf-mpls-ldp-p2mp (work in progress), October 2009. [I-D. draft-ietf-pwe3-p2mp-pw-requirements] Jounay, F., Kamite, Y., Martini, L., Aggarwal, R., Delord, S., Bocci, M., Wang, L., Jin, L., and G. Heron, "Requirements for Point to Multipoint Pseudowire", draft-ietf-pwe3-p2mp-pw-requirements-02.txt (work in progress), January 2009. [I-D. draft-martini-pwe3-p2mp-pw] Martini, L., Jounay, F., Vecchio, G., Delord, S., Jin, L., and L. Ciavaglia, "Signaling Root-Initiated Point-to- Multipoint Pseudowires using LDP", draft-martini-pwe3-p2mp-pw-01 (work in progress), October 2009. Jin & Liu Expires January 3, 2011 [Page 12] Internet-Draft draft-jin-mpls-mldp-leaf-discovery July 2010 Authors' Addresses Lizhong Jin ZTE Corporation 889, Bibo Road Shanghai, 201203, China Email: lizhong.jin@zte.com.cn Kebo Liu Nokia Siemens Networks 1122 North Qinzhou Road Shanghai, 200233, China Email: kebo.liu@nsn.com Jin & Liu Expires January 3, 2011 [Page 13]