draft-ietf-pce-segment-routing-ipv6-02.txt   draft-ietf-pce-segment-routing-ipv6-03.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 10, 2019 S. Sivabalan Expires: April 11, 2020 S. Sivabalan
Cisco Systems Cisco Systems
P. Kaladharan P. Kaladharan
RtBrick Inc RtBrick Inc
Z. Yongqing Z. Yongqing
China Telecom China Telecom
April 8, 2019 October 9, 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-02 draft-ietf-pce-segment-routing-ipv6-03
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 2, line 20 skipping to change at page 2, line 20
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 10, 2019. This Internet-Draft will expire on April 11, 2020.
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 4, line 4 skipping to change at page 4, line 5
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.ietf-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
skipping to change at page 7, line 16 skipping to change at page 7, line 16
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 MUST indicate its support of the function described in
in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN
OPEN object with this new PST included in the PST list. 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
capability. If a PCEP speaker includes PST=TBD2 in the PST List of capability. If a PCEP speaker includes PST=TBD2 in the PST List of
the PATH-SETUP-TYPE-CAPABILITY TLV then it MUST also include the the PATH-SETUP-TYPE-CAPABILITY TLV then it MUST also include the
SRv6-PCE- CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY SRv6-PCE- CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY
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:
skipping to change at page 8, line 20 skipping to change at page 8, line 20
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 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 per the IGP MSD Type registry created by [RFC8491] and populated
with SRv6 MSD types as per [I-D.bashandy-isis-srv6-extensions]; with SRv6 MSD types as per [I-D.ietf-lsr-isis-srv6-extensions];
MSD-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 This 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
In order to indicate the SRv6 path, RP or SRP object MUST include the 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 PATH-SETUP-TYPE TLV specified in [RFC8408]. This document defines a
new Path Setup Type (PST=TBD2) for SRv6. new Path Setup Type (PST=TBD2) for SRv6.
The LSP-IDENTIFIERS TLV MAY be present for the above PST type. The LSP-IDENTIFIERS TLV MAY be present for the above PST type.
4.3. ERO 4.3. ERO
In order to support SRv6, new subobjects "SRv6-ERO" and "SRv6-RRO" In order to support SRv6, new subobject "SRv6-ERO" is defined in ERO.
are defined in ERO and RRO respectively.
4.3.1. SRv6-ERO Subobject 4.3.1. SRv6-ERO Subobject
An SRv6-ERO subobject is formatted as shown in the following diagram. An SRv6-ERO subobject is formatted as shown in the following figure.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type=TBD3 | Length | NT | Flags |F|S| |L| Type=TBD3 | Length | NT | Flags |F|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | Function Code | | reserved | Function Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| SRv6 SID (optional) | | SRv6 SID (optional) |
skipping to change at page 9, line 34 skipping to change at page 9, line 34
The 'L' Flag: Indicates whether the subobject represents a loose-hop The 'L' Flag: Indicates whether the subobject represents a loose-hop
(see [RFC3209]). If this flag is set to zero, a PCC MUST NOT (see [RFC3209]). If this flag is set to zero, a PCC MUST NOT
overwrite the SID value present in the SRv6-ERO subobject. overwrite the SID value present in the SRv6-ERO subobject.
Otherwise, a PCC MAY expand or replace one or more SID values in the Otherwise, a PCC MAY expand or replace one or more SID values in the
received SRv6-ERO based on its local policy. received SRv6-ERO based on its local policy.
Type: Set to TBD3. Type: Set to TBD3.
Length: Contains the total length of the subobject in octets. The 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 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 subobject MUST contain at least one of a SRv6-SID or an NAI. The S
flags described below indicate whether the SRv6-SID or NAI fields are and F bit in the Flags field indicates whether the SRv6-SID or NAI
absent. fields are absent.
NAI Type (NT): Indicates the type and format of the NAI contained in 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 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 below) then the NT field has no meaning and MUST be ignored by the
receiver. This document reuses NT types defined in receiver. This document reuses NT types defined in
[I-D.ietf-pce-segment-routing]: [I-D.ietf-pce-segment-routing]:
If NT value is 0, the NAI MUST NOT be included. 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 When NT value is 2, the NAI is as per the 'IPv6 Node ID' format
skipping to change at page 10, line 37 skipping to change at page 10, line 37
bit is set to 1 then F bit MUST be set to zero. 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 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 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. 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 Function Code: A 16 bit field representing supported functions
associated with SRv6 SIDs. This information is optional and plays no associated with SRv6 SIDs. This information is optional and plays no
role in the SRH imposed on the packet. It could be included for role in the SRH imposed on the packet. It could be included for
maintainability and diagnostic purpose. If function code is not maintainability and diagnostic purpose. If function code is not
defined 0 is used. Functions codes are defined in defined, 0 is used. Functions codes are defined in
[I-D.filsfils-spring-srv6-network-programming]. [I-D.ietf-spring-srv6-network-programming].
SRv6 SID: SRv6 Identifier is the 128 bit IPv6 addresses representing SRv6 SID: SRv6 Identifier is the 128 bit IPv6 addresses representing
the SRv6 segment. the SRv6 segment.
NAI: The NAI associated with the SRv6-SID. The NAI's format depends NAI: The NAI associated with the SRv6-SID. The NAI's format depends
on the value in the NT field, and is described in on the value in the NT field, and is described in
[I-D.ietf-pce-segment-routing]. [I-D.ietf-pce-segment-routing].
At least one of the SRv6-SID and the NAI MUST be included in the At least one of the SRv6-SID or 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
In order to support SRv6, new subobject "SRv6-RRO" is defined in 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:
skipping to change at page 12, line 38 skipping to change at page 12, line 40
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-
CAPABILITY sub-TLV indicates the SRv6 SID imposition limit for the CAPABILITY sub-TLV indicates the SRv6 SID imposition limit for the
PCC node. However, if a PCE learns these via different means, e.g PCC node. However, if a PCE learns these via different means, e.g
routing protocols, as specified in: routing protocols, as specified in:
[I-D.li-ospf-ospfv3-srv6-extensions]; [I-D.li-ospf-ospfv3-srv6-extensions];
[I-D.bashandy-isis-srv6-extensions]; [I-D.dawra-idr-bgpls-srv6-ext], [I-D.ietf-lsr-isis-srv6-extensions]; [I-D.ietf-idr-bgpls-srv6-ext],
then it ignores the values in the SRv6-PCE-CAPABILITY sub-TLV. then it ignores the values in the SRv6-PCE-CAPABILITY sub-TLV.
Furthermore, whenever a PCE learns the other advanced SRv6 MSD via Furthermore, whenever a PCE learns the other advanced SRv6 MSD via
different means, it MUST use that value regardless of the values different means, it MUST use that value regardless of the values
exchanged in the SRv6-PCE-CAPABILITY sub-TLV. exchanged in the SRv6-PCE-CAPABILITY sub-TLV.
Once an SRv6-capable PCEP session is established with a non-zero SRv6 Once an SRv6-capable PCEP session is established with a non-zero SRv6
MSD value, the corresponding PCE MUST NOT send SRv6 paths with a MSD value, the corresponding PCE MUST NOT send SRv6 paths with a
number of SIDs exceeding that SRv6 MSD value (based on the SRv6 MSD number of SIDs exceeding that SRv6 MSD value (based on the SRv6 MSD
Type). If a PCC needs to modify the SRv6 MSD value, it MUST close Type). If a PCC needs to modify the SRv6 MSD value, it MUST close
the PCEP session and re-establish it with the new value. If a PCEP the PCEP session and re-establish it with the new value. If a PCEP
skipping to change at page 14, line 29 skipping to change at page 14, line 31
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 of When a PCEP speaker detects that all subobjects of ERO are not of
type TBD3, and if it does not handle such ERO, it MUST send a PCErr type TBD3, and if it does not handle such ERO, it 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 = 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].
5.2.2. Interpreting the SRv6-ERO 5.2.2. Interpreting the SRv6-ERO
The SR-ERO contains a sequence of subobjects. According to The SRv6-ERO contains a sequence of subobjects. According to
[I-D.ietf-spring-segment-routing-policy], each SRv6-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 SRv6-ERO
subobject represents the second segment, and so on. subobject represents the second segment, and so on.
The PCC interprets the SRv6-ERO by converting it to an SRv6 SRH plus The PCC interprets the SRv6-ERO by converting it to an SRv6 SRH plus
a 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.
5.3. RRO Processing 5.3. RRO Processing
The syntax checking rules that apply to the SRv6-RRO subobject are The syntax checking rules that apply to the SRv6-RRO subobject are
skipping to change at page 19, line 16 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.
[I-D.bashandy-isis-srv6-extensions] [I-D.ietf-lsr-isis-srv6-extensions]
Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and
Z. Hu, "IS-IS Extensions to Support Routing over IPv6 Z. Hu, "IS-IS Extension to Support Segment Routing over
Dataplane", draft-bashandy-isis-srv6-extensions-05 (work IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-03
in progress), March 2019. (work in progress), October 2019.
[I-D.filsfils-spring-srv6-network-programming] [I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Filsfils, C., Camarillo, P., Leddy, J.,
daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
Network Programming", draft-filsfils-spring-srv6-network- Network Programming", draft-ietf-spring-srv6-network-
programming-07 (work in progress), February 2019. programming-04 (work in progress), October 2019.
9.2. Informative References 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
skipping to change at page 20, line 6 skipping to change at page 20, line 6
DOI 10.17487/RFC8051, January 2017, DOI 10.17487/RFC8051, January 2017,
<https://www.rfc-editor.org/info/rfc8051>. <https://www.rfc-editor.org/info/rfc8051>.
[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., Dukes, D., Previdi, S., Leddy, J.,
d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment
(SRH)", draft-ietf-6man-segment-routing-header-18 (work in Routing Header (SRH)", draft-ietf-6man-segment-routing-
progress), April 2019. header-24 (work in progress), October 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-23 (work in progress), March 2019. extensions-25 (work in progress), May 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-03 (work in progress), May 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-05 (work in progress), August 2019.
[I-D.dawra-idr-bgpls-srv6-ext] [I-D.ietf-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., and B. Decraene, "BGP Link
H. Elmalky, "BGP Link State Extensions for SRv6", draft- State Extensions for SRv6", draft-ietf-idr-bgpls-
dawra-idr-bgpls-srv6-ext-06 (work in progress), March srv6-ext-01 (work in progress), July 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 Huawei Technologies
Divyashree Techno Park, Whitefield Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066 Bangalore, Karnataka 560066
India India
skipping to change at page 21, line 33 skipping to change at page 21, line 33
Email: huangwumin@huawei.com 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: mahend.ietf@gmail.com
Cheng Li Cheng Li
Huawei Technologies Huawei Technologies
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
 End of changes. 28 change blocks. 
43 lines changed or deleted 42 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/