spring Z. Ali Internet-Draft C. Filsfils Intended status: Standards Track N. Nainar Expires: May 15, 2023 C. Pignataro F. Clad Cisco Systems, Inc. F. Iqbal Arista Networks X. Xu Capitalonline November 16, 2022 OAM for Service Programming with Segment Routing draft-ali-spring-sr-service-programming-oam-05 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 May 15, 2023. 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, . [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, Ed., "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., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, . [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, . 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.xu@capitalonline.net Ali, et al. Expires August 22, 2021 [Page 11]