PCE Working Group C. Li
Internet-Draft M. Chen
Intended status: Standards Track J. Dong
Expires: December 22, 2018 Z. Li
D. Dhody
Huawei Technologies
June 20, 2018
Path Computation Element Communication Protocol (PCEP) Extension for
Path Identification in Segment Routing (SR)
draft-li-pce-sr-path-segment-00
Abstract
The Path Computation Element (PCE) provides path computation
functions in support of traffic engineering in Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) networks.
The Source Packet Routing in Networking (SPRING) architecture
describes how Segment Routing (SR) can be used to steer packets
through an IPv6 or MPLS network using the source routing paradigm. A
Segment Routed Path can be derived from a variety of mechanisms,
including an IGP Shortest Path Tree (SPT), explicit configuration, or
a Path Computation Element (PCE).
Path identification is needed for several use cases such as
performance measurement in Segment Routing (SR) network. This
document specifies extensions to the Path Computation Element
Protocol (PCEP) to support requesting, replying, reporting and
updating the path identifier between PCEP speakers.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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
Li, et al. Expires December 22, 2018 [Page 1]
Internet-Draft Path ID in PCEP June 2018
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
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 December 22, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Path ID Extensions in PCEP . . . . . . . . . . . 4
4. Objects and TLVs . . . . . . . . . . . . . . . . . . . . . . 5
4.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. The SR PCE Capability sub-TLV . . . . . . . . . . . . 5
4.1.2. The SRv6 PCE Capability sub-TLV . . . . . . . . . . . 5
4.1.3. PCECC-CAPABILITY sub-TLV . . . . . . . . . . . . . . 5
4.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. Path ID TLV . . . . . . . . . . . . . . . . . . . . . 6
4.3. FEC Object . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 9
5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. PCC Allocated Path ID . . . . . . . . . . . . . . . . . . 9
5.1.1. Ingress PCC Allocated Path ID . . . . . . . . . . . . 9
5.2. PCE Allocated Path ID . . . . . . . . . . . . . . . . . . 10
5.2.1. PCE Controlled ID Spaces Advertisement . . . . . . . 10
5.2.2. Ingress PCC request Path ID to PCE . . . . . . . . . 10
5.2.3. PCE allocated Path ID on its own . . . . . . . . . . 11
5.3. Two Label Solution . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
Li, et al. Expires December 22, 2018 [Page 2]
Internet-Draft Path ID in PCEP June 2018
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
[RFC5440] describes the Path Computation Element (PCE) Communication
Protocol (PCEP). PCEP enables the communication between a Path
Computation Client (PCC) and a PCE, or between PCE and PCE, for the
purpose of computation of Multiprotocol Label Switching (MPLS) as
well as Generalzied MPLS (GMPLS) Traffic Engineering Label Switched
Path (TE LSP) characteristics.
[RFC8231] specifies a set of extensions to PCEP to enable stateful
control of TE LSPs within and across PCEP sessions in compliance with
[RFC4657]. It includes mechanisms to effect LSP State
Synchronization between PCCs and PCEs, delegation of control over
LSPs to PCEs, and PCE control of timing and sequence of path
computations within and across PCEP sessions. The model of operation
where LSPs are initiated from the PCE is described in [RFC8281].
[I-D.zhao-pce-pcep-extension-for-pce-controller] specify the
procedures and PCEP protocol extensions for using the PCE as the
central controller for static LSPs, where LSPs can be provisioned as
explicit label instructions at each hop on the end-to-end path.
Segment routing (SR) [I-D.ietf-spring-segment-routing] leverages the
source routing and tunneling paradigms. SR supports steering packets
into an explicit forwarding path according to the Segment Routing
Policy ( SR Policy) [I-D.ietf-spring-segment-routing-policy] at the
ingress node.
An SR path needs to be identified in some use cases such as
performance measurement. For identifying an SR path,
[I-D.cheng-spring-mpls-path-segment] introduces a new segment that is
referred to as Path Segment.
[I-D.li-idr-sr-policy-path-segment-distribution] defines extensions
to BGP to distribute SR policies carrying Path segment identifier.
[I-D.ietf-pce-segment-routing] specifies extensions to the Path
Computation Element Protocol (PCEP) [RFC5440] for SR networks, that
allow a stateful PCE to compute and initiate SR-TE paths, as well as
a PCC to request, report or delegate SR paths.
[I-D.negi-pce-segment-routing-ipv6] extend PCEP to support SR for
IPv6 data plane.
Li, et al. Expires December 22, 2018 [Page 3]
Internet-Draft Path ID in PCEP June 2018
[I-D.zhao-pce-pcep-extension-pce-controller-sr] specifies the
procedures and PCEP protocol extensions when a PCE-based controller
is also responsible for configuring the forwarding actions on the
routers (SR SID distribution in this case), in addition to computing
the paths for packet flows in a segment routing network and telling
the edge routers what instructions to attach to packets as they enter
the network.
This document specifies a mechanism to carry the SR path
identification information in PCEP messages [RFC5440] [RFC8231]
[RFC8281]. The path ID can be a path segment in SR-MPLS
[I-D.cheng-spring-mpls-path-segment], or a path ID in SRv6
[I-D.li-spring-passive-pm-for-srv6-np], or other IDs that can
identify the SR path. This document also extends the PCECC-SR
mechanism to inform the path ID to the egress PCC.
2. Terminology
This memo makes use of the terms defined in [RFC4655],
[I-D.ietf-pce-segment-routing], and
[I-D.ietf-spring-segment-routing].
3. Overview of Path ID Extensions in PCEP
This document specifies a mechanism of encoding (and allocating) path
ID (path segment in case of MPLS, path ID in case of IPv6, etc) in
PCEP extensions. For supporting path ID in PCEP, several TLVs and
flags are defined. The formats of the objects and TLVs are described
in Section 4. The procedures of path ID allocation are described in
Section 5.
There are various modes of operations, such as -
o The path ID can be allocated by Ingress PCC itself and informed to
the PCE. The PCE can then inform the egress PCC.
o The PCC can also request PCE to allocate the path ID, in this
case, the PCE would allocate and inform the assigned path ID to
the ingress/egress PCC using PCEP messages.
o For PCE can allocate a path ID on its own accord and inform the
ingress/egress PCC , useful for PCE-initiated LSPs.
The path ID information to the ingress PCC and PCE is exchanged via
an extension to [I-D.ietf-pce-segment-routing] and
[I-D.negi-pce-segment-routing-ipv6]. The path ID information to the
egress PCC is informed via an extension to the PCECC-SR procedures
[I-D.zhao-pce-pcep-extension-pce-controller-sr].
Li, et al. Expires December 22, 2018 [Page 4]
Internet-Draft Path ID in PCEP June 2018
For the PCE to allocate a path ID, the PCE MUST be aware of the path
ID space from the PCCs. This is done via mechanism as described in
[I-D.li-pce-controlled-id-space].
[Editor's note - There is currently no mechanism for the PCE to ask
PCC to allocate path ID. Further discussion is needed to check if
that would be useful in any way.]
4. Objects and TLVs
4.1. The OPEN Object
4.1.1. The SR PCE Capability sub-TLV
[I-D.ietf-pce-segment-routing] defined a new Path Setup Type (PST)
and SR-PCE-CAPABILITY sub-TLV for SR. PCEP speakers use this sub-TLV
to exchange information about their SR capability. The TLV includes
a Flags field and one bit (L-flag) was allocated in
[I-D.ietf-pce-segment-routing].
This document adds an additional flag for path ID allocation, as
follows -
P (Path Identification bit): A PCEP speaker sets this flag to 1 to
indicate that it has the capability to encode SR path
identification (path segment, as per
[I-D.cheng-spring-mpls-path-segment]).
4.1.2. The SRv6 PCE Capability sub-TLV
[I-D.negi-pce-segment-routing-ipv6] defined a new Path Setup Type
(PST) and SRv6-PCE-CAPABILITY sub-TLV for SRv6. PCEP speakers use
this sub-TLV to exchange information about their SRv6 capability.
The TLV includes a Flags field and one bit (L-flag) was allocated in
[I-D.negi-pce-segment-routing-ipv6].
This document adds an additional flag for path ID allocation, as
follows -
P (Path Identification bit): A PCEP speaker sets this flag to 1 to
indicate that it has the capability to encode SRv6 path
identification.
4.1.3. PCECC-CAPABILITY sub-TLV
The PCECC Capability as per
[I-D.zhao-pce-pcep-extension-pce-controller-sr] MUST also be
advertised on the egress PCEP session, along with the SR sub-TLVs.
Li, et al. Expires December 22, 2018 [Page 5]
Internet-Draft Path ID in PCEP June 2018
This is needed to ensure that the PCE can inform the egress PCC of
the path ID via PCECC mechanism as described in this document.
4.2. LSP Object
The LSP Object is defined in Section 7.3 of [RFC8231]. This document
adds the following flags to the LSP Object:
P (Path Identification Allocation bit): If the bit is set to 1, it
indicates that the path identifier needs to be allocated by the
PCE for this LSP. A PCC would set this bit to 1 to request for
allocation of path identifier by the PCE in the PCReq or PCRpt
message. A PCE would also set this bit to 1 to indicate that the
path identifier is allocated by PCE and encoded in the PCRep,
PCUpd or PCInitiate message (the PATH-ID TLV MUST be present in
LSP object).
4.2.1. Path ID TLV
The PATH-ID TLV is an optional TLV for use in the LSP Object for path
ID allocation. The type of this TLV is to be allocated by IANA. The
format is shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IDT | Flags |E|C|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The PATH-ID TLV Format
The type (16-bit) of the TLV is TBA (to be allocated by IANA). The
length (16-bit) has a fixed value of 8 octets. The value contains
the following fields:
IDT (The ID type - 8 bits): The IDT field specifies the type of
the Path ID field, which carries a Path ID corresponding to the SR
path.
* 0: MPLS Path segment, which is an MPLS label as defined in
[I-D.cheng-spring-mpls-path-segment]. The PST type MUST be set
to SR (MPLS).
Li, et al. Expires December 22, 2018 [Page 6]
Internet-Draft Path ID in PCEP June 2018
* 1: SRv6 Path ID, which is a 4-octet integer as defined in
[I-D.li-spring-passive-pm-for-srv6-np]. The PST type MUST be
set to SRv6.
Flags (24 bits): Three flag is currently defined:
* L-Bit (Local/Global - 1 bit): If set, then the Path ID carried
by the PATH-ID TLV has local significance. If not set, then
the Path ID carried by this TLV has global significance (i.e.
Path ID is global within an SR domain).
* C-bit (PCC/PCE - 1 bit): If set, then the Path ID carried by
the PATH-ID TLV has been allocated by the PCC. If not set,
then the Path ID carried by this TLV has been allocated by the
PCE.
* E-bit (Egress/Ingress - 1 bit): If set, then the Path ID
carried by the PATH-ID TLV has been allocated from the Egress
Path ID space. If not set, then the Path ID carried by this
TLV has been allocated from the Ingress Path ID space.
* The unassigned bits MUST be set to 0 and MUST be ignored at
receipt.
Path ID: The path ID of an SR path. The path ID type is indicated
by the ID Type field. It can be a path segment
[I-D.cheng-spring-mpls-path-segment] in MPLS label format. Or it
can be a 4 octets integer ID as defined in
[I-D.li-spring-passive-pm-for-srv6-np] or other IDs that can
identify a path.
Only one instance of each TLV is processed, if more than one TLV of
each type is included, the first one is processed and others MUST be
ignored.
When the path ID allocation is enable, a PATH-ID TLV SHOULD be
included in the LSP object.
If the path ID is allocated by the ingress node, a PATH-ID TLV MUST
be included in a LSP object (with C-bit set and E-bit is unset) in
the PCEP message from PCC. In this case the P flag in LSP object is
set to 0.
If the PCC request the path ID to be allocated by the PCE, P flag in
LSP object is set to 1 and Path ID TLV MAY be skipped. After the PCE
has allocated a path ID, it MUST include the PATH-ID TLV in a LSP
object (with C-bit unset), the E-bit is set by PCE based on the path
ID space from which the allocation is made.
Li, et al. Expires December 22, 2018 [Page 7]
Internet-Draft Path ID in PCEP June 2018
If the PCE allocated the path ID on its own accord, a PATH-ID TLV
MUST be included in a LSP object (with C-bit unset), the E-bit is set
by PCE based on the path ID space from which the allocation is made.
4.3. FEC Object
The FEC Object [I-D.zhao-pce-pcep-extension-pce-controller-sr] is
used to specify the FEC information and MAY be carried within
PCInitiate or PCRpt message for the PCECC-SR operations. The PCE
MUST inform the Path Identification information to the Egress PCC.
To do this, this document extends the procedures of
[I-D.zhao-pce-pcep-extension-pce-controller-sr] by defining a new FEC
object type for Path.
FEC Object-Type is TBD 'Path'.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// TLV(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The path FEC object Format
One or more following TLV(s) are allowed in the 'path' FEC object -
o SYMBOLIC-PATH-NAME TLV: As defined in [RFC8231], it is a human-
readable string that identifies an LSP in the network.
o LSP-IDENTIFIERS TLVs: As defined in [RFC8231], it is optional for
SR, but could be used to encode the source, destination and other
identification information for the path.
o SPEAKER-ENTITY-ID TLV: As defined in [RFC8232], a unique
identifier for the PCEP speaker, it is used to identify the
Ingress PCC.
Either SYMBOLIC-PATH-NAME TLV or LSP-IDENTIFIERS TLV MUST be
included. SPEAKER-ENTITY-ID TLV is optional. Only one instance of
each TLV is processed, if more than one TLV of each type is included,
the first one is processed and others MUST be ignored.
Li, et al. Expires December 22, 2018 [Page 8]
Internet-Draft Path ID in PCEP June 2018
4.4. CCI Object
The Central Control Instructions (CCI) Object is used by the PCE to
specify the forwarding instructions is defined in
[I-D.zhao-pce-pcep-extension-for-pce-controller]. Further
[I-D.zhao-pce-pcep-extension-pce-controller-sr] defined a CCI object
type for SR.
The Path ID information is encoded directly in the CCI SR object.
The Path ID TLV as described in the Section 4.2.1, MAY also be
included in the CCI SR object.
5. Operations
The path ID allocation and encoding is as per the stateful PCE
operations for segment routing. The procedures are as per the
corresponding extensions defined in [I-D.ietf-pce-segment-routing]
and [I-D.negi-pce-segment-routing-ipv6] (which are further based on
[RFC8231] and [RFC8281]). The additional operations for path
identification are defined in this section.
To notify the path ID to the Egress PCC, the procedures are as per
the PCECC-SR [I-D.zhao-pce-pcep-extension-pce-controller-sr] (which
is based on [I-D.zhao-pce-pcep-extension-for-pce-controller]). The
additional operations are defined in this section.
5.1. PCC Allocated Path ID
5.1.1. Ingress PCC Allocated Path ID
The Ingress PCC could allocate the Path ID and inform the PCE via the
PCRpt message as per [RFC8231]. The PATH-ID TLV MUST be included in
a LSP object in the PCEP message from PCC. The P flag in LSP object
is set to 0. On receiving this report, the PCE updates the
information in its database. The active PCE (where the LSP is
delegated) further informs the egress about the path ID allocated by
the PCC using the PCInitiate message as described in
[I-D.zhao-pce-pcep-extension-pce-controller-sr].
Li, et al. Expires December 22, 2018 [Page 9]
Internet-Draft Path ID in PCEP June 2018
Ingress Egress
+-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC|
+-+-+ +-+-+ +-+-+
1) LSP State | ---- PCRpt ----> | |
Delegate and | Delegate=1 | |
Inform the | PATH-ID TLV |2) PCE update |
Path ID alloc | | the LSP-DB |
by PCC | | |
|3) PCE informs the | --- PCInitiate ---> |
| Path ID to Egress| FEC=Path |
| | |
| | <-------- PCRpt --- |
| | |
Figure 3: Ingress PCC Allocated Path ID
5.2. PCE Allocated Path ID
5.2.1. PCE Controlled ID Spaces Advertisement
For allocating the path IDs to SR paths by the PCEs, the PCE
controlled ID Spaces MUST be known at PCEs via configurations or any
other mechanism. The PCE controlled ID spaces MAY be advertised as
described in [I-D.li-pce-controlled-id-space].
5.2.2. Ingress PCC request Path ID to PCE
The ingress PCC could request the path ID to be allocated by the PCE
via PCRpt message as per [RFC8231]. The delegate flag (D-flag) MUST
also be set for this LSP. The PATH-ID TLV MAY be included with Path
ID set to 0x0000. The active PCE would allocated the path ID as per
the PATH-ID flags and in case PATH-ID is not included, the PCE MUST
act based on the local policy. The PCE would further respond to
Ingress PCC with PCUpd message as per [RFC8231] and MUST include the
PATH-ID TLV in a LSP object. The PCE would further inform the egress
PCC about the path ID allocated by the PCE using the PCInitiate
message as described in
[I-D.zhao-pce-pcep-extension-pce-controller-sr].
Li, et al. Expires December 22, 2018 [Page 10]
Internet-Draft Path ID in PCEP June 2018
Ingress Egress
+-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC|
+-+-+ +-+-+ +-+-+
1) LSP State | ---- PCRpt ----> | |
Delegate | Delegate=1 | |
| P=1 |2) PCE update |
| | the LSP-DB and |
| | allocate Path ID |
|<---- PCUpd ---- |3)Paths update with |
| PATH-ID TLV | Path ID |
| | |
4) LSP State Report | ----- PCRpt ---> | |
| | |
|5) PCE informs the | --- PCInitiate ---> |
| Path ID to Egress| FEC=Path |
| | |
| | <-------- PCRpt --- |
| | |
Figure 4: Ingress PCC request Path ID to PCE
5.2.3. PCE allocated Path ID on its own
The PCE could allocate the path ID on its own accord for a PCE-
Initiated (or delegated LSP). The allocated path ID needs to be
informed to the Ingress and Egress PCC. The PCE would use the
PCInitiate message [RFC8281] or PCUpd message [RFC8231] towards the
Ingress PCC and MUST include the PATH-ID TLV in the LSP object. The
PCE would further inform the egress PCC about the path ID allocated
by the PCE using the PCInitiate message as described in
[I-D.zhao-pce-pcep-extension-pce-controller-sr].
Li, et al. Expires December 22, 2018 [Page 11]
Internet-Draft Path ID in PCEP June 2018
Ingress Egress
+-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC|
+-+-+ +-+-+ +-+-+
| | |
| <--PCInitiate--- |1)Initiate LSP with |
| PATH-ID TLV | Path ID |
| | |
2)LSP delegation |---PCRpt, D=1---> | (Confirm) |
| | |
|3) PCE informs the | --- PCInitiate ---> |
| Path ID to Egress| FEC=Path |
| | |
| | <-------- PCRpt --- |
| | |
Figure 5: PCE allocated Path ID on its own
5.3. Two Label Solution
[I-D.cheng-spring-mpls-path-segment] describe a Path Segment to
uniquely identify an SR path in a specific context. (e.g., in the
context of the egress node or ingress node of an SR path, or within
an SR domain). It further describes two solution based on 'one
label' or 'two labels' solution. For the latter, two segments
(Source segment and Path segment) are used to identify an SR path
where the source segment is a global node segment which can uniquely
identify a node within the SR domain (it is NOT used for forwarding
and indicates that a Path segment immediately follows). The
combination of Source segment and Path segment uniquely identify an
SR Path with an SR domain.
The procedure described in this document allocates and encode the
Path Segment only. It is expected that the Egress PCC is aware of
the Source segment by some other procedures. These procedures could
be IGP, PCECC-SR, or some other mechanisms.
6. IANA Considerations
TBA
7. Security Considerations
TBA
Li, et al. Expires December 22, 2018 [Page 12]
Internet-Draft Path ID in PCEP June 2018
8. Acknowledgments
9. References
9.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>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
and D. Dhody, "Optimizations of Label Switched Path State
Synchronization Procedures for a Stateful PCE", RFC 8232,
DOI 10.17487/RFC8232, September 2017,
<https://www.rfc-editor.org/info/rfc8232>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>.
[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.
Li, et al. Expires December 22, 2018 [Page 13]
Internet-Draft Path ID in PCEP June 2018
[I-D.negi-pce-segment-routing-ipv6]
Negi, M., Kaladharan, P., Dhody, D., and S. Sivabalan,
"PCEP Extensions for Segment Routing leveraging the IPv6
data plane", draft-negi-pce-segment-routing-ipv6-01 (work
in progress), March 2018.
[I-D.li-pce-controlled-id-space]
Li, C., Chen, M., Dong, J., Li, Z., and D. Dhody, "PCE
Controlled ID Space", draft-li-pce-controlled-id-space-00
(work in progress), June 2018.
[I-D.zhao-pce-pcep-extension-pce-controller-sr]
Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A.,
and C. Zhou, "PCEP Procedures and Protocol Extensions for
Using PCE as a Central Controller (PCECC) of SR-LSPs",
draft-zhao-pce-pcep-extension-pce-controller-sr-03 (work
in progress), June 2018.
[I-D.zhao-pce-pcep-extension-for-pce-controller]
Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A.,
and C. Zhou, "PCEP Procedures and Protocol Extensions for
Using PCE as a Central Controller (PCECC) of LSPs", draft-
zhao-pce-pcep-extension-for-pce-controller-08 (work in
progress), June 2018.
9.2. Informative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, DOI 10.17487/RFC4657, September
2006, <https://www.rfc-editor.org/info/rfc4657>.
[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-policy]
Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d.,
bogdanov@google.com, b., and P. Mattes, "Segment Routing
Policy Architecture", draft-ietf-spring-segment-routing-
policy-01 (work in progress), June 2018.
Li, et al. Expires December 22, 2018 [Page 14]
Internet-Draft Path ID in PCEP June 2018
[I-D.cheng-spring-mpls-path-segment]
Cheng, W., Wang, L., Li, H., Chen, M., Zigler, R., and S.
Zhan, "Path Segment in MPLS Based Sement Routing Network",
draft-cheng-spring-mpls-path-segment-01 (work in
progress), March 2018.
[I-D.li-spring-passive-pm-for-srv6-np]
Li, C. and M. Chen, "Passive Performance Measurement for
SRv6 Network Programming", draft-li-spring-passive-pm-for-
srv6-np-00 (work in progress), March 2018.
[I-D.li-idr-sr-policy-path-segment-distribution]
Li, C., Chen, M., Dong, J., and Z. Li, "Segment Routing
Policies for Path Segment and Bi-directional Path", draft-
li-idr-sr-policy-path-segment-distribution-00 (work in
progress), April 2018.
Authors' Addresses
Cheng Li
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China
Email: chengli13@huawei.com
Mach(Guoyi) Chen
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China
Email: Mach.chen@huawei.com
Jie Dong
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China
Email: jie.dong@huawei.com
Li, et al. Expires December 22, 2018 [Page 15]
Internet-Draft Path ID in PCEP June 2018
Zhenbin Li
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
Email: dhruv.ietf@gmail.com
Li, et al. Expires December 22, 2018 [Page 16]