draft-ietf-pce-segment-routing-ipv6-00.txt   draft-ietf-pce-segment-routing-ipv6-01.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: September 11, 2019 S. Sivabalan Expires: October 9, 2019 S. Sivabalan
Cisco Systems Cisco Systems
P. Kaladharan P. Kaladharan
RtBrick Inc RtBrick Inc
March 10, 2019 Z. Yongqing
China Telecom
April 7, 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-00 draft-ietf-pce-segment-routing-ipv6-01
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.
Segment Routing (SR) enables any head-end node to select any path SR enables any head-end node to select any path without relying on a
without relying on a hop-by-hop signaling technique (e.g., LDP or hop-by-hop signaling technique (e.g., LDP or RSVP-TE).
RSVP-TE).
It depends only on "segments" that are advertised by Link- State It depends only on "segments" that are advertised by Link- State
IGPs. A Segment Routed Path can be derived from a variety of IGPs. A Segment Routed Path can be derived from a variety of
mechanisms, including an IGP Shortest Path Tree (SPT), explicit mechanisms, including an IGP Shortest Path Tree (SPT), explicit
configuration, or a Path Computation Element (PCE). configuration, or a Path Computation Element (PCE).
Since, Segment Routing can be applied to both MPLS and IPv6 Since SR can be applied to both MPLS and IPv6 forwarding plane, a PCE
forwarding plane, a PCE should be able to compute SR-Path for both should be able to compute SR-Path for both MPLS and IPv6 forwarding
MPLS and IPv6 forwarding plane. This draft describes the extensions plane. This document describes the extensions required for SR
required for Segment Routing support for IPv6 data plane in Path support for IPv6 data plane in Path Computation Element communication
Computation Element communication Protocol (PCEP). Protocol (PCEP). The PCEP extension and mechanism to support SR-MPLS
is described in [I-D.ietf-pce-segment-routing]. This document
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 September 11, 2019. This Internet-Draft will expire on October 9, 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of PCEP Operation in SRv6 Networks . . . . . . . . . 5 3. Overview of PCEP Operation in SRv6 Networks . . . . . . . . . 5
3.1. Operation Overview . . . . . . . . . . . . . . . . . . . 6 3.1. Operation Overview . . . . . . . . . . . . . . . . . . . 6
3.2. SRv6-Specific PCEP Message Extensions . . . . . . . . . . 6 3.2. SRv6-Specific PCEP Message Extensions . . . . . . . . . . 6
3.3. Object Formats . . . . . . . . . . . . . . . . . . . . . 6 4. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.1. The OPEN Object . . . . . . . . . . . . . . . . . . . 6 4.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 7
3.3.1.1. The SRv6 PCE Capability sub-TLV . . . . . . . . . 6 4.1.1. The SRv6 PCE Capability sub-TLV . . . . . . . . . . . 7
3.3.1.2. Exchanging the SRv6 Capability . . . . . . . . . 8 4.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . . . 8
3.3.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . 9 4.3. ERO . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.3. ERO Object . . . . . . . . . . . . . . . . . . . . . 9 4.3.1. SRv6-ERO Subobject . . . . . . . . . . . . . . . . . 8
3.3.3.1. SR-ERO Subobject . . . . . . . . . . . . . . . . 10 4.4. RRO . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.3.2. ERO Processing . . . . . . . . . . . . . . . . . 12 4.4.1. SRv6-RRO Subobject . . . . . . . . . . . . . . . . . 11
3.3.4. RRO Object . . . . . . . . . . . . . . . . . . . . . 13 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.4.1. SR-RRO Subobject . . . . . . . . . . . . . . . . 13 5.1. Exchanging the SRv6 Capability . . . . . . . . . . . . . 11
3.4. Security Considerations . . . . . . . . . . . . . . . . . 14 5.2. ERO Processing . . . . . . . . . . . . . . . . . . . . . 13
3.5. IANA Considerations . . . . . . . . . . . . . . . . . . . 14 5.2.1. SRv6 ERO Validation . . . . . . . . . . . . . . . . . 13
3.5.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . 14 5.2.2. Interpreting the SRv6-ERO . . . . . . . . . . . . . . 14
3.5.1.1. ERROR Objects . . . . . . . . . . . . . . . . . . 14 5.3. RRO Processing . . . . . . . . . . . . . . . . . . . . . 14
3.5.1.2. TLV Type Indicators . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
3.5.1.3. New Path Setup Type . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7.1. PCEP ERO and RRO subobjects . . . . . . . . . . . . . . . 15
3.6. The NAI Type field . . . . . . . . . . . . . . . . . . . 15 7.2. New SRv6-ERO Flag Registry . . . . . . . . . . . . . . . 15
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 7.3. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators . . . 16
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.4. SRv6 PCE Capability Flags . . . . . . . . . . . . . . . . 16
5.1. Normative References . . . . . . . . . . . . . . . . . . 15 7.5. New Path Setup Type . . . . . . . . . . . . . . . . . . . 17
5.2. Informative References . . . . . . . . . . . . . . . . . 16 7.6. ERROR Objects . . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Contributor . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Contributor . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
As per [RFC8402], with Segment Routing (SR), a node steers a packet As per [RFC8402], with Segment Routing (SR), a node steers a packet
through an ordered list of instructions, called segments. A segment through an ordered list of instructions, called segments. A segment
can represent any instruction, topological or service-based. A can represent any instruction, topological or service-based. A
segment can have a semantic local to an SR node or global within an 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 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 chain while maintaining per-flow state only at the ingress node of
the SR domain. Segments can be derived from different components: the SR domain. Segments can be derived from different components:
skipping to change at page 3, line 33 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 32 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 ERO subobject denoted by [I-D.ietf-pce-segment-routing]defined a new Explicit Route Object
"SR-ERO subobject" capable of carrying a SID as well as the identity (ERO) subobject denoted by "SR-ERO subobject" capable of carrying a
of the node/adjacency represented by the SID. SR-capable PCEP SID as well as the identity of the node/adjacency represented by the
speakers should be able to generate and/or process such ERO SID. SR-capable PCEP speakers should be able to generate and/or
subobject. An ERO containing SR-ERO subobjects can be included in process such ERO subobject. An ERO containing SR-ERO subobjects can
the PCEP Path Computation Reply (PCRep) message defined in [RFC5440], be included in the PCEP Path Computation Reply (PCRep) message
the PCEP LSP Initiate Request message (PCInitiate) defined in defined in [RFC5440], the PCEP LSP Initiate Request message
[RFC8281], as well as in the PCEP LSP Update Request (PCUpd) and PCEP (PCInitiate) defined in [RFC8281], as well as in the PCEP LSP Update
LSP State Report (PCRpt) messages defined in defined in [RFC8231]. Request (PCUpd) and PCEP LSP State Report (PCRpt) messages defined in
defined in [RFC8231].
This document extends the "SR-ERO subobject" defined in This document define new subobjects "SRv6-ERO" and "SRv6-RRO" in ERO
[I-D.ietf-pce-segment-routing] to carry IPv6 SID(s) (IPv6 Addresses). and RRO respectively to carry SRv6 SID (IPv6 Address). SRv6-capable
SRv6-capable PCEP speakers MUST be able to generate and/or process PCEP speakers MUST be able to generate and/or process this.
this.
When a PCEP session between a PCC and a PCE is established, both PCEP When a PCEP session between a PCC and a PCE is established, both PCEP
speakers exchange their capabilities to indicate their ability to speakers exchange their capabilities to indicate their ability to
support SRv6 specific functionality. support SRv6 specific functionality.
In summary, this document: In summary, this document:
o Defines a new PCEP capability for SRv6 o Defines a new PCEP capability for SRv6.
o Update the SR-ERO and SR-RRO sub-object for SRv6 o Defines a new subobject SRv6-ERO in ERO.
o Defines a new subobject SRv6-RRO in RRO.
o Defines a new path setup type carried in the PATH-SETUP-TYPE and o Defines a new path setup type carried in the PATH-SETUP-TYPE and
PATH-SETUP-TYPE-CAPABILITY TLVs. PATH-SETUP-TYPE-CAPABILITY TLVs.
3.1. Operation Overview 3.1. Operation Overview
In SR networks, an ingress node of an SR path appends all outgoing 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 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 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 the packets from the ingress node to the egress node of the path, and
skipping to change at page 6, line 29 skipping to change at page 6, line 41
For IPv6 in control plane with MPLS data-plane, mechanism remains For IPv6 in control plane with MPLS data-plane, mechanism remains
same as [I-D.ietf-pce-segment-routing] same as [I-D.ietf-pce-segment-routing]
This document describes extensions to SR path for IPv6 data plane. This document describes extensions to SR path for IPv6 data plane.
SRv6 Path (i.e. ERO) consists of an ordered set of SRv6 SIDs(see SRv6 Path (i.e. ERO) consists of an ordered set of SRv6 SIDs(see
details in Figure 2). details in Figure 2).
A PCC or PCE indicates its ability to support SRv6 during the PCEP A PCC or PCE indicates its ability to support SRv6 during the PCEP
session Initialization Phase via a new SRv6-PCE-CAPABILITY sub-TLV session Initialization Phase via a new SRv6-PCE-CAPABILITY sub-TLV
(see details in Section 3.3.1.1). (see details in Section 4.1.1).
3.2. SRv6-Specific PCEP Message Extensions 3.2. SRv6-Specific PCEP Message Extensions
As defined in [RFC5440], a PCEP message consists of a common header As defined in [RFC5440], a PCEP message consists of a common header
followed by a variable length body made up of mandatory and/or followed by a variable length body made up of mandatory and/or
optional objects. This document does not require any changes in the optional objects. This document does not require any changes in the
format of PCReq and PCRep messages specified in [RFC5440], PCInitiate format of PCReq and PCRep messages specified in [RFC5440], PCInitiate
message specified in [RFC8281], and PCRpt and PCUpd messages message specified in [RFC8281], and PCRpt and PCUpd messages
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.
3.3. Object Formats 4. Object Formats
3.3.1. The OPEN Object 4.1. The OPEN Object
3.3.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 7, line 24 skipping to change at page 7, line 35
TLV. TLV.
The format of the SRv6-PCE-CAPABILITY sub-TLV is shown in the The format of the SRv6-PCE-CAPABILITY sub-TLV is shown in the
following figure: following figure:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD1 | Length | | Type=TBD1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |L| | Reserved | Flags |N|X|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSD-Type | MSD-Value | MSD-Type | MSD-Value | | MSD-Type | MSD-Value | MSD-Type | MSD-Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ... // // ... //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSD-Type | MSD-Value | Padding | | MSD-Type | MSD-Value | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SRv6-PCE-CAPABILITY sub-TLV format Figure 1: SRv6-PCE-CAPABILITY sub-TLV format
skipping to change at page 7, line 39 skipping to change at page 8, line 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSD-Type | MSD-Value | Padding | | MSD-Type | MSD-Value | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SRv6-PCE-CAPABILITY sub-TLV format Figure 1: SRv6-PCE-CAPABILITY sub-TLV format
The code point for the TLV type (TBD1) is to be defined by IANA. The The code point for the TLV type (TBD1) is to be defined by IANA. The
TLV length is variable. TLV length is variable.
The value comprise of - The value comprise of -
Reserved: 2 octet, this field MUST be set to 0 on transmission, Reserved: 2 octet, this field MUST be set to 0 on transmission,
and ignored on receipt. and ignored on receipt.
Flags: 2 octet, one bit is currently assigned in this document. Flags: 2 octet, two bits are currently assigned in this document.
L bit: A PCC sets this bit to 1 to indicate that it does not 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
SRv6-SID.
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 per
the IGP MSD Type registry created by [RFC8491] and populated with the IGP MSD Type registry created by [RFC8491]and populated with
SRv6 MSD types as per [I-D.bashandy-isis-srv6-extensions]; MSD- SRv6 MSD types as per [I-D.bashandy-isis-srv6-extensions]; MSD-
Value (1 octet) is as per [RFC8491]. 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.
3.3.1.2. Exchanging the SRv6 Capability 4.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 [RFC8408]. This document defines a
new Path Setup Type (PST=TBD2) for SRv6.
The LSP-IDENTIFIERS TLV MAY be present for the above PST type.
4.3. ERO
In order to support SRv6, new subobjects "SRv6-ERO" and "SRv6-RRO"
are defined in ERO and RRO respectively.
4.3.1. SRv6-ERO Subobject
An SRv6-ERO subobject is formatted as shown in the following diagram.
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=TBD3 | Length | NT | Flags |F|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | Function Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SRv6 SID (optional) |
| (128-bit) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NAI (variable, optional) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SRv6-ERO Subobject Format
The fields in the SRv6-ERO Subobject are as follows:
The 'L' Flag: Indicates whether the subobject represents a loose-hop
(see [RFC3209]). If this flag is set to zero, a PCC MUST NOT
overwrite the SID value present in the SRv6-ERO subobject.
Otherwise, a PCC MAY expand or replace one or more SID values in the
received SRv6-ERO based on its local policy.
Type: Set to TBD3.
Length: Contains the total length of the subobject in octets. The
Length MUST be at least 24, and MUST be a multiple of 4. An SRv6-ERO
subobject MUST contain at least one of a SRv6-SID or an NAI. The
flags described below indicate whether the SRv6-SID or NAI fields are
absent.
NAI Type (NT): Indicates the type and format of the NAI contained in
the object body, if any is present. If the F bit is set to zero (see
below) then the NT field has no meaning and MUST be ignored by the
receiver. This document reuses NT types defined in
[I-D.ietf-pce-segment-routing]:
If NT value is 0, the NAI MUST NOT be included.
When NT value is 2, the NAI is as per the 'IPv6 Node ID' format
defined in [I-D.ietf-pce-segment-routing], which specifies an IPv6
address. This is used to identify the owner of the SRv6
Identifier. This is optional, as the LOC (the locater portion) of
the SRv6 SID serves a similar purpose (when present).
When NT value is 3, 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.
When NT value is 6, the NAI is as per the 'link-local IPv6
addresses' format defined in [I-D.ietf-pce-segment-routing], which
specify a pair of (global IPv6 address, interface ID) tuples. It
is used to identify the IPv6 Adjacency and used with the SRv6 Adj-
SID.
SR-MPLS specific NT types are not valid in SRv6-ERO.
Flags: Used to carry additional information pertaining to the
SRv6-SID. This document defines the following flag bits. The other
bits MUST be set to zero by the sender and MUST be ignored by the
receiver.
o S: When this bit is set to 1, the SRv6-SID value in the subobject
body is absent. In this case, the PCC is responsible for choosing
the SRv6-SID value, e.g., by looking up in the SR-DB using the NAI
which, in this case, MUST be present in the subobject. If the S
bit is set to 1 then F bit MUST be set to zero.
o F: When this bit is set to 1, the NAI value in the subobject body
is absent. The F bit MUST be set to 1 if NT=0, and otherwise MUST
be set to zero. The S and F bits MUST NOT both be set to 1.
Function Code: A 16 bit field representing supported functions
associated with SRv6 SIDs. This information is optional and plays no
role in the SRH imposed on the packet. It could be included for
maintainability and diagnostic purpose. If function code is not
defined 0 is used. Functions codes are defined in
[I-D.filsfils-spring-srv6-network-programming].
SRv6 SID: SRv6 Identifier is the 128 bit IPv6 addresses representing
the SRv6 segment.
NAI: The NAI associated with the SRv6-SID. The NAI's format depends
on the value in the NT field, and is described in
[I-D.ietf-pce-segment-routing].
At least one of the SRv6-SID and the NAI MUST be included in the
SRv6-ERO subobject, and both MAY be included.
4.4. RRO
4.4.1. SRv6-RRO Subobject
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
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
equally to this specification without change.
An RRO contains one or more subobjects called "SRv6-RRO subobjects"
whose format is 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=TBD4 | Length | NT | Flags |F|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | Function Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SRv6 SID |
| (128-bit) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NAI (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: SRv6-RRO Subobject Format
The format of the SRv6-RRO subobject is the same as that of the
SRv6-ERO subobject, but without the L flag.
Ordering of SRv6-RRO subobjects by PCC in PCRpt message remains as
per [I-D.ietf-pce-segment-routing].
5. Procedures
5.1. Exchanging the SRv6 Capability
A PCC indicates that it is capable of supporting the head-end A PCC indicates that it is capable of supporting the head-end
functions for SRv6 by including the SRv6-PCE-CAPABILITY sub-TLV in functions for SRv6 by including the SRv6-PCE-CAPABILITY sub-TLV in
the Open message that it sends to a PCE. A PCE indicates that it is the Open message that it sends to a PCE. A PCE indicates that it is
capable of computing SRv6 paths by including the SRv6-PCE-CAPABILITY capable of computing SRv6 paths by including the SRv6-PCE-CAPABILITY
sub-TLV in the Open message that it sends to a PCC. sub-TLV in the Open message that it sends to a PCC.
If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a
PST list containing PST=TBD2, but the SRv6-PCE-CAPABILITY sub-TLV is PST list containing PST=TBD2, but the SRv6-PCE-CAPABILITY sub-TLV is
absent, then the PCEP speaker MUST send a PCErr message with Error- absent, then the PCEP speaker MUST send a PCErr message with Error-
Type 10 (Reception of an invalid object) and Error-Value TBD5 (to be Type 10 (Reception of an invalid object) and Error-Value TBD5 (to be
assigned by IANA) (Missing PCE-SRv6-CAPABILITY sub-TLV) and MUST then assigned by IANA) (Missing PCE-SRv6-CAPABILITY sub-TLV) and MUST then
close the PCEP session. If a PCEP speaker receives a PATH-SETUP- close the PCEP session. If a PCEP speaker receives a PATH-SETUP-
TYPE-CAPABILITY TLV with a SRv6-PCE-CAPABILITY sub-TLV, but the PST TYPE-CAPABILITY TLV with a SRv6-PCE-CAPABILITY sub-TLV, but the PST
list does not contain PST=TBD2, then the PCEP speaker MUST ignore the list does not contain PST=TBD2, then the PCEP speaker MUST ignore the
SRv6-PCE-CAPABILITY sub-TLV. SRv6-PCE-CAPABILITY sub-TLV.
The number of SRv6 SIDs that can be imposed on a packet depends on The number of SRv6 SIDs that can be imposed on a packet depends on
the PCC's IPv6 data plane's capability. If a PCC sets the L flag to the PCC's IPv6 data plane's capability. If a PCC sets the X flag to
1 then the MSD is not used and MUST not be included. If a PCE 1 then the MSD is not used and MUST NOT be included. If a PCE
receives an SRv6-PCE-CAPABILITY sub-TLV with the L flag set to 1 then receives an SRv6-PCE-CAPABILITY sub-TLV with the X flag set to 1 then
it MUST ignore any MSD-Type, MSD-Value fields and MUST assume that it MUST ignore any MSD-Type, MSD-Value fields and MUST assume that
the sender can impose any length of SRH. If a PCC sets the L flag to the sender can impose any length of SRH. If a PCC sets the X flag to
zero, then it sets the SRv6 MSD-Type, MSD-Value fields that it can zero, then it sets the SRv6 MSD-Type, MSD-Value fields that it can
impose on a packet. If a PCE receives an SRv6-PCE-CAPABILITY sub-TLV impose on a packet. If a PCE receives an SRv6-PCE-CAPABILITY sub-TLV
with the L flag and SRv6 MSD-Type, MSD-Value fields both set to zero with the X flag and SRv6 MSD-Type, MSD-Value fields both set to zero
then it is considered as an error and the PCE MUST respond with a then it is considered as an error and the PCE MUST respond with a
PCErr message (Error-Type=1 "PCEP session establishment failure" and PCErr message (Error-Type=1 "PCEP session establishment failure" and
Error-Value=1 "reception of an invalid Open message or a non Open Error-Value=1 "reception of an invalid Open message or a non Open
message."). In case the MSD-Type in SRv6-PCE-CAPABILITY sub-TLV message."). In case the MSD-Type in SRv6-PCE-CAPABILITY sub-TLV
received by the PCE does not correspond to one of the SRv6 MSD types, received by the PCE does not correspond to one of the SRv6 MSD types,
the PCE MUST respond with a PCErr message (Error-Type=1 "PCEP session the PCE MUST respond with a PCErr message (Error-Type=1 "PCEP session
establishment failure" and Error-Value=1 "reception of an invalid establishment failure" and Error-Value=1 "reception of an invalid
Open message or a non Open message."). Open message or a non Open message.").
Note that the MSD-Type, MSD-Value exchanged via the SRv6-PCE- Note that the MSD-Type, MSD-Value exchanged via the SRv6-PCE-
skipping to change at page 9, line 31 skipping to change at page 13, line 10
session is established with a non-zero SRv6 MSD value, and the PCC session is established with a non-zero SRv6 MSD value, and the PCC
receives an SRv6 path containing more SIDs than specified in the SRv6 receives an SRv6 path containing more SIDs than specified in the SRv6
MSD value (based on the SRv6 MSD type), the PCC MUST send a PCErr MSD value (based on the SRv6 MSD type), the PCC MUST send a PCErr
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 L 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 L flag and not include a PCC to a PCE. As such, a PCE MUST set the flags to zero and not
(MSD-Type,MSD-Value) in an outbound message to a PCC. Similarly, a include any (MSD-Type, MSD-Value) pair in the SRv6-PCE-CAPABILITY
PCC MUST ignore any (MSD-Type,MSD-Value) received from a PCE. If a sub-TLV in an outbound message to a PCC. Similarly, a PCC MUST
PCE receives multiple SRv6-PCE-CAPABILITY sub-TLVs in an Open ignore N, X flag and any (MSD-Type,MSD-Value) pair received from a
message, it processes only the first sub-TLV received. PCE. If a PCE receives multiple SRv6-PCE-CAPABILITY sub-TLVs in an
Open message, it processes only the first sub-TLV received.
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 [RFC8408]. This document defines a
new Path Setup Type (PST=TBD2) for SRv6.
The LSP-IDENTIFIERS TLV MAY be present for the above PST type.
3.3.3. ERO Object
In order to support SRv6, the SR-ERO subobject is used
[I-D.ietf-pce-segment-routing]. This documents extends the SR-ERO
subobject. All the processing rules remains the same.
3.3.3.1. SR-ERO Subobject
For supporting SRv6, a new NAI Type (NT) is defined, the format of
SR-ERO sub object remains the same as defined in
[I-D.ietf-pce-segment-routing].
When the NAI Type (NT) 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 is not used for SRv6
and MUST NOT be included. 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 | NT | Flags |F|S|C|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (not included) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6I (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SR-ERO Subobject Format 5.2. ERO Processing
The description of all the flags and fields is as per The ERO processing remains as per [RFC5440]and
[I-D.ietf-pce-segment-routing]. [I-D.ietf-pce-segment-routing].
For SRv6 segments, a new NT (NAI Type) is assigned by IANA as TBD3. 5.2.1. SRv6 ERO Validation
For SRv6 segments (when NT is TBD3), M and C flag MUST NOT be set.
The S flag MUST be set and SID field MUST NOT be included. The F bit
MUST NOT be set.
If these flags are not set properly, the subobject MUST be considered
malformed and the PCEP speaker react as per the error handling
described in Section 3.3.3.2.
The SRv6I format is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SRv6 Identifier |
| (128-bit) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6NT| Flags | Function Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NAI (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: SR-ERO Subobject's SRv6I Format
SRv6 Identifier is the 128 bit IPv6 addresses representing SRv6
segment.
SRv6NT is the SRv6 NAI 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. This MUST be set to 0 and ignored on receipt.
Function Code is is the 16 bit field representing supported
functions associated with SRv6 SIDs. This information is optional
and included only for maintainability. Following function codes
are currently defined -
0: Reserved
1: End Function
2: End.DX6 Function
3: End.DT6 Function If a PCC does not support the SRv6 PCE Capability and thus cannot
recognize the SRv6-ERO or SRv6-RRO subobjects, it will respond
according to the rules for a malformed object per [RFC5440].
4: End.X Function 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.
NAI field [I-D.ietf-pce-segment-routing] contains the NAI o If NT=0, the F bit MUST be 1, the S bit MUST be zero and the
associated with the SRv6 Identifier. Depending on the value of Length MUST be 24.
SRv6NT, the NAI can have different formats.
When SRv6NT value is 1, the NAI is as per the 'IPv6 Node ID' o If NT=2, the F bit MUST be zero. If the S bit is 1, the Length
format defined in [I-D.ietf-pce-segment-routing], which specify MUST be 24, otherwise the Length MUST be 40.
an IPv6 address. This is used to identify the owner of the
SRv6 Identifier. This is optional, as the LOC (the locater
portion) of the SRv6 SID serves a similar purpose.
When SRv6NT value is 2, the NAI is as per the 'IPv6 Adjacency' o If NT=4, the F bit MUST be zero. If the S bit is 1, the Length
format defined in [I-D.ietf-pce-segment-routing], which specify MUST be 40, otherwise the Length MUST be 56.
a pair of IPv6 addresses. This is used to identify the IPv6
Adjacency and used with the SRv6 Adj-SID.
Note that when SRv6NT value is 0, NAI is not included and MUST o If NT=6, the F bit MUST be zero. If the S bit is 1, the Length
be NULL. MUST be 48, otherwise the Length MUST be 64.
[Editor's Note - Add IPv6 unnumbered adjacency, once done by o NT types (1, 3, and 5) are not valid for SRv6.
[I-D.ietf-pce-segment-routing]]
3.3.3.2. ERO Processing 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
a PCErr message with Error-Type = 10 ("Reception of an invalid
object") and Error-Value = 11 ("Malformed object").
The ERO and SR-ERO subobject processing remains as per [RFC5440] and If a PCEP speaker that does not recognize the NT value received in
SRv6-ERO subobject, it would behave as per
[I-D.ietf-pce-segment-routing]. [I-D.ietf-pce-segment-routing].
The NT MUST only be TDB3, if the PST=TBD3 is set in the PCEP message In case a PCEP speaker receives the SRv6-ERO subobject, when the PST
and SRv6-PCE-CAPABILITY sub-TLV is exchanged with the PCEP peer. In is not set to TBD2 or SRv6-PCE-CAPABILITY sub-TLV was not exchanged,
case a PCEP speaker receives the SR-ERO subobject with NT indicating it MUST send a PCErr message with Error-Type = 19 ("Invalid
SRv6 segment, when the PST is not set to TBD3 or SRv6-PCE-CAPABILITY Operation") and Error-Value = TBD5 ("Attempted SRv6 when the
sub-TLV was not exchanged, it MUST send a PCErr message with Error- capability was not advertised").
Type = 19 ("Invalid Operation") and Error-Value = TBD4 ("Attempted
SRv6 when the capability was not advertised"). A PCEP speaker that
does not recognize the NT value, it would behave as per
[I-D.ietf-pce-segment-routing].
If a PCC receives a list of SRv6 segments, and the number of SRv6 If a PCC receives a list of SRv6 segments, and the number of SRv6
segments exceeds the SRv6 MSD that the PCC can impose on the packet segments exceeds the SRv6 MSD that the PCC can impose on the packet
(SRH), it MAY send a PCErr message with Error-Type = 10 ("Reception (SRH), it MUST send a PCErr message with Error-Type = 10 ("Reception
of an invalid object") and Error-Value = TBD ("Unsupported number of of an invalid object") and Error-Value = TBD ("Unsupported number of
Segment ERO subobjects") as per [I-D.ietf-pce-segment-routing]. Segment ERO subobjects") as per [I-D.ietf-pce-segment-routing].
When a PCEP speaker detects that all subobjects of ERO are not When a PCEP speaker detects that all subobjects of ERO are not of
identical to SRv6, and if it does not handle such ERO, it MUST send a type TBD3, and if it does not handle such ERO, it MUST send a PCErr
PCErr message with Error-Type = 10 ("Reception of an invalid object") message with Error-Type = 10 ("Reception of an invalid object") and
and Error-Value = TBD ("Non-identical ERO subobjects")as per Error-Value = TBD ("Non-identical ERO subobjects")as per
[I-D.ietf-pce-segment-routing]. [I-D.ietf-pce-segment-routing].
When a PCEP speaker receives an SR-ERO subobject for SRv6 segment, M, 5.2.2. Interpreting the SRv6-ERO
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.
3.3.3.2.1. Interpreting the SR-ERO
The SR-ERO contains a sequence of subobjects. According to The SR-ERO contains a sequence of subobjects. According to
[I-D.ietf-spring-segment-routing-policy], each SR-ERO subobject in [I-D.ietf-spring-segment-routing-policy], each SRv6-ERO subobject in
the sequence identifies a segment that the traffic will be directed the sequence identifies a segment that the traffic will be directed
to, in the order given. That is, the first subobject identifies the to, in the order given. That is, the first subobject identifies the
first segment the traffic will be directed to, the second SR-ERO first segment the traffic will be directed to, the second SR-ERO
subobject represents the second segment, and so on. subobject represents the second segment, and so on.
The PCC interprets the SR-ERO by converting it to an SRv6 SRH plus a The PCC interprets the SRv6-ERO by converting it to an SRv6 SRH plus
next hop. The PCC sends packets along the segment routed path by a next hop. The PCC sends packets along the segment routed path by
prepending the SRH onto the packets and sending the resulting, prepending the SRH onto the packets and sending the resulting,
modified packet to the next hop. modified packet to the next hop.
3.3.4. RRO Object 5.3. RRO Processing
In order to support SRv6, the SR-RRO Subobject is used
[I-D.ietf-pce-segment-routing]. All other processing rules remains
the same.
3.3.4.1. SR-RRO Subobject The syntax checking rules that apply to the SRv6-RRO subobject are
identical to those of the SRv6-ERO subobject, except as noted below.
For SRv6 segments, a new NT (NAI Type) is assigned by IANA as TBD3, If a PCEP speaker receives an SRv6-RRO subobject in which both SRv6
the format of SR-RRO sub object remains the same as the SR-ERO SID and NAI are absent, it MUST consider the entire RRO invalid and
subobject, but without the L flag [I-D.ietf-pce-segment-routing]. send a PCErr message with Error-Type = 10 ("Reception of an invalid
object") and Error-Value = TBD6 ("Both SID and NAI are absent in
SRv6-RRO subobject").
When the NAI Type (NT) indicates SRv6, then the SR-RRO subobject If a PCE detects that the subobjects of an RRO are a mixture of
represent a SRv6 segment and include a field SRv6I (SRv6 Identifier) SRv6-RRO subobjects and subobjects of other types, then it MUST send
in place of NAI (Node or Adjacency Identifier) defined in a PCErr message with Error-Type = 10 ("Reception of an invalid
[I-D.ietf-pce-segment-routing]. The 32 bit SID MUST NOT be included. object") and Error-Value = TBD7 ("RRO mixes SRv6-RRO subobjects with
The format of SR-RRO subobject is reproduced with the SRv6I field as other subobject types").
shown below:
0 1 2 3 6. Security Considerations
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 (not included) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6I (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SR-RRO Subobject Format The security considerations described in [RFC5440], [RFC8231]and
[RFC8281], [I-D.ietf-pce-segment-routing], are applicable to this
specification. No additional security measure is required.
The description of all fields and flags is as per SR-ERO subobject. 7. IANA Considerations
Processing rules of SR-RRO subobject are identical to those of SR-ERO 7.1. PCEP ERO and RRO subobjects
subobject.
If a PCE detects that all subobjects of RRO are not identical, and if This document defines a new subobject type for the PCEP explicit
it does not handle such RRO, it MUST send a PCErr message with Error- route object (ERO), and a new subobject type for the PCEP record
Type = 10 ("Reception of an invalid object") and Error-Value = 10 route object (RRO). The code points for subobject types of these
("Non-identical RRO subobjects"). objects is maintained in the RSVP parameters registry, under the
EXPLICIT_ROUTE and ROUTE_RECORD objects. IANA is requested to
allocate code-points in the RSVP Parameters registry for each of the
new subobject types defined in this document.
3.4. Security Considerations Object Subobject Subobject Type
--------------------- -------------------------- ------------------
EXPLICIT_ROUTE SRv6-ERO (PCEP-specific) TBD3
ROUTE_RECORD SRv6-RRO (PCEP-specific) TBD4
The security considerations described in [RFC5440], [RFC8231] and 7.2. New SRv6-ERO Flag Registry
[RFC8281], [I-D.ietf-pce-segment-routing], are applicable to this
specification. No additional security measure is required.
3.5. IANA Considerations IANA is requested to create a new sub-registry, named "SRv6-ERO Flag
Field", within the "Path Computation Element Protocol (PCEP) Numbers"
registry to manage the Flag field of the SRv6-ERO subobject. New
values are to be assigned by Standards Action [RFC8126]. Each bit
should be tracked with the following qualities:
This document requests IANA to include (I) bit in flags registry for o Bit number (counting from bit 0 as the most significant bit)
SR-ERO and SR-RRO sub-objects. Other changes are defined as:
3.5.1. PCEP Objects o Capability description
3.5.1.1. ERROR Objects o Defining RFC
IANA is requested to allocate code-points in the PCEP-ERROR Object The following values are defined in this document:
Error Types and Values registry for the following new error-values:
Error-Type Meaning Bit Description Reference
---------- ------- ----- ------------------ --------------
10 Reception of an invalid object 0-9 Unassigned
Error-value = TBD5 (Missing 10 NAI is absent (F) This document
PCE-SRv6-CAPABILITY sub-TLV) 11 SID is absent (S) This document
19 Invalid Operation
Error-value = TBD4 (Attempted SRv6 when the
capability was not advertised)
3.5.1.2. TLV Type Indicators 7.3. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators
IANA is requested to make the assignment of the new code points for IANA maintains a sub-registry, named "PATH-SETUP- TYPE-CAPABILITY
the existing "PCEP TLV Type Indicators" registry as follows: Sub-TLV Type Indicators", within the "Path Computation Element
Protocol (PCEP) Numbers" registry to manage the type indicator space
for sub-TLVs of the PATH-SETUP-TYPE-CAPABILITY TLV. IANA is
requested to make the following assignment:
Value Meaning Reference Value Meaning Reference
----- ------- --------- ----- ------- ---------
TBD1 SRv6-PCE-CAPABILITY This Document TBD1 SRv6-PCE-CAPABILITY This Document
3.5.1.3. New Path Setup Type 7.4. SRv6 PCE Capability Flags
[RFC8408] defines the PATH-SETUP-TYPE TLV and requests that IANA IANA is requested to create a new sub-registry, named "SRv6
creates a registry to manage the value of the PATH-SETUP-TYPE TLV's Capability Flag Field", within the "Path Computation Element Protocol
PST field. IANA is requested to allocate a new code point in the (PCEP) Numbers" registry to manage the Flag field of the SRv6-PCE-
PCEP PATH_SETUP_TYPE TLV PST field registry, as follows: CAPABILITY sub-TLV. New values are to be assigned by Standards
Action [RFC8126]. Each bit should be tracked with the following
qualities:
o Bit number (counting from bit 0 as the most significant bit)
o Capability description
o Defining RFC
The following values are defined in this document:
Bit Description Reference
0-13 Unassigned
14 Node or Adjacency This document
Identifier (NAI) is
supported (N)
15 Unlimited Maximum SID This document
Depth (X)
7.5. New Path Setup Type
[RFC8408]created a sub-registry within the "Path Computation Element
Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types".
IANA is requested to allocate a new code point within this registry,
as follows:
Value Description Reference Value Description Reference
----- ----------- --------- ----- ----------- ---------
TBD2 SRv6 (SRH) technique This Document TBD2 Traffic engineering path is This Document
setup using SRv6.
3.6. The NAI Type field 7.6. ERROR Objects
As per [I-D.ietf-pce-segment-routing], a new subregistery for "PCEP IANA is requested to allocate code-points in the PCEP-ERROR Object
SR-ERO NAI Types" was created. IANA is requested to make the Error Types and Values registry for the following new error-values:
assignment of the new code points in the afore-mentioned registry as
follows:
Value Description Reference Error-Type Meaning
----- ------- --------- ---------- -------
TBD3 NAI is an SRv6 segment This Document 10 Reception of an invalid object
Error-value = TBD5 (Missing
PCE-SRv6-CAPABILITY sub-TLV)
Error-value = TBD6 (Both SID and NAI are absent
in SRv6-RRO subobject)
Error-value = TBD7 (RRO mixes SRv6-RRO subobjects
with other subobject types)
19 Invalid Operation
Error-value = TBD5 (Attempted SRv6 when the
capability was not advertised)
4. Acknowledgements 8. Acknowledgements
The authors would like to thank Jeff Tentsura for suggestions The authors would like to thank Jeff Tentsura, Adrian Farrel and
regarding SRv6 MSD Types. Khasanov Boris for valuable suggestions.
5. References 9. References
5.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>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[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>.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, DOI 10.17487/RFC5511, April Specifications", RFC 5511, DOI 10.17487/RFC5511, April
2009, <https://www.rfc-editor.org/info/rfc5511>. 2009, <https://www.rfc-editor.org/info/rfc5511>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
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>.
skipping to change at page 16, line 42 skipping to change at page 19, line 16
"Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491,
DOI 10.17487/RFC8491, November 2018, DOI 10.17487/RFC8491, November 2018,
<https://www.rfc-editor.org/info/rfc8491>. <https://www.rfc-editor.org/info/rfc8491>.
[I-D.ietf-pce-segment-routing] [I-D.ietf-pce-segment-routing]
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "PCEP Extensions for Segment Routing", and J. Hardwick, "PCEP Extensions for Segment Routing",
draft-ietf-pce-segment-routing-16 (work in progress), draft-ietf-pce-segment-routing-16 (work in progress),
March 2019. March 2019.
5.2. Informative References [I-D.bashandy-isis-srv6-extensions]
Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and
Z. Hu, "IS-IS Extensions to Support Routing over IPv6
Dataplane", draft-bashandy-isis-srv6-extensions-05 (work
in progress), March 2019.
[I-D.filsfils-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J.,
daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
Network Programming", draft-filsfils-spring-srv6-network-
programming-07 (work in progress), February 2019.
9.2. Informative References
[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>.
[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
Litkowski, S., Horneffer, M., and R. Shakir, "Source Litkowski, S., Horneffer, M., and R. Shakir, "Source
Packet Routing in Networking (SPRING) Problem Statement Packet Routing in Networking (SPRING) Problem Statement
and Requirements", RFC 7855, DOI 10.17487/RFC7855, May and Requirements", RFC 7855, DOI 10.17487/RFC7855, May
skipping to change at page 17, line 25 skipping to change at page 20, line 8
[RFC8354] Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., [RFC8354] Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R.,
Ed., and M. Townsley, "Use Cases for IPv6 Source Packet Ed., and M. Townsley, "Use Cases for IPv6 Source Packet
Routing in Networking (SPRING)", RFC 8354, Routing in Networking (SPRING)", RFC 8354,
DOI 10.17487/RFC8354, March 2018, DOI 10.17487/RFC8354, March 2018,
<https://www.rfc-editor.org/info/rfc8354>. <https://www.rfc-editor.org/info/rfc8354>.
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and
d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header
(SRH)", draft-ietf-6man-segment-routing-header-16 (work in (SRH)", draft-ietf-6man-segment-routing-header-18 (work in
progress), February 2019. progress), April 2019.
[I-D.ietf-isis-segment-routing-extensions] [I-D.ietf-isis-segment-routing-extensions]
Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A.,
Gredler, H., and B. Decraene, "IS-IS Extensions for Gredler, H., and B. Decraene, "IS-IS Extensions for
Segment Routing", draft-ietf-isis-segment-routing- Segment Routing", draft-ietf-isis-segment-routing-
extensions-22 (work in progress), December 2018. extensions-23 (work in progress), March 2019.
[I-D.ietf-ospf-ospfv3-segment-routing-extensions] [I-D.ietf-ospf-ospfv3-segment-routing-extensions]
Psenak, P. and S. Previdi, "OSPFv3 Extensions for Segment Psenak, P. and S. Previdi, "OSPFv3 Extensions for Segment
Routing", draft-ietf-ospf-ospfv3-segment-routing- Routing", draft-ietf-ospf-ospfv3-segment-routing-
extensions-23 (work in progress), January 2019. extensions-23 (work in progress), January 2019.
[I-D.ietf-spring-segment-routing-policy] [I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d.,
bogdanov@google.com, b., and P. Mattes, "Segment Routing bogdanov@google.com, b., and P. Mattes, "Segment Routing
Policy Architecture", draft-ietf-spring-segment-routing- Policy Architecture", draft-ietf-spring-segment-routing-
policy-02 (work in progress), October 2018. policy-02 (work in progress), October 2018.
[I-D.filsfils-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J.,
daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
Network Programming", draft-filsfils-spring-srv6-network-
programming-07 (work in progress), February 2019.
[I-D.li-ospf-ospfv3-srv6-extensions] [I-D.li-ospf-ospfv3-srv6-extensions]
Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak,
"OSPFv3 Extensions for SRv6", draft-li-ospf- "OSPFv3 Extensions for SRv6", draft-li-ospf-
ospfv3-srv6-extensions-03 (work in progress), March 2019. ospfv3-srv6-extensions-03 (work in progress), March 2019.
[I-D.bashandy-isis-srv6-extensions]
Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and
Z. Hu, "IS-IS Extensions to Support Routing over IPv6
Dataplane", draft-bashandy-isis-srv6-extensions-05 (work
in progress), March 2019.
[I-D.dawra-idr-bgpls-srv6-ext] [I-D.dawra-idr-bgpls-srv6-ext]
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-05 (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 Dhruv Dhody Huawei Technologies Divyashree Techno
Huawei Technologies Park, Whitefield Bangalore, Karnataka 560066 India EMail:
Divyashree Techno Park, Whitefield dhruv.ietf@gmail.com Huang Wumin Huawei Technologies Huawei
Bangalore, Karnataka 560066 Building, No. 156 Beiqing Rd. Beijing 100095 China Email:
India huangwumin@huawei.com
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
skipping to change at page 20, line 4 skipping to change at page 21, line 37
Huawei Campus, No. 156 Beiqing Rd. Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
EMail: chengli13@huawei.com EMail: chengli13@huawei.com
Siva Sivabalan Siva Sivabalan
Cisco Systems Cisco Systems
EMail: msiva@cisco.com EMail: msiva@cisco.com
Prejeeth Kaladharan Prejeeth Kaladharan
RtBrick Inc RtBrick Inc
Bangalore, Karnataka Bangalore, Karnataka
India India
EMail: prejeeth@rtbrick.com EMail: prejeeth@rtbrick.com
Yongqing Zhu
China Telecom
109 West Zhongshan Ave, Tianhe District
Bangalore, Guangzhou
P.R. China
EMail: zhuyq.gd@chinatelecom.cn
 End of changes. 94 change blocks. 
319 lines changed or deleted 416 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/