draft-ietf-pce-segment-routing-ipv6-01.txt   draft-ietf-pce-segment-routing-ipv6-02.txt 
PCE Working Group M. Negi PCE Working Group M. Negi
Internet-Draft C. Li Internet-Draft C. Li
Intended status: Standards Track Huawei Technologies Intended status: Standards Track Huawei Technologies
Expires: October 9, 2019 S. Sivabalan Expires: October 10, 2019 S. Sivabalan
Cisco Systems Cisco Systems
P. Kaladharan P. Kaladharan
RtBrick Inc RtBrick Inc
Z. Yongqing Z. Yongqing
China Telecom China Telecom
April 7, 2019 April 8, 2019
PCEP Extensions for Segment Routing leveraging the IPv6 data plane PCEP Extensions for Segment Routing leveraging the IPv6 data plane
draft-ietf-pce-segment-routing-ipv6-01 draft-ietf-pce-segment-routing-ipv6-02
Abstract Abstract
The Source Packet Routing in Networking (SPRING) architecture The Source Packet Routing in Networking (SPRING) architecture
describes how Segment Routing (SR) can be used to steer packets describes how Segment Routing (SR) can be used to steer packets
through an IPv6 or MPLS network using the source routing paradigm. through an IPv6 or MPLS network using the source routing paradigm.
SR enables any head-end node to select any path without relying on a 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). hop-by-hop signaling technique (e.g., LDP or RSVP-TE).
It depends only on "segments" that are advertised by Link- State It depends only on "segments" that are advertised by Link- State
skipping to change at page 1, line 43 skipping to change at page 1, line 43
support for IPv6 data plane in Path Computation Element communication support for IPv6 data plane in Path Computation Element communication
Protocol (PCEP). The PCEP extension and mechanism to support SR-MPLS Protocol (PCEP). The PCEP extension and mechanism to support SR-MPLS
is described in [I-D.ietf-pce-segment-routing]. This document is described in [I-D.ietf-pce-segment-routing]. This document
extends it to support SRv6 (SR over IPv6). extends it to support SRv6 (SR over IPv6).
Requirements Language 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 BCP
14 [RFC2119] [RFC8174]when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 October 9, 2019. This Internet-Draft will expire on October 10, 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 3, line 44 skipping to change at page 3, line 44
forming the path is called the Segment List and is encoded in the forming the path is called the Segment List and is encoded in the
packet header. Segment Routing can be applied to the IPv6 packet header. Segment Routing can be applied to the IPv6
architecture with the Segment Routing Header (SRH) architecture with the Segment Routing Header (SRH)
[I-D.ietf-6man-segment-routing-header]. A segment is encoded as an [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 IPv6 address. An ordered list of segments is encoded as an ordered
list of IPv6 addresses in the routing header. The active segment is list of IPv6 addresses in the routing header. The active segment is
indicated by the Destination Address of the packet. Upon completion indicated by the Destination Address of the packet. Upon completion
of a segment, a pointer in the new routing header is incremented and of a segment, a pointer in the new routing header is incremented and
indicates the next segment. indicates the next segment.
Segment Routing use cases are described in [RFC7855]and [RFC8354]. Segment Routing use cases are described in [RFC7855] and [RFC8354].
Segment Routing protocol extensions are defined in Segment Routing protocol extensions are defined in
[I-D.ietf-isis-segment-routing-extensions], and [I-D.ietf-isis-segment-routing-extensions], and
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [I-D.ietf-ospf-ospfv3-segment-routing-extensions].
As per [I-D.ietf-6man-segment-routing-header], an SRv6 Segment is a 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 128-bit value. "SRv6 SID" or simply "SID" are often used as a
shorter reference for "SRv6 Segment". Further details are in an shorter reference for "SRv6 Segment". Further details are in an
illustration provided in illustration provided in
[I-D.filsfils-spring-srv6-network-programming]. [I-D.filsfils-spring-srv6-network-programming].
The SR architecture can be applied to the MPLS forwarding plane The SR architecture can be applied to the MPLS forwarding plane
without any change, in which case an SR path corresponds to an MPLS without any change, in which case an SR path corresponds to an MPLS
Label Switching Path (LSP). The SR is applied to IPV6 forwarding 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 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 Tree (SPT), but SR-TE paths may not follow IGP SPT. Such paths may
be chosen by a suitable network planning tool, or a PCE and be chosen by a suitable network planning tool, or a PCE and
provisioned on the ingress node. provisioned on the ingress node.
[RFC5440]describes Path Computation Element communication Protocol [RFC5440] describes Path Computation Element communication Protocol
(PCEP) for communication between a Path Computation Client (PCC) and (PCEP) for communication between a Path Computation Client (PCC) and
a Path Computation Element (PCE) or between a pair of PCEs. A PCE or a Path Computation Element (PCE) or between a pair of PCEs. A PCE or
a PCC operating as a PCE (in hierarchical PCE environment) computes a PCC operating as a PCE (in hierarchical PCE environment) computes
paths for MPLS Traffic Engineering LSPs (MPLS-TE LSPs) based on paths for MPLS Traffic Engineering LSPs (MPLS-TE LSPs) based on
various constraints and optimization criteria. [RFC8231]specifies various constraints and optimization criteria. [RFC8231] specifies
extensions to PCEP that allow a stateful PCE to compute and recommend extensions to PCEP that allow a stateful PCE to compute and recommend
network paths in compliance with [RFC4657]and defines objects and network paths in compliance with [RFC4657] and defines objects and
TLVs for MPLS-TE LSPs. Stateful PCEP extensions provide TLVs for MPLS-TE LSPs. Stateful PCEP extensions provide
synchronization of LSP state between a PCC and a PCE or between a 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 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 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 a PCE to a PCC. Stateful PCEP extensions are intended for an
operational model in which LSPs are configured on the PCC, and operational model in which LSPs are configured on the PCC, and
control over them is delegated to the PCE. control over them is delegated to the PCE.
A mechanism to dynamically initiate LSPs on a PCC based on the A mechanism to dynamically initiate LSPs on a PCC based on the
requests from a stateful PCE or a controller using stateful PCE is requests from a stateful PCE or a controller using stateful PCE is
specified in [RFC8281]. As per [I-D.ietf-pce-segment-routing], it is specified in [RFC8281]. As per [I-D.ietf-pce-segment-routing], it is
possible to use a stateful PCE for computing one or more SR-TE paths possible to use a stateful PCE for computing one or more SR-TE paths
taking into account various constraints and objective functions. taking into account various constraints and objective functions.
Once a path is chosen, the stateful PCE can initiate an SR-TE path on Once a path is chosen, the stateful PCE can initiate an SR-TE path on
a PCC using PCEP extensions specified in [RFC8281]using the SR a PCC using PCEP extensions specified in [RFC8281] using the SR
specific PCEP extensions specified in [I-D.ietf-pce-segment-routing]. specific PCEP extensions specified in [I-D.ietf-pce-segment-routing].
[I-D.ietf-pce-segment-routing]specifies PCEP extensions for [I-D.ietf-pce-segment-routing] specifies PCEP extensions for
supporting a SR-TE LSP for MPLS data plane. This document extends 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. [I-D.ietf-pce-segment-routing] to support SR for IPv6 data plane.
Additionally, using procedures described in this document, a PCC can Additionally, using procedures described in this document, a PCC can
request an SRv6 path from either stateful or a stateless PCE. This request an SRv6 path from either stateful or a stateless PCE. This
specification relies on the PATH-SETUP-TYPE TLV and procedures specification relies on the PATH-SETUP-TYPE TLV and procedures
specified in [RFC8408]. specified in [RFC8408].
This specification provides a mechanism for a network controller This specification provides a mechanism for a network controller
(acting as a PCE) to instantiate candidate paths for an SR Policy (acting as a PCE) to instantiate candidate paths for an SR Policy
onto a head-end node (acting as a PCC) using PCEP. For more onto a head-end node (acting as a PCC) using PCEP. For more
information on the SR Policy Architecture, see information on the SR Policy Architecture, see
[I-D.ietf-spring-segment-routing-policy]. [I-D.ietf-spring-segment-routing-policy].
skipping to change at page 5, line 43 skipping to change at page 5, line 43
SR domain) SR domain)
3. Overview of PCEP Operation in SRv6 Networks 3. Overview of PCEP Operation in SRv6 Networks
Basic operations for PCEP speakers is as per Basic operations for PCEP speakers is as per
[I-D.ietf-pce-segment-routing]. SRv6 Paths computed by a PCE can be [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. 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 SID" or simply "SID" are often used as a shorter reference for
"SRv6 Segment" in this document. "SRv6 Segment" in this document.
[I-D.ietf-pce-segment-routing]defined a new Explicit Route Object [I-D.ietf-pce-segment-routing] defined a new Explicit Route Object
(ERO) subobject denoted by "SR-ERO subobject" capable of carrying a (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 as well as the identity of the node/adjacency represented by the
SID. SR-capable PCEP speakers should be able to generate and/or SID. SR-capable PCEP speakers should be able to generate and/or
process such ERO subobject. An ERO containing SR-ERO subobjects can process such ERO subobject. An ERO containing SR-ERO subobjects can
be included in the PCEP Path Computation Reply (PCRep) message be included in the PCEP Path Computation Reply (PCRep) message
defined in [RFC5440], the PCEP LSP Initiate Request message defined in [RFC5440], the PCEP LSP Initiate Request message
(PCInitiate) defined in [RFC8281], as well as in the PCEP LSP Update (PCInitiate) defined in [RFC8281], as well as in the PCEP LSP Update
Request (PCUpd) and PCEP LSP State Report (PCRpt) messages defined in Request (PCUpd) and PCEP LSP State Report (PCRpt) messages defined in
defined in [RFC8231]. defined in [RFC8231].
skipping to change at page 7, line 11 skipping to change at page 7, line 11
specified in [RFC8231]. However, PCEP messages pertaining to SRv6 specified in [RFC8231]. However, PCEP messages pertaining to SRv6
MUST include PATH-SETUP-TYPE TLV in the RP or SRP object to clearly MUST include PATH-SETUP-TYPE TLV in the RP or SRP object to clearly
identify that SRv6 is intended. identify that SRv6 is intended.
4. Object Formats 4. Object Formats
4.1. The OPEN Object 4.1. The OPEN Object
4.1.1. The SRv6 PCE Capability sub-TLV 4.1.1. The SRv6 PCE Capability sub-TLV
This document defines a new Path Setup Type (PST) [RFC8408]for SRv6, This document defines a new Path Setup Type (PST) [RFC8408] for SRv6,
as follows: as follows:
o PST = TBD2: Path is setup using SRv6. o PST = TBD2: Path is setup using SRv6.
A PCEP speaker SHOULD indicate its support of the function described A PCEP speaker SHOULD indicate its support of the function described
in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the
OPEN object with this new PST included in the PST list. OPEN object with this new PST included in the PST list.
This document also defines the SRv6-PCE-CAPABILITY sub-TLV. PCEP This document also defines the SRv6-PCE-CAPABILITY sub-TLV. PCEP
speakers use this sub-TLV to exchange information about their SRv6 speakers use this sub-TLV to exchange information about their SRv6
skipping to change at page 8, line 18 skipping to change at page 8, line 18
N bit: A PCC sets this flag bit to 1 to indicate that it is N bit: A PCC sets this flag bit to 1 to indicate that it is
capable of resolving a Node or Adjacency Identifier (NAI) to a capable of resolving a Node or Adjacency Identifier (NAI) to a
SRv6-SID. SRv6-SID.
X bit: A PCC sets this bit to 1 to indicate that it does not X bit: A PCC sets this bit to 1 to indicate that it does not
impose any limit on MSD (irrespective of the MSD-Type). impose any limit on MSD (irrespective of the MSD-Type).
Unassigned bits MUST be set to 0 and ignored on receipt. Unassigned bits MUST be set to 0 and ignored on receipt.
A pair of (MSD-Type,MSD-Value): Where MSD-Type (1 octet) is as per A pair of (MSD-Type, MSD-Value): Where MSD-Type (1 octet) is as
the IGP MSD Type registry created by [RFC8491]and populated with per the IGP MSD Type registry created by [RFC8491] and populated
SRv6 MSD types as per [I-D.bashandy-isis-srv6-extensions]; MSD- with SRv6 MSD types as per [I-D.bashandy-isis-srv6-extensions];
Value (1 octet) is as per [RFC8491]. MSD-Value (1 octet) is as per [RFC8491].
The TLV format is compliant with the PCEP TLV format defined in The TLV format is compliant with the PCEP TLV format defined in
[RFC5440]. That is, the TLV is composed of 2 octets for the type, 2 [RFC5440]. That is, the TLV is composed of 2 octets for the type, 2
octets specifying the TLV length, and a Value field. The Length octets specifying the TLV length, and a Value field. The Length
field defines the length of the value portion in octets. The TLV is field defines the length of the value portion in octets. The TLV is
padded to 4-octet alignment, and padding is not included in the padded to 4-octet alignment, and padding is not included in the
Length field. The number of (MSD-Type,MSD-Value) pairs can be Length field. The number of (MSD-Type,MSD-Value) pairs can be
determined from the Length field of the TLV. determined from the Length field of the TLV.
4.2. The RP/SRP Object 4.2. The RP/SRP Object
skipping to change at page 11, line 12 skipping to change at page 11, line 12
At least one of the SRv6-SID and the NAI MUST be included in the At least one of the SRv6-SID and the NAI MUST be included in the
SRv6-ERO subobject, and both MAY be included. SRv6-ERO subobject, and both MAY be included.
4.4. RRO 4.4. RRO
4.4.1. SRv6-RRO Subobject 4.4.1. SRv6-RRO Subobject
A PCC reports an SRv6 path to a PCE by sending a PCRpt message, per A PCC reports an SRv6 path 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. The procedures applied by the PCC, that is, the actual path taken. The procedures
of [I-D.ietf-pce-segment-routing]with respect to the RRO apply of [I-D.ietf-pce-segment-routing] with respect to the RRO apply
equally to this specification without change. equally to this specification without change.
An RRO contains one or more subobjects called "SRv6-RRO subobjects" An RRO contains one or more subobjects called "SRv6-RRO subobjects"
whose format is shown below: whose format is shown below:
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=TBD4 | Length | NT | Flags |F|S| | Type=TBD4 | Length | NT | Flags |F|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 13, line 13 skipping to change at page 13, line 13
message with Error-Type 10 (Reception of an invalid object) and message with Error-Type 10 (Reception of an invalid object) and
Error-Value 3 (Unsupported number of Segment ERO subobjects). If a Error-Value 3 (Unsupported number of Segment ERO subobjects). If a
PCEP session is established with an SRv6 MSD value of zero, then the PCEP session is established with an SRv6 MSD value of zero, then the
PCC MAY specify an SRv6 MSD for each path computation request that it PCC MAY specify an SRv6 MSD for each path computation request that it
sends to the PCE, by including a "maximum SID depth" metric object on sends to the PCE, by including a "maximum SID depth" metric object on
the request similar to [I-D.ietf-pce-segment-routing]. the request similar to [I-D.ietf-pce-segment-routing].
The N flag, X flag and (MSD-Type,MSD-Value) pair inside the SRv6-PCE- The N flag, X flag and (MSD-Type,MSD-Value) pair inside the SRv6-PCE-
CAPABILITY sub-TLV are meaningful only in the Open message sent from CAPABILITY sub-TLV are meaningful only in the Open message sent from
a PCC to a PCE. As such, a PCE MUST set the flags to zero and not a PCC to a PCE. As such, a PCE MUST set the flags to zero and not
include any (MSD-Type, MSD-Value) pair in the SRv6-PCE-CAPABILITY include any (MSD-Type,MSD-Value) pair in the SRv6-PCE-CAPABILITY sub-
sub-TLV in an outbound message to a PCC. Similarly, a PCC MUST TLV in an outbound message to a PCC. Similarly, a PCC MUST ignore
ignore N, X flag and any (MSD-Type,MSD-Value) pair received from a N,X flag and any (MSD-Type,MSD-Value) pair received from a PCE. If a
PCE. If a PCE receives multiple SRv6-PCE-CAPABILITY sub-TLVs in an PCE receives multiple SRv6-PCE-CAPABILITY sub-TLVs in an Open
Open message, it processes only the first sub-TLV received. message, it processes only the first sub-TLV received.
5.2. ERO Processing 5.2. ERO Processing
The ERO processing remains as per [RFC5440]and The ERO processing remains as per [RFC5440] and
[I-D.ietf-pce-segment-routing]. [I-D.ietf-pce-segment-routing].
5.2.1. SRv6 ERO Validation 5.2.1. SRv6 ERO Validation
If a PCC does not support the SRv6 PCE Capability and thus cannot If a PCC does not support the SRv6 PCE Capability and thus cannot
recognize the SRv6-ERO or SRv6-RRO subobjects, it will respond recognize the SRv6-ERO or SRv6-RRO subobjects, it will respond
according to the rules for a malformed object per [RFC5440]. according to the rules for a malformed object per [RFC5440].
On receiving an SRv6-ERO, a PCC MUST validate that the Length field, On receiving an SRv6-ERO, a PCC MUST validate that the Length field,
the S bit, the F bit and the NT field are consistent, as follows. the S bit, the F bit and the NT field are consistent, as follows.
skipping to change at page 13, line 45 skipping to change at page 13, line 45
o If NT=2, the F bit MUST be zero. If the S bit is 1, the Length o If NT=2, the F bit MUST be zero. If the S bit is 1, the Length
MUST be 24, otherwise the Length MUST be 40. MUST be 24, otherwise the Length MUST be 40.
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 40, otherwise the Length MUST be 56. MUST be 40, otherwise the Length MUST be 56.
o If NT=6, the F bit MUST be zero. If the S bit is 1, the Length o If NT=6, the F bit MUST be zero. If the S bit is 1, the Length
MUST be 48, otherwise the Length MUST be 64. MUST be 48, otherwise the Length MUST be 64.
o NT types (1, 3, and 5) are not valid for SRv6. o NT types (1,3, and 5) are not valid for SRv6.
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 PCEP speaker that does not recognize the NT value received in If a PCEP speaker that does not recognize the NT value received in
SRv6-ERO subobject, it would behave as per SRv6-ERO subobject, it would behave as per
[I-D.ietf-pce-segment-routing]. [I-D.ietf-pce-segment-routing].
skipping to change at page 15, line 13 skipping to change at page 15, line 13
SRv6-RRO subobject"). SRv6-RRO subobject").
If a PCE detects that the subobjects of an RRO are a mixture of If a PCE detects that the subobjects of an RRO are a mixture of
SRv6-RRO subobjects and subobjects of other types, then it MUST send SRv6-RRO subobjects and subobjects of other types, then it 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 = TBD7 ("RRO mixes SRv6-RRO subobjects with object") and Error-Value = TBD7 ("RRO mixes SRv6-RRO subobjects with
other subobject types"). other subobject types").
6. Security Considerations 6. Security Considerations
The security considerations described in [RFC5440], [RFC8231]and The security considerations described in [RFC5440], [RFC8231] and
[RFC8281], [I-D.ietf-pce-segment-routing], are applicable to this [RFC8281], [I-D.ietf-pce-segment-routing], are applicable to this
specification. No additional security measure is required. specification. No additional security measure is required.
7. IANA Considerations 7. IANA Considerations
7.1. PCEP ERO and RRO subobjects 7.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
skipping to change at page 17, line 7 skipping to change at page 17, line 7
0-13 Unassigned 0-13 Unassigned
14 Node or Adjacency This document 14 Node or Adjacency This document
Identifier (NAI) is Identifier (NAI) is
supported (N) supported (N)
15 Unlimited Maximum SID This document 15 Unlimited Maximum SID This document
Depth (X) Depth (X)
7.5. New Path Setup Type 7.5. 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
----- ----------- --------- ----- ----------- ---------
TBD2 Traffic engineering path is This Document TBD2 Traffic engineering path is This Document
setup using SRv6. setup using SRv6.
7.6. ERROR Objects 7.6. ERROR Objects
skipping to change at page 21, line 9 skipping to change at page 21, line 9
Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., Dawra, G., Filsfils, C., Talaulikar, K., Chen, M.,
daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B., and daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B., and
H. Elmalky, "BGP Link State Extensions for SRv6", draft- H. Elmalky, "BGP Link State Extensions for SRv6", draft-
dawra-idr-bgpls-srv6-ext-06 (work in progress), March dawra-idr-bgpls-srv6-ext-06 (work in progress), March
2019. 2019.
Appendix A. Contributor Appendix A. Contributor
The following persons contributed to this document: The following persons contributed to this document:
Dhruv Dhody Huawei Technologies Divyashree Techno Dhruv Dhody
Park, Whitefield Bangalore, Karnataka 560066 India EMail: Huawei Technologies
dhruv.ietf@gmail.com Huang Wumin Huawei Technologies Huawei Divyashree Techno Park, Whitefield
Building, No. 156 Beiqing Rd. Beijing 100095 China Email: Bangalore, Karnataka 560066
huangwumin@huawei.com India
EMail: dhruv.ietf@gmail.com
Huang Wumin
Huawei Technologies
Huawei Building, No. 156 Beiqing Rd.
Beijing 100095
China
Email: huangwumin@huawei.com
Authors' Addresses Authors' Addresses
Mahendra Singh Negi Mahendra Singh Negi
Huawei Technologies Huawei Technologies
Divyashree Techno Park, Whitefield Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066 Bangalore, Karnataka 560066
India India
EMail: mahendrasingh@huawei.com EMail: mahendrasingh@huawei.com
 End of changes. 22 change blocks. 
33 lines changed or deleted 43 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/