Network Working Group Z. Li Internet-Draft Q. Zhao Intended status: Informational Huawei Technologies Expires: April 19, 2016 T. Yang China Mobile R. Raszuk Individual L. Fang Microsoft October 17, 2015 Usecases of MPLS Global Label draft-li-mpls-global-label-usecases-03 Abstract As the MPLS technologies develop, MPLS label is not only used with the local meaning which is always be understood by the upstream node and the downstream node, but also used with the global meaning which can be understood by all nodes or part of nodes in the network. The document defines the latter as the global label and proposes the possible use cases of global label. In these usecases MPLS global label can be used for location identification, VPN identification, segment routing, etc. Requirements Language 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]. 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 April 19, 2016. Li, et al. Expires April 19, 2016 [Page 1] Internet-Draft Usecases of MPLS Global Label October 2015 Copyright Notice Copyright (c) 2015 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Location Identification . . . . . . . . . . . . . . . . . 3 3.2. VPN Identification . . . . . . . . . . . . . . . . . . . 4 3.2.1. Flow Label of VPN LSP . . . . . . . . . . . . . . . . 4 3.2.2. Aggregate MVPN/VPLS over Single P-Tunnel . . . . . . 5 3.3. Segment Routing . . . . . . . . . . . . . . . . . . . . . 5 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction In the traditional MPLS architecture, MPLS label is always distributed from the downstream node to the upstream node by LDP, RSVP-TE and MP-BGP. These label mappings always have the local meaning which can only be understood by the upstream node and the downstream node. As the MPLS technologies develop, there proposes possible usecases in which MPLS label mapping can be advertised to all nodes or part of nodes in the network. That is, the meaning of the label mapping will be understood by all nodes or part of nodes in the network other than the local upstream node and downstream node. This document defines such type of MPLS label as global label as the opposite of local label. Li, et al. Expires April 19, 2016 [Page 2] Internet-Draft Usecases of MPLS Global Label October 2015 In the MPLS world there are another pair of label related concepts: per-platform label space [RFC3031]and context-specific label space[RFC5331]. According to [RFC3031] MPLS local label can be allocated from per-platform label space and per-interface label space (in [RFC5331], per-interface label space is generalized as one type of context-specific label space). MPLS global label can also be allocated from per-platform label space or context-specific label space. The document proposes the possible usecases of MPLS global label. In these usecases MPLS global label can be used for location identification, VPN identification, segment routing, etc. 2. Terminology CE: Customer Edge MP2P: Multi-Point to Point MP2MP: Multi-point to Multi-point MVPN: Multicast VPN P2MP: Point to Multi-Point P2P: Point to Point PE: Provider Edge 3. Use Cases 3.1. Location Identification [I-D.bryant-mpls-flow-ident] and [I-D.bryant-mpls-synonymous-flow-labels] propose the challenge of the measurement of packet loss for the multi-point to point LSP. In this case the same label is normally used by multiple ingress or upstream LSRs for specific prefixes and hence source identification is not possible by inspection of the top label by the egress LSRs. Thus [I-D.bryant-mpls-synonymous-flow-labels] proposes the synonymous flow label to be used to introduce some source specific information encapsulated in the packet to identify packet batches from a specific source. MPLS LDP LSP is one type of multi-point to point LSP. As the network convergence develops, MPLS LDP network needs to interwork with MPLS TE/MPLS-TP network and unified MPLS OAM becomes the realistic requirement. In this usecase, MPLS global label can be allocated for Li, et al. Expires April 19, 2016 [Page 3] Internet-Draft Usecases of MPLS Global Label October 2015 each network node and advertised in the network. When implement the measurement of packet loss for LDP LSP, such MPLS global label can be used as the flow label to identify the source node of the LDP LSP. When the destination receives the packets it can differentiate flows from specific source node based on the advertised global label binding information for network nodes. In this usecase, MPLS global label is used as the unique identification of source nodes in the network and may save the complex flow label negotiation process between the source node and the destination node. 3.2. VPN Identification MPLS global label can be allocated for VPN and advertised in the network. In this usecase, MPLS global label is used as the unique identification of VPN in the network and can be used for multiple purposes. 3.2.1. Flow Label of VPN LSP BGP VPN LSP is another type of multi-point to point LSP which faces the challenge of the measurement of packet loss proposed by [I-D.bryant-mpls-flow-ident] and [I-D.bryant-mpls-synonymous-flow-labels]. In this usecase, the flow label should be introduced to identfication of the source VPN. There are two possible ways to use global label as the flow label: Option 1: The global label is allocated for the same VPN on all PE nodes and advertised in the network. And global labels can be allocated for PE nodes and advertised in the network. Then the flow label should be the source PE label + the VPN label shown in the figure 1. +-----------------+ | | +-----------------+ \ | Source PE | | | -------\ | Global Label | | Flow Label | -------/ +-----------------+ | | / | | +-----------------+ | VPN | | Label | +-----------------+ Figure 1: Flow Label using Two Layers of Global Label Option 2: The global label is allocated directly for source VPN (ideentified by the pair of { Source PE, VPN }) and advertised in the network. We call such label as Source VPN label. The flow label should be the source VPN label shown in the figure 2. Li, et al. Expires April 19, 2016 [Page 4] Internet-Draft Usecases of MPLS Global Label October 2015 +-----------------+ \ +-----------------+ | | -------\ | | | Flow Label | -------/ | Source VPN | | | / | Global Label | +-----------------+ +-----------------+ Figure 2: Flow Label using One Layer of Global Label No matter option 1 or option 2 is adopted, when the destination receives the packets it can differentiate flows from specific source VPN based on the advertised global label binding information. 3.2.2. Aggregate MVPN/VPLS over Single P-Tunnel In BGP-base Multicast VPN ( [RFC6513]) and VPLS Multicast( [RFC7117]), in order to implement aggregating multiple MVPN/VPLS Instances on a single P-Tunnel (i.e. sharing one P2MP LSP) , context- specific label is introduced to identify the MVPN/VPLS instance and the label binding is allocated by the root PE and advertised to the leaf PEs. In this usecase the context-specific label is one type of global label to uniquely identify the MVPN/VPLS instance in the network. The context-specific label can solve the issue of aggregating multiple MVPNs or VPLS instances over a single P2MP LSP. But if the MP2MP LSP is adopted for aggregating multiple MVPN/VPLS instances the solution does not work since there are multiple root PEs which may allocate the same context-specific label for different MVPN/VPLS instances. In order to solve the issue the global label can be allocated to the same MVPN/VPLS instance on all PEs and advertised in the network. Then the global label will become the unique identification of VPN instance in the network. When aggregating multiple MVPNs or VPLS instances over one MP2MP LSP, the corresponding MPLS global label binding with the MVPN/VPLS instance can be encapsulated by the root PE. Then the leaf PEs can determine the MVPN or VPLS instance the received packets belong to based on the advertised global label binding information for MVPN/VPLS instances. The solution can provide the unified solution for aggregating multiple MVPN/VPLS instances over P2MP LSP and MP2MP LSP. And the solution can save the complex control plane and forwarding plane process of context-specific label. 3.3. Segment Routing Segment Routing [I-D.ietf-spring-segment-routing] is introduced to leverage the source routing paradigm for traffic engineering, fast re-route, etc. A node can steer a packet through an ordered list of segments. A segment can represent any instruction, topological or Li, et al. Expires April 19, 2016 [Page 5] Internet-Draft Usecases of MPLS Global Label October 2015 service-based. Segment Routing can be directly applied to the MPLS architecture with no change on the forwarding plane in which a segment can be encoded as an MPLS label and an ordered list of segments can be encoded as a stack of labels. Segment Routing [I-D.ietf-spring-segment-routing] introduces some segments such as node segment, adjacency segment, etc. SR Global Block (SRGB) is also introduced for allocation of segment. In the MPLS architecture, SRGB is the set of local labels reserved for global segments. When the global segment index is advertised, it can be transited to MPLS label based on the SRGB. According to [I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-isis-segment-routing-extensions] MPLS global label binding information can also be directly advertised in the network. For example, in the section 2.1 of [I-D.ietf-ospf-segment-routing-extensions], when the Length field of SID/Label Sub-TLV is set as 3, it will represent the label which can be flooded in the whole network. By this method MPLS global label can be directly allocated for specific node or adjacency, etc. and advertised in the network. The solution can save the complex process of SRGB advertisement and transition from the global Segment ID to MPLS label. 4. Discussion In the MPLS world, we can adopt the dichotomy to divide it into per- platform label space and context-specific label space. MPLS World +-----------------+-----------------+ | | | | Per-Platform | Context-Specific| | Label Space | Label Space | | | | +-----------------+-----------------+ When we adopt another dichotomy to divide the MPLS world into local label and global label, we may face more challenges. Li, et al. Expires April 19, 2016 [Page 6] Internet-Draft Usecases of MPLS Global Label October 2015 MPLS World Local Label vs. Global Label +------------------------------+--------------------------------------+ | | Special Purpose Label (RFC 7274) | | |--------------------------------------+ | | MPLS Upstream Label Assignment | | | /Context-Specific Label Space | | | (RFC 5331) | | |--------------------------------------+ | LDP (RFC 5036) | Entropy Label (RFC 6790) | | RSVP-TE (RFC 3209) | Flow Label (RFC 6391) | | BGP LSP (RFC 3107) |--------------------------------------+ | L3VPN (RFC 4364) | BGP-base VPLS (RFC 4761) | | LDP-based L2VPN (RFC 4762) | Segment Routing | | EVPN (RFC 7432) | (draft-ietf-spring-segment-routing) | | +--------------------------------------+ | | Domain-Wide Label | | | (Usecases: Synonymous Label/ | | | Segment Routing, etc.) | +---------------------------------------------------------------------+ Figure 3: Division of MPLS World Using Local Label and Global Label In the figure 3, we can easily understand the local label using for LDP, RSVP-TE, label BGP, L3VPN, LDP-based L2VPN, EVPN,etc. But for the opposite of these applications there may be many usecases which are different from each other, but share the common characteristic that the label meaning can be understood by all network nodes or part of network nodes instead of only the local downstream nodes and upstream nodes for which in this document such lable is defined as global label : -- For special purpose labels, their meaning can be understood by all nodes in the MPLS network. Should they belong to global label? -- For MPLS upstream label assignment in context-specific label space, all downstream nodes can understand the meaning of the label allocated by the upstream node binding for specific MVPN/VPLS instance. We can see the root PE as one type to central controlled node to allocate label to all leaf nodes. And thinking about the uniqueness of the context determine by the shared P-tunnel, these labels in fact are also unique in the network. Should they belong to global label? -- For entropy label and flow label, the label is calculated by the ingress node based on specific hash algorithms which is totally different from the local label distributed in the MPLS control plane. Li, et al. Expires April 19, 2016 [Page 7] Internet-Draft Usecases of MPLS Global Label October 2015 And all nodes along the path will parse the label and according to the uniform meaning to use the label for ECMP. But the label values can be duplicate since they are calculated by different ingress nodes. Should they belong to global label? -- For BGP-based VPLS and Segment Routing, they can adopt the local label block. But they introduce the global ID and transit them into the local label. Especially for segment routing, when all nodes in the network adopts the same SRGB, the global segment ID is easily transited to a unique global label value in the network. Should they belong to global label? -- This document proposes some usecases to directly allocate the unique label value and advise the label binding in the network. Should they be directly called as global label or Domain-Wide label as one type of global label? Since above applications which are different from the traditional MPLS local label, can we define all of them as global label or define some of them as global label and bring some use cases to the local label field? Or maybe such dichotomy using local label and global label does not exist. 5. IANA Considerations This document makes no request of IANA. 6. Security Considerations TBD. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 7.2. Informative References [I-D.bryant-mpls-flow-ident] Bryant, S., Pignataro, C., Chen, M., Li, Z., and G. Mirsky, "MPLS Flow Identification", draft-bryant-mpls- flow-ident-02 (work in progress), September 2015. Li, et al. Expires April 19, 2016 [Page 8] Internet-Draft Usecases of MPLS Global Label October 2015 [I-D.bryant-mpls-synonymous-flow-labels] Bryant, S., Swallow, G., Sivabalan, S., Mirsky, G., Chen, M., and Z. Li, "RFC6374 Synonymous Flow Labels", draft- bryant-mpls-synonymous-flow-labels-01 (work in progress), July 2015. [I-D.ietf-isis-segment-routing-extensions] Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS Extensions for Segment Routing", draft-ietf-isis-segment- routing-extensions-05 (work in progress), June 2015. [I-D.ietf-ospf-segment-routing-extensions] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", draft-ietf-ospf-segment- routing-extensions-05 (work in progress), June 2015. [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and r. rjs@rob.sh, "Segment Routing Architecture", draft- ietf-spring-segment-routing-06 (work in progress), October 2015. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, . [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, . [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, . Li, et al. Expires April 19, 2016 [Page 9] Internet-Draft Usecases of MPLS Global Label October 2015 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, . [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, . [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August 2008, . [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network", RFC 6391, DOI 10.17487/RFC6391, November 2011, . [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, . [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, . [RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and C. Kodeboniya, "Multicast in Virtual Private LAN Service (VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014, . [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating and Retiring Special-Purpose MPLS Labels", RFC 7274, DOI 10.17487/RFC7274, June 2014, . [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . Li, et al. Expires April 19, 2016 [Page 10] Internet-Draft Usecases of MPLS Global Label October 2015 Authors' Addresses Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Quintin Zhao Huawei Technologies 125 Nagog Technology Park Acton, MA 01719 US Email: quintin.zhao@huawei.com Tianle Yang China Mobile 32, Xuanwumenxi Ave. Beijing 01719 China Email: yangtianle@chinamobile.com Robert Raszuk Individual Email: robert@raszuk.net Luyuan Fang Microsoft 5600 148th Ave NE Redmond, WA 98052 USA Email: lufang@microsoft.com Li, et al. Expires April 19, 2016 [Page 11]