spring                                                            Z. Ali
Internet-Draft                                               C. Filsfils
Intended status: Standards Track                               N. Nainar
Expires: February 15, 2022                                  C. Pignataro
                                                                 F. Clad
                                                     Cisco Systems, Inc.
                                                                F. Iqbal
                                                         Arista Networks
                                                                   X. Xu
                                                                 Alibaba
                                                         August 15, 2021


            OAM for Service Programming with Segment Routing
             draft-ali-spring-sr-service-programming-oam-04

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 February 15, 2022.

Copyright Notice

   Copyright (c) 2021 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.

Ali, et al.              Expires August 22, 2021                [Page 1]


Internet-Draft                  SR-SP OAM                  February 2021



Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements notation . . . . . . . . . . . . . . . . . . . .   2
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Document Scope  . . . . . . . . . . . . . . . . . . . . . . .   3
   5.  OAM for Service Programming  . . .  . . . . . . . . . . . . .   3
     5.1.  Service Programming OAM Packet Processing . . . . . . . .   3
     5.2.  Service Programming OAM in SRv6 Data Plane  . . . . . . .   3
       5.2.1.  OAM with SR-aware services  . . . . . . . . . . . . .   4
       5.2.2.  OAM with SR-unaware services  . . . . . . . . . . . .   4
     5.3.  Service Programming OAM in SR-MPLS Data Plane . . . . . .   5
     5.4.  Controlling OAM packet processing in Services . . . . . .   5
   6.  Illustration  . . . . . . . . . . . . . . . . . . . . . . . .   5
     6.1.  SRv6 Dataplane  . . . . . . . . . . . . . . . . . . . . .   5
       6.1.1.  Pinging SR Service Policy . . . . . . . . . . . . . .   6
       6.1.2.  Pinging a Service SID . . . . . . . . . . . . . . . .   7
       6.1.3.  Tracing a SR Service Policy . . . . . . . . . . . . .   7
     6.2.  SR-MPLS Dataplane . . . . . . . . . . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   9.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   8
   10. Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   [I-D.ietf-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 August 22, 2021                [Page 2]


Internet-Draft                  SR-SP OAM                  February 2021


3.  Terminology

   This document uses the terminologies defined in [RFC8402],
   [I-D.ietf-spring-srv6-network-programming]
   [I-D.ietf-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.  OAM for Service Programming

   Section 4 of [I-D.ietf-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 ping and path tracing to Service Programming
   environment in Segment Routing network.

5.1.  Service Programming OAM Packet Processing

   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.

   The pseudo code for the service function SIDs in
   [I-D.ietf-spring-sr-service-programming] has been defined to avoid
   such uncertainty, as explained in the following subsections.

5.2.  Service Programming OAM in SRv6 Data Plane

   When the service programming is applied in an SRv6 network, the
   Upper-layer header type is typically set to ICMPv6 or UDP to differentiate the
   OAM packet from the data packets.





Ali, et al.              Expires August 22, 2021                [Page 3]


Internet-Draft                  SR-SP OAM                  February 2021


5.2.1.  OAM with SR-aware services

   As defined in section 4.1 of
   [I-D.ietf-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, processing the upper layer
   header, etc.

   An SR-aware service SHOULD skip applying the service on the OAM.
   As defined in section 9, a local policy may be used to control any
   malicious use of OAM marker.

   An SR-aware service follows the procedure defined in the
   [I-D.draft-ietf-6man-spring-srv6-oam] to implement ping and trace-route
   to a SR-aware SID and additional OAM mechanisms including the support
   for the OAM flag (O-flag).

5.2.2.  OAM with SR-unaware services

   As defined in section 4.2 of
   [I-D.ietf-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.



Ali, et al.              Expires August 22, 2021                [Page 4]


Internet-Draft                  SR-SP OAM                  February 2021


   The SRv6 pseudocode for SR Proxy defined in Sections 6.1.2.1, 6.1.2.2
   and 6.1.2.3 of [I-D.ietf-spring-sr-service-programming] handles the
   OAM packets as explained in the following.

   - Case 1: The service service programming segment is a transit segment.
     In this case, if the Upper-layer header does not match Ethernet,
     IPv4 or IPv6, the service function is skipped and packet is
     resubmitted to the IPv6 module for transmission to the new destination
     in the header (towards the next SRv6 segment).

     Please refer to the following lines of SRv6 pseudocode for SR Proxy
     defined in Sections 6.1.2.1, 6.1.2.2
     and 6.1.2.3 of [I-D.ietf-spring-sr-service-programming], respectively.

     In case of Static Proxy for Inner Type Ethernet:
     S15.   If (Upper-layer header type != 143 (Ethernet)) {
     S16.     Resubmit the packet to the IPv6 module for transmission to
              the new destination.
     S17.   }

     In case of Static Proxy for Inner Type IPv4:
     S15.   If (Upper-layer header type != 4 (IPv4)) {
     S16.     Resubmit the packet to the IPv6 module for transmission to
              the new destination.
     S17.   }

     In case of Static Proxy for Inner Type IPv6:
     S15.   If (Upper-layer header type != 41 (IPv6)) {
     S16.     Resubmit the packet to the IPv6 module for transmission to
              the new destination.
     S17.   }

   - Case 2: The service service programming segment is the ultimate segment.
     This is the case of OAM operations are targetted to a service programming
     SID (e.g., Ping and Trace-route to a service programming SID).
     In this case, as part of the Upper-layer header
     processing, the SR proxy processes to OAM payload, skips applying the
     service on the OAM packet and responds to the OAM message, accordingly.

     Please refer to the following lines of SRv6 pseudocode for SR Proxy
     defined in Sections 6.1.2.1, 6.1.2.2
     and 6.1.2.3 of [I-D.ietf-spring-sr-service-programming], respectively.

     In case of Static Proxy for Inner Type Ethernet:
     When processing the Upper-layer header of a packet matching a FIB
     entry locally instantiated as an SRv6 static proxy SID for Ethernet
     traffic, the following pseudocode is executed.

     S01. If (Upper-layer header type != 143 (Ethernet)) {
     S02.   Process as per [I-D.ietf-spring-srv6-network-programming]
            Section 4.1.1
     S03. }

     In case of Static Proxy for Inner Type IPv4:
     When processing the Upper-layer header of a packet matching a FIB
     entry locally instantiated as an SRv6 static proxy SID for IPv4
     traffic, the following pseudocode is executed.
     S01. If (Upper-layer header type != 4 (IPv4)) {
     S02.   Process as per [I-D.ietf-spring-srv6-network-programming]
            Section 4.1.1
     S03. }

     In case of Static Proxy for Inner Type IPv6:
     When processing the Upper-layer header of a packet matching a FIB
     entry locally instantiated as an SRv6 static proxy SID for IPv6
     traffic, the following pseudocode is executed.
     S01. If (Upper-layer header type != 41 (IPv6)) {
     S02.   Process as per [I-D.ietf-spring-srv6-network-programming]
            Section 4.1.1
     S03. }


5.3.  Service Programming OAM in SR-MPLS Data Plane

   This section will be updated later.

5.4.  Controlling OAM packet processing in Services

   As mentioned in the above sections, SR-aware service or the SR proxy
   can use the Upper-layer header to differentiate the OAM packet from
   data packet to skip the service treatment.  To avoid any intentional
   or unintentional use of OAM, a local policy SHOULD be used in the SR-
   aware service or SR Proxy to rate limit the incoming OAM packets.

6.  Illustration

   This section illustrates how the existing OAM tools can be used to
   perform the connectivity check or path tracing of SR Service
   Policies.

6.1.  SRv6 Dataplane

   This section illustrates how ICMPv6 can be used to ping or trace SR
   service policies in an SRv6 network using the below example topology.


           +-----------------------------------------------------+
           |                                                     |
           |                                +---------+          |
           |                                |    S2   |          |
           |                                |(service)|          |
           |                                +---------+          |
           |                                  |     |            |
      +----+----+  --->  +---------+  --->  +---------+     +----+-----+
      |    H    +--------+    S1   +--------+    SR   +----+|    E     |
      |(headend)|        |(service)|        |   Proxy |     |(endpoint)|
      +----+----+        +---------+        +---------+     +----+-----+
           |                                                     |
           |                        SRv6 Network                 |
           +-----------------------------------------------------+
                Figure 2. SR Service Policies in SRv6 Network




Ali, et al.              Expires August 22, 2021                [Page 5]


Internet-Draft                  SR-SP OAM                  February 2021


6.1.1.  Pinging SR Service Policy

   The user interested to ping the SR service policy shown in Figure 2
   will trigger the ICMPv6 echo request from the headend H with
   IP6(H,S1)(SRH) and the upper layer header set to ICMPv6.  The probe
   will be processed along the path as below:


           +-----------------------------------------------------+
           |                                                     |
           |                                +---------+          |
           |                                |    S2   |          |
           |                                |(service)|          |
           |                                +---------+          |
           |                                  |     |            |
      +----+----+  --->  +---------+  --->  +---------+     +----+-----+
      |    H    +--------+    S1   +--------+    SR   +----+|    E     |
      |(headend)|        |(service)|        |   Proxy |     |(endpoint)|
      +----+----+        +---------+        +---------+     +----+-----+
           |                                                     |
                 +---------+        +---------+      +---------+ |
           |     |IP6(H,S1)|        |IP6(H, S)|      |IP6(H,E.)| |
           |     +---------+        +---------+      +---------+ |
           |     |SRH(E,..,|        |SRH(E,..,|      |SRH(E,..,| |
           |     |   S2,..;|        |   S2,..;|      |   S2,..;| |
           |     |   S1,..;|        |   S1,..;|      |   S1,..;| |
           |     |    SL=i)|        |    SL=j)|      |    SL=k)| |
           |     +---------+        +---------+      +---------+ |
           |     |  ICMPv6 |        |  ICMPv6 |      |  ICMPv6 | |
           |     +---------+        +---------+      +---------+ |
           |                        SRv6 Network                 |
           +-----------------------------------------------------+
             Figure 3. Ping to SR Service Policies in SRv6 Network

      S1 (SR-aware service) will apply END function and follow the steps
      defined in [I-D.draft-ietf-6man-spring-srv6-oam].
      The Upper-layer header matches ICMPv6 but
      the Segment Left is not 0 and so the packet will be forwarded to
      the next destination S2. Service function is skipped due to ICMPv6
      payload.

      SR Proxy upon receiving the packet will match the local proxy SID
      and follow the steps defined in Sections 6.1.2.1, 6.1.2.2
      and 6.1.2.3 of [I-D.ietf-spring-sr-service-programming].
      The Upper-layer header
      does not match Ethernet, IPv4 or IPv6 and so resubmit the packet
      to the IPv6 module for transmission to the next destination E
      and service function is skipped.

      The endpoint E will process the upper-layer header and reply back
      to the initiator node H.




Ali, et al.              Expires August 22, 2021                [Page 6]


Internet-Draft                  SR-SP OAM                  February 2021


6.1.2.  Pinging a Service SID

   The user interested to ping a specific service SID SR service policy
   shown in Figure 4 will trigger the ICMPv6 echo request from the
   headend H with IP6(H,S1) and the upper layer header set to
   ICMPv6.  The probe will be processed along the path as below:


           +-----------------------------------------------------+
           |                                                     |
           |                                +---------+          |
           |                                |    S2   |          |
           |                                |(service)|          |
           |                                +---------+          |
           |                                  |     |            |
      +----+----+  --->  +---------+  --->  +---------+     +----+-----+
      |    H    +--------+    S1   +--------+    SR   +----+|    E     |
      |(headend)|        |(service)|        |   Proxy |     |(endpoint)|
      +----+----+        +---------+        +---------+     +----+-----+
           |                                                     |
                 +---------+                                     |
           |     |IP6(H,S1)|                                     |
           |     +---------+                                     |
           |     |  ICMPv6 |                                     |
           |     +---------+                                     |
           |                        SRv6 Network                 |
           +-----------------------------------------------------+
            Figure 4. Ping to specific Service SID in SRv6 Network

      S1 (SR-aware service) will follow the steps
      defined in [I-D.draft-ietf-6man-spring-srv6-oam].  Specifically,
      the service processes the ICMPv6 message and respond to the source,
      accordingly.

      S2 (SR-Unaware Service): The SR Proxy upon receiving the packet will
      match the local proxy SID
      and follow the steps defined in Sections 6.1.2.1, 6.1.2.2
      and 6.1.2.3 of [I-D.ietf-spring-sr-service-programming].
      When processing the Upper-layer header of a packet matching a FIB
      entry locally instantiated SID, the proxy process the ICMPv6 payload
      and respond to it, accordingly.

6.1.3.  Tracing a SR Service Policy

   The user interested to trace the SR service policy shown in Figure 2
   will trigger the ICMPv6 echo request from the headend H with
   IPv6(H,S1)(SRH), set the upper layer header set to ICMPv6 and the TTL
   to 1 and increment the same in the subsequent packets.  The probe
   will be processed along the path as below:




Ali, et al.              Expires August 22, 2021                [Page 7]


Internet-Draft                  SR-SP OAM                  February 2021


      The first probe sent from H will reach S1 (SR-aware service) with
      Hop Limit of 1.  S1 will process TTL expiry as described in
      [I-D.draft-ietf-6man-spring-srv6-oam]  and sends
      an ICMP Time Exceeded message to H with Code 0.

      The second probe sent from H will reach S2 (SR Proxy) with Hop
      Limit of 1.  SR Proxy will process as defined in the step S05 in
      Sections 6.1.2.1, 6.1.2.2
      and 6.1.2.3 of [I-D.ietf-spring-sr-service-programming] and sends
      an ICMP Time Exceeded message to H with Code 0.

      The third probe sent from H will reach E with Hop Limit of 1.  E
      processes TTL expiry as described in
      [I-D.draft-ietf-6man-spring-srv6-oam] and send an ICMP Time
      Exceeded message to H with Code 0.

6.2.  SR-MPLS Dataplane

   To be Updated.

7.  IANA Considerations

   None.

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

9.  Acknowledgement

   Authors would like to thank Bruno Decraene for review and useful
   comments.

10.  Normative References

   [I-D.ietf-6man-segment-routing-header]
              Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", draft-ietf-6man-segment-routing-header-26 (work in
              progress), October 2019.

   [I-D.ietf-6man-spring-srv6-oam]
              Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M.
              Chen, "Operations, Administration, and Maintenance (OAM)
              in Segment Routing Networks with IPv6 Data plane (SRv6)",
              draft-ietf-6man-spring-srv6-oam-08 (work in progress),
              October 2020.



Ali, et al.              Expires August 22, 2021                [Page 8]


Internet-Draft                  SR-SP OAM                  February 2021


   [I-D.ietf-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-ietf-spring-sr-service-
              programming-03 (work in progress), September 2020.

   [I-D.ietf-spring-srv6-network-programming]
              Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
              Matsushima, S., and Z. Li, "SRv6 Network Programming",
              draft-ietf-spring-srv6-network-programming-28 (work in
              progress), December 2020.

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

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

Authors' Addresses







Ali, et al.              Expires August 22, 2021                [Page 9]


Internet-Draft                  SR-SP OAM                  February 2021


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

   Email: faisal.ietf@gmail.com








Ali, et al.              Expires August 22, 2021               [Page 10]


Internet-Draft                  SR-SP OAM                  February 2021


   Xiaohu Xu
   Alibaba

   Email: xiaohu.xxh@alibaba-inc.com















































Ali, et al.              Expires August 22, 2021               [Page 11]