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