Network Working Group L. Jin Internet-Draft ZTE Intended status: Standards Track K. Liu Expires: September 15, 2011 Nokia Siemens S. Kini Ericsson March 14, 2011 Leaf discovery mechanism for mLDP based P2MP/MP2MP LSP draft-jin-mpls-mldp-leaf-discovery-02.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.ietf-pwe3-p2mp-pw], VPLS multicast [I-D.ietf-l2vpn-vpls-mcast], L3VPN multicast [I-D.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 September 15, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Jin, et al. Expires September 15, 2011 [Page 1] Internet-Draft draft-jin-mpls-mldp-leaf-discovery March 2011 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the 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. Node operation . . . . . . . . . . . . . . . . . . . . 6 4.2. Leaf discovery mechanism based on MP-BGP . . . . . . . . . 6 4.2.1. mLDP leaf NLRI . . . . . . . . . . . . . . . . . . . . 7 4.2.2. Node operation . . . . . . . . . . . . . . . . . . . . 7 5. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7.1. MP-BGP . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative references . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Jin, et al. Expires September 15, 2011 [Page 2] Internet-Draft draft-jin-mpls-mldp-leaf-discovery March 2011 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.ietf-pwe3-p2mp-pw], VPLS multicast [I-D.ietf-l2vpn-vpls-mcast], L3VPN multicast [I-D.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.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.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, et al. Expires September 15, 2011 [Page 3] Internet-Draft draft-jin-mpls-mldp-leaf-discovery March 2011 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.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.ietf-l3vpn-2547bis-mcast] section 9.1.1. 2.3. Application using T-LDP [I-D.ietf-pwe3-p2mp-pw] describes the P2MP PW setup and signaling mechanism. P2MP PW needs P2MP LSP to do multiplexing/demultiplexing [I-D.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, et al. Expires September 15, 2011 [Page 4] Internet-Draft draft-jin-mpls-mldp-leaf-discovery March 2011 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, without requiring additional session overload. 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.ietf-l2vpn-vpls-mcast], L3VPN Multicast [I-D.ietf-l3vpn-2547bis-mcast] may use leaf discovery mechanism based on MP-BGP. Jin, et al. Expires September 15, 2011 [Page 5] Internet-Draft draft-jin-mpls-mldp-leaf-discovery March 2011 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 [I-D.ietf-mpls-ldp-p2mp] A LDP Label mapping message on the T-LDP session to the root with the MP FEC Element is used to convey the addition of the leaf membership to the root. The implicit NULL label is used to indicate that the mapping is from a leaf node. The Label Withdraw message is used to convey the deletion of the leaf membership to the root. 4.1.1. 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. 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 label map message with MP FEC to its root node. When the root node receives the LDP label map message over T-LDP session with MP FEC, 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 LDP label withdraw message with MP FEC to its root node. When the root node receives the LDP label withdraw message over T-LDP with MP FEC, it will delete the leaf node information associated with the specified P2MP/MP2MP LSP locally. 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. Jin, et al. Expires September 15, 2011 [Page 6] Internet-Draft draft-jin-mpls-mldp-leaf-discovery March 2011 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 1 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)). 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 Jin, et al. Expires September 15, 2011 [Page 7] Internet-Draft draft-jin-mpls-mldp-leaf-discovery March 2011 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 As recommended in section 4, leaf discovery will reuse the same signaling session as application, and will not setup additional sessions. 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. 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. 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. Jin, et al. Expires September 15, 2011 [Page 8] Internet-Draft draft-jin-mpls-mldp-leaf-discovery March 2011 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] Chandrasekeran, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. 9.2. Informative References [I-D.ietf-l2vpn-vpls-mcast] Aggarwal, R., Kamite, Y., Fang, L., and Y. Rekhter, "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-08 (work in progress), October 2010. [I-D.ietf-l3vpn-2547bis-mcast] Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10 (work in progress), January 2010. [I-D.ietf-mpls-ldp-p2mp] Minei, I., Wijnands, I., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to- Multipoint and Multipoint-to-Multipoint Label Switched Paths", draft-ietf-mpls-ldp-p2mp-12 (work in progress), February 2011. [I-D.ietf-pwe3-p2mp-pw] Jin, et al. Expires September 15, 2011 [Page 9] Internet-Draft draft-jin-mpls-mldp-leaf-discovery March 2011 Martini, L., Boutros, S., Sivabalan, S., Konstantynowicz, M., Vecchio, G., Nadeau, T., JOUNAY, F., Niger, P., Kamite, Y., Jin, L., Vigoureux, M., Ciavaglia, L., and S. Delord, "Signaling Root-Initiated Point-to-Multipoint Pseudowires using LDP", draft-ietf-pwe3-p2mp-pw-02 (work in progress), March 2011. [I-D.ietf-pwe3-p2mp-pw-requirements] Heron, G., Wang, L., Aggarwal, R., Vigoureux, M., Bocci, M., Jin, L., JOUNAY, F., Niger, P., Kamite, Y., DeLord, S., and L. Martini, "Requirements for Point-to-Multipoint Pseudowire", draft-ietf-pwe3-p2mp-pw-requirements-03 (work in progress), August 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 Sriganesh Kini Ericsson 300 Holger Way San Jose, CA 95134 Email: sriganesh.kini@ericsson.com Jin, et al. Expires September 15, 2011 [Page 10]