spring Z. Ali
Internet-Draft C. Filsfils
Intended status: Standards Track N. Nainar
Expires: October 26, 2019 C. Pignataro
F. Clad
F. Iqbal
Cisco Systems, Inc.
X. Xu
Alibaba
April 24, 2019
OAM for Service Programming with Segment Routing
draft-ali-spring-sr-service-programming-oam-01
Abstract
This document defines the Operations, Administrations and Maintenance
(OAM) for service programming in SR-enabled MPLS and IP networks.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 26, 2019.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Ali, et al. Expires October 26, 2019 [Page 1]
Internet-Draft SR-SP OAM April 2019
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 2
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 3
5. Programmable OAM . . . . . . . . . . . . . . . . . . . . . . 3
5.1. Service Programming OAM Packet Marker . . . . . . . . . . 3
5.2. OAM with SR-aware services . . . . . . . . . . . . . . . 3
5.3. OAM with SR-unaware services . . . . . . . . . . . . . . 4
5.4. Controlling OAM packet processing in Services . . . . . . 4
6. OAM for Service Programming with SRv6 . . . . . . . . . . . . 4
6.1. OAM Tool Kit . . . . . . . . . . . . . . . . . . . . . . 5
6.1.1. OAM Flag Processing . . . . . . . . . . . . . . . . . 5
6.1.2. OAM Segment ID . . . . . . . . . . . . . . . . . . . 5
6.1.3. ICMP . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1.4. UDP Probes . . . . . . . . . . . . . . . . . . . . . 6
6.1.5. In-band OAM . . . . . . . . . . . . . . . . . . . . . 6
7. OAM for Service Programming with SR-MPLS . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7
11. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
[I-D.xuclad-spring-sr-service-programming] defines data plane
functionality required to implement service segments and achieve
service programming in SR-enabled MPLS and IP networks, as described
in the Segment Routing architecture. This document defines the
Operations, Administrations and Maintenance (OAM) for service
programming in SR-enabled MPLS and IP networks.
2. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Ali, et al. Expires October 26, 2019 [Page 2]
Internet-Draft SR-SP OAM April 2019
3. Terminology
This document uses the terminologies defined in
[I-D.ietf-spring-segment-routing],
[I-D.filsfils-spring-srv6-network-programming]
[I-D.xuclad-spring-sr-service-programming] and so the readers are
expected to be familiar with the same.
4. Document Scope
The initial focus of this document to define and document the
machinery required to apply OAM mechanisms on SRv6 based service
programming.
Future version of this document will include the required details to
apply OAM mechanism on other data planes.
5. Programmable OAM
Section 4 of [I-D.xuclad-spring-sr-service-programming] introduces
Service segments and the procedure of service programming when the
services are SR-aware and SR-unaware. By integrating the OAM
functionality in the services, versatile OAM tool kits can be used to
execute programmable OAM for service programming with Segment
Routing.
This section describes the procedure to perform basic OAM mechanisms
such as path validation and path tracing of Service Programming
environment in Segment Routing network.
5.1. Service Programming OAM Packet Marker
Any services upon receiving OAM packet may apply the service
treatment if it cannot differentiate the OAM packet from normal data
packet. Depending on the service type, service treatment on OAM
packet may result in dropping the OAM probe packet that may cause
uncertainty in OAM mechanism.
To avoid such uncertainty, any node that is originating the OAM probe
for Service Programming OAM MUST mark the packet as OAM packet so
that the services can differentiate the OAM packet from data traffic.
5.2. OAM with SR-aware services
As defined in section 4.1 of
[I-D.xuclad-spring-sr-service-programming], an SR-aware service can
process the SR information in the packet header such as performing
lookup or executing the next segment etc. An SR-aware service may
Ali, et al. Expires October 26, 2019 [Page 3]
Internet-Draft SR-SP OAM April 2019
need to identify the packet payload and/or interpret SR information
to apply the right policy to the received packet. While processing
SR information in the packet header, it can process the OAM packet
marker in the SR header to differentiate the OAM packet from normal
data packet.
An SR-aware service SHOULD skip applying the service on the OAM
packet while forwarding the packet to the next segment or IP address.
As defined in section 9, a local policy may be used to control any
malicious use of OAM marker.
5.3. OAM with SR-unaware services
As defined in section 4.2 of
[I-D.xuclad-spring-sr-service-programming], an SR-unaware service may
be a legacy service that is not able to process the SR information in
the packet header. SR Proxy, an entity that is external to the
service is used to handle the SR information processing on behalf of
the service. SR Proxy will remove the SR header before forwarding
the packet to SR-unaware services to avoid any erroneous decision due
to the presence of SR header that the service cannot recognize.
While processing SR information in the packet header, SR proxy can
process the OAM packet marker in the SR header to differentiate the
OAM packet from normal data packet. SR Proxy MUST skip forwarding
the packets with OAM marker to the service while forwarding the
packet to the next segment or IP address. As defined in section 9, a
local policy may be used to control any malicious use of OAM marker.
5.4. Controlling OAM packet processing in Services
As mentioned in the above sections, SR-aware service or the SR proxy
can use the OAM marker to differentiate the OAM packet from data
packet to skip the service treatment. Any intentional or
unintentional use of OAM marker in data traffic may result in
skipping service treatment for data traffic. To avoid such
condition, a local policy will be used in the SR-aware service or SR
Proxy that SHOULD rate limit or MAY drop the packets received with
OAM marker.
6. OAM for Service Programming with SRv6
[] defines SRH.Flags.O-bit in SRH
header. When service programming is implemented with SRv6 dataplane,
SRH.Flags.O-bit is used as OAM marker. An IPv6 packet received with
a local END.OP or END.OTP SID is also considered as an OAM packet.
Ali, et al. Expires October 26, 2019 [Page 4]
Internet-Draft SR-SP OAM April 2019
Any node that is originating OAM probe to a service in SRv6 dataplane
MUST set SRH.Flags.O-bit in the SRH.
6.1. OAM Tool Kit
This section describes the availability of different tool kits that
can be used to perform OAM functionality for Service Programming with
SRv6 dataplane.
6.1.1. OAM Flag Processing
An SR-aware service or SR proxy MUST implement the SRH.Flags.O bit.
An SR-aware service SHOULD skip applying the service to the packet
when SRH.Flags.O-bit is set and SHOULD forward the packet based on
the next header. SR Service Proxy MUST skip applying the service to
the packet when SRH.Flags.O-bit is set and SHOULD forward the packet
based on the next header.
An SR-aware service and SR proxy may choose to time-stamp and punt
the packet with SRH.Flags.O-bit set for further processing and this
is a local implementation matter.
6.1.2. OAM Segment ID
Section 3.2 of [[I-D.ali-spring-srv6-oam]] defines OAM segment ID and
the associated forwarding semantics to implement the punt behavior
for OAM packets. Specifically, the draft defines END.OP and END.OTP
SIDs. An IPv6 packet received with DA set to a local END.OP or
END.OTP SID is considered as an OAM packet.
Any service policy head end MAY include OAM segment ID in the desired
segment list position of SRH. The inclusion of OAM SID in SRH can be
used to control the services that are required to punt the OAM packet
for processing.
6.1.3. ICMP
There is no hardware or software changes required to use ICMP for
Ping operation. It can be triggered from the service policy head end
or from any classical IPv6 nodes by sending ICMPv6 Echo Request. The
existing ICMP Ping mechanism works seamlessly in SRv6 dataplane with
no protocol changes required to the standard ICMPv6 [[RFC4443]],
[[RFC4884]] or the standard ICMPv4 [[RFC0792]].
An SR-aware service SHOULD skip the service and forward to next
segment based on the SR information in the packet header. An SR
Service Proxy MUST skip the service and forward to next segment based
on the SR information in the packet header.
Ali, et al. Expires October 26, 2019 [Page 5]
Internet-Draft SR-SP OAM April 2019
6.1.3.1. Pinging Service SID Function
When a remote node pings a service segment, it MUST set SRH.Flags.O =
1. If the target service segment is implemented with USP behavior,
the ICMP packet can be constructed without adding END.OP or END.OTP
SIDs defined in [I-D.ali-spring-srv6-oam]. However, if the target
service SID observes a PSP behavior, the sender needs to insert
END.OP/ END.OTP SIDs before the target service SID in the segment-
list. In either case, the target SR-aware service or SR proxy
receives the ICMP echo request with either SRH.Flags.O-bit set or
with the local END.OP or END.OTP SID. In both cases, the packet is
punted for slow-path processing and service is skipped.
The Egress node process the packet as per procedure defined in
[I-D.ali-spring-srv6-oam]. The Egress checks if the target SID is
locally programmed or not.
If the target SID is not locally programmed, the Egress responses
with the ICMPv6 message (Type: "SRv6 OAM (TBA)", Code: "SID not
locally implemented (TBA)"); otherwise a success is returned
[I-D.ali-spring-srv6-oam].
6.1.4. UDP Probes
A classic traceroute mechanism relies on UDP probes by sending
packets with sequentially incrementing the TTL. More details are
available in section 4.3.1 of [I-D.ali-spring-srv6-oam].
An SR-aware service or SR proxy upon receiving the probe with TTL=1,
may follow the traditional behavior of replying with ICMPv6 Time
Exceeded Message (Type 3) as defined in [RFC4443] without applying
the service.
Use of SRH.Flags.O bit and END.OP/ END.OTP SIDs as OAM marker in the
UDP probe for trace route is same as discussed for ICMPv6 ping
discussed in the last section.
6.1.5. In-band OAM
To be Updated.
7. OAM for Service Programming with SR-MPLS
To be updated.
Ali, et al. Expires October 26, 2019 [Page 6]
Internet-Draft SR-SP OAM April 2019
8. IANA Considerations
None.
9. Security Considerations
A local policy may be used to control any malicious use of OAM
marker. More details are to be added in a future revision of the
document.
10. Acknowledgement
Authors would like to thank Bruno Decraene for his review and useful
comments.
11. Normative References
[I-D.ali-spring-srv6-oam]
Ali, Z., Filsfils, C., Kumar, N., Pignataro, C.,
faiqbal@cisco.com, f., Gandhi, R., Leddy, J., Matsushima,
S., Raszuk, R., daniel.voyer@bell.ca, d., Dawra, G.,
Peirens, B., Chen, M., and G. Naik, "Operations,
Administration, and Maintenance (OAM) in Segment Routing
Networks with IPv6 Data plane (SRv6)", draft-ali-spring-
srv6-oam-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.
[]
Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and
d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header
(SRH)", draft-ietf-6man-segment-routing-header-18 (work in
progress), April 2019.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), January 2018.
Ali, et al. Expires October 26, 2019 [Page 7]
Internet-Draft SR-SP OAM April 2019
[I-D.xuclad-spring-sr-service-programming]
Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
d., Li, C., Decraene, B., Ma, S., Yadlapalli, C.,
Henderickx, W., and S. Salsano, "Service Programming with
Segment Routing", draft-xuclad-spring-sr-service-
programming-02 (work in progress), April 2019.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
"Extended ICMP to Support Multi-Part Messages", RFC 4884,
DOI 10.17487/RFC4884, April 2007,
<https://www.rfc-editor.org/info/rfc4884>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>.
Authors' Addresses
Zafar Ali
Cisco Systems, Inc.
US
Email: zali@cisco.com
Clarence Filsfils
Cisco Systems, Inc.
Belgium
Email: cfilsfils@cisco.com
Ali, et al. Expires October 26, 2019 [Page 8]
Internet-Draft SR-SP OAM April 2019
Nagendra Kumar Nainar
Cisco Systems, Inc.
7200-12 Kit Creek Road
Research Triangle Park, NC 27709
US
Email: naikumar@cisco.com
Carlos Pignataro
Cisco Systems, Inc.
7200 Kit Creek Road
Research Triangle Park, NC 27709-4987
US
Email: cpignata@cisco.com
Francois Clad
Cisco Systems, Inc.
France
Email: fclad@cisco.com
Faisal Iqbal
Cisco Systems, Inc.
2000 Innovation Dr
Ottawa, ON 3E8
Canada
Email: faiqbal@cisco.com
Xiaohu Xu
Alibaba
Email: xiaohu.xxh@alibaba-inc.com
Ali, et al. Expires October 26, 2019 [Page 9]