idnits 2.17.1 draft-ali-spring-sr-service-programming-oam-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 5) being 87 lines == It seems as if not all pages are separated by form feeds - found 8 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 26 instances of too long lines in the document, the longest one being 13 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2018) is 2012 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.draft-xuclad-spring-sr-service-programming' is mentioned on line 81, but not defined == Missing Reference: 'I-D.draft-ietf-6man-segment-routing-header' is mentioned on line 184, but not defined == Missing Reference: 'I-D.draft-ali-spring-srv6-oam' is mentioned on line 258, but not defined == Unused Reference: 'RFC0792' is defined on line 326, but no explicit reference was found in the text == Unused Reference: 'RFC4443' is defined on line 335, but no explicit reference was found in the text == Unused Reference: 'RFC4884' is defined on line 341, but no explicit reference was found in the text == Unused Reference: 'RFC7665' is defined on line 346, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-ali-spring-srv6-oam-01 == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-05 == Outdated reference: A later version (-02) exists of draft-xuclad-spring-sr-service-programming-00 ** Downref: Normative reference to an Informational RFC: RFC 7665 Summary: 2 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 spring Z. Ali 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track N. Nainar 5 Expires: April 21, 2019 C. Pignataro 6 F. Clad 7 F. Iqbal 8 Cisco Systems, Inc. 9 X. Xu 10 Alibaba Inc. 11 October 22, 2018 13 OAM for Service Programming with Segment Routing 14 draft-ali-spring-sr-service-programming-oam-00 16 Abstract 18 This document defines the Operations, Administrations and Maintenance 19 (OAM) for service programming in SR-enabled MPLS and IP networks. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 21, 2019. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 3 59 5. Programmable OAM . . . . . . . . . . . . . . . . . . . . . . 3 60 5.1. Service Programming OAM Packet Marker . . . . . . . . . . 3 61 5.2. OAM with SR-aware services . . . . . . . . . . . . . . . 3 62 5.3. OAM with SR-unaware services . . . . . . . . . . . . . . 4 63 5.4. Controlling OAM packet processing in Services . . . . . . 4 64 6. OAM for Service Programming with SRv6 . . . . . . . . . . . . 4 65 6.1. OAM Tool Kit . . . . . . . . . . . . . . . . . . . . . . 5 66 6.1.1. ICMP . . . . . . . . . . . . . . . . . . . . . . . . 5 67 6.1.2. UDP Probes . . . . . . . . . . . . . . . . . . . . . 5 68 6.1.3. OAM Flag Processing . . . . . . . . . . . . . . . . . 6 69 6.1.4. OAM Segment ID . . . . . . . . . . . . . . . . . . . 6 70 6.1.5. In-band OAM . . . . . . . . . . . . . . . . . . . . . 6 71 6.2. Example with ICMPv6 Ping . . . . . . . . . . . . . . . . 6 72 7. OAM for Service Programming with SR-MPLS . . . . . . . . . . 8 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 76 11. Normative References . . . . . . . . . . . . . . . . . . . . 8 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 [I-D.draft-xuclad-spring-sr-service-programming] defines data plane 82 functionality required to implement service segments and achieve service 83 programming in SR-enabled MPLS and IP networks, as described in the 84 Segment Routing architecture. This document defines the Operations, 85 Administrations and Maintenance (OAM) for service programming in 86 SR-enabled MPLS and IP networks. 88 2. Requirements notation 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 3. Terminology 96 This document uses the terminologies defined in 97 [I-D.ietf-spring-segment-routing], 98 [I-D.filsfils-spring-srv6-network-programming] 99 [I-D.xuclad-spring-sr-service-programming] and so the readers are 100 expected to be familiar with the same. 102 4. Document Scope 104 The initial focus of this document to define and document the 105 machinery required to apply OAM mechanisms on SRv6 based service 106 programming. 108 Future version of this document will include the required details to 109 apply OAM mechanism on other data planes. 111 5. Programmable OAM 113 Section 4 of [I-D.xuclad-spring-sr-service-programming] introduces 114 Service segments and the procedure of service programming when the 115 services are SR-aware and SR-unaware. By integrating the OAM 116 functionality in the services, versatile OAM tool kits can be used to 117 execute programmable OAM for service programming with Segment 118 Routing. 120 This section describes the procedure to perform basic OAM mechanisms 121 such as path validation and path tracing of Service Programming 122 environment in Segment Routing network. 124 5.1. Service Programming OAM Packet Marker 126 Any services upon receiving OAM packet may apply the service 127 treatment if it cannot differentiate the OAM packet from normal data 128 packet. Depending on the service type, service treatment on OAM 129 packet may result in dropping the OAM probe packet that may cause 130 uncertainty in OAM mechanism. 132 To avoid such uncertainty, any node that is originating the OAM probe 133 for Service Programming OAM MUST mark the packet as OAM packet so 134 that the services can differentiate the OAM packet from data traffic. 136 5.2. OAM with SR-aware services 138 As defined in section 4.1 of 139 [I-D.xuclad-spring-sr-service-programming], an SR-aware service can 140 process the SR information in the packet header such as performing 141 lookup or executing the next segment etc. An SR-aware service may 142 need to identify the packet payload and/or interpret SR information 143 to apply the right policy to the received packet. While processing 144 SR information in the packet header, it can process the OAM packet 145 marker in the SR header to differentiate the OAM packet from normal 146 data packet. 148 An SR-aware service SHOULD skip applying the service on the OAM 149 packet while forwarding the packet to the next segment or IP address. 150 As defined in section 9, a local policy may be used to 151 control any malicious use of OAM marker. 153 5.3. OAM with SR-unaware services 155 As defined in section 4.2 of 156 [I-D.xuclad-spring-sr-service-programming], an SR-unaware service may 157 be a legacy service that is not able to process the SR information in 158 the packet header. SR Proxy, an entity that is external to the 159 service is used to handle the SR information processing on behalf of 160 the service. SR Proxy will remove the SR header before forwarding 161 the packet to SR-unaware services to avoid any erroneous decision due 162 to the presence of SR header that the service cannot recognize. 164 While processing SR information in the packet header, SR proxy can 165 process the OAM packet marker in the SR header to differentiate the 166 OAM packet from normal data packet. SR Proxy MUST skip forwarding 167 the packets with OAM marker to the service while forwarding the packet 168 to the next segment or IP address. As defined in section 9, 169 a local policy may be used to control any malicious use of OAM marker. 171 5.4. Controlling OAM packet processing in Services 173 As mentioned in the above sections, SR-aware service or the SR proxy 174 can use the OAM marker to differentiate the OAM packet from data 175 packet to skip the service treatment. Any intentional or 176 unintentional use of OAM marker in data traffic may result in 177 skipping service treatment for data traffic. To avoid such 178 condition, a local policy will be used in the SR-aware service or SR 179 Proxy that SHOULD rate limit or MAY drop the packets received with 180 OAM marker. 182 6. OAM for Service Programming with SRv6 184 [I-D.draft-ietf-6man-segment-routing-header] defines SRH.Flags.O-bit 185 in Segment Routing header. When service programming is implemented with 186 SRv6 dataplane, SRH.Flags.O-bit is used as OAM marker. An IPv6 packet 187 received with a local END.OP or END.OTP SID is also considered as an 188 OAM packet. 190 Any node that is originating OAM probe to a service in SRv6 data plane 191 MUST set SRH.Flags.O-bit in the SRH. 193 6.1. OAM Tool Kit 195 This section describes the availability of different tool kits that 196 can be used to perform OAM functionality for Service Programming with 197 SRv6 dataplane. 199 6.1.3. OAM Flag Processing 201 An SR-aware service or SR proxy MUST implement the SRH.Flags.O bit. 202 An SR-aware service SHOULD skip applying the service to the packet when 203 SRH.Flags.O-bit is set and SHOULD forward the packet based on the next header. 204 SR Service Proxy MUST skip applying the service to the packet when SRH.Flags.O-bit 205 is set and SHOULD forward the packet based on the next header. 207 An SR-aware service and SR proxy may choose to time-stamp and punt the packet with 208 SRH.Flags.O-bit set for further processing and this is a local 209 implementation matter. 211 6.1.4. OAM Segment ID 213 Section 3.2 of [[I-D.ali-spring-srv6-oam]] defines OAM segment ID and 214 the associated forwarding semantics to implement the punt behavior 215 for OAM packets. Specifically, the draft defines END.OP and END.OTP SIDs. 216 An IPv6 packet received with DA set to a local END.OP or END.OTP SID is 217 considered as an OAM packet. 219 Any service policy head end MAY include OAM segment ID in the desired 220 segment list position of SRH. The inclusion of OAM SID in SRH can be 221 used to control the services that are required to punt the OAM packet 222 for processing. 224 6.1.3. ICMP 226 There is no hardware or software changes required to use ICMP for 227 Ping operation. It can be triggered from the service policy head end 228 or from any classical IPv6 nodes by sending ICMPv6 Echo Request. The 229 existing ICMP Ping mechanism works seamlessly in SRv6 dataplane with 230 no protocol changes required to the standard ICMPv6 [[RFC4443]], 231 [[RFC4884]] or the standard ICMPv4 [[RFC0792]]. 233 An SR-aware service SHOULD skip the service and forward to next 234 segment based on the SR information in the packet header. 235 An SR Service Proxy MUST skip the service and forward to next 236 segment based on the SR information in the packet header. 238 6.1.3.1. Pinging Service SID Function 240 When a remote node pings a service segment, it MUST set SRH.Flags.O = 1. 241 If the target service segment is implemented with USP behavior, the ICMP 242 packet can be constructed without adding END.OP or END.OTP SIDs defined 243 in [I-D.draft-ali-spring-srv6-oam]. However, if the target service SID 244 observes a PSP behavior, the sender needs to insert END.OP/ END.OTP SIDs 245 before the target service SID in the segment-list. In either case, the 246 target SR-aware service or SR proxy receives the ICMP echo request with 247 either SRH.Flags.O-bit set or with the local END.OP or END.OTP SID. 248 In both cases, the packet is punted for slow-path processing and service is 249 skipped. 251 The Egress node process the packet as per procedure defined in 252 [I-D.draft-ali-spring-srv6-oam]. The Egress checks if the target SID is 253 locally programmed or not. 255 If the target SID is not locally programmed, the Egress responses with 256 the ICMPv6 message (Type: "SRv6 OAM (TBA)", Code: "SID not 257 locally implemented (TBA)"); otherwise a success is returned 258 [I-D.draft-ali-spring-srv6-oam]. 260 6.1.4. UDP Probes 262 A classic traceroute mechanism relies on UDP probes by sending 263 packets with sequentially incrementing the TTL. More details are 264 available in section 4.3.1 of [I-D.ali-spring-srv6-oam]. 266 An SR-aware service or SR proxy upon receiving the probe with TTL=1, 267 may follow the traditional behavior of replying with ICMPv6 Time 268 Exceeded Message (Type 3) as defined in [[RFC4443]], without applying the 269 service. 271 Use of SRH.Flags.O bit and END.OP/ END.OTP SIDs as OAM marker in the UDP 272 probe for trace route is same as discussed for ICMPv6 ping discussed in 273 the last section. 275 6.1.5. In-band OAM 277 To be Updated. 279 7. OAM for Service Programming with SR-MPLS 281 To be updated. 283 8. IANA Considerations 285 None. 287 9. Security Considerations 289 A local policy may be used to control any malicious use of OAM marker. 290 More details are to be added in a future revision of the document. 292 10. Acknowledgement 294 Author would like to thank Bruno Decraene for his review and useful comments. 296 11. Normative References 298 [I-D.ali-spring-srv6-oam] 299 Ali, Z., Filsfils, C., Kumar, N., Pignataro, C., 300 faiqbal@cisco.com, f., Gandhi, R., Leddy, J., Matsushima, 301 S., Raszuk, R., daniel.voyer@bell.ca, d., Dawra, G., 302 Peirens, B., Chen, M., and G. Naik, "Operations, 303 Administration, and Maintenance (OAM) in Segment Routing 304 Networks with IPv6 Data plane (SRv6)", draft-ali-spring- 305 srv6-oam-01 (work in progress), July 2018. 307 [I-D.filsfils-spring-srv6-network-programming] 308 Filsfils, C., Camarillo, P., Leddy, J., 309 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 310 Network Programming", draft-filsfils-spring-srv6-network- 311 programming-05 (work in progress), July 2018. 313 [I-D.ietf-spring-segment-routing] 314 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 315 Litkowski, S., and R. Shakir, "Segment Routing 316 Architecture", draft-ietf-spring-segment-routing-15 (work 317 in progress), January 2018. 319 [I-D.xuclad-spring-sr-service-programming] 320 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 321 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 322 Henderickx, W., and S. Salsano, "Service Programming with 323 Segment Routing", draft-xuclad-spring-sr-service- 324 programming-00 (work in progress), July 2018. 326 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 327 RFC 792, DOI 10.17487/RFC0792, September 1981, 328 . 330 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 331 Requirement Levels", BCP 14, RFC 2119, 332 DOI 10.17487/RFC2119, March 1997, 333 . 335 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 336 Control Message Protocol (ICMPv6) for the Internet 337 Protocol Version 6 (IPv6) Specification", STD 89, 338 RFC 4443, DOI 10.17487/RFC4443, March 2006, 339 . 341 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 342 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 343 DOI 10.17487/RFC4884, April 2007, 344 . 346 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 347 Chaining (SFC) Architecture", RFC 7665, 348 DOI 10.17487/RFC7665, October 2015, 349 . 351 Authors' Addresses 353 Zafar Ali 354 Cisco Systems, Inc. 355 US 357 Email: zali@cisco.com 359 Clarence Filsfils 360 Cisco Systems, Inc. 361 Belgium 363 Email: cfilsfils@cisco.com 365 Nagendra Kumar Nainar 366 Cisco Systems, Inc. 367 7200-12 Kit Creek Road 368 Research Triangle Park, NC 27709 369 US 371 Email: naikumar@cisco.com 372 Carlos Pignataro 373 Cisco Systems, Inc. 374 7200 Kit Creek Road 375 Research Triangle Park, NC 27709-4987 376 US 378 Email: cpignata@cisco.com 380 Francois Clad (editor) 381 Cisco Systems, Inc. 382 France 384 Email: fclad@cisco.com 386 Faisal Iqbal 387 Cisco Systems, Inc. 388 2000 Innovation Dr 389 Ottawa, ON 3E8 390 Canada 392 Email: faiqbal@cisco.com 394 Xiaohu Xu (editor) 395 Alibaba 397 Email: xiaohu.xxh@alibaba-inc.com