idnits 2.17.1 draft-kumar-spring-sr-oam-requirement-03.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 (March 9, 2015) is 3334 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4379' is defined on line 219, but no explicit reference was found in the text == Unused Reference: 'RFC6291' is defined on line 223, but no explicit reference was found in the text == Unused Reference: 'RFC6424' is defined on line 227, but no explicit reference was found in the text == Unused Reference: 'RFC6425' is defined on line 231, 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-01 -- 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 N. Akiya 5 Expires: September 10, 2015 Cisco Systems, Inc. 6 R. Geib 7 Deutsche Telekom 8 G. Mirsky 9 Ericsson 10 S. Litkowski 11 Orange 12 March 9, 2015 14 OAM Requirements for Segment Routing Network 15 draft-kumar-spring-sr-oam-requirement-03 17 Abstract 19 This document describes a list of functional requirement for OAM in 20 Segment Routing (SR) based network. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 10, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 4. Detailed Requirement list . . . . . . . . . . . . . . . . . . 3 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 4 63 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 5 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 66 9.2. Informative References . . . . . . . . . . . . . . . . . 5 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 [I-D.ietf-spring-segment-routing] introduces and explains Segment 72 Routing architecture that leverages source routing and tunneling 73 standards which can be applied directly to MPLS dataplane with no 74 changes on forwarding plane and on IPv6 dataplane with new Routing 75 Extension Header. 77 This document list the OAM requirements for Segment Routing based 78 network which can further be used to produce OAM tools, either 79 through enhancing existing OAM tools or constructing new OAM tools, 80 for path liveliness and service validation. 82 2. Requirements notation 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 3. Terminology 90 SR OAM Packet: OAM probe originated and processed within SR domain(s) 92 ECMP: Equal Cost Multipath 94 SR: Segment Routing 96 UCMP: Unequal Cost Multipath 97 Initiator: Centralized OAM initiator or PMS as referred in 98 [I-D.geib-spring-oam-usecase] 100 4. Detailed Requirement list 102 This section list the OAM requirement for Segment Routing based 103 network. The below listed requirement MUST be supported with both 104 MPLS and IPv6 dataplane: 106 REQ#1: SR OAM MUST support both On-demand and Continuous OAM 107 functionality. 109 REQ#2: The SR OAM packet MUST follow exactly the same path as 110 dataplane traffic. 112 REQ#3: The SR OAM packet MUST have the ability to discover and 113 exercise equal cost multipath (ECMP) paths. 115 REQ#4: The SR OAM packet MUST have the ability to discover and 116 exercise unequal cost multipath (UCMP) paths. 118 REQ#5: The SR OAM packet MUST have ability to exercise any 119 available paths, not just best path available. 121 REQ#6: The forwarding semantic of adjacency Segment ID raises a 122 need for additional consideration to detect any failure in 123 forwarding to the right adjacency. SR OAM MUST have the 124 ability to detect any failure in Node SID and adjacency 125 segment based forwarding. 127 REQ#7: SR OAM SHOULD have the ability to allow the Initiator to 128 control the return path from any transit or egress 129 responder. 131 REQ#8: SR OAM MUST have the ability to be initialized from an 132 arbitrary node to perform connectivity verification and 133 continuity check to any other node within SR domain. 135 REQ#9: In case of any failure with continuity check, SR OAM SHOULD 136 support rapid Connectivity Fault localization to isolate the 137 node on which the failure occurs. 139 REQ#10: SR OAM SHOULD also have the ability to be initialized from a 140 centralized controller. 142 REQ#11: When SR OAM is initialized from centralized controller, it 143 MUST have the ability to alert any edge node in SR domain 144 about the corresponding path or service failure. The node 145 on receiving the alert MAY take a local protection action or 146 pop an informational message. 148 REQ#12: When SR OAM is initialized from centralized controller, it 149 SHOULD support node redundancy. If primary Initiator fails, 150 secondary one MUST take over the responsibility without 151 having any impact on customer traffic. 153 REQ#13: SR OAM MUST have the ability to measure Packet loss, Packet 154 Delay or Delay variation using Active (using synthetic 155 probe) and Passive (using data stream) mode. 157 REQ#14: When a new path is instantiated, SR OAM SHOULD allow path 158 verification without noticeable delay. 160 REQ#15: The above listed requirements SHOULD be supported without 161 any scalability limitation imposed and SHOULD be extensible 162 to accommodate any new SR functionality. 164 REQ#16: SR OAM SHOULD minimize the need to create or maintain per 165 path state entry in any other nodes other than the 166 Initiator. 168 REQ#17: When traffic engineering is initiated by centralized 169 controller device, and when SR OAM is performed by 170 individual nodes, there MUST be a mechanism to communicate 171 failure to centralized controller device. 173 REQ#18: When service instruction is present in SR OAM packet header, 174 there MUST be a method to disallow applying the service to 175 the OAM packet to handle cases where that may result in 176 unintended corruption of the OAM packet. 178 5. IANA Considerations 180 This document does not propose any IANA consideration. 182 6. Security Considerations 184 This document list the OAM requirement for Segment Routing network 185 and does not raise any security considerations. 187 7. Acknowledgement 189 The authors would like to thank Stefano Previdi for his review. 191 8. Contributing Authors 193 Sriganesh Kini 194 Ericsson 195 Email: sriganesh.kini@ericsson.com 197 9. References 199 9.1. Normative References 201 [I-D.geib-spring-oam-usecase] 202 Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use 203 case for a scalable and topology aware MPLS data plane 204 monitoring system", draft-geib-spring-oam-usecase-04 (work 205 in progress), March 2015. 207 [I-D.ietf-spring-segment-routing] 208 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 209 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 210 and E. Crabbe, "Segment Routing Architecture", draft-ietf- 211 spring-segment-routing-01 (work in progress), February 212 2015. 214 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 215 Requirement Levels", BCP 14, RFC 2119, March 1997. 217 9.2. Informative References 219 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 220 Label Switched (MPLS) Data Plane Failures", RFC 4379, 221 February 2006. 223 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 224 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 225 Acronym in the IETF", BCP 161, RFC 6291, June 2011. 227 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 228 Performing Label Switched Path Ping (LSP Ping) over MPLS 229 Tunnels", RFC 6424, November 2011. 231 [RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, 232 S., and T. Nadeau, "Detecting Data-Plane Failures in 233 Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 234 6425, November 2011. 236 Authors' Addresses 238 Nagendra Kumar 239 Cisco Systems, Inc. 240 7200 Kit Creek Road 241 Research Triangle Park, NC 27709 242 US 244 Email: naikumar@cisco.com 246 Carlos Pignataro 247 Cisco Systems, Inc. 248 7200 Kit Creek Road 249 Research Triangle Park, NC 27709-4987 250 US 252 Email: cpignata@cisco.com 254 Nobo Akiya 255 Cisco Systems, Inc. 256 2000 Innovation Drive 257 Kanata, ON K2K 3E8 258 Canada 260 Email: nobo@cisco.com 262 Ruediger Geib 263 Deutsche Telekom 264 Heinrich Hertz Str. 3-7 265 Darmstadt 64295 266 Germany 268 Email: Ruediger.Geib@telekom.de 270 Greg Mirsky 271 Ericsson 273 Email: gregory.mirsky@ericsson.com 275 Stephane Litkowski 276 Orange 278 Email: stephane.litkowski@orange.com