< draft-li-mpls-global-label-usecases-02.txt		draft-li-mpls-global-label-usecases-03.txt >
	Network Working Group Z. Li		Network Working Group Z. Li
	Internet-Draft Q. Zhao		Internet-Draft Q. Zhao
	Intended status: Informational Huawei Technologies		Intended status: Informational Huawei Technologies
	Expires: January 4, 2015 T. Yang		Expires: April 19, 2016 T. Yang
	China Mobile		China Mobile
	R. Raszuk		R. Raszuk
	Individual		Individual
	July 3, 2014		L. Fang
			Microsoft
			October 17, 2015
	Use Cases of MPLS Global Label		Usecases of MPLS Global Label
	draft-li-mpls-global-label-usecases-02		draft-li-mpls-global-label-usecases-03
	Abstract		Abstract
	As the SDN(Service-Driven Network) technology develops, MPLS global		As the MPLS technologies develop, MPLS label is not only used with
	label has been proposed for new solutions. The document proposes		the local meaning which is always be understood by the upstream node
	possible use cases of MPLS global label. In these use cases MPLS		and the downstream node, but also used with the global meaning which
	global label can be used as identification of the location, the		can be understood by all nodes or part of nodes in the network. The
	service and the network in different application scenarios.		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		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 49 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 4, 2015.		This Internet-Draft will expire on April 19, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2015 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Identification of Location . . . . . . . . . . . . . . . 3		3.1. Location Identification . . . . . . . . . . . . . . . . . 3
	3.1.1. VPLS Multicast over MP2MP LSP . . . . . . . . . . . . 3		3.2. VPN Identification . . . . . . . . . . . . . . . . . . . 4
	3.1.2. Segment-Based EVPN . . . . . . . . . . . . . . . . . 4		3.2.1. Flow Label of VPN LSP . . . . . . . . . . . . . . . . 4
	3.1.3. MPLS OAM for LDP LSP . . . . . . . . . . . . . . . . 5		3.2.2. Aggregate MVPN/VPLS over Single P-Tunnel . . . . . . 5
	3.2. Identification of Services . . . . . . . . . . . . . . . 5		3.3. Segment Routing . . . . . . . . . . . . . . . . . . . . . 5
	3.2.1. Identification of MVPN/VPLS . . . . . . . . . . . . . 5		4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.2.2. Local Protection of PE Node . . . . . . . . . . . . . 5		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	3.2.3. Service Chaining . . . . . . . . . . . . . . . . . . 6		6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	3.3. Identification of Network . . . . . . . . . . . . . . . . 6		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.3.1. Segment Routing . . . . . . . . . . . . . . . . . . . 6		7.1. Normative References . . . . . . . . . . . . . . . . . . 8
	3.3.2. MPLS Network Virtualization . . . . . . . . . . . . . 7		7.2. Informative References . . . . . . . . . . . . . . . . . 8
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	6.1. Normative References . . . . . . . . . . . . . . . . . . 7
	6.2. Informative References . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	Currently MPLS label always has local meaning. That is, MPLS label		In the traditional MPLS architecture, MPLS label is always
	is always allocated by the downstream node to the upstream node and		distributed from the downstream node to the upstream node by LDP,
	the meaning of the MPLS label is only understood by the neighboring		RSVP-TE and MP-BGP. These label mappings always have the local
	upstream node and downstream node. As the SDN concept is introduced,		meaning which can only be understood by the upstream node and the
	the MPLS global label mechanism are being proposed for new solutions		downstream node. As the MPLS technologies develop, there proposes
	based on the label binding which should be understood by all nodes or		possible usecases in which MPLS label mapping can be advertised to
	part of nodes in the network. This document proposes possible use		all nodes or part of nodes in the network. That is, the meaning of
	cases for MPLS global label which can be used as identification of		the label mapping will be understood by all nodes or part of nodes in
	the location, the service and the network in different application		the network other than the local upstream node and downstream node.
	scenarios.		This document defines such type of MPLS label as global label as the
			opposite of local label.
	2. Terminology		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.
	BUM: Broadcast, Unknown unicast, or Multicast		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.
	B-MAC: Backbone MAC Address		2. Terminology
	CE: Customer Edge		CE: Customer Edge
	C-MAC: Customer/Client MAC Address		MP2P: Multi-Point to Point
	DF: Designated Forwarder		MP2MP: Multi-point to Multi-point
	ES: Ethernet Segment		MVPN: Multicast VPN
	EVPN: Ethernet VPN		P2MP: Point to Multi-Point
	ICCP: Inter-chassis Communication Protocol		P2P: Point to Point
	MP2MP: Multi-Point to Multi-Point		PE: Provider Edge
	MP2P: Multi-Point to Point		3. Use Cases
	MVPN: Multicast VPN		3.1. Location Identification
	PBB: Provider Backbone Bridge		[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.
	P2MP: Point to Multi-Point		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
			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.
	P2P: Point to Point		3.2. VPN Identification
	PE: Provider Edge		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.
	S-EVPN: Segment-based EVPN		3.2.1. Flow Label of VPN LSP
	3. Use Cases		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:
	3.1. Identification of Location		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.
	3.1.1. VPLS Multicast over MP2MP LSP		+-----------------+
			| |
			+-----------------+ \ | Source PE |
			| | -------\ | Global Label |
			| Flow Label | -------/ +-----------------+
			| | / | |
			+-----------------+ | VPN |
			| Label |
			+-----------------+
	[I-D.ietf-l2vpn-vpls-mcast] defines the VPLS multicast mechanism only		Figure 1: Flow Label using Two Layers of Global Label
	based on P2MP LSPs. In this case BUM (Broadcast, Unknown unicast, or
	Multicast) traffic SHOULD be transported uniformly through P2MP LSPs.
	If MP2MP LSP is introduced to transport BUM traffic, there exists
	issue for unknown unicast traffic. VPLS needs to learn MAC address
	through broadcast or multicast of unknown unicast traffic. PEs of a
	specific VSI can learn the source PE of the MAC address according to
	the P2MP LSP which transports the unknown unicast traffic. If
	unknown unicast traffic is transported by the MP2MP LSPEV, the MAC
	can be learned, but the source PE for the MAC cannot be determined
	since there is no determined root node for the MP2MP LSP. So if the
	MP2MP LSP is used it has to separate the BUM traffic into two parts:
	the broadcast and multicast traffic can be transported by the MP2MP
	LSP; the unknown unicast traffic has to be transported by the P2MP
	LSP or P2P PW. The process is complex and hard to be provisioned.
	MPLS global label can be introduced as the identification of the		Option 2: The global label is allocated directly for source VPN
	source PE and the binding between the MPLS global label and the PE is		(ideentified by the pair of { Source PE, VPN }) and advertised in the
	advertised to all PEs. When the unknown unicast traffic is sent by		network. We call such label as Source VPN label. The flow label
	the source PE, the MPLS global label for the identification of the PE		should be the source VPN label shown in the figure 2.
	could be encapsulated firstly. Thus even if the MP2MP LSP is used,
	the remote PEs can learn the source PE for the learned MAC address
	based on the received MPLS global label.
	3.1.2. Segment-Based EVPN		+-----------------+ \ +-----------------+
			| | -------\ | |
			| Flow Label | -------/ | Source VPN |
			| | / | Global Label |
			+-----------------+ +-----------------+
	EVPN( [I-D.ietf-l2vpn-evpn]) introduces a solution for multipoint		Figure 2: Flow Label using One Layer of Global Label
	L2VPN services. Split horizon is an important feature in EVPN to
	cope with the challenge proposed by BUM traffic. In order to achieve
	the split horizon function, every BUM packet originating from a non-
	DF PE is encapsulated with an ESI label that identifies the Ethernet
	segment of origin (i.e. the segment from which the frame entered the
	EVPN network). The existing ESI label allocation solutions are
	different for the different transport tunnel technologies: downstream
	ESI label assignment for ingress replication and upstream ESI label
	assignment for P2MP LSP. For MP2MP LSP, there is no solutions of ESI
	label assignment for split horizon function yet.
	[I-D.li-l2vpn-segment-evpn] proposes an enhanced EVPN mechanism,
	segment-based EVPN (S-EVPN). It introduces the global label to
	identify the Ethernet Segment which can also be used as the ESI label
	for split horizon. Thus no matter what tunnel technology (including
	MP2MP LSP) is adopted to transport BUM traffic, there will be
	unifying ESI label assignment mechanism for split horizon.
	Besides unifying split horizon function in EVPN, S-EVPN can also be		No matter option 1 or option 2 is adopted, when the destination
	used as an alternative solution in the central control environment		receives the packets it can differentiate flows from specific source
	for PBB-EVPN ([I-D.ietf-l2vpn-pbb-evpn]) without the necessity of		VPN based on the advertised global label binding information.
	implementing PBB functionality on PE. PBB-EVPN
	[I-D.ietf-l2vpn-pbb-evpn] adopts B-MAC to implement C-MACs
	summarization and PEs in PBB-EVPN can determine the source PE through
	B-MAC in the PBB encapsulation for C-MACs which are learned in the
	data plane. S-EVPN introduces MPLS global label for each Ethernet
	Segment (ES) in an EVPN. It inserts the source ES label into packets
	at ingress PE and learns C-MAC and source ES label binding at egress
	PE. Through the source ES label the egress PE can determine the
	source Ethernet Segment and corresponding source PE for the learned
	C-MAC. Owing to the MPLS global label the S-EVPN solution can adopt
	the unified MPLS method to satisfy the requirements of PBB-EVPN.
	3.1.3. MPLS OAM for LDP LSP		3.2.2. Aggregate MVPN/VPLS over Single P-Tunnel
	MPLS OAM mechanism has been defined for MPLS TE and MPLS-TP. MPLS TE		In BGP-base Multicast VPN ( [RFC6513]) and VPLS Multicast(
	or MPLS-TP LSP adopts the point-to-point model which is easy to count		[RFC7117]), in order to implement aggregating multiple MVPN/VPLS
	the number of received packets for the specific LSP based on the MPLS		Instances on a single P-Tunnel (i.e. sharing one P2MP LSP) , context-
	label in the encapsulation if packet loss rate need to be calculated		specific label is introduced to identify the MVPN/VPLS instance and
	for Performance Monitoring. As the network convergence develops,		the label binding is allocated by the root PE and advertised to the
	MPLS LDP network needs to interwork with MPLS TE/MPLS-TP network and		leaf PEs. In this usecase the context-specific label is one type of
	unified MPLS OAM becomes the realistic requirement. Owing to the		global label to uniquely identify the MVPN/VPLS instance in the
	MP2P(Multi-Point to Point) or MP2MP model of MPLS LDP LSP, it is		network.
	difficult for MPLS LDP to implement Performance Monitoring since it
	cannot count the number of the received packets based on the MPLS
	label in the encapsulation for a specific flow between two PEs. MPLS
	global label can be introduced to be used as the source label (Refer
	to [I-D.chen-mpls-source-label]) to identify the source PE and it can
	be encapsulated for the traffic transported by MPLS LDP LSP. Thus
	even if the outer MPLS LDP label is the same for flows from different
	PEs, the egress PE can differentiate flows from specific ingress PEs
	based on the encapsulated MPLS global label for Performance
	Monitoring.
	3.2. Identification of Services		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.2.1. Identification of MVPN/VPLS		3.3. Segment Routing
	In BGP-base Multicast VPN ( [RFC6513]) and VPLS Multicast(		Segment Routing [I-D.ietf-spring-segment-routing] is introduced to
	[I-D.ietf-l2vpn-vpls-mcast]), in order to implement aggregating		leverage the source routing paradigm for traffic engineering, fast
	multiple MVPNs or VPLS on a single P-Tunnel (i.e. sharing one P2MP		re-route, etc. A node can steer a packet through an ordered list of
	LSP) , MPLS global label can be introduced to identify the MVPN		segments. A segment can represent any instruction, topological or
	instance or the VPLS instance and the label binding is advertised to		service-based. Segment Routing can be directly applied to the MPLS
	all PEs. When aggregating multiple MVPN instances and VPLS instances		architecture with no change on the forwarding plane in which a
	over one P-tunnel, the corresponding MPLS global label binded with		segment can be encoded as an MPLS label and an ordered list of
	these VPN instances should be encapsulated. Then the egress PEs can		segments can be encoded as a stack of labels.
	determine the MVPN or VPLS instance based on the encapsulated MPLS
	global label after receive the packets through the P tunnel.
	3.2.2. Local Protection of PE Node		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.
	The local protection mechanisms for PE node such as		4. Discussion
	[I-D.ietf-pwe3-endpoint-fast-protection] and
	[I-D.zhang-l3vpn-label-sharing] have been proposed. If failure
	happens in the PE node, the service traffic to the primary PE node
	can be switched by the penultimate hop to the other backup PE. In
	order to achieve the object, MPLS global label can be introduced to
	identify the same L3VPN instance or L2VPN instance for multi-homed
	PEs. When forwarding packets for VPN service, the inner label in the
	encapsulation to identify the specific VPN can be replaced by the
	MPLS global label. If PE node failure happens, the traffic can
	directly switch to the backup LSP to the backup PE at the penultimate
	hop. It is only to change the out-layer tunnel label without having
	any extra process on the inner label.
	3.2.3. Service Chaining		In the MPLS world, we can adopt the dichotomy to divide it into per-
			platform label space and context-specific label space.
	With the deployment of service functions (such as firewalls, load		MPLS World
	balancers) in large-scale environments, the term service function
	chaining is used to describe the definition and instantiation of an
	ordered set of such service functions, and the subsequent "steering"
	of traffic flows through those service functions. The set of enabled
	service function chains reflect operator service offerings and is
	designed in conjunction with application delivery and service and
	network policy (Refer to [I-D.ietf-sfc-problem-statement]). The
	source packet routing mechanism can be used to implement service
	chaining in MPLS networks ([I-D.xu-spring-sfc-use-case]). MPLS
	global label can be introduced to identify the service functions and
	the label binding can be advertised in the network. Then the ingress
	node can compose the MPLS stacked path to steer packets through the
	required service function path for specific service flow.
	3.3. Identification of Network		+-----------------+-----------------+
			| | |
			| Per-Platform | Context-Specific|
			| Label Space | Label Space |
			| | |
			+-----------------+-----------------+
	MPLS is the basic technology to implement virtual networks. VPN can		When we adopt another dichotomy to divide the MPLS world into local
	be seen as a typical example to use the MPLS label to differentiate		label and global label, we may face more challenges.
	the virtual network instance. Now the virtual network technologies
	based on MPLS concentrate on the service layer such as L3VPN, L2VPN,
	MVPN, etc. New requirements on easy implementation of virtual
	network on the transport layer are being emerged. MPLS global label
	can also play an important role in the course of achieving the
	object.
	3.3.1. Segment Routing		MPLS World
	Segment Routing [I-D.filsfils-spring-segment-routing] is introduced		Local Label vs. Global Label
	to leverage the source routing paradigm for traffic engineering, fast		+------------------------------+--------------------------------------+
	re-route, etc. A node steers a packet through an ordered list of		| | Special Purpose Label (RFC 7274) |
	segments. A segment can represent any instruction, topological or		| |--------------------------------------+
	service-based. Segment Routing can be directly applied to the MPLS		| | MPLS Upstream Label Assignment |
	architecture with no change on the forwarding plane. A segment is		| | /Context-Specific Label Space |
	encoded as an MPLS label. An ordered list of segments is encoded as		| | (RFC 5331) |
	a stack of labels. In Segment Routing, the basic segments include		| |--------------------------------------+
	node segment and adjacency segment. A Node Segment represents the		| LDP (RFC 5036) | Entropy Label (RFC 6790) |
	shortest path to a node and Node segments must be globally unique		| RSVP-TE (RFC 3209) | Flow Label (RFC 6391) |
	within the network domain. That is, In the MPLS data plane		| BGP LSP (RFC 3107) |--------------------------------------+
	instantiation, MPLS global label is used to identify a specific Node		| L3VPN (RFC 4364) | BGP-base VPLS (RFC 4761) |
	Segment. In essence MPLS global label is to represent the		| LDP-based L2VPN (RFC 4762) | Segment Routing |
	virtualized nodes in the network.		| EVPN (RFC 7432) | (draft-ietf-spring-segment-routing) |
			| +--------------------------------------+
			| | Domain-Wide Label |
			| | (Usecases: Synonymous Label/ |
			| | Segment Routing, etc.) |
			+---------------------------------------------------------------------+
	3.3.2. MPLS Network Virtualization		Figure 3: Division of MPLS World Using Local Label and Global Label
	As the virtual network operators develop, it is desirable to provide		In the figure 3, we can easily understand the local label using for
	better network virtualization solutions to facilitate the service		LDP, RSVP-TE, label BGP, L3VPN, LDP-based L2VPN, EVPN,etc. But for
	provision. [I-D.li-mpls-network-virtualization-framework] introduces		the opposite of these applications there may be many usecases which
	the framework for MPLS network virtualization. In the framework,		are different from each other, but share the common characteristic
	MPLS global label can be used to identify the virtualized network		that the label meaning can be understood by all network nodes or part
	topology, nodes and links which can make up the virtual network.		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 :
	4. IANA Considerations		-- 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.
			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.		This document makes no request of IANA.
	5. Security Considerations		6. Security Considerations
	TBD.		TBD.
	6. References		7. References
	6.1. Normative References
	[I-D.li-l2vpn-segment-evpn]		7.1. Normative References
	Li, Z., Yong, L., and J. Zhang, "Segment-Based
	EVPN(S-EVPN)", draft-li-l2vpn-segment-evpn-01 (work in
	progress), February 2014.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
	6.2. Informative References		7.2. Informative References
	[I-D.chen-mpls-source-label]		[I-D.bryant-mpls-flow-ident]
	Chen, M., Xu, X., Li, Z., Fang, L., and G. Mirsky,		Bryant, S., Pignataro, C., Chen, M., Li, Z., and G.
	"MultiProtocol Label Switching (MPLS) Source Label",		Mirsky, "MPLS Flow Identification", draft-bryant-mpls-
	draft-chen-mpls-source-label-05 (work in progress), July		flow-ident-02 (work in progress), September 2015.
	2014.
	[I-D.filsfils-spring-segment-routing]		[I-D.bryant-mpls-synonymous-flow-labels]
	Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,		Bryant, S., Swallow, G., Sivabalan, S., Mirsky, G., Chen,
	Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,		M., and Z. Li, "RFC6374 Synonymous Flow Labels", draft-
	Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,		bryant-mpls-synonymous-flow-labels-01 (work in progress),
	"Segment Routing Architecture", draft-filsfils-spring-		July 2015.
	segment-routing-03 (work in progress), June 2014.
	[I-D.ietf-l2vpn-evpn]		[I-D.ietf-isis-segment-routing-extensions]
	Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J.		Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
	Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn-		Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS
	evpn-07 (work in progress), May 2014.		Extensions for Segment Routing", draft-ietf-isis-segment-
			routing-extensions-05 (work in progress), June 2015.
	[I-D.ietf-l2vpn-pbb-evpn]		[I-D.ietf-ospf-segment-routing-extensions]
	Sajassi, A., Salam, S., Bitar, N., Isaac, A., Henderickx,		Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
	W., and L. Jin, "PBB-EVPN", draft-ietf-l2vpn-pbb-evpn-07		Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
	(work in progress), June 2014.		Extensions for Segment Routing", draft-ietf-ospf-segment-
			routing-extensions-05 (work in progress), June 2015.
	[I-D.ietf-l2vpn-vpls-mcast]		[I-D.ietf-spring-segment-routing]
	Aggarwal, R., Rekhter, Y., Kamite, Y., and L. Fang,		Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
	"Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-16 (work		and r. rjs@rob.sh, "Segment Routing Architecture", draft-
	in progress), November 2013.		ietf-spring-segment-routing-06 (work in progress), October
			2015.
	[I-D.ietf-pwe3-endpoint-fast-protection]		[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
	Shen, Y., Aggarwal, R., Henderickx, W., and Y. Jiang, "PW		Label Switching Architecture", RFC 3031,
	Endpoint Fast Failure Protection", draft-ietf-pwe3-		DOI 10.17487/RFC3031, January 2001,
	endpoint-fast-protection-00 (work in progress), December		<http://www.rfc-editor.org/info/rfc3031>.
	2013.
	[I-D.ietf-sfc-problem-statement]		[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
	Quinn, P. and T. Nadeau, "Service Function Chaining		BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001,
	Problem Statement", draft-ietf-sfc-problem-statement-07		<http://www.rfc-editor.org/info/rfc3107>.
	(work in progress), June 2014.
	[I-D.li-mpls-network-virtualization-framework]		[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
	Li, Z. and M. Li, "Framework of Network Virtualization		and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
	Based on MPLS Global Label", draft-li-mpls-network-		Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
	virtualization-framework-00 (work in progress), October		<http://www.rfc-editor.org/info/rfc3209>.
	2013.
	[I-D.xu-spring-sfc-use-case]		[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
	Xu, X., Li, Z., Shah, H., and L. Contreras, "Service		Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
	Function Chaining Use Case for SPRING", draft-xu-spring-		2006, <http://www.rfc-editor.org/info/rfc4364>.
	sfc-use-case-02 (work in progress), June 2014.
	[I-D.zhang-l3vpn-label-sharing]		[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
	Zhang, M., Zhou, P., and R. White, "Label Sharing for Fast		LAN Service (VPLS) Using BGP for Auto-Discovery and
	PE Protection", draft-zhang-l3vpn-label-sharing-02 (work		Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
	in progress), June 2014.		<http://www.rfc-editor.org/info/rfc4761>.
	[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP		[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
	VPNs", RFC 6513, February 2012.		LAN Service (VPLS) Using Label Distribution Protocol (LDP)
			Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
			<http://www.rfc-editor.org/info/rfc4762>.
			[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
			"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
			October 2007, <http://www.rfc-editor.org/info/rfc5036>.
			[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,
			<http://www.rfc-editor.org/info/rfc5331>.
			[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,
			<http://www.rfc-editor.org/info/rfc6391>.
			[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
			BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
			2012, <http://www.rfc-editor.org/info/rfc6513>.
			[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,
			<http://www.rfc-editor.org/info/rfc6790>.
			[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,
			<http://www.rfc-editor.org/info/rfc7117>.
			[RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating
			and Retiring Special-Purpose MPLS Labels", RFC 7274,
			DOI 10.17487/RFC7274, June 2014,
			<http://www.rfc-editor.org/info/rfc7274>.
			[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, <http://www.rfc-editor.org/info/rfc7432>.
	Authors' Addresses		Authors' Addresses
	Zhenbin Li		Zhenbin Li
	Huawei Technologies		Huawei Technologies
	Huawei Bld., No.156 Beiqing Rd.		Huawei Bld., No.156 Beiqing Rd.
	Beijing 100095		Beijing 100095
	China		China
	Email: lizhenbin@huawei.com		Email: lizhenbin@huawei.com
	skipping to change at line 411 ¶		skipping to change at page 11, line 35 ¶
	32, Xuanwumenxi Ave.		32, Xuanwumenxi Ave.
	Beijing 01719		Beijing 01719
	China		China
	Email: yangtianle@chinamobile.com		Email: yangtianle@chinamobile.com
	Robert Raszuk		Robert Raszuk
	Individual		Individual
	Email: robert@raszuk.net		Email: robert@raszuk.net
			Luyuan Fang
			Microsoft
			5600 148th Ave NE
			Redmond, WA 98052
			USA
			Email: lufang@microsoft.com
End of changes. 65 change blocks.
	260 lines changed or deleted		348 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/