draft-ietf-spring-sr-service-programming-00.txt   draft-ietf-spring-sr-service-programming-01.txt 
SPRING F. Clad, Ed. SPRING F. Clad, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track X. Xu, Ed. Intended status: Standards Track X. Xu, Ed.
Expires: April 16, 2020 Alibaba Expires: May 7, 2020 Alibaba
C. Filsfils C. Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
D. Bernier D. Bernier
Bell Canada Bell Canada
C. Li C. Li
Huawei Huawei
B. Decraene B. Decraene
Orange Orange
S. Ma S. Ma
Juniper Mellanox
C. Yadlapalli C. Yadlapalli
AT&T AT&T
W. Henderickx W. Henderickx
Nokia Nokia
S. Salsano S. Salsano
Universita di Roma "Tor Vergata" Universita di Roma "Tor Vergata"
October 14, 2019 November 04, 2019
Service Programming with Segment Routing Service Programming with Segment Routing
draft-ietf-spring-sr-service-programming-00 draft-ietf-spring-sr-service-programming-01
Abstract Abstract
This document defines data plane functionality required to implement This document defines data plane functionality required to implement
service segments and achieve service programming in SR-enabled MPLS service segments and achieve service programming in SR-enabled MPLS
and IP networks, as described in the Segment Routing architecture. and IPv6 networks, as described in the Segment Routing architecture.
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 April 16, 2020. This Internet-Draft will expire on May 7, 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 3, line 9 skipping to change at page 3, line 9
8. Implementation status . . . . . . . . . . . . . . . . . . . . 25 8. Implementation status . . . . . . . . . . . . . . . . . . . . 25
8.1. SR-aware services . . . . . . . . . . . . . . . . . . . . 26 8.1. SR-aware services . . . . . . . . . . . . . . . . . . . . 26
8.2. Proxy behaviors . . . . . . . . . . . . . . . . . . . . . 26 8.2. Proxy behaviors . . . . . . . . . . . . . . . . . . . . . 26
9. Related works . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Related works . . . . . . . . . . . . . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10.1. SRv6 Endpoint Behaviors . . . . . . . . . . . . . . . . 27 10.1. SRv6 Endpoint Behaviors . . . . . . . . . . . . . . . . 27
10.2. Segment Routing Header TLVs . . . . . . . . . . . . . . 27 10.2. Segment Routing Header TLVs . . . . . . . . . . . . . . 27
11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
14.1. Normative References . . . . . . . . . . . . . . . . . . 28 14.1. Normative References . . . . . . . . . . . . . . . . . . 29
14.2. Informative References . . . . . . . . . . . . . . . . . 29 14.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
Segment Routing (SR) is an architecture based on the source routing Segment Routing (SR) is an architecture based on the source routing
paradigm that seeks the right balance between distributed paradigm that seeks the right balance between distributed
intelligence and centralized programmability. SR can be used with an intelligence and centralized programmability. SR can be used with an
MPLS or an IPv6 data plane to steer packets through an ordered list MPLS or an IPv6 data plane to steer packets through an ordered list
of instructions, called segments. These segments may encode simple of instructions, called segments. These segments may encode simple
routing instructions for forwarding packets along a specific network routing instructions for forwarding packets along a specific network
path, but also steer them through VNFs or physical service appliances path, but also steer them through Virtual Network Functions (VNFs) or
available in the network. physical service appliances available in the network.
In an SR network, each of these services, running either on a In an SR network, each of these services, running either on a
physical appliance or in a virtual environment, are associated with a physical appliance or in a virtual environment, are associated with a
segment identifier (SID). These service SIDs are then leveraged as segment identifier (SID). These service SIDs are then leveraged as
part of a SID-list to steer packets through the corresponding part of a SID-list to steer packets through the corresponding
services. Service SIDs may be combined together in a SID-list to services. Service SIDs may be combined together in a SID-list to
achieve service programming, but also with other types of segments as achieve service programming, but also with other types of segments as
defined in [RFC8402]. SR thus provides a fully integrated solution defined in [RFC8402]. SR thus provides a fully integrated solution
for overlay, underlay and service programming. Furthermore, the IPv6 for overlay, underlay and service programming. Furthermore, the IPv6
instantiation of SR (SRv6) supports metadata transportation in the instantiation of SR (SRv6) supports metadata transportation in the
skipping to change at page 5, line 9 skipping to change at page 5, line 9
SR traffic can be re-classified by an SR endpoint along the original SR traffic can be re-classified by an SR endpoint along the original
SR policy (e.g., DPI service) or a transit node intercepting the SR policy (e.g., DPI service) or a transit node intercepting the
traffic. This node is the head-end of a new SR policy that is traffic. This node is the head-end of a new SR policy that is
imposed onto the packet, either as a stack of MPLS labels or as an imposed onto the packet, either as a stack of MPLS labels or as an
IPv6 SRH. IPv6 SRH.
4. Service segments 4. Service segments
In the context of this document, the term service refers to a In the context of this document, the term service refers to a
physical appliance running on dedicated hardware, a virtualized physical appliance running on dedicated hardware, a virtualized
service inside an isolated environment such as a VM, container or service inside an isolated environment such as a Virtual Machine
namespace, or any process running on a compute element. A service (VM), container or namespace, or any process running on a compute
may also comprise multiple sub-components running in different element. A service may also comprise multiple sub-components running
processes or containers. Unless otherwise stated, this document does in different processes or containers. Unless otherwise stated, this
not make any assumption on the type or execution environment of a document does not make any assumption on the type or execution
service. environment of a service.
The execution of a service can be integrated as part of an SR policy The execution of a service can be integrated as part of an SR policy
by assigning a segment identifier, or SID, to the service and by assigning a segment identifier, or SID, to the service and
including this service SID in the SR policy SID-list. Such a service including this service SID in the SR policy SID-list. Such a service
SID may be of local or global significance. In the former case, SID may be of local or global significance. In the former case,
other segments, such as prefix or adjacency segments, can be used to other segments, such as prefix or adjacency segments, can be used to
steer the traffic up to the node where the service segment is steer the traffic up to the node where the service segment is
instantiated. In the latter case, the service is directly reachable instantiated. In the latter case, the service is directly reachable
from anywhere in the routing domain. This is realized with SR-MPLS from anywhere in the routing domain. This is realized with SR-MPLS
by assigning a SID from the global label block by assigning a SID from the global label block
skipping to change at page 14, line 39 skipping to change at page 14, line 39
* CACHE.SA: IPv6 source address (SRv6 only) * CACHE.SA: IPv6 source address (SRv6 only)
* CACHE.LIST: Segment list expressed as MPLS labels or IPv6 * CACHE.LIST: Segment list expressed as MPLS labels or IPv6
address address
A static SR proxy segment is thus defined for a specific service, A static SR proxy segment is thus defined for a specific service,
inner packet type and cached SR information. It is also bound to a inner packet type and cached SR information. It is also bound to a
pair of directed interfaces on the proxy. These may be both pair of directed interfaces on the proxy. These may be both
directions of a single interface, or opposite directions of two directions of a single interface, or opposite directions of two
different interfaces. The latter is recommended in case the service different interfaces. The latter is recommended in case the service
is to be used as part of a bi-directional SR SC policy. If the proxy is to be used as part of a bi-directional SR service policy. If the
and the service both support 802.1Q, IFACE-OUT and IFACE-IN can also proxy and the service both support 802.1Q, IFACE-OUT and IFACE-IN can
represent sub-interfaces. also represent sub-interfaces.
The first part of this behavior is triggered when the proxy node The first part of this behavior is triggered when the proxy node
receives a packet whose active segment matches a segment associated receives a packet whose active segment matches a segment associated
with the static proxy behavior. It removes the SR information from with the static proxy behavior. It removes the SR information from
the packet then sends it on a specific interface towards the the packet then sends it on a specific interface towards the
associated service. This SR information corresponds to the full associated service. This SR information corresponds to the full
label stack for SR-MPLS or to the encapsulation IPv6 header with any label stack for SR-MPLS or to the encapsulation IPv6 header with any
attached extension header in the case of SRv6. attached extension header in the case of SRv6.
The second part is an inbound policy attached to the proxy interface The second part is an inbound policy attached to the proxy interface
skipping to change at page 15, line 27 skipping to change at page 15, line 27
MPLS or IPv6 encapsulation. MPLS or IPv6 encapsulation.
In this scenario, there are no restrictions on the operations that In this scenario, there are no restrictions on the operations that
can be performed by the service on the stream of packets. It may can be performed by the service on the stream of packets. It may
operate at all protocol layers, terminate transport layer operate at all protocol layers, terminate transport layer
connections, generate new packets and initiate transport layer connections, generate new packets and initiate transport layer
connections. This behavior may also be used to integrate an connections. This behavior may also be used to integrate an
IPv4-only service into an SRv6 policy. However, a static SR proxy IPv4-only service into an SRv6 policy. However, a static SR proxy
segment can be used in only one service policy at a time. As opposed segment can be used in only one service policy at a time. As opposed
to most other segment types, a static SR proxy segment is bound to a to most other segment types, a static SR proxy segment is bound to a
unique list of segments, which represents a directed SR SC policy. unique list of segments, which represents a directed SR service
This is due to the cached SR information being defined in the segment policy. This is due to the cached SR information being defined in
configuration. This limitation only prevents multiple segment lists the segment configuration. This limitation only prevents multiple
from using the same static SR proxy segment at the same time, but a segment lists from using the same static SR proxy segment at the same
single segment list can be shared by any number of traffic flows. time, but a single segment list can be shared by any number of
Besides, since the returning traffic from the service is re- traffic flows. Besides, since the returning traffic from the service
classified based on the incoming interface, an interface can be used is re-classified based on the incoming interface, an interface can be
as receiving interface (IFACE-IN) only for a single SR proxy segment used as receiving interface (IFACE-IN) only for a single SR proxy
at a time. In the case of a bi-directional SR SC policy, a different segment at a time. In the case of a bi-directional SR service
SR proxy segment and receiving interface are required for the return policy, a different SR proxy segment and receiving interface are
direction. required for the return direction.
The static proxy behavior may also be used for sending traffic The static proxy behavior may also be used for sending traffic
through "bump in the wire" services that are transparent to the IP through "bump in the wire" services that are transparent to the IP
and Ethernet layers. This type of processing is assumed when the and Ethernet layers. This type of processing is assumed when the
inner traffic type is Ethernet, since the original destination inner traffic type is Ethernet, since the original destination
address of the Ethernet frame is preserved when the packet is steered address of the Ethernet frame is preserved when the packet is steered
into the SR Policy and likely associated with a node downstream of into the SR Policy and likely associated with a node downstream of
the policy tail-end. In case the inner type is IP (IPv4 or IPv6), the policy tail-end. In case the inner type is IP (IPv4 or IPv6),
the NH-ADDR parameter may be set to a dummy or broadcast Ethernet the NH-ADDR parameter may be set to a dummy or broadcast Ethernet
address, or simply to the address of the proxy receiving interface address, or simply to the address of the proxy receiving interface
skipping to change at page 19, line 39 skipping to change at page 19, line 39
Upon receiving a packet whose active segment matches a dynamic SR Upon receiving a packet whose active segment matches a dynamic SR
proxy function, the proxy node pops the top MPLS label or applies the proxy function, the proxy node pops the top MPLS label or applies the
SRv6 End behavior, then compares the updated SR information with the SRv6 End behavior, then compares the updated SR information with the
cache entry for the current segment. If the cache is empty or cache entry for the current segment. If the cache is empty or
different, it is updated with the new SR information. The SR different, it is updated with the new SR information. The SR
information is then removed and the inner packet is sent towards the information is then removed and the inner packet is sent towards the
service. service.
The cache entry is not mapped to any particular packet, but instead The cache entry is not mapped to any particular packet, but instead
to an SR SC policy identified by the receiving interface (IFACE-IN). to an SR service policy identified by the receiving interface (IFACE-
Any non-link-local IP packet or non-local Ethernet frame received on IN). Any non-link-local IP packet or non-local Ethernet frame
that interface will be re-encapsulated with the cached headers as received on that interface will be re-encapsulated with the cached
described in Section 6.1. The service may thus drop, modify or headers as described in Section 6.1. The service may thus drop,
generate new packets without affecting the proxy. modify or generate new packets without affecting the proxy.
6.2.1. SR-MPLS pseudocode 6.2.1. SR-MPLS pseudocode
The dynamic proxy SR-MPLS pseudocode is obtained by inserting the The dynamic proxy SR-MPLS pseudocode is obtained by inserting the
following instructions at the beginning of the static SR-MPLS following instructions at the beginning of the static SR-MPLS
pseudocode (Section 6.1.1). pseudocode (Section 6.1.1).
1. IF top label S bit is 0 THEN ;; Ref1 1. IF top label S bit is 0 THEN ;; Ref1
2. Pop top label 2. Pop top label
3. IF C(IFACE-IN) different from remaining labels THEN ;; Ref2 3. IF C(IFACE-IN) different from remaining labels THEN ;; Ref2
skipping to change at page 21, line 47 skipping to change at page 21, line 47
o IFACE-OUT: Local interface for sending traffic towards the service o IFACE-OUT: Local interface for sending traffic towards the service
o IFACE-IN: Local interface receiving the traffic coming back from o IFACE-IN: Local interface receiving the traffic coming back from
the service the service
A masquerading SR proxy segment is thus defined for a specific A masquerading SR proxy segment is thus defined for a specific
service and bound to a pair of directed interfaces or sub-interfaces service and bound to a pair of directed interfaces or sub-interfaces
on the proxy. As opposed to the static and dynamic SR proxies, a on the proxy. As opposed to the static and dynamic SR proxies, a
masquerading segment can be present at the same time in any number of masquerading segment can be present at the same time in any number of
SR SC policies and the same interfaces can be bound to multiple SR service policies and the same interfaces can be bound to multiple
masquerading proxy segments. The only restriction is that a masquerading proxy segments. The only restriction is that a
masquerading proxy segment cannot be the last segment in an SR SC masquerading proxy segment cannot be the last segment in an SR
policy. service policy.
The first part of the masquerading behavior is triggered when the The first part of the masquerading behavior is triggered when the
proxy node receives an IPv6 packet whose Destination Address matches proxy node receives an IPv6 packet whose Destination Address matches
a masquerading proxy segment. The proxy inspects the IPv6 extension a masquerading proxy segment. The proxy inspects the IPv6 extension
headers and substitutes the Destination Address with the last segment headers and substitutes the Destination Address with the last segment
in the SRH attached to the IPv6 header, which represents the final in the SRH attached to the IPv6 header, which represents the final
destination of the IPv6 packet. The packet is then sent out towards destination of the IPv6 packet. The packet is then sent out towards
the service. the service.
The service receives an IPv6 packet whose source and destination The service receives an IPv6 packet whose source and destination
skipping to change at page 24, line 16 skipping to change at page 24, line 16
7.2. IPv6 data plane 7.2. IPv6 data plane
7.2.1. SRH TLV objects 7.2.1. SRH TLV objects
The IPv6 SRH TLV objects are designed to carry all sorts of metadata. The IPv6 SRH TLV objects are designed to carry all sorts of metadata.
In particular, the NSH carrier TLV is defined as a container for NSH In particular, the NSH carrier TLV is defined as a container for NSH
metadata. metadata.
TLV objects can be imposed by the ingress edge router that steers the TLV objects can be imposed by the ingress edge router that steers the
traffic into the SR SC policy. traffic into the SR service policy.
An SR-aware service may impose, modify or remove any TLV object An SR-aware service may impose, modify or remove any TLV object
attached to the first SRH, either by directly modifying the packet attached to the first SRH, either by directly modifying the packet
headers or via a control channel between the service and its headers or via a control channel between the service and its
forwarding plane. forwarding plane.
An SR-aware service that re-classifies the traffic and steers it into An SR-aware service that re-classifies the traffic and steers it into
a new SR SC policy (e.g. DPI) may attach any TLV object to the new a new SR service policy (e.g. DPI) may attach any TLV object to the
SRH. new SRH.
Metadata imposition and handling will be further discussed in a Metadata imposition and handling will be further discussed in a
future version of this document. future version of this document.
7.2.1.1. Opaque Metadata TLV 7.2.1.1. Opaque Metadata TLV
This document defines an SRv6 TLV called Opaque Metadata TLV. This This document defines an SRv6 TLV called Opaque Metadata TLV. This
is a fixed-length container to carry any type of Service Metadata. is a fixed-length container to carry any type of Service Metadata.
No assumption is made by this document on the structure or the No assumption is made by this document on the structure or the
content of the carried metadata. The Opaque Metadata TLV has the content of the carried metadata. The Opaque Metadata TLV has the
skipping to change at page 26, line 10 skipping to change at page 26, line 10
8. Implementation status 8. Implementation status
This section is to be removed prior to publishing as an RFC. This section is to be removed prior to publishing as an RFC.
8.1. SR-aware services 8.1. SR-aware services
Specific SRv6 support has been implemented for the below open-source Specific SRv6 support has been implemented for the below open-source
services: services:
o Iptables (1.6.2 and later) o Iptables (1.6.2 and later) [IPTABLES]
o Nftables (0.8.4 and later) o Nftables (0.8.4 and later) [NFTABLES]
o Snort o Snort [SNORT]
In addition, any service relying on the Linux kernel, version 4.10 In addition, any service relying on the Linux kernel, version 4.10
and later, or FD.io VPP for packet forwarding can be considered as and later, or FD.io VPP for packet forwarding can be considered as
SR-aware. SR-aware.
8.2. Proxy behaviors 8.2. Proxy behaviors
The static SR proxy is available for SR-MPLS and SRv6 on various The static SR proxy is available for SR-MPLS and SRv6 on various
Cisco hardware and software platforms. Furthermore, the following Cisco hardware and software platforms. Furthermore, the following
proxies are available on open-source software. proxies are available on open-source software.
skipping to change at page 28, line 9 skipping to change at page 28, line 9
12. Acknowledgements 12. Acknowledgements
The authors would like to thank Thierry Couture, Ketan Talaulikar, The authors would like to thank Thierry Couture, Ketan Talaulikar,
Loa Andersson, Andrew G. Malis, Adrian Farrel, Alexander Vainshtein Loa Andersson, Andrew G. Malis, Adrian Farrel, Alexander Vainshtein
and Joel M. Halpern for their valuable comments and suggestions on and Joel M. Halpern for their valuable comments and suggestions on
the document. the document.
13. Contributors 13. Contributors
P. Camarillo (Cisco), B. Peirens (Proximus), D. Steinberg The following people have contributed to this document:
(Steinberg Consulting), A. AbdelSalam (Gran Sasso Science
Institute), G. Dawra (LinkedIn), S. Bryant (Huawei), H. Assarpour Pablo Camarillo
(Broadcom), H. Shah (Ciena), L. Contreras (Telefonica I+D), J. Cisco Systems, Inc.
Tantsura (Individual), M. Vigoureux (Nokia) and J. Bhattacharya Spain
(Cisco) substantially contributed to the content of this document.
Email: pcamaril@cisco.com
Bart Peirens
Proximus
Belgium
Email: bart.peirens@proximus.com
Dirk Steinberg
Lapishills Consulting Limited
Cyprus
Email: dirk@lapishills.com
Ahmed AbdelSalam
Cisco Systems, Inc.
Italy
Email: ahabdels@cisco.com
Gaurav Dawra
LinkedIn
United States of America
Email: gdawra@linkedin.com
Stewart Bryant
Futurewei Technologies Inc
Email: stewart.bryant@gmail.com
Hamid Assarpour
Broadcom
Email: hamid.assarpour@broadcom.com
Himanshu Shah
Ciena
Email: hshah@ciena.com
Luis M. Contreras
Telefonica I+D
Spain
Email: luismiguel.contrerasmurillo@telefonica.com
Jeff Tantsura
Individual
Email: jefftant@gmail.com
Martin Vigoureux
Nokia
Email: martin.vigoureux@nokia.com
Jisu Bhattacharya
Cisco Systems, Inc.
United States of America
Email: jisu@cisco.com
14. References 14. References
14.1. Normative References 14.1. Normative References
[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-07 (work in progress), February 2019. programming-07 (work in progress), February 2019.
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Filsfils, C., Dukes, D., Previdi, S., Leddy, J., Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment
Routing Header (SRH)", draft-ietf-6man-segment-routing- Routing Header (SRH)", draft-ietf-6man-segment-routing-
header-24 (work in progress), October 2019. header-26 (work in progress), October 2019.
[I-D.ietf-spring-segment-routing-mpls] [I-D.ietf-spring-segment-routing-mpls]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-22 data plane", draft-ietf-spring-segment-routing-mpls-22
(work in progress), May 2019. (work in progress), May 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
skipping to change at page 29, line 36 skipping to change at page 31, line 10
[I-D.xu-mpls-payload-protocol-identifier] [I-D.xu-mpls-payload-protocol-identifier]
Xu, X., Assarpour, H., Ma, S., and F. Clad, "MPLS Payload Xu, X., Assarpour, H., Ma, S., and F. Clad, "MPLS Payload
Protocol Identifier", draft-xu-mpls-payload-protocol- Protocol Identifier", draft-xu-mpls-payload-protocol-
identifier-06 (work in progress), March 2019. identifier-06 (work in progress), March 2019.
[IFIP18] Abdelsalam, A., Salsano, S., Clad, F., Camarillo, P., and [IFIP18] Abdelsalam, A., Salsano, S., Clad, F., Camarillo, P., and
C. Filsfils, "SEgment Routing Aware Firewall For Service C. Filsfils, "SEgment Routing Aware Firewall For Service
Function Chaining scenarios", IFIP Networking conference , Function Chaining scenarios", IFIP Networking conference ,
May 2018. May 2018.
[IPTABLES]
"iptables-1.6.2 changes", February 2018,
<https://netfilter.org/projects/iptables/files/changes-
iptables-1.6.2.txt>.
[NFTABLES]
"nftables-0.8.4 changes", May 2018,
<https://netfilter.org/projects/nftables/files/changes-
nftables-0.8.4.txt>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015, DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>. <https://www.rfc-editor.org/info/rfc7665>.
[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>.
[SNORT] "SR-Snort", March 2018,
<https://github.com/SRouting/SR-Snort>.
Authors' Addresses Authors' Addresses
Francois Clad (editor) Francois Clad (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
France France
Email: fclad@cisco.com Email: fclad@cisco.com
Xiaohu Xu (editor) Xiaohu Xu (editor)
Alibaba Alibaba
Email: xiaohu.xxh@alibaba-inc.com Email: xiaohu.xxh@alibaba-inc.com
Clarence Filsfils Clarence Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
Belgium Belgium
Email: cf@cisco.com Email: cf@cisco.com
skipping to change at page 30, line 33 skipping to change at page 32, line 22
Email: chengli13@huawei.com Email: chengli13@huawei.com
Bruno Decraene Bruno Decraene
Orange Orange
France France
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
Shaowen Ma Shaowen Ma
Juniper Mellanox
Email: mashaowen@gmail.com Email: mashaowen@gmail.com
Chaitanya Yadlapalli Chaitanya Yadlapalli
AT&T AT&T
USA USA
Email: cy098d@att.com Email: cy098d@att.com
Wim Henderickx Wim Henderickx
Nokia Nokia
Belgium Belgium
Email: wim.henderickx@nokia.com Email: wim.henderickx@nokia.com
Stefano Salsano Stefano Salsano
Universita di Roma "Tor Vergata" Universita di Roma "Tor Vergata"
Italy Italy
 End of changes. 26 change blocks. 
54 lines changed or deleted 130 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/