idnits 2.17.1 draft-ietf-spring-sr-oam-requirement-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 30, 2015) is 3216 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4379' is defined on line 218, but no explicit reference was found in the text == Unused Reference: 'RFC6291' is defined on line 222, but no explicit reference was found in the text == Unused Reference: 'RFC6424' is defined on line 226, but no explicit reference was found in the text == Unused Reference: 'RFC6425' is defined on line 230, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-geib-spring-oam-usecase-04 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-03 -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 6424 (Obsoleted by RFC 8029) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 spring N. Kumar 3 Internet-Draft C. Pignataro 4 Intended status: Informational Cisco Systems, Inc. 5 Expires: January 1, 2016 N. Akiya 6 Big Switch Networks 7 R. Geib 8 Deutsche Telekom 9 G. Mirsky 10 Ericsson 11 S. Litkowski 12 Orange 13 June 30, 2015 15 OAM Requirements for Segment Routing Network 16 draft-ietf-spring-sr-oam-requirement-00 18 Abstract 20 This document describes a list of functional requirement for OAM in 21 Segment Routing (SR) based network. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 1, 2016. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 4. Detailed Requirement list . . . . . . . . . . . . . . . . . . 3 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 63 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 5 64 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 5 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 67 9.2. Informative References . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Introduction 72 [I-D.ietf-spring-segment-routing] introduces and explains Segment 73 Routing architecture that leverages source routing and tunneling 74 standards which can be applied directly to MPLS dataplane with no 75 changes on forwarding plane and on IPv6 dataplane with new Routing 76 Extension Header. 78 This document list the OAM requirements for Segment Routing based 79 network which can further be used to produce OAM tools, either 80 through enhancing existing OAM tools or constructing new OAM tools, 81 for path liveliness and service validation. 83 2. Requirements notation 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 3. Terminology 91 SR OAM Packet: OAM probe originated and processed within SR domain(s) 93 ECMP: Equal Cost Multipath 95 SR: Segment Routing 96 UCMP: Unequal Cost Multipath 98 Initiator: Centralized OAM initiator or PMS as referred in 99 [I-D.geib-spring-oam-usecase] 101 4. Detailed Requirement list 103 This section list the OAM requirement for Segment Routing based 104 network. The below listed requirement MUST be supported with both 105 MPLS and IPv6 dataplane: 107 REQ#1: SR OAM MUST support both On-demand and Continuous OAM 108 functionality. 110 REQ#2: The SR OAM packet MUST follow exactly the same path as 111 dataplane traffic. 113 REQ#3: The SR OAM packet MUST have the ability to discover and 114 exercise equal cost multipath (ECMP) paths. 116 REQ#4: The SR OAM packet MUST have the ability to discover and 117 exercise unequal cost multipath (UCMP) paths. 119 REQ#5: The SR OAM packet MUST have ability to exercise any 120 available paths, not just best path available. 122 REQ#6: The forwarding semantic of adjacency Segment ID raises a 123 need for additional consideration to detect any failure in 124 forwarding to the right adjacency. SR OAM MUST have the 125 ability to detect any failure in Node SID and adjacency 126 segment based forwarding. 128 REQ#7: SR OAM SHOULD have the ability to allow the Initiator to 129 control the return path from any transit or egress 130 responder. 132 REQ#8: SR OAM MUST have the ability to be initialized from an 133 arbitrary node to perform connectivity verification and 134 continuity check to any other node within SR domain. 136 REQ#9: In case of any failure with continuity check, SR OAM SHOULD 137 support rapid Connectivity Fault localization to isolate the 138 node on which the failure occurs. 140 REQ#10: SR OAM SHOULD also have the ability to be initialized from a 141 centralized controller. 143 REQ#11: When SR OAM is initialized from centralized controller, it 144 MUST have the ability to alert any edge node in SR domain 145 about the corresponding path or service failure. The node 146 on receiving the alert MAY take a local protection action or 147 pop an informational message. 149 REQ#12: When SR OAM is initialized from centralized controller, it 150 SHOULD support node redundancy. If primary Initiator fails, 151 secondary one MUST take over the responsibility without 152 having any impact on customer traffic. 154 REQ#13: SR OAM MUST have the ability to measure Packet loss, Packet 155 Delay or Delay variation using Active (using synthetic 156 probe) and Passive (using data stream) mode. 158 REQ#14: When a new path is instantiated, SR OAM SHOULD allow path 159 verification without noticeable delay. 161 REQ#15: The above listed requirements SHOULD be supported without 162 any scalability limitation imposed and SHOULD be extensible 163 to accommodate any new SR functionality. 165 REQ#16: SR OAM SHOULD minimize the need to create or maintain per 166 path state entry in any other nodes other than the 167 Initiator. 169 REQ#17: When traffic engineering is initiated by centralized 170 controller device, and when SR OAM is performed by 171 individual nodes, there MUST be a mechanism to communicate 172 failure to centralized controller device. 174 REQ#18: When service instruction is present in SR OAM packet header, 175 there MUST be a method to disallow applying the service to 176 the OAM packet to handle cases where that may result in 177 unintended corruption of the OAM packet. 179 5. IANA Considerations 181 This document does not propose any IANA consideration. 183 6. Security Considerations 185 This document list the OAM requirement for Segment Routing network 186 and does not raise any security considerations. 188 7. Acknowledgement 190 The authors would like to thank Stefano Previdi for his review. 192 8. Contributing Authors 194 Sriganesh Kini 195 Ericsson 196 Email: sriganesh.kini@ericsson.com 198 9. References 200 9.1. Normative References 202 [I-D.geib-spring-oam-usecase] 203 Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use 204 case for a scalable and topology aware MPLS data plane 205 monitoring system", draft-geib-spring-oam-usecase-04 (work 206 in progress), March 2015. 208 [I-D.ietf-spring-segment-routing] 209 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 210 and R. Shakir, "Segment Routing Architecture", draft-ietf- 211 spring-segment-routing-03 (work in progress), May 2015. 213 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 214 Requirement Levels", BCP 14, RFC 2119, March 1997. 216 9.2. Informative References 218 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 219 Label Switched (MPLS) Data Plane Failures", RFC 4379, 220 February 2006. 222 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 223 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 224 Acronym in the IETF", BCP 161, RFC 6291, June 2011. 226 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 227 Performing Label Switched Path Ping (LSP Ping) over MPLS 228 Tunnels", RFC 6424, November 2011. 230 [RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, 231 S., and T. Nadeau, "Detecting Data-Plane Failures in 232 Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 233 6425, November 2011. 235 Authors' Addresses 237 Nagendra Kumar 238 Cisco Systems, Inc. 239 7200 Kit Creek Road 240 Research Triangle Park, NC 27709 241 US 243 Email: naikumar@cisco.com 245 Carlos Pignataro 246 Cisco Systems, Inc. 247 7200 Kit Creek Road 248 Research Triangle Park, NC 27709-4987 249 US 251 Email: cpignata@cisco.com 253 Nobo Akiya 254 Big Switch Networks 255 Japan 257 Email: nobo.akiya.dev@gmail.com 259 Ruediger Geib 260 Deutsche Telekom 261 Heinrich Hertz Str. 3-7 262 Darmstadt 64295 263 Germany 265 Email: Ruediger.Geib@telekom.de 267 Greg Mirsky 268 Ericsson 270 Email: gregory.mirsky@ericsson.com 272 Stephane Litkowski 273 Orange 275 Email: stephane.litkowski@orange.com