PCE Working Group M. Negi
Internet-Draft P. Kaladharan
Intended status: Standards Track D. Dhody
Expires: April 21, 2018 Huawei Technologies
S. Sivabalan
Cisco Systems
October 18, 2017
PCEP Extensions for Segment Routing leveraging the IPv6 data plane
draft-negi-pce-segment-routing-ipv6-00
Abstract
The Source Packet Routing in Networking (SPRING) architecture
describes how Segment Routing (SR) can be used to steer packets
through an IPv6 or MPLS network using the source routing paradigm.
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
RSVP-TE).
It depends only on "segments" that are advertised by Link- State
Interior Gateway Protocols (IGPs). A Segment Routed Path can be
derived from a variety of mechanisms, including an IGP Shortest Path
Tree (SPT), explicit configuration, or a Path Computation Element
(PCE).
Since, Segment Routing can be applied to both MPLS and IPv6
forwarding plane, a PCE should be able to compute SR-Path for both
MPLS and IPv6 forwarding plane. This draft describes the extensions
required for Segment Routing support for IPv6 data plane in PCEP.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
Negi, et al. Expires April 21, 2018 [Page 1]
Internet-Draft PCEP Extensions for SRv6 October 2017
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of PCEP Operation in SRv6 Networks . . . . . . . . . 5
3.1. Operation Overview . . . . . . . . . . . . . . . . . . . 6
3.2. SRv6-Specific PCEP Message Extensions . . . . . . . . . . 6
3.3. Object Formats . . . . . . . . . . . . . . . . . . . . . 6
3.3.1. The OPEN Object . . . . . . . . . . . . . . . . . . . 6
3.3.1.1. The SRv6 PCE Capability TLV . . . . . . . . . . . 6
3.3.1.2. Exchanging SRv6 Capability . . . . . . . . . . . 7
3.3.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . 7
3.3.3. ERO Object . . . . . . . . . . . . . . . . . . . . . 8
3.3.3.1. SR-ERO Subobject . . . . . . . . . . . . . . . . 8
3.3.3.2. ERO Processing . . . . . . . . . . . . . . . . . 10
3.3.4. RRO Object . . . . . . . . . . . . . . . . . . . . . 11
3.3.4.1. SR-RRO Subobject . . . . . . . . . . . . . . . . 11
3.4. Security Considerations . . . . . . . . . . . . . . . . . 11
3.5. IANA Considerations . . . . . . . . . . . . . . . . . . . 12
3.5.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . 12
3.5.1.1. ERROR Objects . . . . . . . . . . . . . . . . . . 12
3.5.1.2. TLV Type Indicators . . . . . . . . . . . . . . . 12
3.5.1.3. New Path Setup Type . . . . . . . . . . . . . . . 12
Negi, et al. Expires April 21, 2018 [Page 2]
Internet-Draft PCEP Extensions for SRv6 October 2017
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Normative References . . . . . . . . . . . . . . . . . . 13
4.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Contributor . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
As per [I-D.ietf-spring-segment-routing], with Segment Routing (SR),
a node steers a packet through an ordered list of instructions,
called segments. A segment can represent any instruction,
topological or service-based. A segment can have a semantic local to
an SR node or global within an SR domain. SR allows to enforce a
flow through any path and service chain while maintaining per-flow
state only at the ingress node of the SR domain. Segments can be
derived from different components: IGP, BGP, Services, Contexts,
Locators, etc. The list of segment forming the path is called the
Segment List and is encoded in the packet header. Segment Routing
can be applied to the IPv6 architecture with the Segment Routing
Header (SRH) [I-D.ietf-6man-segment-routing-header]. A segment is
encoded as an IPv6 address. An ordered list of segments is encoded
as an ordered list of IPv6 addresses in the routing header. The
active segment is indicated by the Destination Address of the packet.
Upon completion of a segment, a pointer in the new routing header is
incremented and indicates the next segment.
Segment Routing use cases are described in [RFC7855] and
[I-D.ietf-spring-ipv6-use-cases]. Segment Routing protocol
extensions are defined in [I-D.ietf-isis-segment-routing-extensions],
and [I-D.ietf-ospf-ospfv3-segment-routing-extensions].
As per [I-D.ietf-6man-segment-routing-header], an SRv6 Segment is a
128-bit value. "SRv6 SID" or simply "SID" are often used as a
shorter reference for "SRv6 Segment". Further details are in An
illustration is provided in
[I-D.filsfils-spring-srv6-network-programming].
The SR architecture can be applied to the MPLS forwarding plane
without any change, in which case an SR path corresponds to an MPLS
Label Switching Path (LSP). The SR is applied to IPV6 forwarding
plane using SRH. A SR path can be derived from an IGP Shortest Path
Tree (SPT), but SR-TE paths may not follow IGP SPT. Such paths may
be chosen by a suitable network planning tool or an and provisioned
on the ingress node.
[RFC5440] describes Path Computation Element Protocol (PCEP) for
communication between a Path Computation Client (PCC) and a Path
Computation Element (PCE) or between one a pair of PCEs. A PCE or a
Negi, et al. Expires April 21, 2018 [Page 3]
Internet-Draft PCEP Extensions for SRv6 October 2017
PCC operating as a PCE (in hierarchical PCE environment) computes
paths for MPLS Traffic Engineering LSPs (MPLS-TE LSPs) based on
various constraints and optimization criteria. [RFC8231] specifies
extensions to PCEP that allow a stateful PCE to compute and recommend
network paths in compliance with [RFC4657] and defines objects and
TLVs for MPLS-TE LSPs. Stateful PCEP extensions provide
synchronization of LSP state between a PCC and a PCE or between a
pair of PCEs, delegation of LSP control, reporting of LSP state from
a PCC to a PCE, controlling the setup and path routing of an LSP from
a PCE to a PCC. Stateful PCEP extensions are intended for an
operational model in which LSPs are configured on the PCC, and
control over them is delegated to the PCE.
A mechanism to dynamically initiate LSPs on a PCC based on the
requests from a stateful PCE or a controller using stateful PCE is
specified in [I-D.ietf-pce-pce-initiated-lsp]. As per
[I-D.ietf-pce-segment-routing], it is possible to use a stateful PCE
for computing one or more SR-TE paths taking into account various
constraints and objective functions. Once a path is chosen, the
stateful PCE can initiate an SR-TE path on a PCC using PCEP
extensions specified in [I-D.ietf-pce-pce-initiated-lsp] using the SR
specific PCEP extensions specified in [I-D.ietf-pce-segment-routing].
[I-D.ietf-pce-segment-routing] specifies PCEP extensions for
supporting a SR-TE LSP for MPLS data plane. This document extends
[I-D.ietf-pce-segment-routing] to support SR for IPv6 data plane.
Additionally, using procedures described in this document, a PCC can
request an SRv6 path from either stateful or a stateless PCE. This
specification relies on the PATH-SETUP-TYPE TLV and procedures
specified in [I-D.ietf-pce-lsp-setup-type].
2. Terminology
This document uses the following terms defined in [RFC5440]: PCC,
PCE, PCEP Peer.
This document uses the following terms defined in [RFC8051]: Stateful
PCE, Delegation.
The message formats in this document are specified using Routing
Backus-Naur Format (RBNF) encoding as specified in [RFC5511].
PCC: Path Computation Client.
PCE: Path Computation Element.
PCEP: Path Computation Element Protocol.
SR: Segment Routing.
Negi, et al. Expires April 21, 2018 [Page 4]
Internet-Draft PCEP Extensions for SRv6 October 2017
SID: Segment Identifier.
SRv6: Segment Routing for IPv6 forwarding plane.
SRH: IPv6 Segment Routing Header.
SR Path: IPv6 Segment (List of IPv6 SID representing a path in IPv6
SR domain)
3. Overview of PCEP Operation in SRv6 Networks
Basic operations for PCEP speakers is as per
[I-D.ietf-pce-segment-routing]. SRv6 Paths computed by a PCE can be
represented as an ordered list of SRv6 segments of 128-bit value.
"SRv6 SID" or simply "SID" are often used as a shorter reference for
"SRv6 Segment".
[I-D.ietf-pce-segment-routing] defined a new ERO subobject denoted by
"SR-ERO subobject" capable of carrying a SID as well as the identity
of the node/adjacency represented by the SID. SR-capable PCEP
speakers should be able to generate and/or process such ERO
subobject. An ERO containing SR-ERO subobjects can be included in
the PCEP Path Computation Reply (PCRep) message defined in [RFC5440],
the PCEP LSP Initiate Request message (PCInitiate) defined in
[I-D.ietf-pce-pce-initiated-lsp], as well as in the PCEP LSP Update
Request (PCUpd) and PCEP LSP State Report (PCRpt) messages defined in
defined in [RFC8231].
This document extends the "SR-ERO subobject" defined in
[I-D.ietf-pce-segment-routing] to carry IPv6 SID(s) (IPv6 Addresses).
SRv6-capable PCEP speakers should be able to generate and/or process
this.
When a PCEP session between a PCC and a PCE is established, both PCEP
speakers exchange their capabilities to indicate their ability to
support SRv6 specific functionality.
In summary, this document defines new path setup type carried in the
PATH-SETUP-TYPE TLV for SRv6 path.
In summary, this document:
o Defines a new PCEP capability for SRv6
o Update the SR-ERO and SR-RRO sub-object for SRv6
o Defines a new path setup type carried in the PATH-SETUP-TYPE TLV
for SR-TE LSP.
Negi, et al. Expires April 21, 2018 [Page 5]
Internet-Draft PCEP Extensions for SRv6 October 2017
3.1. Operation Overview
In SR networks, an ingress node of an SR path appends all outgoing
packets with an SR header consisting of a list of SIDs (IPv6 Prefix
in case of SRv6). The header has all necessary information to guide
the packets from the ingress node to the egress node of the path, and
hence there is no need for any signaling protocol.
For IPv6 in control plane with MPLS data-plane, mechanism remains
same as [I-D.ietf-pce-segment-routing]
This document describes extensions to SR path for IPv6 data plane.
SRv6 Path (i.e. ERO) consists of an ordered set of SIDs(see details
in Figure 2).
A PCC or PCE indicates its ability to support SRv6 during the PCEP
session Initialization Phase via a new SRv6-PCE-CAPABILITY TLV (see
details in Section 3.3.1.1).
3.2. SRv6-Specific PCEP Message Extensions
As defined in [RFC5440], a PCEP message consists of a common header
followed by a variable length body made up of mandatory and/or
optional objects. This document does not require any changes in the
format of PCReq and PCRep messages specified in [RFC5440], PCInitiate
message specified in [I-D.ietf-pce-pce-initiated-lsp], and PCRpt and
PCUpd messages specified in [RFC8231]. However, PCEP messages
pertaining to SRv6 MUST include PATH-SETUP-TYPE TLV in the RP or SRP
object to clearly identify that SRv6 is intended. In other words, a
PCEP speaker MUST NOT infer whether or not a PCEP message pertains to
SRv6 from any other object or TLV.
3.3. Object Formats
3.3.1. The OPEN Object
This document defines a new optional TLV for use in the OPEN Object.
3.3.1.1. The SRv6 PCE Capability TLV
The SRv6-PCE-CAPABILITY TLV is an optional TLV associated with the
OPEN Object to exchange SRv6 capability of PCEP speakers. The format
of the SR-PCE-CAPABILITY TLV is shown in the following figure:
Negi, et al. Expires April 21, 2018 [Page 6]
Internet-Draft PCEP Extensions for SRv6 October 2017
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD1 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| max-SL | Reserved | Flags |L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SRv6-PCE-CAPABILITY TLV format
The code point for the TLV type is to be defined by IANA. The TLV
length is 4 octets.
The 4-octet value comprise of -
max-SL: 1 octet, this field specifies the maximum value of the
"Segments Left (SL)" in the SRH
[I-D.ietf-6man-segment-routing-header].
Reserved: 1 octet, this field MUST be set to 0 on transmission,
and ignored on receipt.
Flags: 2 octet, one flag is currently defined in this document.
L bit: A PCC sets this bit to 1 to indicate that it does not
impose any limit on SL.
3.3.1.2. Exchanging SRv6 Capability
By including the SRv6-PCE-CAPABILITY TLV in the OPEN message destined
to a PCE, a PCC indicates that it is capable of supporting the head-
end functions for SRv6. By including the TLV in the OPEN message
destined to a PCC, a PCE indicates that it is capable of computing
SRv6 paths.
3.3.2. The RP/SRP Object
In order to indicate the SRv6 path, RP or SRP object MUST include the
PATH-SETUP-TYPE TLV specified in [I-D.ietf-pce-lsp-setup-type]. This
document defines a new Path Setup Type (PST) for SRv6 as follows:
o PST = TBD2: Path is setup using SRv6 technique.
Negi, et al. Expires April 21, 2018 [Page 7]
Internet-Draft PCEP Extensions for SRv6 October 2017
3.3.3. ERO Object
In order to support SRv6, the SR-ERO subobject is used
[I-D.ietf-pce-segment-routing]. All other processing rules remains
the same.
3.3.3.1. SR-ERO Subobject
For supporting SRv6, a new SID Type (ST) is defined, the format of
SR-ERO sub object remains the same as defined in
[I-D.ietf-pce-segment-routing].
When the SID Type (ST) indicates SRv6, then the SR-ERO subobject
represent a SRv6 segment and include a field SRv6I (SRv6 Identifier)
in place of NAI (Node or Adjacency Identifier) defined in
[I-D.ietf-pce-segment-routing]. The 32 bit SID MUST be set to zero
on transit and ignored on receipt. The format of SR-ERO subobject is
reproduced with the SRv6I field as shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | ST | Flags |F|S|C|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6I (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SR-ERO Subobject Format
The description of all the flags and fields is as per
[I-D.ietf-pce-segment-routing].
For SRv6 segments, a new ST (SID Type) is assigned by IANA as TBD.
For SRv6 segments (when ST is TBD), M and C flag MUST NOT be set.
The S flag MUST be set and SID field MUST be set to 0. The F bit
MUST NOT be set. The Length is 28.
The SRv6I format is as shown below:
Negi, et al. Expires April 21, 2018 [Page 8]
Internet-Draft PCEP Extensions for SRv6 October 2017
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SRv6 Identifier |
| (128-bit) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6ST| Flags | Function Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NAI (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: SR-ERO Subobject's SRv6I Format
SRv6 Identifier is the 128 bit IPv6 addresses representing SRv6
segment.
SRv6ST is the SRv6 SID Type which indicates the interpretation for
NAI (Node or Adjacency Identifier) as per
[I-D.ietf-pce-segment-routing].
Flags is the 12 bit field, no flag bits are currently defined in
this document.
Function Code is is the 16 bit field representing supported
functions. associated with SRv6 SIDs. See
[I-D.filsfils-spring-srv6-network-programming]. Following
function codes are currently defined -
0: Reserved
1: End Function
2: End.DX6 Function
3: End.DT6 Function
4: End.X Function
NAI field [I-D.ietf-pce-segment-routing] contains the NAI
associated with the SRv6 Identifier. Depending on the value of
SRv6ST, the NAI can have different formats.
When SRv6ST value is 1, the NAI is as per the 'IPv6 Node ID'
format defined in [I-D.ietf-pce-segment-routing], which specify
Negi, et al. Expires April 21, 2018 [Page 9]
Internet-Draft PCEP Extensions for SRv6 October 2017
an IPv6 address. This is used to identify the owner of the
SRv6 Identifier.
When SRv6ST value is 2, the NAI is as per the 'IPv6 Adjacency'
format defined in [I-D.ietf-pce-segment-routing], which specify
a pair of IPv6 addresses. This is used to identify the IPv6
Adjacency and used with the SRv6 Adj-SID.
Note that when SRv6ST value is 0, NAI is not included and MUST
be NULL.
3.3.3.2. ERO Processing
The ERO and SR-ERO subobject processing remains as per [RFC5440] and
[I-D.ietf-pce-segment-routing].
The ST MUST only be TDB, if the SRv6-PCE-CAPABILITY TLV is exchanged
with the PCEP peer. In case a PCEP speaker receives the SR-ERO
subobject with ST indicating SRv6 segment, when the SRv6-PCE-
CAPABILITY TLV was not exchanged, it MUST send a PCErr message with
Error-Type = 19 ("Invalid Operation") and Error-Value = TBD3
("Attempted SRv6 when the capability was not advertised"). A PCEP
speaker that does not recognize the ST value, it would behave as per
[I-D.ietf-pce-segment-routing].
[Editor's Note - this is missing from
[I-D.ietf-pce-segment-routing].]
If a PCC receives a list of SRv6 segments, and the number of SRv6
segments exceeds the max-SL that the PCC can impose on the packet
(SRH), it MAY send a PCErr message with Error-Type = 10 ("Reception
of an invalid object") and Error-Value = TBD ("Unsupported number of
Segment ERO subobjects") as per [I-D.ietf-pce-segment-routing].
When a PCEP speaker detects that all subobjects of ERO are not
identical to SRv6, and if it does not handle such ERO, it MUST send a
PCErr message with Error-Type = 10 ("Reception of an invalid object")
and Error-Value = TBD ("Non-identical ERO subobjects")as per
[I-D.ietf-pce-segment-routing].
When a PCEP speaker receives an SR-ERO subobject for SRv6 segment, M,
C and F flag MUST NOT be set and S flag MUST be set. Otherwise, it
MUST consider the entire ERO object invalid and send a PCErr message
with Error-Type = 10 ("Reception of an invalid object") and Error-
Value = TBD ("Malformed object") as per
[I-D.ietf-pce-segment-routing]. The PCEP speaker MAY include the
malformed SR-ERO object in the PCErr message as well.
Negi, et al. Expires April 21, 2018 [Page 10]
Internet-Draft PCEP Extensions for SRv6 October 2017
3.3.4. RRO Object
In order to support SRv6, the SR-ERO Subobject is used
[I-D.ietf-pce-segment-routing]. All other processing rules remains
the same.
3.3.4.1. SR-RRO Subobject
For SRv6 segments, a new ST (SID Type) is assigned by IANA as TBD,
the format of SR-ERO sub object remains the same as defined in
[I-D.ietf-pce-segment-routing].
When the SID Type (ST) indicates SRv6, then the SR-RRO subobject
represent a SRv6 segment and include a field SRv6I (SRv6 Identifier)
in place of NAI (Node or Adjacency Identifier) defined in
[I-D.ietf-pce-segment-routing]. The 32 bit SID MUST be set to zero
on transit and ignored on receipt. The format of SR-RRO subobject is
reproduced with the SRv6I field as shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | ST | Flags |F|S|C|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6I (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SR-RRO Subobject Format
The description of all fields and flags is as per SR-ERO subobject.
Processing rules of SR-RRO subobject are identical to those of SR-ERO
subobject.
3.4. Security Considerations
The security considerations described in [RFC5440], [RFC8231] and
[I-D.ietf-pce-pce-initiated-lsp] are applicable to this
specification. No additional security measure is required.
Negi, et al. Expires April 21, 2018 [Page 11]
Internet-Draft PCEP Extensions for SRv6 October 2017
3.5. IANA Considerations
This document requests IANA to include (I) bit in flags registry for
SR-ERO and SR-RRO sub-objects. Other changes are defined as:
3.5.1. PCEP Objects
3.5.1.1. ERROR Objects
IANA is requested to allocate code-points in the PCEP-ERROR Object
Error Types and Values registry for the following new error-values:
Error-Type Meaning
---------- -------
19 Invalid Operation
Error-value = TBD3 (Attempted SRv6 when the
capability was not advertised)
3.5.1.2. TLV Type Indicators
IANA is requested to make the assignment of the new code points for
the existing "PCEP TLV Type Indicators" registry as follows:
Value Meaning Reference
----- ------- ---------
TBD1 SRv6-PCE-CAPABILITY TLV This Document
3.5.1.3. New Path Setup Type
[I-D.ietf-pce-lsp-setup-type]defines the PATH-SETUP-TYPE TLV and
requests that IANA creates a registry to manage the value of the
PATH-SETUP-TYPE TLV's PST field. IANA is requested to allocate a new
code point in the PCEP PATH_SETUP_TYPE TLV PST field registry, as
follows:
Value Description Reference
------------------------- ---------------------------- --------------
TBD2 SRv6 (SRH) technique This Document
Negi, et al. Expires April 21, 2018 [Page 12]
Internet-Draft PCEP Extensions for SRv6 October 2017
4. References
4.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, DOI 10.17487/RFC5511, April
2009, <https://www.rfc-editor.org/info/rfc5511>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[I-D.ietf-pce-segment-routing]
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "PCEP Extensions for Segment Routing",
draft-ietf-pce-segment-routing-10 (work in progress),
October 2017.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
and R. Shakir, "Segment Routing Architecture", draft-ietf-
spring-segment-routing-12 (work in progress), June 2017.
[I-D.ietf-pce-pce-initiated-lsp]
Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
Extensions for PCE-initiated LSP Setup in a Stateful PCE
Model", draft-ietf-pce-pce-initiated-lsp-11 (work in
progress), October 2017.
Negi, et al. Expires April 21, 2018 [Page 13]
Internet-Draft PCEP Extensions for SRv6 October 2017
[I-D.ietf-pce-lsp-setup-type]
Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
Hardwick, "Conveying path setup type in PCEP messages",
draft-ietf-pce-lsp-setup-type-04 (work in progress), April
2017.
4.2. Informative References
[RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, DOI 10.17487/RFC4657, September
2006, <https://www.rfc-editor.org/info/rfc4657>.
[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
Litkowski, S., Horneffer, M., and R. Shakir, "Source
Packet Routing in Networking (SPRING) Problem Statement
and Requirements", RFC 7855, DOI 10.17487/RFC7855, May
2016, <https://www.rfc-editor.org/info/rfc7855>.
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
Stateful Path Computation Element (PCE)", RFC 8051,
DOI 10.17487/RFC8051, January 2017,
<https://www.rfc-editor.org/info/rfc8051>.
[]
Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B.,
daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d.,
Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi,
T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk,
"IPv6 Segment Routing Header (SRH)", draft-ietf-6man-
segment-routing-header-07 (work in progress), July 2017.
[I-D.ietf-spring-ipv6-use-cases]
Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., and
M. Townsley, "IPv6 SPRING Use Cases", draft-ietf-spring-
ipv6-use-cases-11 (work in progress), June 2017.
[I-D.ietf-isis-segment-routing-extensions]
Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
Litkowski, S., Decraene, B., and j. jefftant@gmail.com,
"IS-IS Extensions for Segment Routing", draft-ietf-isis-
segment-routing-extensions-13 (work in progress), June
2017.
Negi, et al. Expires April 21, 2018 [Page 14]
Internet-Draft PCEP Extensions for SRv6 October 2017
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3
Extensions for Segment Routing", draft-ietf-ospf-ospfv3-
segment-routing-extensions-10 (work in progress),
September 2017.
[I-D.filsfils-spring-srv6-network-programming]
Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d.,
daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R.,
Matsushima, S., Lebrun, D., Decraene, B., Peirens, B.,
Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P.,
Sharif, M., Ayyangar, A., Mynam, S., Henderickx, W.,
Bashandy, A., Raza, K., Dukes, D., Clad, F., and P.
Camarillo, "SRv6 Network Programming", draft-filsfils-
spring-srv6-network-programming-01 (work in progress),
June 2017.
Negi, et al. Expires April 21, 2018 [Page 15]
Internet-Draft PCEP Extensions for SRv6 October 2017
Appendix A. Contributor
The following persons contributed to this document:
Huang Wumin
Huawei Technologies
Huawei Building, No. 156 Beiqing Rd.
Beijing 100095
China
Email: huangwumin@huawei.com
Authors' Addresses
Mahendra Singh Negi
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
EMail: mahendrasingh@huawei.com
Prejeeth Kaladharan
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
EMail: prejeeth.k@huawei.com
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
EMail: dhruv.ietf@gmail.com
Siva Sivabalan
Cisco Systems
EMail: msiva@cisco.com
Negi, et al. Expires April 21, 2018 [Page 16]