draft-ietf-pce-segment-routing-15.txt   draft-ietf-pce-segment-routing-16.txt 
PCE S. Sivabalan PCE S. Sivabalan
Internet-Draft C. Filsfils Internet-Draft C. Filsfils
Updates: 8408 (if approved) Cisco Systems, Inc. Updates: 8408 (if approved) Cisco Systems, Inc.
Intended status: Standards Track J. Tantsura Intended status: Standards Track J. Tantsura
Expires: August 16, 2019 Apstra, Inc. Expires: September 5, 2019 Apstra, Inc.
W. Henderickx W. Henderickx
Nokia Nokia
J. Hardwick J. Hardwick
Metaswitch Networks Metaswitch Networks
February 12, 2019 March 4, 2019
PCEP Extensions for Segment Routing PCEP Extensions for Segment Routing
draft-ietf-pce-segment-routing-15 draft-ietf-pce-segment-routing-16
Abstract Abstract
Segment Routing (SR) enables any head-end node to select any path Segment Routing (SR) enables any head-end node to select any path
without relying on a hop-by-hop signaling technique (e.g., LDP or without relying on a hop-by-hop signaling technique (e.g., LDP or
RSVP-TE). It depends only on "segments" that are advertised by link- RSVP-TE). It depends only on "segments" that are advertised by link-
state Interior Gateway Protocols (IGPs). A Segment Routing Path can state Interior Gateway Protocols (IGPs). A Segment Routing Path can
be derived from a variety of mechanisms, including an IGP Shortest be derived from a variety of mechanisms, including an IGP Shortest
Path Tree (SPT), explicit configuration, or a Path Computation Path Tree (SPT), explicit configuration, or a Path Computation
Element (PCE). This document specifies extensions to the Path Element (PCE). This document specifies extensions to the Path
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 August 16, 2019. This Internet-Draft will expire on September 5, 2019.
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 42 skipping to change at page 2, line 42
4. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 7 4. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 7 4.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. The Path Setup Type Capability TLV . . . . . . . . . 7 4.1.1. The Path Setup Type Capability TLV . . . . . . . . . 7
4.1.2. The SR PCE Capability sub-TLV . . . . . . . . . . . . 8 4.1.2. The SR PCE Capability sub-TLV . . . . . . . . . . . . 8
4.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . . . 9 4.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . . . 9
4.3. ERO . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. ERO . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3.1. SR-ERO Subobject . . . . . . . . . . . . . . . . . . 9 4.3.1. SR-ERO Subobject . . . . . . . . . . . . . . . . . . 9
4.3.2. NAI Associated with SID . . . . . . . . . . . . . . . 12 4.3.2. NAI Associated with SID . . . . . . . . . . . . . . . 12
4.4. RRO . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.4. RRO . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.5. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 14 4.5. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 14
5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Exchanging the SR PCE Capability . . . . . . . . . . . . 14 5.1. Exchanging the SR PCE Capability . . . . . . . . . . . . 15
5.2. ERO Processing . . . . . . . . . . . . . . . . . . . . . 16 5.2. ERO Processing . . . . . . . . . . . . . . . . . . . . . 16
5.2.1. SR-ERO Validation . . . . . . . . . . . . . . . . . . 16 5.2.1. SR-ERO Validation . . . . . . . . . . . . . . . . . . 16
5.2.2. Interpreting the SR-ERO . . . . . . . . . . . . . . . 18 5.2.2. Interpreting the SR-ERO . . . . . . . . . . . . . . . 18
5.3. RRO Processing . . . . . . . . . . . . . . . . . . . . . 20 5.3. RRO Processing . . . . . . . . . . . . . . . . . . . . . 20
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 20 6. Management Considerations . . . . . . . . . . . . . . . . . . 21
7. Management Considerations . . . . . . . . . . . . . . . . . . 21 6.1. Controlling the Path Setup Type . . . . . . . . . . . . . 21
7.1. Controlling the Path Setup Type . . . . . . . . . . . . . 21 6.2. Migrating a Network to Use PCEP Segment Routed Paths . . 22
7.2. Migrating a Network to Use PCEP Segment Routed Paths . . 22 6.3. Verification of Network Operation . . . . . . . . . . . . 23
7.3. Verification of Network Operation . . . . . . . . . . . . 23 6.4. Relationship to Existing Management Models . . . . . . . 24
7.4. Relationship to Existing Management Models . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9.1. PCEP ERO and RRO subobjects . . . . . . . . . . . . . . . 25 8.1. PCEP ERO and RRO subobjects . . . . . . . . . . . . . . . 24
9.2. New NAI Type Registry . . . . . . . . . . . . . . . . . . 25 8.2. New NAI Type Registry . . . . . . . . . . . . . . . . . . 25
9.3. New SR-ERO Flag Registry . . . . . . . . . . . . . . . . 25 8.3. New SR-ERO Flag Registry . . . . . . . . . . . . . . . . 25
9.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 26 8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 26
9.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 27 8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 27
9.6. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators . . . 27 8.6. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators . . . 27
9.7. New Path Setup Type . . . . . . . . . . . . . . . . . . . 28 8.7. New Path Setup Type . . . . . . . . . . . . . . . . . . . 28
9.8. New Metric Type . . . . . . . . . . . . . . . . . . . . . 28 8.8. New Metric Type . . . . . . . . . . . . . . . . . . . . . 28
9.9. SR PCE Capability Flags . . . . . . . . . . . . . . . . . 28 8.9. SR PCE Capability Flags . . . . . . . . . . . . . . . . . 28
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. Normative References . . . . . . . . . . . . . . . . . . 29 11.1. Normative References . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . 30 11.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Compatibility with Early Implementations . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
Segment Routing (SR) leverages the source routing paradigm. Using Segment Routing (SR) leverages the source routing paradigm. Using
SR, a source node steers a packet through a path without relying on SR, a source node steers a packet through a path without relying on
hop-by-hop signaling protocols such as LDP or RSVP-TE. Each path is hop-by-hop signaling protocols such as LDP or RSVP-TE. Each path is
specified as an ordered list of instructions called "segments". Each specified as an ordered list of instructions called "segments". Each
segment is an instruction to route the packet to a specific place in segment is an instruction to route the packet to a specific place in
the network, or to perform a function on the packet. A database of the network, or to perform a function on the packet. A database of
skipping to change at page 7, line 44 skipping to change at page 7, line 44
4.1.1. The Path Setup Type Capability TLV 4.1.1. The Path Setup Type Capability TLV
[RFC8408] defines the PATH-SETUP-TYPE-CAPABILITY TLV for use in the [RFC8408] defines the PATH-SETUP-TYPE-CAPABILITY TLV for use in the
OPEN object. The PATH-SETUP-TYPE-CAPABILITY TLV contains an optional OPEN object. The PATH-SETUP-TYPE-CAPABILITY TLV contains an optional
list of sub-TLVs which are intended to convey parameters that are list of sub-TLVs which are intended to convey parameters that are
associated with the path setup types supported by a PCEP speaker. associated with the path setup types supported by a PCEP speaker.
This specification updates [RFC8408], as follows. It creates a new This specification updates [RFC8408], as follows. It creates a new
registry which defines the valid type indicators of the sub-TLVs of registry which defines the valid type indicators of the sub-TLVs of
the PATH-SETUP-TYPE-CAPABILITY TLV (see Section 9.6). A PCEP speaker the PATH-SETUP-TYPE-CAPABILITY TLV (see Section 8.6). A PCEP speaker
MUST NOT include a sub-TLV in the PATH-SETUP-TYPE-CAPABILITY TLV MUST NOT include a sub-TLV in the PATH-SETUP-TYPE-CAPABILITY TLV
unless it appears in this registry. If a PCEP speaker receives a unless it appears in this registry. If a PCEP speaker receives a
sub-TLV whose type indicator does not match one of those from the sub-TLV whose type indicator does not match one of those from the
registry, or else is not recognised by the speaker, then the speaker registry, or else is not recognised by the speaker, then the speaker
MUST ignore the sub-TLV. MUST ignore the sub-TLV.
4.1.2. The SR PCE Capability sub-TLV 4.1.2. The SR PCE Capability sub-TLV
This document defines a new Path Setup Type (PST) for SR, as follows: This document defines a new Path Setup Type (PST) for SR, as follows:
skipping to change at page 10, line 45 skipping to change at page 10, line 45
by the receiver. This document describes the following NT values: by the receiver. This document describes the following NT values:
NT=0 The NAI is absent. NT=0 The NAI is absent.
NT=1 The NAI is an IPv4 node ID. NT=1 The NAI is an IPv4 node ID.
NT=2 The NAI is an IPv6 node ID. NT=2 The NAI is an IPv6 node ID.
NT=3 The NAI is an IPv4 adjacency. NT=3 The NAI is an IPv4 adjacency.
NT=4 The NAI is an IPv6 adjacency. NT=4 The NAI is an IPv6 adjacency with global IPv6 addresses.
NT=5 The NAI is an unnumbered adjacency with IPv4 node IDs. NT=5 The NAI is an unnumbered adjacency with IPv4 node IDs.
NT=6 The NAI is an IPv6 adjacency with link-local IPv6 addresses.
Flags: Used to carry additional information pertaining to the SID. Flags: Used to carry additional information pertaining to the SID.
This document defines the following flag bits. The other bits This document defines the following flag bits. The other bits
MUST be set to zero by the sender and MUST be ignored by the MUST be set to zero by the sender and MUST be ignored by the
receiver. receiver.
* M: If this bit is set to 1, the SID value represents an MPLS * M: If this bit is set to 1, the SID value represents an MPLS
label stack entry as specified in [RFC3032]. Otherwise, the label stack entry as specified in [RFC3032]. Otherwise, the
SID value is an administratively configured value which SID value is an administratively configured value which
represents an index into an MPLS label space (either SRGB or represents an index into an MPLS label space (either SRGB or
SRLB) per [RFC8402]. SRLB) per [RFC8402].
skipping to change at page 12, line 29 skipping to change at page 12, line 29
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IPv4 address | | Local IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote IPv4 address | | Remote IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: NAI for IPv4 adjacency Figure 3: NAI for IPv4 adjacency
'IPv6 Adjacency' is specified as a pair of IPv6 addresses. In this 'IPv6 Global Adjacency' is specified as a pair of global IPv6
case, the NT value is 4 and the NAI field length is 32 octets. addresses. It is used to describe an IPv6 adjacency for a link
The format of the NAI is shown in the following figure: that uses global IPv6 addresses. Each global IPv6 address is
configured on a specific router interface, so together they
identify an adjacency between a pair of routers. In this case,
the NT value is 4 and the NAI field length is 32 octets. The
format of the NAI is shown in the following figure:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local IPv6 address (16 octets) // // Local IPv6 address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Remote IPv6 address (16 octets) // // Remote IPv6 address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: NAI for IPv6 adjacency Figure 4: NAI for IPv6 global adjacency
'Unnumbered Adjacency with IPv4 NodeIDs' is specified as a pair of 'Unnumbered Adjacency with IPv4 NodeIDs' is specified as a pair of
Node ID / Interface ID tuples. In this case, the NT value is 5 (node ID, interface ID) tuples. In this case, the NT value is 5
and the NAI field length is 16 octets. The format of the NAI is and the NAI field length is 16 octets. The format of the NAI is
shown in the following figure: shown in the following figure:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Node-ID | | Local Node-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID | | Local Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Node-ID | | Remote Node-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface ID | | Remote Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: NAI for Unnumbered adjacency with IPv4 Node IDs Figure 5: NAI for Unnumbered adjacency with IPv4 Node IDs
'IPv6 Link-Local Adjacency' is specified as a pair of (global IPv6
address, interface ID) tuples. It is used to describe an IPv6
adjacency for a link that uses only link local IPv6 addresses.
Each global IPv6 address is configured on a specific router, so
together they identify a pair of adjacent routers. The interface
IDs identify the link that the adjacency is formed over. In this
case, the NT value is 6 and the NAI field length is 40 octets.
The format of the NAI is shown in the following figure:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local IPv6 address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Remote IPv6 address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: NAI for IPv6 link-local adjacency
4.4. RRO 4.4. RRO
A PCC reports an SR-TE LSP to a PCE by sending a PCRpt message, per A PCC reports an SR-TE LSP to a PCE by sending a PCRpt message, per
[RFC8231]. The RRO on this message represents the SID list that was [RFC8231]. The RRO on this message represents the SID list that was
applied by the PCC, that is, the actual path taken by the LSP. The applied by the PCC, that is, the actual path taken by the LSP. The
procedures of [RFC8231] with respect to the RRO apply equally to this procedures of [RFC8231] with respect to the RRO apply equally to this
specification without change. specification without change.
An RRO contains one or more subobjects called "SR-RRO subobjects" An RRO contains one or more subobjects called "SR-RRO subobjects"
whose format is shown below: whose format is shown below:
skipping to change at page 13, line 40 skipping to change at page 14, line 15
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=36 | Length | NT | Flags |F|S|C|M| | Type=36 | Length | NT | Flags |F|S|C|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID | | SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NAI (variable) // // NAI (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: SR-RRO Subobject format Figure 7: SR-RRO Subobject format
The format of the SR-RRO subobject is the same as that of the SR-ERO The format of the SR-RRO subobject is the same as that of the SR-ERO
subobject, but without the L flag. subobject, but without the L flag.
A PCC MUST order the SR-RRO subobjects such that the first subobject A PCC MUST order the SR-RRO subobjects such that the first subobject
relative to the beginning of the RRO identifies the first segment relative to the beginning of the RRO identifies the first segment
visited by the SR-TE LSP, and the last subobject identifies the final visited by the SR-TE LSP, and the last subobject identifies the final
segment of the SR-TE LSP, that is, its endpoint. segment of the SR-TE LSP, that is, its endpoint.
4.5. METRIC Object 4.5. METRIC Object
skipping to change at page 16, line 44 skipping to change at page 17, line 17
o If NT=3, the F bit MUST be zero. If the S bit is 1, the Length o If NT=3, the F bit MUST be zero. If the S bit is 1, the Length
MUST be 12, otherwise the Length MUST be 16. MUST be 12, otherwise the Length MUST be 16.
o If NT=4, the F bit MUST be zero. If the S bit is 1, the Length o If NT=4, the F bit MUST be zero. If the S bit is 1, the Length
MUST be 36, otherwise the Length MUST be 40. MUST be 36, otherwise the Length MUST be 40.
o If NT=5, the F bit MUST be zero. If the S bit is 1, the Length o If NT=5, the F bit MUST be zero. If the S bit is 1, the Length
MUST be 20, otherwise the Length MUST be 24. MUST be 20, otherwise the Length MUST be 24.
o If NT=6, the F bit MUST be zero. If the S bit is 1, the Length
MUST be 44, otherwise the Length MUST be 48.
If a PCC finds that the NT field, Length field, S bit and F bit are If a PCC finds that the NT field, Length field, S bit and F bit are
not consistent, it MUST consider the entire ERO invalid and MUST send not consistent, it MUST consider the entire ERO invalid and MUST send
a PCErr message with Error-Type = 10 ("Reception of an invalid a PCErr message with Error-Type = 10 ("Reception of an invalid
object") and Error-Value = 11 ("Malformed object"). object") and Error-Value = 11 ("Malformed object").
If a PCC does not recognise or support the value in the NT field, it If a PCC does not recognise or support the value in the NT field, it
MUST consider the entire ERO invalid and MUST send a PCErr message MUST consider the entire ERO invalid and MUST send a PCErr message
with Error-Type = 10 ("Reception of an invalid object") and Error- with Error-Type = 10 ("Reception of an invalid object") and Error-
Value = TBD2 ("Unsupported NAI Type in Segment ERO subobject"). Value = TBD2 ("Unsupported NAI Type in Segment ERO subobject").
skipping to change at page 20, line 40 skipping to change at page 21, line 13
subobject types"). subobject types").
The SR-RRO subobjects can be classified according to whether they The SR-RRO subobjects can be classified according to whether they
contain a SID representing an MPLS label value or a SID representing contain a SID representing an MPLS label value or a SID representing
an index value, or no SID. If a PCE detects that the SR-RRO an index value, or no SID. If a PCE detects that the SR-RRO
subobjects are a mixture of more than one of these types, then it subobjects are a mixture of more than one of these types, then it
MUST send a PCErr message with Error-Type = 10 ("Reception of an MUST send a PCErr message with Error-Type = 10 ("Reception of an
invalid object") and Error-Value = TBD9 ("Inconsistent SIDs in SR-ERO invalid object") and Error-Value = TBD9 ("Inconsistent SIDs in SR-ERO
/ SR-RRO subobjects"). / SR-RRO subobjects").
6. Backward Compatibility 6. Management Considerations
A PCEP speaker that does not support the SR PCEP capability cannot
recognize the SR-ERO or SR-RRO subobjects. As such, it responds
according to the rules for a malformed object, per [RFC5440].
Some implementations, which are compliant with an earlier version of
this specification, do not send the PATH-SETUP-TYPE-CAPABILITY TLV in
their OPEN objects. Instead, to indicate that they support SR, these
implementations include the SR-CAPABILITY-TLV as a top-level TLV in
the OPEN object. Unfortunately, some of these implementations made
it into the field before this document was published in its final
form. Therefore, if a PCEP speaker receives an OPEN object in which
the SR-CAPABILITY-TLV appears as a top-level TLV, then it MUST
interpret this as though the sender had sent a PATH-SETUP-TYPE-
CAPABILITY TLV with a PST list of (0, 1) (that is, both RSVP-TE and
SR-TE PSTs are supported) and with the SR-CAPABILITY-TLV as a sub-
TLV. If a PCEP speaker receives an OPEN object in which both the SR-
CAPABILITY-TLV and PATH-SETUP-TYPE-CAPABILITY TLV appear as top-level
TLVs, then it MUST ignore the top-level SR-CAPABILITY-TLV and process
only the PATH-SETUP-TYPE-CAPABILITY TLV.
7. Management Considerations
This document adds a new path setup type to PCEP to allow LSPs to be This document adds a new path setup type to PCEP to allow LSPs to be
set up using segment routing techniques. This path setup type may be set up using segment routing techniques. This path setup type may be
used with PCEP alongside other path setup types, such as RSVP-TE, or used with PCEP alongside other path setup types, such as RSVP-TE, or
it may be used exclusively. it may be used exclusively.
7.1. Controlling the Path Setup Type 6.1. Controlling the Path Setup Type
The following factors control which path setup type is used for a The following factors control which path setup type is used for a
given LSP. given LSP.
o The available path setup types are constrained to those that are o The available path setup types are constrained to those that are
supported by, or enabled on, the PCEP speakers. The PATH-SETUP- supported by, or enabled on, the PCEP speakers. The PATH-SETUP-
TYPE-CAPABILITY TLV indicates which path setup types a PCEP TYPE-CAPABILITY TLV indicates which path setup types a PCEP
speaker supports. To use segment routing as a path setup type, it speaker supports. To use segment routing as a path setup type, it
is a prerequisite that the PCC and PCE both include PST=1 in the is a prerequisite that the PCC and PCE both include PST=1 in the
list of supported path setup types in this TLV, and also include list of supported path setup types in this TLV, and also include
skipping to change at page 22, line 29 skipping to change at page 22, line 27
requested for an LSP nominates segment routing or RSVP-TE as the requested for an LSP nominates segment routing or RSVP-TE as the
path setup type. path setup type.
o PCC implementations MAY allow the operator to configure a o PCC implementations MAY allow the operator to configure a
preference for the PCC to nominate segment routing or RSVP-TE as preference for the PCC to nominate segment routing or RSVP-TE as
the path setup type if none is specified for an LSP. the path setup type if none is specified for an LSP.
o PCC implementations SHOULD allow the operator to configure a PCC o PCC implementations SHOULD allow the operator to configure a PCC
to refuse to set up an LSP using an undesired path setup type. to refuse to set up an LSP using an undesired path setup type.
7.2. Migrating a Network to Use PCEP Segment Routed Paths 6.2. Migrating a Network to Use PCEP Segment Routed Paths
This section discusses the steps that the operator takes when This section discusses the steps that the operator takes when
migrating a network to enable PCEP to set up paths using segment migrating a network to enable PCEP to set up paths using segment
routing as the path setup type. routing as the path setup type.
o The operator enables the segment routing PST on the PCE servers. o The operator enables the segment routing PST on the PCE servers.
o The operator enables the segment routing PST on the PCCs. o The operator enables the segment routing PST on the PCCs.
o The operator resets each PCEP session. The PCEP sessions come o The operator resets each PCEP session. The PCEP sessions come
skipping to change at page 23, line 21 skipping to change at page 23, line 18
and wait instead for a manual reset. and wait instead for a manual reset.
Once segment routing is enabled on a PCEP session, it can be used as Once segment routing is enabled on a PCEP session, it can be used as
the path setup type for future LSPs. the path setup type for future LSPs.
User traffic is not automatically migrated from existing LSPs onto User traffic is not automatically migrated from existing LSPs onto
segment routed LSPs just by enabling the segment routing PST in PCEP. segment routed LSPs just by enabling the segment routing PST in PCEP.
The migration of user traffic from existing LSPs onto segment routing The migration of user traffic from existing LSPs onto segment routing
LSPs is beyond the scope of this document. LSPs is beyond the scope of this document.
7.3. Verification of Network Operation 6.3. Verification of Network Operation
The operator needs the following information to verify that PCEP is The operator needs the following information to verify that PCEP is
operating correctly with respect to the segment routing path setup operating correctly with respect to the segment routing path setup
type. type.
o An implementation SHOULD allow the operator to view whether the o An implementation SHOULD allow the operator to view whether the
PCEP speaker sent the segment routing PST capability to its peer. PCEP speaker sent the segment routing PST capability to its peer.
If the PCEP speaker is a PCC, then the implementation SHOULD also If the PCEP speaker is a PCC, then the implementation SHOULD also
allow the operator to view the values of the L and N flags that allow the operator to view the values of the L and N flags that
were sent, and the value of the MSD field that was sent. were sent, and the value of the MSD field that was sent.
skipping to change at page 24, line 11 skipping to change at page 24, line 9
o If a PCEP speaker decides to use a different PST to the one that o If a PCEP speaker decides to use a different PST to the one that
was proposed, or requested, for an LSP, then the implementation was proposed, or requested, for an LSP, then the implementation
SHOULD create a log to inform the operator that the expected PST SHOULD create a log to inform the operator that the expected PST
has not been used. The log SHOULD give the reason for this choice has not been used. The log SHOULD give the reason for this choice
(local policy, equipment capability etc.) (local policy, equipment capability etc.)
o If a PCEP speaker rejects a segment routing path, then it SHOULD o If a PCEP speaker rejects a segment routing path, then it SHOULD
create a log to inform the operator, giving the reason for the create a log to inform the operator, giving the reason for the
decision (local policy, MSD exceeded etc.) decision (local policy, MSD exceeded etc.)
7.4. Relationship to Existing Management Models 6.4. Relationship to Existing Management Models
The PCEP YANG module is defined in [I-D.ietf-pce-pcep-yang]. In The PCEP YANG module is defined in [I-D.ietf-pce-pcep-yang]. In
future, this YANG module should be extended or augmented to provide future, this YANG module should be extended or augmented to provide
the following additional information relating to segment routing: the following additional information relating to segment routing:
o The advertised PST capabilities and MSD per PCEP session. o The advertised PST capabilities and MSD per PCEP session.
o The PST configured for, and used by, each LSP. o The PST configured for, and used by, each LSP.
The PCEP MIB [RFC7420] could also be updated to include this The PCEP MIB [RFC7420] could also be updated to include this
information. information.
8. Security Considerations 7. Security Considerations
The security considerations described in [RFC5440], [RFC8231], The security considerations described in [RFC5440], [RFC8231],
[RFC8281] and [RFC8408] are applicable to this specification. No [RFC8281] and [RFC8408] are applicable to this specification. No
additional security measure is required. additional security measure is required.
Note that this specification enables a network controller to Note that this specification enables a network controller to
instantiate a path in the network without the use of a hop-by-hop instantiate a path in the network without the use of a hop-by-hop
signaling protocol (such as RSVP-TE). This creates an additional signaling protocol (such as RSVP-TE). This creates an additional
vulnerability if the security mechanisms of [RFC5440], [RFC8231] and vulnerability if the security mechanisms of [RFC5440], [RFC8231] and
[RFC8281] are not used. If there is no integrity protection on the [RFC8281] are not used. If there is no integrity protection on the
skipping to change at page 24, line 47 skipping to change at page 24, line 45
signaling protocol. signaling protocol.
Note that this specification adds the MSD field to the OPEN message Note that this specification adds the MSD field to the OPEN message
(see Section 4.1.2) which discloses how many MPLS labels the sender (see Section 4.1.2) which discloses how many MPLS labels the sender
can push onto packets that it forwards into the network. If the can push onto packets that it forwards into the network. If the
security mechanisms of [RFC8231] and [RFC8281] are not used with security mechanisms of [RFC8231] and [RFC8281] are not used with
strong encryption, then an attacker could use this new field to gain strong encryption, then an attacker could use this new field to gain
intelligence about the capabilities of the edge devices in the intelligence about the capabilities of the edge devices in the
network. network.
9. IANA Considerations 8. IANA Considerations
9.1. PCEP ERO and RRO subobjects
8.1. PCEP ERO and RRO subobjects
This document defines a new subobject type for the PCEP explicit This document defines a new subobject type for the PCEP explicit
route object (ERO), and a new subobject type for the PCEP record route object (ERO), and a new subobject type for the PCEP record
route object (RRO). The code points for subobject types of these route object (RRO). The code points for subobject types of these
objects is maintained in the RSVP parameters registry, under the objects is maintained in the RSVP parameters registry, under the
EXPLICIT_ROUTE and ROUTE_RECORD objects. IANA is requested to EXPLICIT_ROUTE and ROUTE_RECORD objects. IANA is requested to
confirm the early allocation of the following code points in the RSVP confirm the early allocation of the following code points in the RSVP
Parameters registry for each of the new subobject types defined in Parameters registry for each of the new subobject types defined in
this document. this document.
Object Subobject Subobject Type Object Subobject Subobject Type
--------------------- -------------------------- ------------------ --------------------- -------------------------- ------------------
EXPLICIT_ROUTE SR-ERO (PCEP-specific) 36 EXPLICIT_ROUTE SR-ERO (PCEP-specific) 36
ROUTE_RECORD SR-RRO (PCEP-specific) 36 ROUTE_RECORD SR-RRO (PCEP-specific) 36
9.2. New NAI Type Registry 8.2. New NAI Type Registry
IANA is requested to create a new sub-registry within the "Path IANA is requested to create a new sub-registry within the "Path
Computation Element Protocol (PCEP) Numbers" registry called "PCEP Computation Element Protocol (PCEP) Numbers" registry called "PCEP
SR-ERO NAI Types". The allocation policy for this new registry SR-ERO NAI Types". The allocation policy for this new registry
should be by IETF Review. The new registry should contain the should be by IETF Review. The new registry should contain the
following values: following values:
Value Description Reference Value Description Reference
0 NAI is absent. This document 0 NAI is absent. This document
1 NAI is an IPv4 node ID. This document 1 NAI is an IPv4 node ID. This document
2 NAI is an IPv6 node ID. This document 2 NAI is an IPv6 node ID. This document
3 NAI is an IPv4 adjacency. This document 3 NAI is an IPv4 adjacency. This document
4 NAI is an IPv6 adjacency. This document 4 NAI is an IPv6 adjacency with This document
global IPv6 addresses.
5 NAI is an unnumbered This document 5 NAI is an unnumbered This document
adjacency with IPv4 node IDs. adjacency with IPv4 node IDs.
6 NAI is an IPv6 adjacency with This document
link-local IPv6 addresses.
9.3. New SR-ERO Flag Registry 8.3. New SR-ERO Flag Registry
IANA is requested to create a new sub-registry, named "SR-ERO Flag IANA is requested to create a new sub-registry, named "SR-ERO Flag
Field", within the "Path Computation Element Protocol (PCEP) Numbers" Field", within the "Path Computation Element Protocol (PCEP) Numbers"
registry to manage the Flag field of the SR-ERO subobject. New registry to manage the Flag field of the SR-ERO subobject. New
values are to be assigned by Standards Action [RFC8126]. Each bit values are to be assigned by Standards Action [RFC8126]. Each bit
should be tracked with the following qualities: should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
skipping to change at page 26, line 17 skipping to change at page 26, line 16
0-7 Unassigned 0-7 Unassigned
8 NAI is absent (F) This document 8 NAI is absent (F) This document
9 SID is absent (S) This document 9 SID is absent (S) This document
10 SID specifies TC, S This document 10 SID specifies TC, S This document
and TTL in addition and TTL in addition
to an MPLS label (C) to an MPLS label (C)
11 SID specifies an MPLS This document 11 SID specifies an MPLS This document
label (M) label (M)
9.4. PCEP-Error Object 8.4. PCEP-Error Object
IANA is requested to confirm the early allocation of the code-points IANA is requested to confirm the early allocation of the code-points
in the PCEP-ERROR Object Error Types and Values registry for the in the PCEP-ERROR Object Error Types and Values registry for the
following new error-values: following new error-values:
Error-Type Meaning Error-Type Meaning
---------- ------- ---------- -------
10 Reception of an invalid object. 10 Reception of an invalid object.
Error-value = 2: Bad label value Error-value = 2: Bad label value
skipping to change at page 27, line 35 skipping to change at page 27, line 35
Note to IANA: some Error-values in the above list were defined after Note to IANA: some Error-values in the above list were defined after
the early allocation took place, and so do not currently have a code the early allocation took place, and so do not currently have a code
point assigned. Please assign code points from the indicated point assigned. Please assign code points from the indicated
registry and replace each instance of "TBD1", "TBD2" etc. in this registry and replace each instance of "TBD1", "TBD2" etc. in this
document with the respective code points. document with the respective code points.
Note to IANA: some of the Error-value descriptive strings above have Note to IANA: some of the Error-value descriptive strings above have
changed since the early allocation. Please refresh the registry. changed since the early allocation. Please refresh the registry.
9.5. PCEP TLV Type Indicators 8.5. PCEP TLV Type Indicators
IANA is requested to confirm the early allocation of the following IANA is requested to confirm the early allocation of the following
code point in the PCEP TLV Type Indicators registry. Note that this code point in the PCEP TLV Type Indicators registry. Note that this
TLV type indicator is deprecated but retained to ensure backwards TLV type indicator is deprecated but retained in the registry to
compatibility with early implementations of this specification. See ensure compatibility with early implementations of this
Section 6 for details. specification. See Appendix A for details.
Value Meaning Reference Value Meaning Reference
------------------------- ---------------------------- -------------- ------------------------- ---------------------------- --------------
26 SR-PCE-CAPABILITY This document 26 SR-PCE-CAPABILITY This document
(deprecated) (deprecated)
9.6. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators 8.6. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators
IANA is requested to create a new sub-registry, named "PATH-SETUP- IANA is requested to create a new sub-registry, named "PATH-SETUP-
TYPE-CAPABILITY Sub-TLV Type Indicators", within the "Path TYPE-CAPABILITY Sub-TLV Type Indicators", within the "Path
Computation Element Protocol (PCEP) Numbers" registry to manage the Computation Element Protocol (PCEP) Numbers" registry to manage the
type indicator space for sub-TLVs of the PATH-SETUP-TYPE-CAPABILITY type indicator space for sub-TLVs of the PATH-SETUP-TYPE-CAPABILITY
TLV. New values are to be assigned by Standards Action [RFC8126]. TLV. New values are to be assigned by Standards Action [RFC8126].
The valid range of values in the registry is 0-65535. IANA is The valid range of values in the registry is 0-65535. IANA is
requested to initialize the registry with the following values. All requested to initialize the registry with the following values. All
other values in the registry should be marked as "Unassigned". other values in the registry should be marked as "Unassigned".
Value Meaning Reference Value Meaning Reference
------------------------- ---------------------------- -------------- ------------------------- ---------------------------- --------------
0 Reserved This document 0 Reserved This document
TBD11 (recommended 26) SR-PCE-CAPABILITY This document TBD11 (recommended 26) SR-PCE-CAPABILITY This document
Note to IANA: Please replace each instance of "TBD11" in this Note to IANA: Please replace each instance of "TBD11" in this
document with the allocated code point. We have recommended that document with the allocated code point. We have recommended that
value 26 be used for consistency with the deprecated value in the value 26 be used for consistency with the deprecated value in the
PCEP TLV Type Indicators registry. PCEP TLV Type Indicators registry.
9.7. New Path Setup Type 8.7. New Path Setup Type
[RFC8408] created a sub-registry within the "Path Computation Element [RFC8408] created a sub-registry within the "Path Computation Element
Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types".
IANA is requested to allocate a new code point within this registry, IANA is requested to allocate a new code point within this registry,
as follows: as follows:
Value Description Reference Value Description Reference
------------------------- ---------------------------- -------------- ------------------------- ---------------------------- --------------
1 Traffic engineering path is This document 1 Traffic engineering path is This document
setup using Segment Routing. setup using Segment Routing.
9.8. New Metric Type 8.8. New Metric Type
IANA is requested to confirm the early allocation of the following IANA is requested to confirm the early allocation of the following
code point in the PCEP METRIC object T field registry: code point in the PCEP METRIC object T field registry:
Value Description Reference Value Description Reference
------------------------- ---------------------------- -------------- ------------------------- ---------------------------- --------------
11 Segment-ID (SID) Depth. This document 11 Segment-ID (SID) Depth. This document
9.9. SR PCE Capability Flags 8.9. SR PCE Capability Flags
IANA is requested to create a new sub-registry, named "SR Capability IANA is requested to create a new sub-registry, named "SR Capability
Flag Field", within the "Path Computation Element Protocol (PCEP) Flag Field", within the "Path Computation Element Protocol (PCEP)
Numbers" registry to manage the Flag field of the SR-PCE-CAPABILITY Numbers" registry to manage the Flag field of the SR-PCE-CAPABILITY
TLV. New values are to be assigned by Standards Action [RFC8126]. TLV. New values are to be assigned by Standards Action [RFC8126].
Each bit should be tracked with the following qualities: Each bit should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
o Defining RFC o Defining RFC
skipping to change at page 29, line 18 skipping to change at page 29, line 18
0-5 Unassigned 0-5 Unassigned
6 Node or Adjacency This document 6 Node or Adjacency This document
Identifier (NAI) is Identifier (NAI) is
supported (N) supported (N)
7 Unlimited Maximum SID This document 7 Unlimited Maximum SID This document
Depth (X) Depth (X)
Note to IANA: The name of bit 7 has changed from "Unlimited Maximum Note to IANA: The name of bit 7 has changed from "Unlimited Maximum
SID Depth (L)" to "Unlimited Maximum SID Depth (X)". SID Depth (L)" to "Unlimited Maximum SID Depth (X)".
10. Contributors 9. Contributors
The following people contributed to this document: The following people contributed to this document:
- Lakshmi Sharma - Lakshmi Sharma
- Jan Medved - Jan Medved
- Edward Crabbe - Edward Crabbe
- Robert Raszuk - Robert Raszuk
- Victor Lopez - Victor Lopez
11. Acknowledgements 10. Acknowledgements
We thank Ina Minei, George Swallow, Marek Zavodsky, Dhruv Dhody, Ing- We thank Ina Minei, George Swallow, Marek Zavodsky, Dhruv Dhody, Ing-
Wher Chen and Tomas Janciga for the valuable comments. Wher Chen and Tomas Janciga for the valuable comments.
12. References 11. References
12.1. Normative References 11.1. Normative References
[I-D.ietf-spring-segment-routing-mpls] [I-D.ietf-spring-segment-routing-mpls]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-18 data plane", draft-ietf-spring-segment-routing-mpls-18
(work in progress), December 2018. (work in progress), December 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
skipping to change at page 30, line 41 skipping to change at page 30, line 41
[RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
Hardwick, "Conveying Path Setup Type in PCE Communication Hardwick, "Conveying Path Setup Type in PCE Communication
Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408,
July 2018, <https://www.rfc-editor.org/info/rfc8408>. July 2018, <https://www.rfc-editor.org/info/rfc8408>.
[RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg,
"Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491,
DOI 10.17487/RFC8491, November 2018, DOI 10.17487/RFC8491, November 2018,
<https://www.rfc-editor.org/info/rfc8491>. <https://www.rfc-editor.org/info/rfc8491>.
12.2. Informative References 11.2. Informative References
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and
d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header
(SRH)", draft-ietf-6man-segment-routing-header-16 (work in (SRH)", draft-ietf-6man-segment-routing-header-16 (work in
progress), February 2019. progress), February 2019.
[I-D.ietf-idr-bgp-ls-segment-routing-msd] [I-D.ietf-idr-bgp-ls-segment-routing-msd]
Tantsura, J., Chunduri, U., Mirsky, G., and S. Sivabalan, Tantsura, J., Chunduri, U., Mirsky, G., and S. Sivabalan,
"Signaling MSD (Maximum SID Depth) using Border Gateway "Signaling MSD (Maximum SID Depth) using Border Gateway
skipping to change at page 32, line 20 skipping to change at page 32, line 20
[RFC8413] Zhuang, Y., Wu, Q., Chen, H., and A. Farrel, "Framework [RFC8413] Zhuang, Y., Wu, Q., Chen, H., and A. Farrel, "Framework
for Scheduled Use of Resources", RFC 8413, for Scheduled Use of Resources", RFC 8413,
DOI 10.17487/RFC8413, July 2018, DOI 10.17487/RFC8413, July 2018,
<https://www.rfc-editor.org/info/rfc8413>. <https://www.rfc-editor.org/info/rfc8413>.
[RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak,
"Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476,
DOI 10.17487/RFC8476, December 2018, DOI 10.17487/RFC8476, December 2018,
<https://www.rfc-editor.org/info/rfc8476>. <https://www.rfc-editor.org/info/rfc8476>.
Appendix A. Compatibility with Early Implementations
An early implementation of this specification will send the SR-
CAPABILITY-TLV as a top-level TLV in the OPEN object instead of
sending the PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN object.
Implementations that wish to interoperate with such early
implementations should also send the SR-CAPABILITY-TLV as a top-level
TLV in their OPEN object and should interpret receiving this top-
level TLV as though the sender had sent a PATH-SETUP-TYPE-CAPABILITY
TLV with a PST list of (0, 1) (that is, both RSVP-TE and SR-TE PSTs
are supported) with the SR-CAPABILITY-TLV as a sub-TLV. If a PCEP
speaker receives an OPEN object in which both the SR-CAPABILITY-TLV
and PATH-SETUP-TYPE-CAPABILITY TLV appear as top-level TLVs, then it
should ignore the top-level SR-CAPABILITY-TLV and process only the
PATH-SETUP-TYPE-CAPABILITY TLV.
Authors' Addresses Authors' Addresses
Siva Sivabalan Siva Sivabalan
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive 2000 Innovation Drive
Kanata, Ontario K2K 3E8 Kanata, Ontario K2K 3E8
Canada Canada
Email: msiva@cisco.com Email: msiva@cisco.com
Clarence Filsfils Clarence Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
Pegasus Parc Pegasus Parc
De kleetlaan 6a, DIEGEM BRABANT 1831 De kleetlaan 6a, DIEGEM BRABANT 1831
BELGIUM BELGIUM
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Jeff Tantsura Jeff Tantsura
Apstra, Inc. Apstra, Inc.
 End of changes. 40 change blocks. 
84 lines changed or deleted 114 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/