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 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

[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].

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 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

[I-D.ietf-6man-segment-routing-header] 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.

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.

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.

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)", Internet-Draft draft-ali-spring-srv6-oam-02, 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", Internet-Draft draft-filsfils-spring-srv6-network-programming-07, February 2019.
[I-D.ietf-6man-segment-routing-header] Filsfils, C., Previdi, S., Leddy, J., Matsushima, S. and d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header (SRH)", Internet-Draft draft-ietf-6man-segment-routing-header-18, April 2019.
[I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S. and R. Shakir, "Segment Routing Architecture", Internet-Draft draft-ietf-spring-segment-routing-15, January 2018.
[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", Internet-Draft draft-xuclad-spring-sr-service-programming-02, April 2019.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC4443] Conta, A., Deering, S. and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006.
[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.
[RFC7665] Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015.

Authors' Addresses

Zafar Ali Cisco Systems, Inc. US EMail: zali@cisco.com
Clarence Filsfils Cisco Systems, Inc. Belgium EMail: cfilsfils@cisco.com
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