< draft-li-pce-sr-path-segment-05.txt   draft-li-pce-sr-path-segment-06.txt >
PCE Working Group C. Li PCE Working Group C. Li
Internet-Draft M. Chen Internet-Draft M. Chen
Intended status: Standards Track Huawei Technologies Intended status: Standards Track Huawei Technologies
Expires: September 24, 2019 W. Cheng Expires: January 9, 2020 W. Cheng
China Mobile China Mobile
J. Dong J. Dong
Z. Li Z. Li
Huawei Technologies Huawei Technologies
R. Gandhi R. Gandhi
Cisco Systems, Inc. Cisco Systems, Inc.
Q. Xiong Q. Xiong
ZTE Corporation ZTE Corporation
March 23, 2019 July 8, 2019
Path Computation Element Communication Protocol (PCEP) Extension for Path Computation Element Communication Protocol (PCEP) Extension for
Path Segment in Segment Routing (SR) Path Segment in Segment Routing (SR)
draft-li-pce-sr-path-segment-05 draft-li-pce-sr-path-segment-06
Abstract Abstract
The Path Computation Element (PCE) provides path computation The Path Computation Element (PCE) provides path computation
functions in support of traffic engineering in Multiprotocol Label functions in support of traffic engineering in Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) networks. Switching (MPLS) and Generalized MPLS (GMPLS) networks.
The Source Packet Routing in Networking (SPRING) architecture The Source Packet Routing in Networking (SPRING) architecture
describes how Segment Routing (SR) can be used to steer packets describes how Segment Routing (SR) can be used to steer packets
through an IPv6 or MPLS network using the source routing paradigm. A through an IPv6 or MPLS network using the source routing paradigm. A
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 September 24, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 2, line 43 skipping to change at page 2, line 43
4. Objects and TLVs . . . . . . . . . . . . . . . . . . . . . . 5 4. Objects and TLVs . . . . . . . . . . . . . . . . . . . . . . 5
4.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 5 4.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. The SR PCE Capability sub-TLV . . . . . . . . . . . . 5 4.1.1. The SR PCE Capability sub-TLV . . . . . . . . . . . . 5
4.1.2. The SRv6 PCE Capability sub-TLV . . . . . . . . . . . 6 4.1.2. The SRv6 PCE Capability sub-TLV . . . . . . . . . . . 6
4.1.3. PCECC-CAPABILITY sub-TLV . . . . . . . . . . . . . . 6 4.1.3. PCECC-CAPABILITY sub-TLV . . . . . . . . . . . . . . 6
4.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.1. Path Segment TLV . . . . . . . . . . . . . . . . . . 7 4.2.1. Path Segment TLV . . . . . . . . . . . . . . . . . . 7
4.3. FEC Object . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. FEC Object . . . . . . . . . . . . . . . . . . . . . . . 9
4.4. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 10 4.4. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 10
5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. PCC Allocated Path Segment . . . . . . . . . . . . . . . 11 5.1. Stateful PCE Operation . . . . . . . . . . . . . . . . . 11
5.1.1. Egress PCC Allocated Path Segment . . . . . . . . . . 11 5.1.1. Ingress PCC-Initiated Path Segment Allocation . . . . 12
5.2. PCE Allocated Path Segment . . . . . . . . . . . . . . . 15 5.1.2. PCE Initiated Path Segment Allocation . . . . . . . . 13
5.2. PCECC Based Operation . . . . . . . . . . . . . . . . . . 15
5.2.1. PCE Controlled Label Spaces Advertisement . . . . . . 15 5.2.1. PCE Controlled Label Spaces Advertisement . . . . . . 15
5.2.2. Ingress PCC request Path Segment to PCE . . . . . . . 15 5.2.2. PCECC based Path Segment Allocation . . . . . . . . . 15
5.2.3. PCE allocated Path Segment on its own . . . . . . . . 17
6. Dataplane Considerations . . . . . . . . . . . . . . . . . . 17 6. Dataplane Considerations . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7.1. SR PCE Capability Flags . . . . . . . . . . . . . . . . . 18 7.1. SR PCE Capability Flags . . . . . . . . . . . . . . . . . 18
7.2. SRv6 PCE Capability Flags . . . . . . . . . . . . . . . . 18 7.2. SRv6 PCE Capability Flags . . . . . . . . . . . . . . . . 18
7.3. New LSP Flag Registry . . . . . . . . . . . . . . . . . . 18 7.3. New LSP Flag Registry . . . . . . . . . . . . . . . . . . 18
7.4. New PCEP TLV . . . . . . . . . . . . . . . . . . . . . . 19 7.4. New PCEP TLV . . . . . . . . . . . . . . . . . . . . . . 18
7.4.1. Path Segment TLV . . . . . . . . . . . . . . . . . . 19 7.4.1. Path Segment TLV . . . . . . . . . . . . . . . . . . 19
7.5. New CCI Flag Registry . . . . . . . . . . . . . . . . . . 19 7.5. New CCI Flag Registry . . . . . . . . . . . . . . . . . . 19
7.6. New FEC Type Registry . . . . . . . . . . . . . . . . . . 20 7.6. New FEC Type Registry . . . . . . . . . . . . . . . . . . 20
7.7. PCEP Error Type and Value . . . . . . . . . . . . . . . . 20 7.7. PCEP Error Type and Value . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . 22
skipping to change at page 5, line 37 skipping to change at page 5, line 37
[I-D.ietf-pce-segment-routing] defined a new Path Setup Type (PST) [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 and SR-PCE-CAPABILITY sub-TLV for SR. PCEP speakers use this sub-TLV
to exchange information about their SR capability. The TLV defines a to exchange information about their SR capability. The TLV defines a
Flags field that includes one bit (L-flag) to indicate Local Flags field that includes one bit (L-flag) to indicate Local
Significance [I-D.ietf-pce-segment-routing]. Significance [I-D.ietf-pce-segment-routing].
This document adds an additional flag for Path Segment allocation, as This document adds an additional flag for Path Segment allocation, as
follows - follows -
P (Path Segment Identification bit): A PCEP speaker sets this flag o P (Path Segment Identification bit): A PCEP speaker sets this flag
to 1 to indicate that it has the capability to encode SR path to 1 to indicate that it has the capability to encode SR path
identification (Path Segment, as per identification (Path Segment, as per
[I-D.ietf-spring-mpls-path-segment]). [I-D.ietf-spring-mpls-path-segment]).
0 1 2 3 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 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=TBD11 | Length=4 | | Type=TBD11 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |P|N|X| MSD | | Reserved | Flags |P|N|X| MSD |
skipping to change at page 6, line 19 skipping to change at page 6, line 19
[I-D.ietf-pce-segment-routing-ipv6] defined a new Path Setup Type [I-D.ietf-pce-segment-routing-ipv6] defined a new Path Setup Type
(PST) and SRv6-PCE-CAPABILITY sub-TLV for SRv6. PCEP speakers use (PST) and SRv6-PCE-CAPABILITY sub-TLV for SRv6. PCEP speakers use
this sub-TLV to exchange information about their SRv6 capability. this sub-TLV to exchange information about their SRv6 capability.
The TLV includes a Flags field and one bit (L-flag) was allocated in The TLV includes a Flags field and one bit (L-flag) was allocated in
[I-D.ietf-pce-segment-routing-ipv6]. [I-D.ietf-pce-segment-routing-ipv6].
This document adds an additional flag for Path Segment allocation, as This document adds an additional flag for Path Segment allocation, as
follows - follows -
P (Path Segment Identification bit): A PCEP speaker sets this flag o P (Path Segment Identification bit): A PCEP speaker sets this flag
to 1 to indicate that it has the capability to encode SRv6 path to 1 to indicate that it has the capability to encode SRv6 path
identification.(Path Segment, as per identification.(Path Segment, as per
[I-D.li-spring-srv6-path-segment]). [I-D.li-spring-srv6-path-segment]).
0 1 2 3 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 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=TBD1 | Length | | Type=TBD1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |P|L| | Reserved | Flags |P|L|
skipping to change at page 7, line 12 skipping to change at page 7, line 12
The PCECC Capability should also be advertised on the egress PCEP The PCECC Capability should also be advertised on the egress PCEP
session, along with the SR sub-TLVs. This is needed to ensure that session, along with the SR sub-TLVs. This is needed to ensure that
the PCE can use the PCECC objects/mechanism to request/inform the the PCE can use the PCECC objects/mechanism to request/inform the
egress PCC of the Path Segment as described in this document. egress PCC of the Path Segment as described in this document.
4.2. LSP Object 4.2. LSP Object
The LSP Object is defined in Section 7.3 of [RFC8231]. This document The LSP Object is defined in Section 7.3 of [RFC8231]. This document
adds the following flags to the LSP Object: adds the following flags to the LSP Object:
P (PCE Allocation bit): If the bit is set to 1, it indicates that o P (PCE Allocation bit): If the bit is set to 1, it indicates that
the PCC requests PCE to allocate resource for this LSP. With the the PCC requests PCE to allocate resource for this LSP. With the
resource TLV, a PCE can undertsand what kind of resource should be resource TLV, a PCE can undertsand what kind of resource should be
allocated, such as Path Segment and Binding Segment. A PCC would allocated, such as Path Segment and Binding Segment. A PCC would
set this bit to 1 and include a PATH-SEGMENT TLV in the LSP object set this bit to 1 and include a PATH-SEGMENT TLV in the LSP object
to request for allocation of Path Segment by the PCE in the PCReq to request for allocation of Path Segment by the PCE in the PCReq
or PCRpt message. A PCE would also set this bit to 1 and include or PCRpt message. A PCE would also set this bit to 1 and include
a PATH-SEGMENT TLV to indicate that the Path Segment is allocated a PATH-SEGMENT TLV to indicate that the Path Segment is allocated
by PCE and encoded in the PCRep, PCUpd or PCInitiate message. by PCE and encoded in the PCRep, PCUpd or PCInitiate message.
Further, a PCE would set this bit to 0 and include a PATH-SEGMENT Further, a PCE would set this bit to 0 and include a PATH-SEGMENT
TLV in the LSP object to indicate that the Path Segment should be TLV in the LSP object to indicate that the Path Segment should be
skipping to change at page 8, line 21 skipping to change at page 8, line 21
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ (Variable length) Path Segment ~ ~ (Variable length) Path Segment ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The PATH-SEGMENT TLV Format Figure 4: The PATH-SEGMENT TLV Format
The type (16-bit) of the TLV is TBA4 (to be allocated by IANA). The The type (16-bit) of the TLV is TBA4 (to be allocated by IANA). The
length (16-bit) has a fixed value of 8 octets. The value contains length (16-bit) has a fixed value of 8 octets. The value contains
the following fields: the following fields:
ST (The Segment type - 8 bits): The ST field specifies the type of o ST (The Segment type - 8 bits): The ST field specifies the type of
the Path Segment field, which carries a Path Segment corresponding the Path Segment field, which carries a Path Segment corresponding
to the SR path. to the SR path.
* 0: MPLS Path Segment, which is an MPLS label as defined in * 0: MPLS Path Segment, which is an MPLS label as defined in
[I-D.ietf-spring-mpls-path-segment]. The PST type MUST be set [I-D.ietf-spring-mpls-path-segment]. The PST type MUST be set
to SR (MPLS). to SR (MPLS).
* 1: SRv6 Path Segment, which is a 128 bit IPv6 address as * 1: SRv6 Path Segment, which is a 128 bit IPv6 address as
defined in [I-D.li-spring-srv6-path-segment]. The PST type defined in [I-D.li-spring-srv6-path-segment]. The PST type
MUST be set to SRv6. MUST be set to SRv6.
Flags (8 bits): Two flags are currently defined: o Flags (8 bits): Two flags are currently defined:
* L-Bit (Local/Global - 1 bit): If set, then the Path Segment * L-Bit (Local/Global - 1 bit): If set, then the Path Segment
carried by the PATH-SEGMENT TLV has local significance. If not carried by the PATH-SEGMENT TLV has local significance. If not
set, then the Path Segment carried by this TLV has global set, then the Path Segment carried by this TLV has global
significance (i.e. Path Segment is global within an SR significance (i.e. Path Segment is global within an SR
domain). domain).
* The unassigned bits MUST be set to 0 and MUST be ignored at * The unassigned bits MUST be set to 0 and MUST be ignored at
receipt. receipt.
Reserved (16 bits): MUST be set to 0 and MUST be ignored at o Reserved (16 bits): MUST be set to 0 and MUST be ignored at
receipt. receipt.
Path Segment: The Path Segment of an SR path. The Path Segment o Path Segment: The Path Segment of an SR path. The Path Segment
type is indicated by the ST field. When the ST is 0, it is a MPLS type is indicated by the ST field. When the ST is 0, it is a MPLS
Path Segment [I-D.ietf-spring-mpls-path-segment] in the MPLS label Path Segment [I-D.ietf-spring-mpls-path-segment] in the MPLS label
format. When the ST field is 1, it is a 128-bit SRv6 Path Segment format. When the ST field is 1, it is a 128-bit SRv6 Path Segment
as defined in [I-D.li-spring-srv6-path-segment]. as defined in [I-D.li-spring-srv6-path-segment].
In general, only one instance of PATH-SEGMENT TLV will be included in In general, only one instance of PATH-SEGMENT TLV will be included in
LSP object. If more than one PATH-SEGMENT TLV is included, the first LSP object. If more than one PATH-SEGMENT TLV is included, the first
one is processed and others MUST be ignored. Multiple Path Segment one is processed and others MUST be ignored. Multiple Path Segment
allocation for use cases like alternate-making will be considered in allocation for use cases like alternate-making will be considered in
future version of this draft. future version of this draft.
skipping to change at page 11, line 40 skipping to change at page 11, line 40
and [I-D.ietf-pce-segment-routing-ipv6] (which are further based on and [I-D.ietf-pce-segment-routing-ipv6] (which are further based on
[RFC8231] and [RFC8281]). The additional operations for Path Segment [RFC8231] and [RFC8281]). The additional operations for Path Segment
are defined in this section. are defined in this section.
To notify (or request) the Path Segment to the Egress PCC, the To notify (or request) the Path Segment to the Egress PCC, the
procedures are as per the PCECC-SR 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-pce-controller-sr] (which is based on
[I-D.ietf-pce-pcep-extension-for-pce-controller]). The additional [I-D.ietf-pce-pcep-extension-for-pce-controller]). The additional
operations are defined in this section. operations are defined in this section.
5.1. PCC Allocated Path Segment 5.1. Stateful PCE Operation
5.1.1. Egress PCC Allocated Path Segment
As defined in [I-D.ietf-spring-mpls-path-segment], a Path Segment can As defined in [I-D.ietf-spring-mpls-path-segment], a Path Segment can
be allocated by the egress PCC. In this case, the label space may be be allocated by the egress PCC. In this case, the label space is
maintained on the PCC itself. maintained on the PCC itself.
On receiving a stateful path computation request with Path Segment This section describes the mechanism of Path Segment allocation by
allocation request from an ingress PCC, or by initiating or updating using PCInitiate and PCUpd message in Stateful PCE model.
an LSP with Path Segment actively, a PCE can request the egress PCC
to allocate a Path Segment. This is needed if the PCE does not
control the Path Segment allocation for the egress PCC or the label
space is maintained by the egress PCC itself.
The mechanism of Path Segment request and reply may be achieved by
using PCInitiate and PCUpd message as described in this section.
5.1.1.1. Using CCI and FEC objects (PCECC)
The PCE can request the egress to allocate the Path Segment using the 5.1.1. Ingress PCC-Initiated Path Segment Allocation
PCInitiate message as described in
[I-D.zhao-pce-pcep-extension-pce-controller-sr]. The C flag in the
CCI object is set to 1 and the CC-ID is set to a special value of
0x0000 to indicate that the allocation needs to be done by the PCC.
The PATH-SEGMENT TLV is also be included in CCI object along with the
FEC object identifying the SR-Path. The egress PCC would allocate
the Path Segment and would report to the PCE using the PCRpt message
as described in [I-D.zhao-pce-pcep-extension-pce-controller-sr] with
the allocated Path Segment in the CC-ID field as well as in the PATH-
SEGMENT TLV.
(Editor's Note - An update is planned for The ingress PCC could request the Path Segment to be allocated by the
[I-D.zhao-pce-pcep-extension-pce-controller-sr] in the next revision PCE via PCRpt message. The delegate flag (D-flag) MUST also be set
detailing this procedure) for this LSP. Also, the P-flag in the LSP object MUST be set.
If the value of CC-ID/Path Segment is 0 and the C flag is set, it On receiving a stateful path computation request with Path Segment
indicates that the PCE is requesting a Path Segment for this LSP. If allocation request from an ingress PCC, a stateful PCE requests the
the CC-ID/Path Segment is set to a value 'n' and the C flag is set in egress PCC to allocate a Path Segment.
the CCI object, it indicates that the PCE requests a specific value
'n' of Path Segment. If the Path Segment is allocated successfully,
the egress PCC should report the Path Segment via PCRpt message with
the CCI object along with the PATH-SEGMENT TLV. Else, it MUST send a
PCErr message with Error-Type = TBA7 ("Path SID failure") and Error
Value = 1 ("Invalid SID"). If the value of Path Segment in CCI
object is valid, but the PCC is unable to allocate the Path Segment,
it MUST send a PCErr message with Error-Type = TBA7 ("Path label/SID
failure") and Error Value = 2 ("Unable to allocate the specified
label/SID").
Once the PCE receives the PCRpt message with the CCI object, it can The PATH-SEGMENT TLV MUST be included in an LSP object in the
obtain the Path Segment information from the egress PCC and then PCInitiate message sent from the PCE to the egress to request Path
update the path with Path Segment or reply to the ingress PCC, the Segment allocation by the egress PCC. The P flag in LSP object MUST
path information with Path Segment. be set to 0. This PCInitiate message to egress PCC would be the
similar to the one sent to ingress PCC as per
[I-D.ietf-pce-segment-routing], but the egress PCC would only
allocate the Path Segment and would not trigger the initiation/update
operation.
If the SR-Path is setup the ingress PCC will acknowledge with a PCRpt If the value of Path Segment is 0x0 it indicates that the PCE is
message to the PCE. In case of error, as described in requesting a Path Segment for this LSP. If the Path Segment is set
[I-D.ietf-pce-segment-routing], an PCErr message will be sent back to to a value 'n' and the P flag is unset in the LSP object, it
the PCE. The PCE MUST request the withdraw of the Path Segment indicates that the PCE requests a specific value 'n' of Path Segment.
allocation by sending a PCInitiate message to remove the central If the Path Segment is allocated successfully, the egress PCC reports
controller instruction as per the Path Segment via PCRpt message with PATH-SEGMENT TLV in LSP
[I-D.zhao-pce-pcep-extension-pce-controller-sr]. When the LSP is object. Else, it MUST send a PCErr message with Error-Type = TBA7
deleted or the Path Segment is removed, the PCE should synchronize ("Path SID failure") and Error Value = 1 ("Invalid SID"). If the
with the egress PCC. value of Path Segment is valid, but the PCC is unable to allocate the
Path Segment, it MUST send a PCErr message with Error-Type = TBA7
("Path label/SID failure") and Error Value = 2 ("Unable to allocate
the specified label/SID").
If the egress PCC wishes to withdraw or modify a previously reported Once the PCE receives the PCRpt message, it can obtain the Path
Path Segment value, it MUST send a PCRpt message without any PATH- Segment information from the egress PCC and then update the path with
SEGMENT TLV or with the PATH-SEGMENT TLV containing the new Path Path Segment by sending PCUpd message.
Segment respectively in the CCI object. The PCE would further
trigger the removal of the central controller instruction as per
[I-D.zhao-pce-pcep-extension-pce-controller-sr].
If a PCE wishes to modify a previously requested Path Segment value, If the Path Segment is updated successfully, the ingress PCC will
it MUST send a new PCInitiate message with an allocation request CC- acknowledge with a PCRpt message to the PCE. In case of error, as
ID/PATH-SEGMENT TLV containing the new Path Segment value and C flag described in [I-D.ietf-pce-segment-routing], an PCErr message with
is set. The PCE should trigger the removal of the older Path Segment Error-Type = TBA7 ("Path SID failure") and Error Value = 1 ("Invalid
next as per [I-D.zhao-pce-pcep-extension-pce-controller-sr]. SID") will be sent back to the PCE. The PCE MUST roll back the Path
Segment vlaue to the previous value by sending a PCUpd message to
synchronize with the egress PCC.
Ingress Egress Ingress Egress
+-+-+ +-+-+ +-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCC| |PCE| |PCC|
+-+-+ +-+-+ +-+-+ +-+-+ +-+-+ +-+-+
1) LSP State | ---- PCRpt ----> | | 1) LSP State | ---- PCRpt ----> | |
Delegate | Delegate=1 | | Delegate | Delegate=1 | |
| P=1 |2) PCE update | | P=1 |2) PCE update |
| | the LSP-DB and | | | the LSP-DB and |
| | request Path SID | | | request Path SID |
| | | | | |
| | --- PCInitiate ---> | Egress | | --- PCInitiate ---> | Egress
| | CC-ID=0 | allocates | | PATH-SEGMENT | allocates
| | FEC=Path | a Path-SID | | TLV in LSP | a Path-SID
| | | from its | | | from its
| | <----- PCRpt ------ | space | | <----- PCRpt ------ | space
| | CC-ID= |
| | Path SID | | | Path SID |
| | | | | |
|<---- PCUpd ---- |3)Paths update with | |<---- PCUpd ---- |3)Paths update with |
| PATH-SEGMENT TLV | Path SID | | PATH-SEGMENT TLV | Path SID |
| | | | | |
4) LSP State | ----- PCRpt ---> | | 4) LSP State | ----- PCRpt ---> | |
Report | | | Report | | |
| | | | | |
Figure 7: Egress PCC Allocated Path Segment Figure 7: Ingress PCC-Initiated Path Segment Allocation
5.1.1.2. Using LSP objects (PCEP-SR) If the ingress PCC wishes to withdraw or modify a previously reported
Path Segment value, it MUST send a PCRpt message without any PATH-
SEGMENT TLV or with the PATH-SEGMENT TLV containing the new Path
Segment respectively. The Path Segment MUST be withdrawed when the
corresponding LSP is removed. When the LSP is deleted or the Path
Segment is removed, the PCE should send a PCUpd message to
synchronize with the egress PCC.
The PATH-SEGMENT TLV MUST be included in an LSP object in the If an egress PCC receives a valid Path Segment value from a PCE which
PCInitiate message sent from the PCE to the egress to request path is different than the current Path Segment, it MUST try to allocate
identification allocation by the egress PCC. The P flag in LSP the new value. If the new Path Segment is successfully allocated,
object MUST be set to 0. This PCInitiate message to egress PCC would the egress PCC MUST report the new value to the PCE. Otherwise, it
be the similar to the one sent to ingress PCC as per MUST send a PCErr message with Error-Type = TBA7 ("Path label/SID
[I-D.ietf-pce-segment-routing], but the egress PCC would only failure") and Error Value = 2 ("Unable to allocate the specified
allocate the Path Segment and would not trigger the initiation/update label/SID").
operation.
If the value of Path Segment is 0x0 it indicates that the PCE is 5.1.2. PCE Initiated Path Segment Allocation
requesting a Path Segment for this LSP. If the Path Segment is set
to a value 'n' and the P flag is unset in the LSP object, it A stateful PCE also can initiate or update an LSP with Path Segment
indicates that the PCE requests a specific value 'n' of Path Segment. actively via requesting the egress PCC to allocate a Path Segment.
If the Path Segment is allocated successfully, the egress PCC should
report the Path Segment via PCRpt message with PATH-SEGMENT TLV in If a PCE wishes to modify a previously requested Path Segment value
LSP object. Else, it MUST send a PCErr message with Error-Type = or allocate a Path Segment for an PCE-Initiated LSP, it MUST request
TBA7 ("Path SID failure") and Error Value = 1 ("Invalid SID"). If the egress PCC to allocate a new value by sending a PCUpd message to
the value of Path Segment is valid, but the PCC is unable to allocate the egress PCC with PATH-SEGMENT TLV containing the new Path Segment
the Path Segment, it MUST send a PCErr message with Error-Type = TBA7 value. Also, the P flag in LSP object is unset. Absence of the
("Path label/SID failure") and Error Value = 2 ("Unable to allocate PATH-SEGMENT TLV in PCUpd message means that the PCE wishes to
the specified label/SID"). withdraw the Path Segment.
The mechanism of requesting Path Segment is as per Section 5.1.1.
Once the PCE receives the PCRpt message, it can obtain the Path Once the PCE receives the PCRpt message, it can obtain the Path
Segment information from the egress PCC and then update the path with Segment information from the egress PCC and then update or initiate
Path Segment or reply to the ingress PCC, the path information with an LSP with Path Segment.
Path Segment.
If the SR-Path is setup, the ingress PCC will acknowledge with a If the SR-Path is setup, the ingress PCC will acknowledge with a
PCRpt message to the PCE. In case of error, as described in PCRpt message to the PCE. In case of error, as described in
[I-D.ietf-pce-segment-routing], an PCErr message will be sent back to [I-D.ietf-pce-segment-routing], an PCErr message will be sent back to
the PCE. The PCE MUST request the withdraw of the Path Segment the PCE. The PCE MUST request the egress PCC to withdraw the LSP and
allocation by sending a PCUpd message to remove the LSP and associated Path Segment via PCUpd message with the R flag is set in
associated Path Segment by setting the R flag in the SRP object. the SRP object. When the LSP is deleted or the Path Segment is
When the LSP is deleted or the Path Segment is removed, the PCE removed, the PCE should send a PCUpd message to synchronize with the
should send a PCUpd message to synchronize with the egress PCC. egress PCC.
If the egress PCC wishes to withdraw or modify a previously reported
Path Segment value, it MUST send a PCRpt message without any PATH-
SEGMENT TLV or with the PATH-SEGMENT TLV containing the new Path
Segment respectively.
If a PCE wishes to modify a previously requested Path Segment value,
it MUST send a PCUpd message with PATH-SEGMENT TLV containing the new
Path Segment value and P flag is LSP object would be unset. Absence
of the PATH-SEGMENT TLV in PCUpd message means that the PCE wishes to
withdraw the Path Segment.
If a PCC receives a valid Path Segment value from a PCE which is If the Path Segment is updated successfully, the ingress PCC will
different than the current Path Segment, it MUST try to allocate the acknowledge with a PCRpt message to the PCE. In case of error, an
new value. If the new Path Segment is successfully allocated, the PCErr message with Error-Type = TBA7 ("Path SID failure") and Error
PCC MUST report the new value to the PCE. Otherwise, it MUST send a Value = 1 ("Invalid SID") will be sent back to the PCE. The PCE MUST
PCErr message with Error-Type = TBA7 ("Path label/SID failure") and roll back the Path Segment vlaue to the previous value by sending a
Error Value = 2 ("Unable to allocate the specified label/SID"). PCUpd message to synchronize with the egress PCC.
Ingress Egress Ingress Egress
+-+-+ +-+-+ +-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCC| |PCE| |PCC|
+-+-+ +-+-+ +-+-+ +-+-+ +-+-+ +-+-+
1) LSP State | ---- PCRpt ----> | | 1) LSP State | ---- PCRpt ----> | |
Delegate | Delegate=1 | | Delegate if| Delegate=1 | |
| P=1 |2) PCE update | the LSP exists| |2)PCE actively update|
| | the LSP-DB and | | | the LSP-DB and |
| | request Path SID | | | request Path SID |
| | | | | |
| | --- PCInitiate ---> | Egress | | --- PCInitiate ---> | Egress
| | PATH-SEGMENT | allocates | | PATH-SEGMENT | allocates
| | TLV in LSP | a Path-SID | | TLV in LSP | a Path-SID
| | | from its | | | from its
| | <----- PCRpt ------ | space | | <----- PCRpt ------ | space
| | Path SID | | | Path SID |
| | | | | |
|<---- PCUpd ---- |3)Paths update with | |<-- PCUpd/PCInit -- |3)Paths update with |
| PATH-SEGMENT TLV | Path SID | | PATH-SEGMENT TLV | Path SID |
| | | | | |
4) LSP State | ----- PCRpt ---> | | 4) LSP State | ----- PCRpt ---> | |
Report | | | Report | | |
| | | | | |
Figure 8: Egress PCC Allocated Path Segment Figure 8: Stateful PCE-Initiated Path Segment Allocation
5.2. PCE Allocated Path Segment 5.2. PCECC Based Operation
5.2.1. PCE Controlled Label Spaces Advertisement 5.2.1. PCE Controlled Label Spaces Advertisement
For allocating the Path Segments to SR paths by the PCEs, the PCE For allocating the Path Segments to SR paths by the PCEs, the PCE
controlled label space MUST be known at PCEs via configurations or controlled label space MUST be known at PCEs via configurations or
any other mechanism. The PCE controlled label spaces MAY be any other mechanisms. The PCE controlled label spaces MAY be
advertised as described in [I-D.li-pce-controlled-id-space]. advertised as described in [I-D.li-pce-controlled-id-space].
5.2.2. Ingress PCC request Path Segment to PCE 5.2.2. PCECC based Path Segment Allocation
5.2.2.1. PCECC-Initiated
The PCE could allocate the Path Segment on its own for a PCE-
Initiated (or delegated LSP). The allocated Path Segment 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-SEGMENT TLV in the LSP object.
The PCE would further inform the egress PCC about the Path Segment
allocated by the PCE using the PCInitiate message as described in
[I-D.zhao-pce-pcep-extension-pce-controller-sr].
Ingress Egress
+-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC|
+-+-+ +-+-+ +-+-+
| | |
| <--PCInitiate--- |1)Initiate LSP with |
| PATH-SEGMENT TLV | Path SID |
| | |
2)LSP delegation |---PCRpt, D=1---> | (Confirm) |
| | |
|3) PCE informs the | --- PCInitiate ---> |
| Path SID to Egress| FEC=Path |
| | |
| | <-------- PCRpt --- |
| | |
Figure 9: PCE allocated Path Segment on its own
5.2.2.2. Ingress PCC-Initiated PCECC
The ingress PCC could request the Path Segment to be allocated by the The ingress PCC could request the Path Segment to be allocated by the
PCE via PCRpt message as per [RFC8231]. The delegate flag (D-flag) PCE via PCRpt message as per [RFC8231]. The delegate flag (D-flag)
MUST also be set for this LSP. Also, the P-flag in the LSP object MUST also be set for this LSP. Also, the P-flag in the LSP object
MUST be set. MUST be set.
A PATH-SEGMENT TLV MUST be included in the LSP object. If the value A PATH-SEGMENT TLV MUST be included in the LSP object. If the value
of Path Segment is 0x0, it indicates that the Ingress PCC is of Path Segment is 0x0, it indicates that the Ingress PCC is
requesting a Path Segment for this LSP. If the Path Segment is set requesting a Path Segment for this LSP. If the Path Segment is set
to a value 'n', it indicates that the ingress PCC requests a specific to a value 'n', it indicates that the ingress PCC requests a specific
skipping to change at page 16, line 50 skipping to change at page 17, line 25
| PATH-SEGMENT TLV | Path SID | | PATH-SEGMENT TLV | Path SID |
| | | | | |
4) LSP State Report | ----- PCRpt ---> | | 4) LSP State Report | ----- PCRpt ---> | |
| | | | | |
|5) PCE informs the | --- PCInitiate ---> | |5) PCE informs the | --- PCInitiate ---> |
| Path SID to Egress| FEC=Path | | Path SID to Egress| FEC=Path |
| | | | | |
| | <-------- PCRpt --- | | | <-------- PCRpt --- |
| | | | | |
Figure 9: Ingress PCC request Path Segment to PCE Figure 10: Ingress PCC request Path Segment to PCE
5.2.3. PCE allocated Path Segment on its own
The PCE could allocate the Path Segment on its own for a PCE-
Initiated (or delegated LSP). The allocated Path Segment 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-SEGMENT TLV in the LSP object.
The PCE would further inform the egress PCC about the Path Segment
allocated by the PCE using the PCInitiate message as described in
[I-D.zhao-pce-pcep-extension-pce-controller-sr].
Ingress Egress
+-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC|
+-+-+ +-+-+ +-+-+
| | |
| <--PCInitiate--- |1)Initiate LSP with |
| PATH-SEGMENT TLV | Path SID |
| | |
2)LSP delegation |---PCRpt, D=1---> | (Confirm) |
| | |
|3) PCE informs the | --- PCInitiate ---> |
| Path SID to Egress| FEC=Path |
| | |
| | <-------- PCRpt --- |
| | |
Figure 10: PCE allocated Path Segment on its own
6. Dataplane Considerations 6. Dataplane Considerations
As described in [I-D.ietf-spring-mpls-path-segment], in an SR-MPLS As described in [I-D.ietf-spring-mpls-path-segment], in an SR-MPLS
network, when a packet is transmitted along an SR path, the labels in network, when a packet is transmitted along an SR path, the labels in
the MPLS label stack will be swapped or popped. So that no label or the MPLS label stack will be swapped or popped. So that no label or
only the last label may be left in the MPLS label stack when the only the last label may be left in the MPLS label stack when the
packet reaches the egress node. Thus, the egress node cannot packet reaches the egress node. Thus, the egress node cannot
determine from which SR path the packet comes. For this reason, it determine from which SR path the packet comes. For this reason, it
introduces the Path Segment. introduces the Path Segment.
skipping to change at page 22, line 18 skipping to change at page 22, line 18
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>. <https://www.rfc-editor.org/info/rfc8281>.
[I-D.ietf-pce-segment-routing] [I-D.ietf-pce-segment-routing]
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "PCEP Extensions for Segment Routing", and J. Hardwick, "PCEP Extensions for Segment Routing",
draft-ietf-pce-segment-routing-16 (work in progress), draft-ietf-pce-segment-routing-16 (work in progress),
March 2019. March 2019.
[I-D.ietf-pce-segment-routing-ipv6] [I-D.ietf-pce-segment-routing-ipv6]
Negi, M., Li, C., Sivabalan, S., and P. Kaladharan, "PCEP Negi, M., Li, C., Sivabalan, S., Kaladharan, P., and Y.
Extensions for Segment Routing leveraging the IPv6 data Zhu, "PCEP Extensions for Segment Routing leveraging the
plane", draft-ietf-pce-segment-routing-ipv6-00 (work in IPv6 data plane", draft-ietf-pce-segment-routing-ipv6-02
progress), March 2019. (work in progress), April 2019.
[I-D.zhao-pce-pcep-extension-pce-controller-sr] [I-D.zhao-pce-pcep-extension-pce-controller-sr]
Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures
and Protocol Extensions for Using PCE as a Central and Protocol Extensions for Using PCE as a Central
Controller (PCECC) of SR-LSPs", draft-zhao-pce-pcep- Controller (PCECC) of SR-LSPs", draft-zhao-pce-pcep-
extension-pce-controller-sr-04 (work in progress), extension-pce-controller-sr-04 (work in progress),
February 2019. February 2019.
[I-D.ietf-pce-pcep-extension-for-pce-controller] [I-D.ietf-pce-pcep-extension-for-pce-controller]
Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures
and Protocol Extensions for Using PCE as a Central and Protocol Extensions for Using PCE as a Central
Controller (PCECC) of LSPs", draft-ietf-pce-pcep- Controller (PCECC) of LSPs", draft-ietf-pce-pcep-
extension-for-pce-controller-01 (work in progress), extension-for-pce-controller-01 (work in progress),
February 2019. February 2019.
[I-D.li-spring-srv6-path-segment] [I-D.li-spring-srv6-path-segment]
Li, C., Chen, M., Dhody, D., Li, Z., Dong, J., and R. Li, C., Cheng, W., Chen, M., Dhody, D., Li, Z., Dong, J.,
Gandhi, "Path Segment for SRv6 (Segment Routing in IPv6)", and R. Gandhi, "Path Segment for SRv6 (Segment Routing in
draft-li-spring-srv6-path-segment-00 (work in progress), IPv6)", draft-li-spring-srv6-path-segment-01 (work in
October 2018. progress), June 2019.
11.2. Informative References 11.2. Informative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>. <https://www.rfc-editor.org/info/rfc4655>.
[RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, DOI 10.17487/RFC4657, September Requirements", RFC 4657, DOI 10.17487/RFC4657, September
2006, <https://www.rfc-editor.org/info/rfc4657>. 2006, <https://www.rfc-editor.org/info/rfc4657>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[I-D.li-pce-controlled-id-space] [I-D.li-pce-controlled-id-space]
Li, C., Chen, M., Dong, J., Li, Z., Wang, A., and C. Zhou, Li, C., Chen, M., Dong, J., Li, Z., Wang, A., Cheng, W.,
"PCE Controlled ID Space", draft-li-pce-controlled-id- and C. Zhou, "PCE Controlled ID Space", draft-li-pce-
space-02 (work in progress), March 2019. controlled-id-space-03 (work in progress), June 2019.
[I-D.ietf-spring-mpls-path-segment] [I-D.ietf-spring-mpls-path-segment]
Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler,
"Path Segment in MPLS Based Segment Routing Network", "Path Segment in MPLS Based Segment Routing Network",
draft-ietf-spring-mpls-path-segment-00 (work in progress), draft-ietf-spring-mpls-path-segment-00 (work in progress),
March 2019. March 2019.
Authors' Addresses Authors' Addresses
Cheng Li Cheng Li
 End of changes. 43 change blocks. 
183 lines changed or deleted 154 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/