Internet DRAFT - draft-li-mpls-path-programming
draft-li-mpls-path-programming
Network Working Group Z. Li
Internet-Draft Z. Zhuang
Intended status: Informational Huawei Technologies
Expires: September 6, 2018 March 5, 2018
Service-Oriented MPLS Path Programming (MPP)
draft-li-mpls-path-programming-00
Abstract
Segment Routing has been proposed to cope with the use cases in
traffic engineering, fast re-reroute, service chain, etc. It can
leverage existing MPLS dataplane without any modification. In fact,
the label stack capability in MPLS would have been utilized well to
implement flexible path programming to satisfy all kinds of
requirements of service bearing. But in the distributed environment,
the flexible programming capability is difficult to implement and
always confined to reachability. As the introducing of central
control in the network, the flexible MPLS programming capability
becomes possible owing to two factors: 1. It becomes easier to
allocate label for more purposes than reachability; 2. It is easy to
calculate the MPLS path in a global network view. Moreover, the MPLS
path programming capability can be utilized to satisfy more
requirements of service bearing in the service layer which is defined
as service-oriented MPLS path programming. This document defines the
concept of MPLS path programming, then proposes use cases,
architecture and protocol extension requirements in the service
layer.
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 https://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
Li & Zhuang Expires September 6, 2018 [Page 1]
Internet-Draft Service-Oriented MPLS Path Programming March 2018
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 6, 2018.
Copyright Notice
Copyright (c) 2018 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
(https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Programming Capability of MPLS Path . . . . . . . . . . . . . 4
3.1. History Review . . . . . . . . . . . . . . . . . . . . . 4
3.2. Gap Analysis of Segment Routing . . . . . . . . . . . . . 5
4. Use Cases of Service-Oriented MPLS Path Programming . . . . . 6
4.1. Use Cases for Unicast Service . . . . . . . . . . . . . . 6
4.1.1. Basic Reachability . . . . . . . . . . . . . . . . . 6
4.1.2. VPN Identification . . . . . . . . . . . . . . . . . 6
4.1.3. ECMP( Equal Cost Multi-Path) . . . . . . . . . . . . 6
4.1.4. Service OAM . . . . . . . . . . . . . . . . . . . . . 6
4.1.5. Traffic Steering . . . . . . . . . . . . . . . . . . 7
4.2. Use Cases of Multicast Service . . . . . . . . . . . . . 7
4.2.1. Basic Reachability . . . . . . . . . . . . . . . . . 7
4.2.2. MVPN Identification . . . . . . . . . . . . . . . . . 8
4.2.3. Source Identification . . . . . . . . . . . . . . . . 8
4.3. Use Cases of MPLS Virtual Network . . . . . . . . . . . . 8
4.4. Use cases of More Label Combinations . . . . . . . . . . 8
4.5. Use cases for Centralized Mapping of Service to Tunnels . 9
5. Framework of Service-Oriented MPLS Path Programming . . . . . 9
5.1. Central Control for MPLS Path Programming . . . . . . . . 9
5.2. BGP-based MPLS Segment Distribution . . . . . . . . . . . 11
5.3. MPLS Service Path Programming . . . . . . . . . . . . . . 11
5.3.1. Label Combination and Download of MPLS Path . . . . . 11
5.3.2. Mapping of Service Path to Service Path . . . . . . . 11
5.4. Compatibility . . . . . . . . . . . . . . . . . . . . . . 12
Li & Zhuang Expires September 6, 2018 [Page 2]
Internet-Draft Service-Oriented MPLS Path Programming March 2018
5.5. Protocol Extensions Requirements . . . . . . . . . . . . 12
5.5.1. BGP . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.5.2. I2RS . . . . . . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
Segment Routing has been proposed to cope with the use cases in
traffic engineering, fast re-reroute, service chain, etc. It can
leverage existing MPLS dataplane without any modification. In fact,
the label stack capability in MPLS would have been utilized well to
implement flexible path programming to satisfy all kinds of
requirements of service bearing. But in the distributed environment,
the flexible programming capability is difficult to implement and
always confined to reachability. As the introducing of central
control in the network, the flexible MPLS programming capability
becomes possible owing to two factors: 1. It becomes easier to
allocate label for more purposes than reachability; 2. It is easy to
calculate the MPLS path in a global network view. Moreover, the MPLS
path programming capability can be utilized to satisfy more
requirements of service bearing in the service layer which is defined
as service-oriented MPLS path programming. This document defines the
concept of MPLS path programming, then proposes use cases,
architecture and protocol extension requirements in the service
layer.
2. Terminology
BGP: Border Gateway Protocol
BUM: Broadcast, Unknown unicast and Multicast
EVPN: Ethernet VPN
FRR: Fast Re-Route
L2VPN: Layer 2 VPN
L3VPN: Layer 3 VPN
MPP: MPLS Path Programming
MVPN: Multicast VPN
Li & Zhuang Expires September 6, 2018 [Page 3]
Internet-Draft Service-Oriented MPLS Path Programming March 2018
RR: Route Reflector
SDN: Software-Defined Network
SR-path: Segment Routing Path
3. Programming Capability of MPLS Path
MPLS path is composed by label stacks. Since in the label stack the
labels in different layers can represent different meaning and the
depth of the label stack can be unlimited in theory, it is possible
can make up all kinks of MPLS paths based on the combination of
labels. If we look on the combination of MPLS labels as programming,
it is can be seen that the MPLS path has high programming capability.
3.1. History Review
The solutions based on MPLS label stack have been widely deployed.
For example, in the scenario of Options C inter-AS VPN ([RFC4364]),
we assume that LDP over TE is used as the transport tunnel and the TE
tunnel starts at the ingress PE, following label stack can be
composed by the ingress PE for MPLS path to bear VPN service:
+----------+---------+---------+---------+
|VPN Prefix| BGP | LDP | RSVP-TE |
| Label | Label | Label | Label |
+----------+---------+---------+---------+
If facility FRR ([RFC4090]) is deployed for the MPLS TE tunnel, once
the failure happens, additional label will be pushed for the label
stack which is shown as follows:
+----------+---------+---------+---------+------------+
|VPN Prefix| BGP | LDP | RSVP-TE | BYPASS FRR |
| Label | Label | Label | Label | Label |
+----------+---------+---------+---------+------------+
The combination of labels in the above label stack is not simpler
than the existing segment routing solution which composes the segment
routing path through combination of segments. In fact, this is also
a use case of source packet routing. But the combination is not as
flexible as the segment routing since the combination of labels is
always to cope with the reachability issue with limited capability in
the distributed environment as follows:
1. Each label in the label stack is always binded with the
reachability to a specific prefix. That is, the purpose of the
label binding is limited.
Li & Zhuang Expires September 6, 2018 [Page 4]
Internet-Draft Service-Oriented MPLS Path Programming March 2018
2. It is difficult to implement flexible path calculation based on
policy or constraints. For example, MPLS TE proposes rich set of
traffic engineering attributes for transport. But it needs
complex configurations in each ingress node in an unscalable way.
That is, the path calculation and composition capability is
limited.
As more concepts on MPLS label are proposed such as entropy label,
source label, segment routing, etc., the purpose of label binding
expands and the combination of labels can become more flexible. MPLS
path programming capability becomes more realistic to satisfy more
application scenarios.
3.2. Gap Analysis of Segment Routing
Segment Routing ([I-D.ietf-spring-segment-routing]) is a typical
example of MPLS path programming. The segment based on MPLS label is
to represent nodes or agencies in the network. Through the collected
information of network segments and path calculation based on the
service requirement in the central controller, there will be flexible
segment routing paths for the usage of traffic engineering. The SR-
path can be advertised to the ingress node through PCE extensions.
([I-D.ietf-pce-segment-routing]).
Segment routing can implement source packet routing with high
flexibility. On the other hand, there are multiple layers for MPLS
path to bear services which is shown in the following figure:
+---+ +---+
+--+ | | +---+ +---+ +---+ | | +--+
|CE|----|PE1|----| P |----| P |----| P |----|PE2|----|CE|
+--+ | | +---+ +---+ +---+ | | +--+
+---+ +---+
o--------o--------- Service Layer------------o--------o
o--------- Network Layer -----------o
o-------o--------o---------o-------o Transport Layer
o-----o o-----o o-----o o-----o o-----o o-----o Link Layer
Figure 1: Multiple Layers of Service Bearing
Now the segment routing is to provide the source packet routing in
the transport layer. We can call this type of source packet routing
as Transport-Oriented MPLS path programming. There will be more
Li & Zhuang Expires September 6, 2018 [Page 5]
Internet-Draft Service-Oriented MPLS Path Programming March 2018
application scenarios which needs the source packet routing in the
service layer and network layer. We call these types of source
packet routing as Service-Oriented MPLS path programming.
4. Use Cases of Service-Oriented MPLS Path Programming
4.1. Use Cases for Unicast Service
4.1.1. Basic Reachability
The basic reachability for VPN service is to allocate label to
specific prefix including IP address or MAC address. MPLS path is as
follows (using L3VPN as the example):
+----------+
|VPN Prefix| ---> Transport
| Label | Tunnel
+----------+
4.1.2. VPN Identification
There are several use cases which need to indentify the VPN the
packet belongs to in the forwarding plane such as the egress PE node
protection for VPN ([I-D.zhang-l3vpn-label-sharing]). MPLS Path can
be as follows:
+----------+----------+
|VPN Prefix| VPN | ---> Transport
| Label | Label | Tunnel
+----------+----------+
4.1.3. ECMP( Equal Cost Multi-Path)
In order to satisfy ECMP to take full advantage of link bandwidth in
the network, the entropy label ([RFC6790]) can be encapsulated. MPLS
path can be as follows:
+----------+----------+----------+
| Entropy |VPN Prefix| VPN | ---> Transport
| Label | Label | Label | Tunnel
+----------+----------+----------+
4.1.4. Service OAM
OAM is an important requirement for the service. The performance
metrics should be measured against the Service Level Agreement(SLA)
for the user. Now there are relatively complete and mature OAM
mechanism for the point-to-point service. But for LDP LSP, owing to
Li & Zhuang Expires September 6, 2018 [Page 6]
Internet-Draft Service-Oriented MPLS Path Programming March 2018
the MP2P model it is difficult to identify the flow from a specific
PE based on the label. Synonymous flow label (SFL) has been proposed
as a possible solution([I-D.ietf-mpls-sfl-framework]). When the
source label is applied, MPLS path can be as follows:
+----------+----------+----------+----------+
| Entropy |VPN Prefix| VPN | SFL | ---> Transport
| Label | Label | Label | | Tunnel
+----------+----------+----------+----------+
4.1.5. Traffic Steering
Service traffic may span multiple ASes. It is an important use case
to steer traffic at ASBR in an AS to specific ASBR in neighboring AS.
There are possible solutions for this type of traffic steering:
1. Traffic Steering based on Transport Tunnel
This method looks on the segment between two ASBRs as the extension
of the transport tunnel in an AS. It can steer the traffic through
the specific path to the neighboring AS.
2. Traffic Steering in Service/Network Layer
This method is to directly encapsulate the service flow with the
steering label in the ingress PE before it enters into the transport
tunnel. [I-D.ietf-spring-segment-routing-central-epe] illustrates
the application of Segment Routing to solve the Egress Peer
Engineering (EPE) requirement. When this method is applied, the MPLS
path can be as follows:
+----------+----------+----------+----------+----------+
| Entropy | Steering |VPN Prefix| VPN | Source | ---> Transport
| Label | Label | Label | Label | Label | Tunnel
+----------+----------+----------+----------+----------+
4.2. Use Cases of Multicast Service
4.2.1. Basic Reachability
When MPLS multicast tunnel is applied for the multicast service in
BGP-based MVPN, VPLS or EVPN, the basic MPLS path can be as follows:
+-----------+
| Multicast |---> Transport
| Payload | Multicast Tunnel
+-----------+
Li & Zhuang Expires September 6, 2018 [Page 7]
Internet-Draft Service-Oriented MPLS Path Programming March 2018
4.2.2. MVPN Identification
When multiple MVPNs shares the MPLS multicast tunnel, it is necessary
to encapsulate the label to identify specific MVPN([RFC6514]). The
MPLS path can be as follows:
+-----------+----------+
| Multicast | MVPN | ---> Transport
| Payload | Label | Multicast Tunnel
+-----------+----------+
4.2.3. Source Identification
In order to implement the split horizon or C-MAC learning in the
fowarding plane when MPLS multicast is to bear BUM traffic in L2VPN,
it is necessary to introduce the label to identify the source of the
BUM traffic([I-D.li-l2vpn-segment-evpn]). The MPLS path is as
follows:
+-----------+----------+----------+
| Multicast | EVPN | Source | ---> Transport
| Payload | Label | Label | Multicast Tunnel
+-----------+----------+----------+
4.3. Use Cases of MPLS Virtual Network
The framework of MPLS virtual network has been proposed in
[I-D.li-mpls-network-virtualization-framework]. When the unicast
service or the multicast service enters into the transport tunnel, it
may take different MPLS virtual network identified by the MPLS label
for the purpose of QoS routing, security or virtual operations. The
MPLS path is as follows:
+-------------+ +-----------------+
| Service | ---> | Virtual Network | ---> Transport
| Label Stack | | Label | Tunnel
+-------------+ +-----------------+
4.4. Use cases of More Label Combinations
Service-oriented MPLS path programming can make full use of flexible
combination of MPLS labels to satisfy different requirements for the
service flow. Based on the above proposed use cases, MPLS path can
be composed adopting part or whole labels for these use cases based
on the service requirement. Besides this, more flexible MPLS label
combination may be provided:
Li & Zhuang Expires September 6, 2018 [Page 8]
Internet-Draft Service-Oriented MPLS Path Programming March 2018
1. Hierarchical process or multiple repeated process: The label for
the same usage can exist in different layers. Or the process
identified by the label can exist in multiple nodes along the path.
Then the labels for the same usage can be encapsulated several times
in the label stack. The encapsulation can be as follows (using
SERVICE LABEL to identify the label for the same service process in
different layers):
+----------+----------+----------+----------+----------+----------+
| SERVICE |VPN Prefix| SERVICE | VPN | SERVICE | Tunnel |
| LABEL | Label | LABEL | Label | LABEL | Label |
+----------+----------+----------+----------+----------+----------+
2. Special-purpose label indicator: Since the label in the service-
oriented MPLS programming is for special-purpose process, it may need
a special purpose label to indicate the usage of the label followed
the special-purpose labels. For example, the ELI( Entropy Label
Indicator) is introduced for the entropy label. This may introduce
more labels for the combination.
This document is not to define all possible use cases for the
service-oriented path programming. The new use cases can be defined
in the future independent document.
4.5. Use cases for Centralized Mapping of Service to Tunnels
In the transport layers, there can be multiple tunnels to one
specific destination which satisfy different constraints. In the
traditional way, the tunnel is set up by the distributed forwarding
nodes. As the PCE-initiated LSP setup
[I-D.ietf-pce-pce-initiated-lsp]is introduced, the tunnel can be
setup in the central controlled way. In order to satisfy the
different service requirements, it is necessary to provide the
capability to flexibly map the service to different tunnels. Since
the central control point has enough information based on the whole
network view, it can be an effective way to map the service to the
tunnel by the central point and advertise the mapping information to
the end-points of the service to guide the mapping in the forwarding
node.
5. Framework of Service-Oriented MPLS Path Programming
5.1. Central Control for MPLS Path Programming
Central control plays an important role in MPLS path programming. It
can extend the MPLS path programming capability easily. There are
two important functionalities for the central control:
Li & Zhuang Expires September 6, 2018 [Page 9]
Internet-Draft Service-Oriented MPLS Path Programming March 2018
1. Central controlled MPLS label allocation: Label can be allocated
centrally for special usage other than reachability. These labels
can be used to compose MPLS path. We call it as MPLS Segment.
2. Central controlled MPLS path programming: Central controller can
calculate path in a global network view and implement the MPLS path
programming based on the collected information of MPLS segments to
satisfy different requirements of services.
+-------------------+
| Central |
| Controller |
|----------|(Path Calculation |--------|
| | /Path Programming)| |
| +-------------------+ |
| / | \ |
MPLS Path / Segment \ MPLS Path
| / Allocation \ |
| Segment | Segment |
| Allocation | Allocation |
| / | \ |
| / | \ |
+--------+ +--------+ +--------+
| CLIENT | | CLIENT | | CLIENT |
| | ...... | | ...... | |
| (PE) | | (P) | | (PE) |
| | | | | |
+--------+ +--------+ +--------+
Figure 2 Central Control for MPLS Path Programming
There are two types of MPLS path: Transport-Oriented MPLS Path and
Service-Oriented MPLS Path. For the transport-oriented MPLS path,
segment routing is the typical solution: MPLS segment distribution is
done by IGP extensions ([I-D.ietf-isis-segment-routing-extensions])
and [I-D.ietf-ospf-segment-routing-extensions]); the programmed MPLS
path can be downloaded through PCEP extensions from PCE to
PCC([I-D.ietf-pce-segment-routing]). For the service-oriented MPLS
path programming, it not only includes composing the MPLS path in the
service and network layer, but also includes determining the mapping
of the service path to the transport path. Since the process
corresponding to the label in the service label stack is always
located at the PE nodes, BGP extensions can be introduced for
service-oriented path programming.
Li & Zhuang Expires September 6, 2018 [Page 10]
Internet-Draft Service-Oriented MPLS Path Programming March 2018
5.2. BGP-based MPLS Segment Distribution
1. Label Allocation
There are two types of label used for MPLS segments:
1) Local Label: The service process is done locally. The label can
be allocated by the local PE which provides the process.
2) Global Label: The service process is common in multiple PEs. This
means the label has global meaning. The label allocation can be done
by the central controller. The global label work can refer to
[I-D.li-mpls-global-label-framework].
2. Label Mapping Distribution
BGP extensions can be used to distribution label mapping. Regarding
to the above two types of label allocation, the process is as
follows:
1) Local Label Mapping: BGP can directly distribute the label mapping
from the local PE to peer PEs. The local PE can also only distribute
the label mapping to central controller. Then the central controller
re-distribute the label mapping to other PEs. In this method, the
central controller plays the role of traditional RR.
2) Global Label Mapping: The label mapping for the service can be
directly distributed by the central controller to multiple PEs. It
can be done by BGP extensions.
5.3. MPLS Service Path Programming
5.3.1. Label Combination and Download of MPLS Path
According to the service requirements, the central controller can
combine MPLS segments flexibly. Then it can download the service
label combination for specific prefix related with the service. The
BGP extensions can be reused to download the programmed MPLS path.
5.3.2. Mapping of Service Path to Service Path
Since the transport path is also to satisfy the service bearing the
requirement, it can reuse the existing MPLS tunnel technology or it
can also be programmed according to traffic engineering requirements
of service. Then there needs to be implements the mapping of the
service path to the transport path. There are two ways to implement
the mapping:
Li & Zhuang Expires September 6, 2018 [Page 11]
Internet-Draft Service-Oriented MPLS Path Programming March 2018
1. BGP Extensions: Through the community attribute of BGP, the
identifier of the transport path can be carrier when distribute label
stack for a specific prefix.
2. I2RS Extensions: I2RS can be used to download route policy to the
client node. Based on the policy, the client node can implement the
required mapping.
5.4. Compatibility
When the MPLS path programming is done the central controller and
downloaded through BGP extensions to the Client node, the path SHOULD
has higher priority than the path calculated on the Client node's
own.
5.5. Protocol Extensions Requirements
5.5.1. BGP
REQ 01: BGP extensions SHOULD be introduced to distribute local label
mapping for specific process to the central controller and other
client nodes.
REQ 02: BGP extensions SHOULD be introduced to distribute global
label mapping for specific process from the central controller to the
client nodes .
REQ 03: BGP extensions SHOULD be introduced to download label stack
for service-oriented MPLS path.
REQ 04: BGP extensions SHOULD be introduced to carry the identifier
of the transport MPLS path with service MPLS path to implement the
mapping.
REQ 05: BGP extensions SHOULD be introduced to specify the end-points
to accept the prefix advertised by the central controller.
REQ 06: BGP extensions SHOULD be introduced to specify the priority
for the prefix with attributes of MPLS path programming advertised by
the central controller.
REQ 07: When route selection is done in the client node, the path
advertised by the central controller SHOULD has higher priority than
the path calculated on the client's own.
Li & Zhuang Expires September 6, 2018 [Page 12]
Internet-Draft Service-Oriented MPLS Path Programming March 2018
5.5.2. I2RS
REQ 11: I2RS clients SHOULD provide interface to I2RS agent to
download policy to implement the mapping of the service path to the
transport path.
6. IANA Considerations
This document makes no request of IANA.
7. Security Considerations
TBD.
8. References
8.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,
<https://www.rfc-editor.org/info/rfc2119>.
8.2. Informative References
[I-D.ietf-isis-segment-routing-extensions]
Previdi, S., Ginsberg, L., 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-15 (work in progress), December
2017.
[I-D.ietf-mpls-sfl-framework]
Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S.,
and G. Mirsky, "Synonymous Flow Label Framework", draft-
ietf-mpls-sfl-framework-01 (work in progress), January
2018.
[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-24 (work in progress), December 2017.
Li & Zhuang Expires September 6, 2018 [Page 13]
Internet-Draft Service-Oriented MPLS Path Programming March 2018
[I-D.ietf-pce-pce-initiated-lsp]
Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
Extensions for PCE-initiated LSP Setup in a Stateful PCE
Model", draft-ietf-pce-pce-initiated-lsp-11 (work in
progress), October 2017.
[I-D.ietf-pce-segment-routing]
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "PCEP Extensions for Segment Routing",
draft-ietf-pce-segment-routing-11 (work in progress),
November 2017.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), January 2018.
[I-D.ietf-spring-segment-routing-central-epe]
Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D.
Afanasiev, "Segment Routing Centralized BGP Egress Peer
Engineering", draft-ietf-spring-segment-routing-central-
epe-10 (work in progress), December 2017.
[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.
[I-D.li-mpls-global-label-framework]
Li, Z., Zhao, Q., Chen, X., Yang, T., and R. Raszuk, "A
Framework of MPLS Global Label", draft-li-mpls-global-
label-framework-02 (work in progress), July 2014.
[I-D.li-mpls-global-label-usecases]
Li, Z., Zhao, Q., Yang, T., Raszuk, R., and L. Fang,
"Usecases of MPLS Global Label", draft-li-mpls-global-
label-usecases-03 (work in progress), October 2015.
[I-D.li-mpls-network-virtualization-framework]
Li, Z. and M. Li, "Framework of Network Virtualization
Based on MPLS Global Label", draft-li-mpls-network-
virtualization-framework-00 (work in progress), October
2013.
Li & Zhuang Expires September 6, 2018 [Page 14]
Internet-Draft Service-Oriented MPLS Path Programming March 2018
[I-D.zhang-l3vpn-label-sharing]
Zhang, M., Zhou, P., and R. White, "Label Sharing for Fast
PE Protection", draft-zhang-l3vpn-label-sharing-02 (work
in progress), June 2014.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
DOI 10.17487/RFC4090, May 2005,
<https://www.rfc-editor.org/info/rfc4090>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>.
[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,
<https://www.rfc-editor.org/info/rfc6790>.
Authors' Addresses
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Shunwan Zhuang
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: zhuangshunwan@huawei.com
Li & Zhuang Expires September 6, 2018 [Page 15]
