< draft-peng-spring-srv6-compatibility-00.txt   draft-peng-spring-srv6-compatibility-01.txt >
SPRING Working Group S. Peng SPRING Working Group S. Peng
Internet-Draft Z. Li Internet-Draft Z. Li
Intended status: Informational Huawei Intended status: Informational Huawei Technologies
Expires: April 25, 2019 October 22, 2018 Expires: January 9, 2020 C. Xie
C. Li
China Telecom
July 8, 2019
SRv6 Compatibility with Legacy Devices SRv6 Compatibility with Legacy Devices
draft-peng-spring-srv6-compatibility-00 draft-peng-spring-srv6-compatibility-01
Abstract Abstract
When deploying SRv6 on legacy devices, there are some compatibility When deploying SRv6 on legacy devices, there are some compatibility
challenges such as the support of SRH processing. This document challenges such as the support of SRH processing.
identifies some of the major challenges, and provides solutions that
are able to mitigate those challenges and smooth the evolution This document identifies some of the major challenges, and provides
towards SRv6 deployment. solutions that are able to mitigate those challenges and smooth the
migration towards SRv6 deployment.
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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
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
skipping to change at page 1, line 40 skipping to change at page 1, line 44
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 April 25, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Compatibility challenges . . . . . . . . . . . . . . . . . . 3 2. Compatibility challenges . . . . . . . . . . . . . . . . . . 3
2.1. Fast Reroute (FRR) . . . . . . . . . . . . . . . . . . . 3 2.1. Fast Reroute (FRR) . . . . . . . . . . . . . . . . . . . 3
2.2. Traffic Engineering (TE) . . . . . . . . . . . . . . . . 3 2.2. Traffic Engineering (TE) . . . . . . . . . . . . . . . . 4
2.3. Service Function Chaining (SFC) . . . . . . . . . . . . . 4 2.3. Service Function Chaining (SFC) . . . . . . . . . . . . . 4
2.4. iOAM . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. IOAM . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Binding SID (BSID) . . . . . . . . . . . . . . . . . 5 3.1.1. Binding SID (BSID) . . . . . . . . . . . . . . . . . 6
3.1.2. PCEP FlowSpec . . . . . . . . . . . . . . . . . . . . 6 3.1.2. PCEP FlowSpec . . . . . . . . . . . . . . . . . . . . 6
3.2. SFC . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. SFC . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Stateless SFC . . . . . . . . . . . . . . . . . . . . 6 3.2.1. Stateless SFC . . . . . . . . . . . . . . . . . . . . 6
3.2.2. Stateful SFC . . . . . . . . . . . . . . . . . . . . 7 3.2.2. Stateful SFC . . . . . . . . . . . . . . . . . . . . 7
3.3. Light Weight iOAM . . . . . . . . . . . . . . . . . . . . 7 3.3. Light Weight IOAM . . . . . . . . . . . . . . . . . . . . 7
4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . 8 8. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
Segment Routing (SR) is a source routing paradigm, which allows a Segment Routing (SR) is a source routing paradigm, which allows a
headend node to steer the packets through an ordered list of headend node to steer the packets through an ordered list of
instructions, i.e. segments [RFC8402]. A segment can either be instructions, i.e. segments [RFC8402]. A segment can either be
topological or service based. SR over IPv6 (SRv6) topological or service based. SR over IPv6 (SRv6)
[I-D.filsfils-spring-srv6-network-programming] is the SR instantiated [I-D.filsfils-spring-srv6-network-programming] is the SR instantiated
on the IPv6 data plane with a new type of routing extension header, on the IPv6 data plane with a new type of routing extension header,
i.e. SR Header (SRH) [I-D.ietf-6man-segment-routing-header]. An SRv6 i.e. SR Header (SRH) [I-D.ietf-6man-segment-routing-header]. An SRv6
segment, also called SRv6 SID, is a 128-bit value, represented as segment, also called SRv6 SID, is a 128-bit value, represented as
LOC:FUNCT:ARGS (ARGS is optional), and encoded as an IPv6 address. LOC:FUNCT:ARGS (ARGS is optional), and encoded as an IPv6 address.
An ordered list of SRv6 SIDs forms an SR Policy, which can be used An ordered list of SRv6 SIDs forms an SR Policy, which can be used
for, for example, Traffic Engineering (TE), Service Function Chaining for, for example, Traffic Engineering (TE), Service Function Chaining
(SFC), and Operations, Administration, and Maintenance (OAM). (SFC), and In-situ Operations, Administration, and Maintenance
Meanwhile, it will also bring challenges on the legacy devices to (IOAM). Meanwhile, it will also bring challenges on the legacy
support SRv6 correspondingly. devices to support SRv6 correspondingly.
This document provides solutions that can mitigate the identified This document provides solutions that can mitigate the identified
compatibility challenges and ease the evolution towards SRv6 compatibility challenges and ease the evolution towards SRv6
deployment. deployment.
2. Compatibility challenges 2. Compatibility challenges
By adopting SR Policy, the states in the network can be greatly By adopting SR Policy, the states in the network can be greatly
reduced, which will relieve the devices and evolve into stateless reduced, which will relieve the devices and evolve into stateless
fabric ultimately. However, it will also bring compatibility fabric ultimately. However, it will also bring compatibility
challenges on the legacy devices correspondingly. In particular, the challenges on the legacy devices correspondingly. In particular, the
legacy devices need to upgrade in order to support the processing of legacy devices need to upgrade in order to support the processing of
SRH. Furthermore, as the segments in the segment list increase the SRH.
SR Policy incrementally expends, the encapsulation header overhead
Furthermore, as the segments in the segment list increase the SR
Policy incrementally expends, the encapsulation header overhead
increases, which will also impose high requirements on the increases, which will also impose high requirements on the
performance of hardware forwarding (i.e. the capability of chipset). performance of hardware forwarding (i.e. the capability of chipset).
This section identifies the imposed challenges in the following This section identifies the imposed challenges in the following
SPRING use cases. SPRING use cases.
2.1. Fast Reroute (FRR) 2.1. Fast Reroute (FRR)
FRR is deployed to cope with link or node failures by precomputing FRR is deployed to cope with link or node failures by precomputing
backup paths. By relying on SR, Topology Independent Loop-free backup paths. By relying on SR, Topology Independent Loop-free
Alternate Fast Re-route (TI-LFA) Alternate Fast Re-route (TI-LFA)
[I-D.bashandy-rtgwg-segment-routing-ti-lfa] provides a local repair [I-D.bashandy-rtgwg-segment-routing-ti-lfa] provides a local repair
skipping to change at page 3, line 48 skipping to change at page 4, line 12
convergence path to the destination. This action will increase the convergence path to the destination. This action will increase the
length of the segment list in the SRH as shown in Figure 1. length of the segment list in the SRH as shown in Figure 1.
2.2. Traffic Engineering (TE) 2.2. Traffic Engineering (TE)
TE enables operators to control specific traffic flows going through TE enables operators to control specific traffic flows going through
configured explicit paths. There are loose and strict options. With configured explicit paths. There are loose and strict options. With
the loose option, only a small number of hops along the paths are the loose option, only a small number of hops along the paths are
explicitly expressed, while the strict option specifies each explicitly expressed, while the strict option specifies each
individual hop in the explicit path, e.g. to encode a low-latency individual hop in the explicit path, e.g. to encode a low-latency
path from node A to node B. With SRv6, the strict source-routed path from node A to node B.
explicit paths will result in a long segment list in the SRH as shown
in Figure 1, which places high requirements on the devices. With SRv6, the strict source-routed explicit paths will result in a
long segment list in the SRH as shown in Figure 1, which places high
requirements on the devices.
2.3. Service Function Chaining (SFC) 2.3. Service Function Chaining (SFC)
The SR segments can also encode instructions, called service The SR segments can also encode instructions, called service
segments, for steering packets through services running on physical segments, for steering packets through services running on physical
service appliances or virtual network functions (VNF) running in a service appliances or virtual network functions (VNF) running in a
virtual enviornment [I-D.xuclad-spring-sr-service-programming]. virtual enviornment [I-D.xuclad-spring-sr-service-programming].
These service segments can also be integrated in an SR policy along These service segments can also be integrated in an SR policy along
with node and adjacency segments. This feature of SR will further with node and adjacency segments. This feature of SR will further
increase the length of the segment list in the SRH as shown in increase the length of the segment list in the SRH as shown in
Figure 1. Figure 1.
In terms of SR awareness, there are two types of services, i.e. SR- In terms of SR awareness, there are two types of services, i.e. SR-
aware and SR-unaware services, which both impose new requirements on aware and SR-unaware services, which both impose new requirements on
the hardware. The SR-aware service needs to be fully capable of the hardware. The SR-aware service needs to be fully capable of
processing SR traffic, while for the SR-unaware services, an SR proxy processing SR traffic, while for the SR-unaware services, an SR proxy
function needs to be defined. If the Network Service Header (NSH) function needs to be defined.
based SFC [RFC8300] has already been deployed in the network, the
compatibility with existing NSH is required.
2.4. iOAM If the Network Service Header (NSH) based SFC [RFC8300] has already
been deployed in the network, the compatibility with existing NSH is
required.
iOAM, i.e. "in-situ" Operations, Administration, and Maintenance 2.4. IOAM
IOAM, i.e. "in-situ" Operations, Administration, and Maintenance
(OAM), encodes telemetry and operational information within the data (OAM), encodes telemetry and operational information within the data
packets to complement other "out-of-band" OAM mechnisms, e.g. ICMP packets to complement other "out-of-band" OAM mechnisms, e.g. ICMP
and active probing. The iOAM data fields, i.e. a node data list, and active probing. The IOAM data fields, i.e. a node data list,
hold the information collected as the packets traversing the iOAM hold the information collected as the packets traversing the IOAM
domain [I-D.ietf-ippm-ioam-data], which is populated iteratively domain [I-D.ietf-ippm-ioam-data], which is populated iteratively
starting with the last entry of the list. starting with the last entry of the list.
The iOAM data can be embedded into a variety of transports. To The IOAM data can be embedded into a variety of transports. To
support the iOAM on the SRv6 data plane, the O-flag in the SRH is support the IOAM on the SRv6 data plane, the O-flag in the SRH is
defined [I-D.ali-spring-srv6-oam], which implements the "punt a defined [I-D.ali-spring-srv6-oam], which implements the "punt a
timestamped copy and forward" or "forward and punt a timestamped timestamped copy and forward" or "forward and punt a timestamped
copy" behavior. The iOAM data fields, i.e. the node data list, are copy" behavior. The IOAM data fields, i.e. the node data list, are
encapsulated in the iOAM TLV in SRH, which further increases the encapsulated in the IOAM TLV in SRH, which further increases the
length of the SRH as shown in Figure 1. length of the SRH as shown in Figure 1.
+-----------+ +-----------+
|IPv6 packet| |IPv6 packet|
+-----------+ +-----------+
/ / / /
+-----------+ / iOAM Info / +-----------+ / IOAM Info /
|IPv6 packet| / / |IPv6 packet| / /
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
|IPv6 packet| / / / / |IPv6 packet| / / / /
+-----------+ +-----------+ / / / / +-----------+ +-----------+ / / / /
|IPv6 packet| / / / SF Chain / / SF Chain / |IPv6 packet| / / / SF Chain / / SF Chain /
+-----------+ +-----------+ / TE Path / / / / / +-----------+ +-----------+ / TE Path / / / / /
|IPv6 packet| /TI-LFA Path/ / / / / / / |IPv6 packet| /TI-LFA Path/ / / / / / /
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
|SA,DA | |SA,DA | |SA,DA | |SA,DA | |SA,DA | |SA,DA | |SA,DA | |SA,DA | |SA,DA | |SA,DA |
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
SRv6 BE SRv6 BE+ SRv6 TE SRv6 SFC SRv6 SFC+ SRv6 BE SRv6 BE+ SRv6 TE SRv6 SFC SRv6 SFC+
TI-LFA iOAM TI-LFA IOAM
Figure 1. Evolution of SRv6 SRH Figure 1. Evolution of SRv6 SRH
The compatibility challenges on the legacy devices are summarised as The compatibility challenges on the legacy devices are summarised as
follows, follows,
o The legacy devices need to upgrade in order to support the o The legacy devices need to upgrade in order to support the
processing of SRH processing of SRH
o As the SRH expands, the overhead increases and correspondingly the o As the SRH expands, the overhead increases and correspondingly the
skipping to change at page 6, line 5 skipping to change at page 6, line 11
With the strict traffic engineering, the resulted long SID list in With the strict traffic engineering, the resulted long SID list in
the SRH raises high requirements on the hardware chipset, which can the SRH raises high requirements on the hardware chipset, which can
be mitigated by the following solutions. be mitigated by the following solutions.
3.1.1. Binding SID (BSID) 3.1.1. Binding SID (BSID)
Binding SID involves a list of SIDs, and is bound to an SR Policy. Binding SID involves a list of SIDs, and is bound to an SR Policy.
The node(s) that imposes the bound policy needs to store the SID The node(s) that imposes the bound policy needs to store the SID
list. When a node receives a packet with its active segment as a list. When a node receives a packet with its active segment as a
BSID, the node will steer the packet onto the bound policy BSID, the node will steer the packet onto the bound policy
accordingly. To reduce the long SID list of a strict TE explicit accordingly.
path, BSID can be used at the selected nodes, maybe according to the
processing capacity of the hardware chipset. BSID can also be used To reduce the long SID list of a strict TE explicit path, BSID can be
to impose the repair list in the TI-LFA as described in Section 2.1. used at the selected nodes, maybe according to the processing
capacity of the hardware chipset. BSID can also be used to impose
the repair list in the TI-LFA as described in Section 2.1.
3.1.2. PCEP FlowSpec 3.1.2. PCEP FlowSpec
When the SR architecture adopts a centralized model, the SDN When the SR architecture adopts a centralized model, the SDN
controller (e.g. Path Computation Element (PCE)) only needs to apply controller (e.g. Path Computation Element (PCE)) only needs to apply
the SR policy at the head-end. There is no state maintained at the SR policy at the head-end. There is no state maintained at
midpoints and tail-ends. Eliminating states in the network midpoints and tail-ends. Eliminating states in the network
(midpoints and tail-points) is a key benefit of utilizing SR. (midpoints and tail-points) is a key benefit of utilizing SR.
However, it also leads to a long SID list for expressing a strict TE However, it also leads to a long SID list for expressing a strict TE
path. path.
skipping to change at page 7, line 34 skipping to change at page 7, line 41
needs to be forwarded to an SF, the SFF performs a lookup based on needs to be forwarded to an SF, the SFF performs a lookup based on
the service SID associated with the SF to retrieve the next-hop the service SID associated with the SF to retrieve the next-hop
context (a MAC address) between the SFF and SF. Then the SFF strips context (a MAC address) between the SFF and SF. Then the SFF strips
the SRH and forwards the packet with NSH carrying metadata to the SF the SRH and forwards the packet with NSH carrying metadata to the SF
where the packet will be processed as specified in [RFC8300]. In where the packet will be processed as specified in [RFC8300]. In
this case, the SF is not required to be capable of the SR operation, this case, the SF is not required to be capable of the SR operation,
neither is the SR proxy. Meanwhile, the stripped SRH will be updated neither is the SR proxy. Meanwhile, the stripped SRH will be updated
and stored in a cache in the SFF, indexed by the NSH SPI for the and stored in a cache in the SFF, indexed by the NSH SPI for the
forwarding of the packet coming back from the SF. forwarding of the packet coming back from the SF.
3.3. Light Weight iOAM 3.3. Light Weight IOAM
In most cases, after the IPv6 Destination Address (DA) is updated In most cases, after the IPv6 Destination Address (DA) is updated
according to the active segment in the SRH, the SID in the SRH will according to the active segment in the SRH, the SID in the SRH will
not be used again. However, the entire SID list in the SRH will not be used again. However, the entire SID list in the SRH will
still be carried in the packet along the path till a PSP/USP is still be carried in the packet along the path till a PSP/USP is
enforced. enforced.
The light weight iOAM method [I-D.li-spring-passive-pm-for-srv6-np] The light weight IOAM method [I-D.li-spring-passive-pm-for-srv6-np]
makes use of the used segments in the SRH to carry the iOAM makes use of the used segments in the SRH to carry the IOAM
information, which saves the extra space in the SRH and mitigate the information, which saves the extra space in the SRH and mitigate the
requirements on the hardware. requirements on the hardware.
4. Summary 4. Summary
The SRH enables a great number of features for SRv6 and opens new The SRH enables a great number of features for SRv6 and opens new
network programming possilities. By using SRH, it relieves the network programming possibilities. By using SRH, it relieves the
network devices from states, evolving towards stateless fabric, while network devices from states, evolving towards stateless fabric, while
the complexity in the control plane increases. The corresponding the complexity in the control plane increases. The corresponding
challenges imposed on the hardware chipset become high as the SRH challenges imposed on the hardware chipset become high as the SRH
expands when supporting the diverse use cases. The trade-off expands when supporting the diverse use cases. The trade-off
solutions presented in this document are able to mitigate these solutions presented in this document are able to mitigate these
challenges and smooth the evolution in operators' networks. challenges and smooth the evolution in operators' networks.
5. IANA Considerations 5. IANA Considerations
This document makes no request of IANA. There are no IANA considerations in this document.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
6. Security Considerations 6. Security Considerations
TBD TBD
7. Acknowledgements 7. Acknowledgements
skipping to change at page 8, line 34 skipping to change at page 8, line 42
8. Normative References 8. Normative References
[I-D.ali-spring-srv6-oam] [I-D.ali-spring-srv6-oam]
Ali, Z., Filsfils, C., Kumar, N., Pignataro, C., Ali, Z., Filsfils, C., Kumar, N., Pignataro, C.,
faiqbal@cisco.com, f., Gandhi, R., Leddy, J., Matsushima, faiqbal@cisco.com, f., Gandhi, R., Leddy, J., Matsushima,
S., Raszuk, R., daniel.voyer@bell.ca, d., Dawra, G., S., Raszuk, R., daniel.voyer@bell.ca, d., Dawra, G.,
Peirens, B., Chen, M., and G. Naik, "Operations, Peirens, B., Chen, M., and G. Naik, "Operations,
Administration, and Maintenance (OAM) in Segment Routing Administration, and Maintenance (OAM) in Segment Routing
Networks with IPv6 Data plane (SRv6)", draft-ali-spring- Networks with IPv6 Data plane (SRv6)", draft-ali-spring-
srv6-oam-01 (work in progress), July 2018. srv6-oam-02 (work in progress), October 2018.
[I-D.bashandy-rtgwg-segment-routing-ti-lfa] [I-D.bashandy-rtgwg-segment-routing-ti-lfa]
Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S.,
Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P.
Camarillo, "Topology Independent Fast Reroute using Camarillo, "Topology Independent Fast Reroute using
Segment Routing", draft-bashandy-rtgwg-segment-routing-ti- Segment Routing", draft-bashandy-rtgwg-segment-routing-ti-
lfa-05 (work in progress), October 2018. lfa-05 (work in progress), October 2018.
[I-D.filsfils-spring-srv6-network-programming] [I-D.filsfils-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-filsfils-spring-srv6-network-
programming-05 (work in progress), July 2018. programming-07 (work in progress), February 2019.
[I-D.guichard-spring-nsh-sr] [I-D.guichard-spring-nsh-sr]
Guichard, J., Song, H., Tantsura, J., Halpern, J., Guichard, J., Song, H., Tantsura, J., Halpern, J.,
Henderickx, W., and M. Boucadair, "NSH and Segment Routing Henderickx, W., Boucadair, M., and S. Hassan, "NSH and
Integration for Service Function Chaining (SFC)", draft- Segment Routing Integration for Service Function Chaining
guichard-spring-nsh-sr-00 (work in progress), September (SFC)", draft-guichard-spring-nsh-sr-01 (work in
2018. progress), March 2019.
[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-14 (work in Routing Header (SRH)", draft-ietf-6man-segment-routing-
progress), June 2018. header-21 (work in progress), June 2019.
[I-D.ietf-ippm-ioam-data] [I-D.ietf-ippm-ioam-data]
Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon,
"Data Fields for In-situ OAM", draft-ietf-ippm-ioam- "Data Fields for In-situ OAM", draft-ietf-ippm-ioam-
data-03 (work in progress), June 2018. data-06 (work in progress), July 2019.
[I-D.ietf-pce-pcep-flowspec] [I-D.ietf-pce-pcep-flowspec]
Dhody, D., Farrel, A., and Z. Li, "PCEP Extension for Flow Dhody, D., Farrel, A., and Z. Li, "PCEP Extension for Flow
Specification", draft-ietf-pce-pcep-flowspec-02 (work in Specification", draft-ietf-pce-pcep-flowspec-03 (work in
progress), October 2018. progress), February 2019.
[I-D.li-spring-passive-pm-for-srv6-np] [I-D.li-spring-passive-pm-for-srv6-np]
Li, C. and M. Chen, "Passive Performance Measurement for Li, C. and M. Chen, "Passive Performance Measurement for
SRv6 Network Programming", draft-li-spring-passive-pm-for- SRv6 Network Programming", draft-li-spring-passive-pm-for-
srv6-np-00 (work in progress), March 2018. srv6-np-00 (work in progress), March 2018.
[I-D.xuclad-spring-sr-service-programming] [I-D.xuclad-spring-sr-service-programming]
Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., d., Li, C., Decraene, B., Ma, S., Yadlapalli, C.,
Henderickx, W., and S. Salsano, "Service Programming with Henderickx, W., and S. Salsano, "Service Programming with
Segment Routing", draft-xuclad-spring-sr-service- Segment Routing", draft-xuclad-spring-sr-service-
programming-00 (work in progress), July 2018. programming-02 (work in progress), April 2019.
[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>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300, "Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018, DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>. <https://www.rfc-editor.org/info/rfc8300>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
Authors' Addresses Authors' Addresses
Shuping Peng Shuping Peng
Huawei Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: pengshuping@huawei.com Email: pengshuping@huawei.com
Zhenbin Li Zhenbin Li
Huawei Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com Email: lizhenbin@huawei.com
Chongfeng Xie
China Telecom
China Telecom Information Science&Technology Innovation park, Beiqijia Town,Changping District
Beijing 102209
China
Phone: +86-10-50902116
Email: xiechf.bri@chinatelecom.cn
Cong Li
China Telecom
China Telecom Information Science&Technology Innovation park, Beiqijia Town,Changping District
Beijing 102209
China
Phone: +86-10-50902556
Email: licong.bri@chinatelecom.cn
 End of changes. 36 change blocks. 
61 lines changed or deleted 79 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/