wdiff draft-li-mpls-global-label-usecases-02.txt draft-li-mpls-global-label-usecases-03.txt

Network Working Group Z. Li
Internet-Draft Q. Zhao
Intended status: Informational Huawei Technologies
Expires: January 4, 2015 April 19, 2016 T. Yang
China Mobile
R. Raszuk
Individual
July 3, 2014

Use Cases
L. Fang
Microsoft
October 17, 2015

Usecases of MPLS Global Label
draft-li-mpls-global-label-usecases-02
draft-li-mpls-global-label-usecases-03

Abstract

As the SDN(Service-Driven Network) technology develops, MPLS global technologies develop, MPLS label has been proposed for new solutions. 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 MPLS global label. In these use cases usecases MPLS global
label can be used as identification of the location, the
service and the network in different application scenarios. 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 January 4, 2015. April 19, 2016.

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. Identification of Location Identification . . . . . . . . . . . . . . . 3
3.1.1. VPLS Multicast over MP2MP LSP . . . . . . . . . . . . 3
3.1.2. Segment-Based EVPN . . . . . . . . . . . . . . . . . 4
3.1.3. MPLS OAM for LDP LSP . . . . . . . . . . . . . . . . 5
3.2. VPN Identification of Services . . . . . . . . . . . . . . . 5
3.2.1. Identification of MVPN/VPLS . . . . . . . . . . . . . 5
3.2.2. Local Protection 4
3.2.1. Flow Label of PE Node . . . . . . . . VPN LSP . . . . . 5
3.2.3. Service Chaining . . . . . . . . . . . . 4
3.2.2. Aggregate MVPN/VPLS over Single P-Tunnel . . . . . . 6 5
3.3. Identification of Network . . Segment Routing . . . . . . . . . . . . . . 6
3.3.1. Segment Routing . . . . . . . 5
4. Discussion . . . . . . . . . . . . 6
3.3.2. MPLS Network Virtualization . . . . . . . . . . . . . 7
4. 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. 8
7.2. Informative References . . . . . . . . . . . . . . . . . 7 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 11

1. Introduction

Currently

In the traditional MPLS label always has local meaning. That is, architecture, MPLS label is always allocated by
distributed from the downstream node to the upstream node by LDP,
RSVP-TE and MP-BGP. These label mappings always have the local
meaning of the MPLS label is which can only be understood by the neighboring upstream node and the
downstream node. As the SDN concept is introduced,
the MPLS global technologies develop, there proposes
possible usecases in which MPLS label mechanism are being proposed for new solutions
based on mapping can be advertised to
all nodes or part of nodes in the network. That is, the meaning of
the label binding which should mapping will be understood by all nodes or part of nodes in
the network. network other than the local upstream node and downstream node.
This document proposes possible use
cases for defines such type of MPLS label as global label which can be used as identification of the location,
opposite of local label.

In the service 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 network in different application
scenarios. 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

BUM: Broadcast, Unknown unicast, or Multicast

B-MAC: Backbone MAC Address

CE: Customer Edge

C-MAC: Customer/Client MAC Address

DF: Designated Forwarder

ES: Ethernet Segment

EVPN: Ethernet VPN

ICCP: Inter-chassis Communication Protocol

MP2MP: Multi-Point to Multi-Point

MP2P: Multi-Point to Point

MP2MP: Multi-point to Multi-point

MVPN: Multicast VPN

PBB: Provider Backbone Bridge

P2MP: Point to Multi-Point

P2P: Point to Point

PE: Provider Edge

S-EVPN: Segment-based EVPN

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 Location

3.1.1. VPLS Multicast over MP2MP LSP

[I-D.ietf-l2vpn-vpls-mcast] defines the VPLS multicast mechanism only
based on P2MP LSPs.
measurement of packet loss for the multi-point to point LSP. In this
case BUM (Broadcast, Unknown unicast, or
Multicast) traffic SHOULD be transported uniformly through P2MP LSPs.
If MP2MP LSP the same label is introduced to transport BUM traffic, there exists
issue for unknown unicast traffic. VPLS needs to learn MAC address
through broadcast normally used by multiple ingress or multicast of unknown unicast traffic. PEs of a upstream
LSRs for specific VSI can learn the prefixes and hence source PE identification is not
possible by inspection of the MAC address according to
the P2MP LSP which transports the unknown unicast traffic. If
unknown unicast traffic is transported top label by the MP2MP LSPEV, egress LSRs. Thus
[I-D.bryant-mpls-synonymous-flow-labels] proposes the MAC
can synonymous flow
label to be learned, but the used to introduce some source PE for the MAC cannot be determined
since there is no determined root node for the MP2MP LSP. So if specific information
encapsulated in the
MP2MP packet to identify packet batches from a specific
source.

MPLS LDP LSP is used it has one type of multi-point to separate the BUM traffic into two parts:
the broadcast and multicast traffic can be transported by the MP2MP
LSP; point LSP. As the unknown unicast traffic has network
convergence develops, MPLS LDP network needs to be transported by the P2MP
LSP or P2P PW. The process is complex interwork with MPLS
TE/MPLS-TP network and hard to be provisioned. unified MPLS OAM becomes the realistic
requirement. In this usecase, MPLS global label can be introduced as the identification of the
source PE allocated for
each network node and advertised in the binding between network. When implement the
measurement of packet loss for LDP LSP, such MPLS global label and can be
used as the PE is
advertised flow label to all PEs. When the unknown unicast traffic is sent by identify the source PE, the MPLS global label for the identification node of the PE
could be encapsulated firstly. Thus even if LDP LSP.
When the MP2MP LSP is used, destination receives the remote PEs packets it can learn the differentiate flows
from specific source PE for the learned MAC address node based on the received MPLS advertised global label.

3.1.2. Segment-Based EVPN

EVPN( [I-D.ietf-l2vpn-evpn]) introduces a solution label
binding information for multipoint
L2VPN services. Split horizon is an important feature in EVPN to
cope with the challenge proposed by BUM traffic. network nodes. In order to achieve
the split horizon function, every BUM packet originating from a non-
DF PE is encapsulated with an ESI this usecase, MPLS global
label that identifies is used as the Ethernet
segment unique identification of origin (i.e. the segment from which source nodes in the frame entered
network and may save the
EVPN network). The existing ESI complex flow label allocation solutions are
different for negotiation process
between the different transport tunnel technologies: downstream
ESI label assignment for ingress replication source node 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 destination node.

3.2. VPN Identification

MPLS global label to
identify the Ethernet Segment which can also be used as allocated for VPN and advertised in the ESI
network. In this usecase, MPLS global 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 used as an alternative solution the unique
identification of VPN in the central control environment network and can be used for PBB-EVPN ([I-D.ietf-l2vpn-pbb-evpn]) without the necessity multiple
purposes.

3.2.1. Flow Label of
implementing PBB functionality on PE. PBB-EVPN
[I-D.ietf-l2vpn-pbb-evpn] adopts B-MAC VPN LSP

BGP VPN LSP is another type of multi-point to implement C-MACs
summarization and PEs in PBB-EVPN can determine point LSP which faces
the source PE through
B-MAC in challenge of the PBB encapsulation for C-MACs which are learned in measurement of packet loss proposed by
[I-D.bryant-mpls-flow-ident] and
[I-D.bryant-mpls-synonymous-flow-labels]. In this usecase, the
data plane. S-EVPN introduces MPLS global flow
label for each Ethernet
Segment (ES) in an EVPN. It inserts should be introduced to identfication of the source ES label into packets
at ingress PE and learns C-MAC and source ES VPN. There
are two possible ways to use global label binding at egress
PE. Through as the source ES flow label:

Option 1: The global label is allocated for the egress same VPN on all PE can determine the
source Ethernet Segment
nodes and corresponding source PE for the learned
C-MAC. Owing to advertised in the MPLS network. And global label the S-EVPN solution labels can adopt
the unified MPLS method to satisfy the requirements of PBB-EVPN.

3.1.3. MPLS OAM for LDP LSP

MPLS OAM mechanism has been defined be
allocated for MPLS TE PE nodes and MPLS-TP. MPLS TE
or MPLS-TP LSP adopts the point-to-point model which is easy to count
the number of received packets for advertised in the specific LSP based on network. Then the MPLS flow
label in the encapsulation if packet loss rate need to should be calculated
for Performance Monitoring. As the network convergence develops,
MPLS LDP network needs to interwork with MPLS TE/MPLS-TP network and
unified MPLS OAM becomes source PE label + the realistic requirement. Owing to VPN label shown in the
MP2P(Multi-Point to Point) or MP2MP model
figure 1.

+-----------------+
| |
+-----------------+ \ | Source PE |
| | -------\ | Global Label |
| Flow Label | -------/ +-----------------+
| | / | |
+-----------------+ | VPN |
| Label |
+-----------------+

Figure 1: Flow Label using Two Layers of MPLS LDP LSP, it Global Label

Option 2: The global label is
difficult allocated directly for MPLS LDP to implement Performance Monitoring since it
cannot count source VPN
(ideentified by the number pair of the received packets based on the MPLS
label { Source PE, VPN }) and advertised in the encapsulation for a specific
network. We call such label as Source VPN label. The flow between two PEs. MPLS
global label can be introduced to
should be used as the source VPN 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 shown in the outer MPLS LDP label figure 2.

+-----------------+ \ +-----------------+
| | -------\ | |
| 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 same for flows from different
PEs, destination
receives the egress PE packets it can differentiate flows from specific ingress PEs source
VPN based on the encapsulated MPLS advertised global label for Performance
Monitoring.

3.2. Identification of Services

3.2.1. Identification of binding information.

3.2.2. Aggregate MVPN/VPLS over Single P-Tunnel

In BGP-base Multicast VPN ( [RFC6513]) and VPLS Multicast(
[I-D.ietf-l2vpn-vpls-mcast]),
[RFC7117]), in order to implement aggregating multiple MVPNs or VPLS MVPN/VPLS
Instances on a single P-Tunnel (i.e. sharing one P2MP LSP) , MPLS global context-
specific label can be is introduced to identify the MVPN
instance or the VPLS MVPN/VPLS instance and
the label binding is allocated by the root PE and advertised to
all the
leaf PEs. When aggregating multiple MVPN instances and VPLS instances
over one P-tunnel, In this usecase the corresponding MPLS context-specific label is one type of
global label binded with
these VPN instances should be encapsulated. Then the egress PEs can
determine to uniquely identify the MVPN or VPLS MVPN/VPLS instance based on in the encapsulated MPLS
global
network.

The context-specific label after receive the packets through can solve the P tunnel.

3.2.2. Local Protection issue of PE Node

The local protection mechanisms for PE node such as
[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 aggregating
multiple MVPNs or VPLS instances over a single P2MP LSP. But if the primary PE node
can be switched by
MP2MP LSP is adopted for aggregating multiple MVPN/VPLS instances the penultimate hop to
solution does not work since there are multiple root PEs which may
allocate the other backup PE. same context-specific label for different MVPN/VPLS
instances. In order to achieve solve the issue the object, MPLS global label can be introduced
allocated to
identify the same L3VPN instance or L2VPN MVPN/VPLS instance for multi-homed
PEs. When forwarding packets for VPN service, the inner label on all PEs and advertised in
the
encapsulation to identify the specific VPN can be replaced by network. Then 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

With will become the deployment unique
identification of service functions (such as firewalls, load
balancers) in large-scale environments, the term service function
chaining is used to describe VPN instance in the definition and instantiation of an
ordered set of such service functions, and network. When aggregating
multiple MVPNs or VPLS instances over one MP2MP LSP, 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]).
corresponding MPLS global label can be introduced to identify the service functions and
the label binding with the MVPN/VPLS instance
can be advertised in encapsulated by the network. root PE. Then the ingress
node leaf PEs can compose the MPLS stacked path to steer packets through the
required service function path for specific service flow.

3.3. Identification of Network

MPLS is determine
the basic technology to implement virtual networks. VPN can
be seen as a typical example to use MVPN or VPLS instance the MPLS label received packets belong to differentiate
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
advertised global label binding information for MVPN/VPLS instances.
The solution can also play an important role in provide the course of achieving unified solution for aggregating
multiple MVPN/VPLS instances over P2MP LSP and MP2MP LSP. And the
object.

3.3.1.
solution can save the complex control plane and forwarding plane
process of context-specific label.

3.3. Segment Routing

Segment Routing [I-D.filsfils-spring-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 steers can steer a packet through an ordered list of
segments. A segment can represent any instruction, topological or
service-based. Segment Routing can be directly applied to the MPLS
architecture with no change on the forwarding plane. A plane in which a
segment is can be encoded as an MPLS label. An label and an ordered list of
segments is can be encoded as a stack of labels. In

Segment Routing, the basic Routing [I-D.ietf-spring-segment-routing] introduces some
segments include such as node segment and segment, adjacency segment, etc. SR Global
Block (SRGB) is also introduced for allocation of segment. A Node Segment represents In the
shortest path
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 a node MPLS label based on the SRGB. According to
[I-D.ietf-ospf-segment-routing-extensions] and Node segments must
[I-D.ietf-isis-segment-routing-extensions] MPLS global label binding
information can also be globally unique
within directly advertised in the network domain. That is, In network. For
example, in the MPLS data plane
instantiation, 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 is used to identify a
can be directly allocated for specific Node
Segment. 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 essence the MPLS global world, we can adopt the dichotomy to divide it into per-
platform label is space and context-specific label space.

MPLS World

When we adopt another dichotomy to represent divide the MPLS world into local
label and global label, we may face more challenges.

MPLS World

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
virtualized 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.

3.3.2. Should they belong to global label?

-- For MPLS Network Virtualization

As upstream label assignment in context-specific label
space, all downstream nodes can understand the virtual network operators develop, it is desirable 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 provide
better network virtualization solutions central controlled
node to allocate label to facilitate all leaf nodes. And thinking about the service
provision. [I-D.li-mpls-network-virtualization-framework] introduces
uniqueness of the framework for MPLS network virtualization. In context determine by the framework,
MPLS 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 used duplicate since they are calculated by different ingress
nodes. Should they belong to identify global label?

-- For BGP-based VPLS and Segment Routing, they can adopt the virtualized network
topology, 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 links 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 make up we define all of them as global label or define
some of them as global label and bring some use cases to the virtual network.

4. 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

6.1.

7.1. Normative References

[I-D.li-l2vpn-segment-evpn]
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
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997.

6.2. 1997,
<http://www.rfc-editor.org/info/rfc2119>.

7.2. Informative References

[I-D.chen-mpls-source-label]

[I-D.bryant-mpls-flow-ident]
Bryant, S., Pignataro, C., Chen, M., Xu, X., Li, Z., Fang, L., and G.
Mirsky,
"MultiProtocol Label Switching (MPLS) Source Label",
draft-chen-mpls-source-label-05 "MPLS Flow Identification", draft-bryant-mpls-
flow-ident-02 (work in progress), July
2014.

[I-D.filsfils-spring-segment-routing]
Filsfils, C., Previdi, September 2015.

[I-D.bryant-mpls-synonymous-flow-labels]
Bryant, S., Bashandy, A., Decraene, B.,
Litkowski, Swallow, G., Sivabalan, S., Horneffer, Mirsky, G., Chen,
M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
"Segment Routing Architecture", draft-filsfils-spring-
segment-routing-03 Z. Li, "RFC6374 Synonymous Flow Labels", draft-
bryant-mpls-synonymous-flow-labels-01 (work in progress), June 2014.

[I-D.ietf-l2vpn-evpn]
Sajassi, A., Aggarwal, R., Bitar, N., Isaac,
July 2015.

[I-D.ietf-isis-segment-routing-extensions]
Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
Litkowski, S., Decraene, B., and J.
Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn-
evpn-07 Tantsura, "IS-IS
Extensions for Segment Routing", draft-ietf-isis-segment-
routing-extensions-05 (work in progress), May 2014.

[I-D.ietf-l2vpn-pbb-evpn]
Sajassi, A., Salam, June 2015.

[I-D.ietf-ospf-segment-routing-extensions]
Psenak, P., Previdi, S., Bitar, N., Isaac, A., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and L. Jin, "PBB-EVPN", draft-ietf-l2vpn-pbb-evpn-07 J. Tantsura, "OSPF
Extensions for Segment Routing", draft-ietf-ospf-segment-
routing-extensions-05 (work in progress), June 2014.

[I-D.ietf-l2vpn-vpls-mcast]
Aggarwal, R., Rekhter, Y., Kamite, Y., 2015.

[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
and L. Fang,
"Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-16 r. rjs@rob.sh, "Segment Routing Architecture", draft-
ietf-spring-segment-routing-06 (work in progress), November 2013.

[I-D.ietf-pwe3-endpoint-fast-protection]
Shen, Y., Aggarwal, R., Henderickx, W., October
2015.

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<http://www.rfc-editor.org/info/rfc3031>.

[RFC3107] Rekhter, Y. Jiang, "PW
Endpoint Fast Failure Protection", draft-ietf-pwe3-
endpoint-fast-protection-00 (work in progress), December
2013.

[I-D.ietf-sfc-problem-statement]
Quinn, P. and T. Nadeau, "Service Function Chaining
Problem Statement", draft-ietf-sfc-problem-statement-07
(work E. Rosen, "Carrying Label Information in progress), June 2014.

[I-D.li-mpls-network-virtualization-framework]
BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001,
<http://www.rfc-editor.org/info/rfc3107>.

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, Z. T., Srinivasan, V.,
and M. Li, "Framework of Network Virtualization
Based on MPLS Global Label", draft-li-mpls-network-
virtualization-framework-00 (work in progress), October
2013.

[I-D.xu-spring-sfc-use-case]
Xu, X., Li, Z., Shah, H., G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.

[RFC4364] Rosen, E. and L. Contreras, "Service
Function Chaining Use Case Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>.

[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for SPRING", draft-xu-spring-
sfc-use-case-02 (work in progress), June 2014.

[I-D.zhang-l3vpn-label-sharing]
Zhang, Auto-Discovery and
Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
<http://www.rfc-editor.org/info/rfc4761>.

[RFC4762] Lasserre, M., Zhou, P., Ed. and R. White, "Label Sharing for Fast
PE Protection", draft-zhang-l3vpn-label-sharing-02 (work
in progress), June 2014. V. Kompella, Ed., "Virtual Private
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. E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/BGP MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012.
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

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