draft-ietf-pce-lsp-setup-type-10.txt   rfc8408.txt 
PCE Working Group S. Sivabalan Internet Engineering Task Force (IETF) S. Sivabalan
Internet-Draft Cisco Systems, Inc. Request for Comments: 8408 Cisco Systems, Inc.
Intended status: Standards Track J. Tantsura Category: Standards Track J. Tantsura
Expires: November 5, 2018 Nuage Networks ISSN: 2070-1721 Nuage Networks
I. Minei I. Minei
Google, Inc. Google, Inc.
R. Varga R. Varga
Pantheon Technologies SRO Pantheon Technologies SRO
J. Hardwick J. Hardwick
Metaswitch Networks Metaswitch Networks
May 4, 2018 July 2018
Conveying path setup type in PCEP messages Conveying Path Setup Type
draft-ietf-pce-lsp-setup-type-10 in PCE Communication Protocol (PCEP) Messages
Abstract Abstract
A Path Computation Element (PCE) can compute Traffic Engineering (TE) A Path Computation Element (PCE) can compute Traffic Engineering (TE)
paths through a network that are subject to various constraints. paths through a network; these paths are subject to various
Currently, TE paths are Label Switched Paths (LSPs) which are set up constraints. Currently, TE paths are Label Switched Paths (LSPs)
using the RSVP-TE signaling protocol. However, other TE path setup that are set up using the RSVP-TE signaling protocol. However, other
methods are possible within the PCE architecture. This document TE path setup methods are possible within the PCE architecture. This
proposes an extension to the PCE communication protocol (PCEP) to document proposes an extension to the PCE Communication Protocol
allow support for different path setup methods over a given PCEP (PCEP) to allow support for different path setup methods over a given
session. PCEP session.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on November 5, 2018. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8408.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Path Setup Type Capability TLV . . . . . . . . . . . . . . . 4 3. Path Setup Type Capability TLV . . . . . . . . . . . . . . . 4
4. Path Setup Type TLV . . . . . . . . . . . . . . . . . . . . . 6 4. Path Setup Type TLV . . . . . . . . . . . . . . . . . . . . . 6
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Manageability Considerations . . . . . . . . . . . . . . . . 8 6. Manageability Considerations . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 9 8.1. Additions to PCEP TLV Type Indicators Registry . . . . . 9
8.2. New Path Setup Type Registry . . . . . . . . . . . . . . 9 8.2. New PCEP Path Setup Types Registry . . . . . . . . . . . 9
8.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 10 8.3. Additions to PCEP-ERROR Object Error Types and Values
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 Registry . . . . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 11 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
[RFC5440] describes the Path Computation Element communication [RFC5440] describes the PCE Communication Protocol (PCEP) for
Protocol (PCEP) for communication between a Path Computation Client communication between a Path Computation Client (PCC) and a Path
(PCC) and a Path Computation Element (PCE), or between a PCE and a Computation Element (PCE) or between a PCE and a PCE. A PCC
PCE. A PCC requests a path subject to various constraints and requests, from a PCE, a path subject to various constraints and
optimization criteria from a PCE. The PCE responds to the PCC with a optimization criteria. The PCE responds to the PCC with a hop-by-hop
hop-by-hop path in an Explicit Route Object (ERO). The PCC uses the path in an Explicit Route Object (ERO). The PCC uses the ERO to set
ERO to set up the path in the network. up the path in the network.
[RFC8231] specifies extensions to PCEP that allow a PCC to delegate [RFC8231] specifies extensions to PCEP that allow a PCC to delegate
its LSPs to a PCE. The PCE can then update the state of LSPs its LSPs to a PCE. The PCE can then update the state of LSPs
delegated to it. In particular, the PCE may modify the path of an delegated to it. In particular, the PCE may modify the path of an
LSP by sending a new ERO. The PCC uses this ERO to re-route the LSP LSP by sending a new ERO. The PCC uses this ERO to reroute the LSP
in a make-before-break fashion. [RFC8281] specifies a mechanism in a make-before-break fashion. [RFC8281] specifies a mechanism that
allowing a PCE to dynamically instantiate an LSP on a PCC by sending allows a PCE to dynamically instantiate an LSP on a PCC by sending
the ERO and the characteristics of the LSP. The PCC creates the LSP the ERO and the characteristics of the LSP. The PCC creates the LSP
using the ERO and other attributes sent by the PCE. using the ERO and other attributes sent by the PCE.
So far, PCEP and its extensions have assumed that the TE paths are So far, PCEP and its extensions have assumed that the TE paths are
label switched and are established via the RSVP-TE protocol. label switched and are established via the RSVP-TE signaling
However, other methods of LSP setup are possible in the PCE protocol. However, other methods of LSP setup are possible in the
architecture (see [RFC4655] and [RFC4657]). This document PCE architecture (see [RFC4655] and [RFC4657]). This document
generalizes PCEP to allow other LSP setup methods to be used. It generalizes PCEP to allow other LSP setup methods to be used. It
defines two new TLVs and specifies the base procedures to facilitate defines two new TLVs and specifies the base procedures to facilitate
this, as follows. this:
o The PATH-SETUP-TYPE-CAPABILITY TLV, which allows a PCEP speaker to o The PATH-SETUP-TYPE-CAPABILITY TLV allows a PCEP speaker to
announce which LSP setup methods it supports when the PCEP session announce which LSP setup methods it supports when the PCEP session
is established. is established.
o The PATH-SETUP-TYPE TLV, which allows a PCEP speaker to specify o The PATH-SETUP-TYPE TLV allows a PCEP speaker to specify which
which setup method should be used for a given LSP. When multiple setup method should be used for a given LSP. When multiple path
path setup types are deployed in a network, a given PCEP session setup types are deployed in a network, a given PCEP session may
may have to simultaneously support more than one path setup type. have to simultaneously support more than one path setup type. A
A PCEP speaker uses the PATH-SETUP-TYPE TLV to explicitly indicate PCEP speaker uses the PATH-SETUP-TYPE TLV to explicitly indicate
the intended path setup type in the appropriate PCEP messages, the intended path setup type in the appropriate PCEP messages,
unless the path setup type is RSVP-TE (which is assumed to be the unless the path setup type is RSVP-TE (which is assumed to be the
path setup type if no other setup type is indicated). This is so path setup type if no other setup type is indicated). This is so
that both the PCC and the PCE can take the necessary steps to set that both the PCC and the PCE can take the necessary steps to set
up the path. up the path.
This document defines a path setup type code for RSVP-TE. When a new This document defines a path setup type code for RSVP-TE. When a new
path setup type (other than RSVP-TE) is introduced for setting up a path setup type (other than RSVP-TE) is introduced for setting up a
path, a path setup type code and, optionally, a sub-TLV pertaining to path, a path setup type code and, optionally, a sub-TLV pertaining to
the new path setup type will be defined by the document that the new path setup type will be defined by the document that
specifies the new path setup type. specifies the new path setup type.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Terminology 2. Terminology
The following terminologies are used in this document: The following terminology is used in this document:
ERO: Explicit Route Object.
LSR: Label Switching Router. ERO: Explicit Route Object
PCC: Path Computation Client. PCC: Path Computation Client
PCE: Path Computation Element. PCE: Path Computation Element
PCEP: Path Computation Element Protocol. PCEP: PCE Communication Protocol
PST: Path Setup Type. PST: Path Setup Type
TLV: Type, Length, and Value. TLV: Type, Length, and Value
3. Path Setup Type Capability TLV 3. Path Setup Type Capability TLV
A PCEP speaker indicates which PSTs it supports during the PCEP A PCEP speaker indicates which PSTs it supports during the PCEP
initialization phase, as follows. When the PCEP session is created, initialization phase using the following process. When the PCEP
it sends an Open message with an OPEN object containing the PATH- session is created, it sends an Open message with an OPEN object
SETUP-TYPE-CAPABILITY TLV. The format of this TLV is as follows. containing the PATH-SETUP-TYPE-CAPABILITY TLV. The format of this
TLV is as follows.
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 (34) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Num of PSTs | | Reserved | Num of PSTs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PST#1 | ... | PST#N | Padding | | PST#1 | ... | PST#N | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional sub-TLVs (variable) // // Optional sub-TLVs (variable) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PATH-SETUP-TYPE-CAPABILITY TLV Figure 1: PATH-SETUP-TYPE-CAPABILITY TLV
The TLV type is TBD1 (to be assigned by IANA). Its reserved field The TLV Type is 34. Its Reserved field MUST be set to zero by the
MUST be set to zero by the sender and MUST be ignored by the sender and MUST be ignored by the receiver. The other fields in the
receiver. The other fields in the TLV are as follows. TLV are as follows.
Length: The total length in bytes of the remainder of the TLV, that Length: The total length in bytes of the remainder of the TLV, that
is, excluding the Type and Length fields. is, excluding the Type and Length fields.
Number of PSTs: The number of PSTs in the following list, excluding Num of PSTs: The number of PSTs in the following list, excluding
padding. padding.
List of PSTs: A list of the PSTs that the PCEP speaker supports. List of PSTs: A list of the PSTs that the PCEP speaker supports.
Each PST is a single byte in length. Duplicate entries in this Each PST is a single byte in length. Duplicate entries in this
list MUST be ignored. The PCEP speaker MUST pad the list with list MUST be ignored. The PCEP speaker MUST pad the list with
zeros so that it is a muliple of four bytes in length. This zeros so that it is a multiple of four bytes in length. This
document defines the following PST value: document defines the following PST value:
* PST = 0: Path is setup using the RSVP-TE signaling protocol. * PST = 0: Path is set up using the RSVP-TE signaling protocol
Optional sub-TLVs: A list of sub-TLVs associated with the supported Optional sub-TLVs: A list of sub-TLVs associated with the supported
PSTs. Each PST has zero or one sub-TLVs associated with it, and PSTs. Each PST has zero or one sub-TLVs associated with it, and
each sub-TLV is associated with exactly one PST. Each sub-TLV each sub-TLV is associated with exactly one PST. Each sub-TLV
MUST obey the rules for TLV formatting defined in ([RFC5440]). MUST obey the rules for TLV formatting defined in [RFC5440]. That
That is, each sub-TLV is padded to a four byte alignment, and the is, each sub-TLV is padded to a four-byte alignment, and the
length field of each sub-TLV does not include the padding bytes. Length field of each sub-TLV does not include the padding bytes.
This document does not define any sub-TLVs; an example can be This document does not define any sub-TLVs; an example sub-TLV can
found in [I-D.ietf-pce-segment-routing]. be found in [PCEP-EXTENSIONS].
A PCEP speaker MUST check that this TLV is correctly formatted, as A PCEP speaker MUST check that this TLV is correctly formatted, as
follows. follows.
o If there are no sub-TLVs, then the TLV length field MUST be equal o If there are no sub-TLVs, then the TLV Length field MUST be equal
to four bytes plus the size of the PST list, excluding any padding to four bytes plus the size of the PST list, excluding any padding
bytes. bytes.
o If there are sub-TLVs then the TLV Length field MUST be equal to o If there are sub-TLVs, then the TLV Length field MUST be equal to
four bytes plus the size of the PST list (rounded up to the four bytes plus the size of the PST list (rounded up to the
nearest multiple of four) plus the size of the appended sub-TLVs nearest multiple of four) plus the size of the appended sub-TLVs,
excluding any padding bytes in the final sub-TLV. excluding any padding bytes in the final sub-TLV.
o The Number of PSTs field MUST be greater than zero. o The Num of PSTs field MUST be greater than zero.
If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV which If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV that
violates these rules, then the PCEP speaker MUST send a PCErr message violates these rules, then the PCEP speaker MUST send a PCErr message
with Error-Type = 10 (Reception of an invalid object) and Error-Value with Error-Type = 10 (Reception of an invalid object) and Error-value
= 11 (Malformed object) and MUST close the PCEP session. The PCEP = 11 (Malformed object) and MUST close the PCEP session. The PCEP
speaker MAY include the malformed OPEN object in the PCErr message as speaker MAY include the malformed OPEN object in the PCErr message as
well. well.
If a PCEP speaker receives an OPEN object with more than one PATH- If a PCEP speaker receives an OPEN object with more than one PATH-
SETUP-TYPE-CAPABILITY TLV then it MUST ignore all but the first SETUP-TYPE-CAPABILITY TLV, then it MUST ignore all but the first
instance of this TLV. instance of this TLV.
The absence of the PATH-SETUP-TYPE-CAPABILITY TLV from the OPEN The absence of the PATH-SETUP-TYPE-CAPABILITY TLV from the OPEN
object is equivalent to a PATH-SETUP-TYPE-CAPABILITY TLV containing a object is equivalent to a PATH-SETUP-TYPE-CAPABILITY TLV containing a
single PST of 0 (RSVP-TE signaling protocol) and no sub-TLVs. A PCEP single PST value of 0 (Path is set up using the RSVP-TE signaling
speaker MAY omit the PATH-SETUP-TYPE-CAPABILITY TLV if the only PST protocol) and no sub-TLVs. A PCEP speaker MAY omit the PATH-SETUP-
it supports is RSVP-TE. If a PCEP speaker supports other PSTs TYPE-CAPABILITY TLV if the only PST it supports is RSVP-TE. If a
besides RSVP-TE, then it SHOULD include the PATH-SETUP-TYPE- PCEP speaker supports other PSTs besides RSVP-TE, then it SHOULD
CAPABILITY TLV in its OPEN object. include the PATH-SETUP-TYPE-CAPABILITY TLV in its OPEN object.
If a PCEP speaker does not recognize the PATH-SETUP-TYPE-CAPABILITY If a PCEP speaker does not recognize the PATH-SETUP-TYPE-CAPABILITY
TLV, it will ignore the TLV in accordance with [RFC5440]. TLV, it will ignore the TLV in accordance with [RFC5440].
4. Path Setup Type TLV 4. Path Setup Type TLV
When a PCEP session is used to set up TE paths using different When a PCEP session is used to set up TE paths using different
methods, the corresponding PCE and PCC must be aware of the path methods, the corresponding PCE and PCC must be aware of the path
setup method used. That means, a PCE must be able to specify paths setup method used. This means that a PCE must be able to specify
in the correct format and a PCC must be able to take control plane paths in the correct format, and a PCC must be able to take control-
and forwarding plane actions appropriate to the PST. plane and forwarding-plane actions appropriate to the PST.
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 (28) | Length (4) | | Type (28) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | PST | | Reserved | PST |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: PATH-SETUP-TYPE TLV Figure 2: PATH-SETUP-TYPE TLV
PATH-SETUP-TYPE TLV is an optional TLV associated with the RP The PATH-SETUP-TYPE TLV is an optional TLV associated with the
([RFC5440]) and the SRP ([RFC8231]) objects. Its format is shown in Request Parameters (RP) [RFC5440] and the Stateful PCE Request
the above figure. The TLV type is 28. Its reserved field MUST be Parameters (SRP) [RFC8231] objects. Its format is shown in Figure 2.
set to zero. The one byte value contains the PST as defined for the The TLV type is 28. Its Reserved field MUST be set to zero. The
PATH-SETUP-TYPE-CAPABILITY TLV. one-byte PST field contains the PST as defined for the PATH-SETUP-
TYPE-CAPABILITY TLV.
The absence of the PATH-SETUP-TYPE TLV is equivalent to a PATH-SETUP- The absence of the PATH-SETUP-TYPE TLV is equivalent to a PATH-SETUP-
TYPE TLV with a PST value of 0 (RSVP-TE). A PCEP speaker MAY omit TYPE TLV with a PST value of 0 (Path is set up using the RSVP-TE
the TLV if the PST is RSVP-TE. If the RP or SRP object contains more signaling protocol). A PCEP speaker MAY omit the TLV if the PST is
than one PATH-SETUP-TYPE TLV, only the first TLV MUST be processed RSVP-TE. If the RP or SRP object contains more than one PATH-SETUP-
and the rest MUST be ignored. TYPE TLV, only the first TLV MUST be processed, and the rest MUST be
ignored.
If a PCEP speaker does not recognize the PATH-SETUP-TYPE TLV, it will If a PCEP speaker does not recognize the PATH-SETUP-TYPE TLV, it will
ignore the TLV in accordance with [RFC5440], and will use RSVP-TE to ignore the TLV in accordance with [RFC5440] and use RSVP-TE to set up
set up the path. the path.
5. Operation 5. Operation
During the PCEP initialization phase, if a PCEP speaker receives a During the PCEP initialization phase, if a PCEP speaker receives a
PATH-SETUP-TYPE-CAPABILITY TLV from its peer, it MUST assume that the PATH-SETUP-TYPE-CAPABILITY TLV from its peer, it MUST assume that the
peer supports only the PSTs listed in the TLV. If the PCEP speaker peer supports only the PSTs listed in the TLV. If the PCEP speaker
and its peer have no PSTs in common, then the PCEP speaker MUST send and its peer have no PSTs in common, then the PCEP speaker MUST send
a PCErr message with Error-Type = 21 (Invalid traffic engineering a PCErr message with Error-Type = 21 (Invalid traffic engineering
path setup type) and Error-Value = 2 (Mismatched path setup type) and path setup type) and Error-value = 2 (Mismatched path setup type) and
close the PCEP session. close the PCEP session.
If the peer has sent no PATH-SETUP-TYPE-CAPABILITY TLV, then the PCEP If the peer has sent no PATH-SETUP-TYPE-CAPABILITY TLV, then the PCEP
speaker MUST infer that the peer supports path setup using at least speaker MUST infer that the peer supports path setup using at least
RSVP-TE. The PCEP speaker MAY also infer that the peer supports RSVP-TE. The PCEP speaker MAY also infer that the peer supports
other path setup types, but the means of inference are outside the other path setup types, but the means of inference are outside the
scope of this document. scope of this document.
When a PCC sends a PCReq message to a PCE ([RFC5440]), it MUST When a PCC sends a PCReq message to a PCE [RFC5440], it MUST include
include the PATH-SETUP-TYPE TLV in the RP object, unless the intended the PATH-SETUP-TYPE TLV in the RP object, unless the intended PST is
PST is RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. RSVP-TE (in which case it MAY omit the PATH-SETUP-TYPE TLV). If the
If the PCE is capable of expressing the path in a format appropriate PCE is capable of expressing the path in a format appropriate to the
to the intended PST, it MUST use the appropriate ERO format in the intended PST, it MUST use the appropriate ERO format in the PCRep
PCRep message. message.
When a PCE sends a PCRep message to a PCC ([RFC5440]), it MUST When a PCE sends a PCRep message to a PCC [RFC5440], it MUST include
include the PATH-SETUP-TYPE TLV in the RP object, unless the PST is the PATH-SETUP-TYPE TLV in the RP object, unless the PST is RSVP-TE
RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. If the (in which case it MAY omit the PATH-SETUP-TYPE TLV). If the PCE does
PCE does not support the intended PST, it MUST send a PCErr message not support the intended PST, it MUST send a PCErr message with
with Error-Type = 21 (Invalid traffic engineering path setup type) Error-Type = 21 (Invalid traffic engineering path setup type) and
and Error-Value = 1 (Unsupported path setup type) and close the PCEP Error-value = 1 (Unsupported path setup type) and close the PCEP
session. If the PSTs corresponding to the PCReq and PCRep messages session. If the PSTs corresponding to the PCReq and PCRep messages
do not match, the PCC MUST send a PCErr message with Error-Type = 21 do not match, the PCC MUST send a PCErr message with Error-Type = 21
(Invalid traffic engineering path setup type) and Error-Value = 2 (Invalid traffic engineering path setup type) and Error-value = 2
(Mismatched path setup type) and close the PCEP session. (Mismatched path setup type) and close the PCEP session.
When a stateful PCE sends a PCUpd message ([RFC8231]) or a PCInitiate When a stateful PCE sends a PCUpd message [RFC8231] or a PCInitiate
message ([RFC8281]) to a PCC, it MUST include the PATH-SETUP-TYPE TLV message [RFC8281] to a PCC, it MUST include the PATH-SETUP-TYPE TLV
in the SRP object, unless the intended PST is RSVP-TE, in which case in the SRP object, unless the intended PST is RSVP-TE (in which case
it MAY omit the PATH-SETUP-TYPE TLV. If the PCC does not support the it MAY omit the PATH-SETUP-TYPE TLV). If the PCC does not support
PST associated with the PCUpd or PCInitiate message, it MUST send a the PST associated with the PCUpd or PCInitiate message, it MUST send
PCErr message with Error-Type = 21 (Invalid traffic engineering path a PCErr message with Error-Type = 21 (Invalid traffic engineering
setup type) and Error-Value = 1 (Unsupported path setup type) and path setup type) and Error-value = 1 (Unsupported path setup type)
close the PCEP session. and close the PCEP session.
When a PCC sends a PCRpt message to a stateful PCE ([RFC8231]), it When a PCC sends a PCRpt message to a stateful PCE [RFC8231], it MUST
MUST include the PATH-SETUP-TYPE TLV in the SRP object, unless the include the PATH-SETUP-TYPE TLV in the SRP object, unless the PST is
PST is RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. RSVP-TE (in which case it MAY omit the PATH-SETUP-TYPE TLV). The PCC
The PCC MUST include the SRP object in the PCRpt message if the PST MUST include the SRP object in the PCRpt message if the PST is not
is not RSVP-TE, even when the SRP-ID-number is the reserved value of RSVP-TE, even when the SRP-ID-number is the reserved value of
0x00000000. If the PCRpt message is triggered by a PCUpd or 0x00000000. If the PCRpt message is triggered by a PCUpd or
PCInitiate message, then the PST that the PCC indicates in the PCRpt PCInitiate message, then the PST that the PCC indicates in the PCRpt
MUST match the PST that the stateful PCE intended in the PCUpd or message MUST match the PST that the stateful PCE intended in the
PCInitiate. If it does not, then the PCE MUST send a PCErr message PCUpd or PCInitiate message. If it does not match, then the PCE MUST
with Error-Type = 21 (Invalid traffic engineering path setup type) send a PCErr message with Error-Type = 21 (Invalid traffic
and Error-Value = 2 (Mismatched path setup type) and close the PCEP engineering path setup type) and Error-value = 2 (Mismatched path
session. setup type) and close the PCEP session.
6. Manageability Considerations 6. Manageability Considerations
This document generalises PCEP to allow path setup methods other than This document generalizes PCEP to allow path setup methods other than
RSVP-TE to be used by the network (but does not define any new path RSVP-TE to be used by the network (but does not define any new path
setup types, besides RSVP-TE). It is possible that, in a given setup types besides RSVP-TE). It is possible that, in a given
network, multiple path setup methods will be used. It is also network, multiple path setup methods will be used. It is also
possible that not all devices will support the same set of path setup possible that not all devices will support the same set of path setup
methods. Managing networks that combine multiple path setup methods methods. Managing networks that combine multiple path setup methods
may therefore raise some challenges from a configuration and may therefore raise some challenges from a configuration and
observability point of view. observability point of view.
Each document that defines a new Path Setup Type in the Path Setup Each document that defines a new path setup type in the "PCEP Path
Type Registry (Section 8.2) must include a manageability section. Setup Types" registry (Section 8.2) must include a Manageability
The manageability section must explain how operators can manage PCEP Considerations section. The Manageability Considerations section
with the new path setup type. It must address the following must explain how operators can manage PCEP with the new path setup
questions, which are generally applicable when working with multiple type. It must address the following questions, which are generally
path setup types in PCEP. applicable when working with multiple path setup types in PCEP.
o What are the criteria for when devices will use the new path setup o What are the criteria for when devices will use the new path setup
type in PCEP, and how can the operator control this? type in PCEP, and how can the operator control this?
o How can the network be migrated to the new path setup type, and o How can the network be migrated to the new path setup type, and
are there any backwards compatibility issues that operators need are there any backwards-compatibility issues that operators need
to be aware of? to be aware of?
o Are paths set up using the new path setup type intended to coexist o Are paths set up using the new path setup type intended to coexist
with other paths over the long term and, if so, how is this with other paths over the long term, and if so, how is this
situation managed with PCEP? situation managed with PCEP?
o How can operators verify the correct operation of PCEP in the o How can operators verify the correct operation of PCEP in the
network with respect to the new path setup type? Which fault network with respect to the new path setup type? Which fault
conditions must be reported to the operators? conditions must be reported to the operators?
o Are there any existing management interfaces (such as YANG models) o Are there any existing management interfaces (such as YANG models)
that must be extended to model the operation of PCEP in the that must be extended to model the operation of PCEP in the
network with respect to the new path setup type? network with respect to the new path setup type?
See [RFC5706] for further guidance on how to write manageability See [RFC5706] for further guidance on how to write Manageability
sections in standards-track documents. Considerations sections in Standards Track documents.
7. Security Considerations 7. Security Considerations
The security considerations described in [RFC5440] and [RFC8281] are The security considerations described in [RFC5440] and [RFC8281] are
applicable to this specification. No additional security measure is applicable to this specification. No additional security measure is
required. required.
Note that, if the security mechanisms of [RFC5440] and [RFC8281] are Note that if the security mechanisms of [RFC5440] and [RFC8281] are
not used, then the protocol described by this draft could be attacked not used, then the protocol described in this document could be
in the following new way. An attacker, using a TCP man-in-the-middle attacked in the following new way. An attacker, using a TCP man-in-
attack, could inject error messages into the PCEP session when a the-middle attack, could inject error messages into the PCEP session
particular PST is (or is not) used. By doing so, the attacker could when a particular PST is (or is not) used. Doing this could
potentially force the use of a specific PST, which may allow them to potentially force the use of a specific PST, which may allow the
subsequently attack a weakness in that PST. attacker to subsequently attack a weakness in that PST.
8. IANA Considerations 8. IANA Considerations
8.1. PCEP TLV Type Indicators 8.1. Additions to PCEP TLV Type Indicators Registry
IANA is requested to confirm the early allocation of the following
code point in the PCEP TLV Type Indicators registry.
Value Description Reference
28 PATH-SETUP-TYPE This document
IANA is requested to allocate a new code point for the following TLV
in the PCEP TLV Type Indicators registry.
Value Description Reference
TBD1 PATH-SETUP-TYPE-CAPABILITY This document
Note to IANA: The above TLV type was not part of the early code point
allocation that was done for this draft. It was added to the draft
after the early code point allocation had taken place. Please assign
a code point from the indicated registry and replace each instance of
"TBD1" in this document with the allocated code point.
8.2. New Path Setup Type Registry
IANA is requested to create a new sub-registry within the "Path
Computation Element Protocol (PCEP) Numbers" registry called "PCEP
Path Setup Types". The allocation policy for this new registry
should be by IETF Review. The new registry should contain the
following value:
Value Description Reference
0 Path is setup using the RSVP- This document
TE signaling protocol.
8.3. PCEP-Error Object
IANA is requested to confirm the early allocation of the following IANA has allocated the following code points in the "PCEP TLV Type
code-points in the PCEP-ERROR Object Error Types and Values registry. Indicators" registry.
Error-Type Meaning Value Description Reference
10 Reception of an invalid object ----- -------------------------- ---------
28 PATH-SETUP-TYPE RFC 8408
34 PATH-SETUP-TYPE-CAPABILITY RFC 8408
Error-value=11: Malformed object 8.2. New PCEP Path Setup Types Registry
Error-Type Meaning IANA has created a new sub-registry within the "Path Computation
21 Invalid traffic engineering path setup type Element Protocol (PCEP) Numbers" registry called "PCEP Path Setup
Types". The allocation policy for this new registry is IETF Review
[RFC8126]. This new registry contains the following value:
Error-value=0: Unassigned Value Description Reference
Error-value=1: Unsupported path setup type ----- -------------------------- ---------
Error-value=2: Mismatched path setup type 0 Path is set up using the RFC 8408
RSVP-TE signaling protocol
Note to IANA: the early allocation for Error-Type=10, Error-value=11 8.3. Additions to PCEP-ERROR Object Error Types and Values Registry
was originally done by draft-ietf-pce-segment-routing. However, we
have since moved its definition into this document. Therefore,
please update the reference for this Error-value in the indicated
registry to point to RFC.ietf-pce-lsp-setup-type.
9. Contributors IANA has allocated the following code points in the "PCEP-ERROR
Object Error Types and Values" registry.
The following people contributed to this document: Error-Type Meaning Reference
---------- ------------------------------------------- ---------
10 Reception of an invalid object RFC 5440
- Jan Medved Error-value = 11: Malformed object RFC 8408
- Edward Crabbe
10. Acknowledgements 21 Invalid traffic engineering path setup type RFC 8408
We like to thank Marek Zavodsky for valuable comments. Error-value = 0: Unassigned RFC 8408
Error-value = 1: Unsupported path setup type RFC 8408
Error-value = 2: Mismatched path setup type RFC 8408
11. References 9. References
11.1. Normative References 9.1. Normative References
[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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>. <https://www.rfc-editor.org/info/rfc5440>.
skipping to change at page 11, line 21 skipping to change at page 11, line 5
Extensions for Stateful PCE", RFC 8231, Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017, DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>. <https://www.rfc-editor.org/info/rfc8231>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE Extensions for PCE-Initiated LSP Setup in a Stateful PCE
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>.
11.2. Informative References 9.2. Informative References
[I-D.ietf-pce-segment-routing] [PCEP-EXTENSIONS]
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-11 (work in progress), Work in Progress, draft-ietf-pce-segment-routing-12, June
November 2017. 2018.
[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>.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and [RFC5706] Harrington, D., "Guidelines for Considering Operations and
Management of New Protocols and Protocol Extensions", Management of New Protocols and Protocol Extensions",
RFC 5706, DOI 10.17487/RFC5706, November 2009, RFC 5706, DOI 10.17487/RFC5706, November 2009,
<https://www.rfc-editor.org/info/rfc5706>. <https://www.rfc-editor.org/info/rfc5706>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
Acknowledgements
We would like to thank Marek Zavodsky for valuable comments.
Contributors
The following people contributed to this document:
- Jan Medved
- Edward Crabbe
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
Jeff Tantsura Jeff Tantsura
Nuage Networks Nuage Networks
755 Ravendale Drive 755 Ravendale Drive
Mountain View, CA 94043 Mountain View, CA 94043
USA United States of America
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
Ina Minei Ina Minei
Google, Inc. Google, Inc.
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
USA United States of America
Email: inaminei@google.com Email: inaminei@google.com
Robert Varga Robert Varga
Pantheon Technologies SRO Pantheon Technologies SRO
Mlynske Nivy 56 Mlynske Nivy 56
Bratislava, 821 05 Bratislava, 821 05
Slovakia Slovakia
Email: nite@hq.sk Email: nite@hq.sk
Jon Hardwick Jon Hardwick
Metaswitch Networks Metaswitch Networks
100 Church Street 100 Church Street
Enfield, Middlesex Enfield, Middlesex
UK United Kingdom
Email: jonathan.hardwick@metaswitch.com Email: jonathan.hardwick@metaswitch.com
 End of changes. 80 change blocks. 
228 lines changed or deleted 214 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/