idnits 2.17.1 draft-kumar-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 (February 14, 2014) is 3723 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4379' is defined on line 199, but no explicit reference was found in the text == Unused Reference: 'RFC6291' is defined on line 203, but no explicit reference was found in the text == Unused Reference: 'RFC6424' is defined on line 207, but no explicit reference was found in the text == Unused Reference: 'RFC6425' is defined on line 211, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-geib-spring-oam-usecase-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 (~~), 6 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: August 18, 2014 Cisco Systems, Inc. 6 R. Geib 7 Deutsche Telekom 8 G. Mirsky 9 Ericsson 10 February 14, 2014 12 OAM Requirements for Segment Routing Network 13 draft-kumar-spring-sr-oam-requirement-00 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 August 18, 2014. 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. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 63 8.2. Informative References . . . . . . . . . . . . . . . . . 5 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 [I-D.filsfils-rtgwg-segment-routing] introduces and explains Segment 69 Routing architecture that leverages source routing and tunneling 70 standards which can be applied directly to MPLS dataplane with no 71 changes on forwarding plane and on IPv6 dataplane with new Routing 72 Extension Header. 74 This document is a place holder to identify and list the OAM 75 requirements for Segment Routing based network which can further be 76 used to produce OAM tools, either through enhancing existing OAM 77 tools or constructing new OAM tools, for path liveliness and service 78 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 ECMP: Equal Cost Multipath 90 SR: Segment Routing 92 UCMP: Unequal Cost Multipath 94 Initiator: Centralized OAM initiator or PMS as referred in 95 [I-D.geib-spring-oam-usecase] 97 4. Detailed Requirement list 99 This section list the OAM requirement for Segment Routing based 100 network. The below listed requirement MUST be supported with both 101 MPLS and IPv6 dataplane: 103 REQ#1: SR OAM MUST support both On-demand and Continuous OAM 104 functionality. 106 REQ#2: The OAM packet MUST follow exactly the same path as 107 dataplane traffic. 109 REQ#3: The OAM packet MUST have the ability to discover and 110 exercise equal cost multipath (ECMP) paths. 112 REQ#4: The OAM packet MUST have the ability to discover and 113 exercise unequal cost multipath (UCMP) paths. 115 REQ#5: The OAM packet MUST have ability to exercise any available 116 paths, not just best path available. 118 REQ#6: The forwarding semantic of adjacency Segment ID raises a 119 need for additional consideration to detect any failure in 120 forwarding to the right adjacency. SR OAM MUST have the 121 ability to detect any failure in Node SID and adjacency 122 segment based forwarding. 124 REQ#7: SR OAM MUST have the ability to be initialized from an 125 arbitrary node to perform connectivity verification and 126 continuity check to any other node within SR domain. 128 REQ#8: In case of any failure with continuity check, SR OAM SHOULD 129 support rapid Connectivity Fault localization to isolate the 130 node on which the failure occurs. 132 REQ#9: SR OAM SHOULD also have the ability to be initialized from a 133 centralized controller. 135 REQ#10: When SR OAM is initialized from centralized controller, it 136 MUST have the ability to alert any edge node in SR domain 137 about the corresponding path or service failure. The node 138 on receiving the alert MAY take a local protection action or 139 pop an informational message. 141 REQ#11: When SR OAM is initialized from centralized controller, it 142 SHOULD support node redundancy. If primary Initiator fails, 143 secondary one MUST take over the responsibility without 144 having any impact on customer traffic. 146 REQ#12: SR OAM MUST have the ability to measure Packet loss, Packet 147 Delay or Delay variation. 149 REQ#13: When a new path is instantiated, SR OAM SHOULD allow path 150 verification without noticeable delay. 152 REQ#14: The above listed requirements SHOULD be supported without 153 any scalability limitation imposed and SHOULD be extensible 154 to accommodate any new SR functionality. 156 REQ#15: SR OAM SHOULD NOT create or maintain per path state entry in 157 any other nodes other than the Initiator. 159 REQ#16: When traffic engineering is initiated by centralized 160 controller device, and when SR OAM is performed by 161 individual nodes, there MUST be a mechanism to communicate 162 failure to centralized controller device. 164 5. IANA Considerations 166 This document does not propose any IANA consideration. 168 6. Security Considerations 170 This document list the OAM requirement for Segment Routing network 171 and does not raise any security considerations. 173 7. Acknowledgement 175 The authors would like to thank Stefano Previdi for his review. 177 8. References 179 8.1. Normative References 181 [I-D.filsfils-rtgwg-segment-routing] 182 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 183 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 184 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 185 "Segment Routing Architecture", draft-filsfils-rtgwg- 186 segment-routing-01 (work in progress), October 2013. 188 [I-D.geib-spring-oam-usecase] 189 Geib, R. and C. Filsfils, "Use case for a scalable and 190 topology aware MPLS data plane monitoring system", draft- 191 geib-spring-oam-usecase-01 (work in progress), February 192 2014. 194 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 195 Requirement Levels", BCP 14, RFC 2119, March 1997. 197 8.2. Informative References 199 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 200 Label Switched (MPLS) Data Plane Failures", RFC 4379, 201 February 2006. 203 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 204 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 205 Acronym in the IETF", BCP 161, RFC 6291, June 2011. 207 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 208 Performing Label Switched Path Ping (LSP Ping) over MPLS 209 Tunnels", RFC 6424, November 2011. 211 [RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, 212 S., and T. Nadeau, "Detecting Data-Plane Failures in 213 Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 214 6425, November 2011. 216 Authors' Addresses 218 Nagendra Kumar 219 Cisco Systems, Inc. 220 7200 Kit Creek Road 221 Research Triangle Park, NC 27709 222 US 224 Email: naikumar@cisco.com 226 Carlos Pignataro 227 Cisco Systems, Inc. 228 7200 Kit Creek Road 229 Research Triangle Park, NC 27709-4987 230 US 232 Email: cpignata@cisco.com 233 Nobo Akiya 234 Cisco Systems, Inc. 235 2000 Innovation Drive 236 Kanata, ON K2K 3E8 237 Canada 239 Email: nobo@cisco.com 241 Ruediger Geib 242 Deutsche Telekom 243 Heinrich Hertz Str. 3-7 244 Darmstadt 64295 245 Germany 247 Email: Ruediger.Geib@telekom.de 249 Greg Mirsky 250 Ericsson 252 Email: gregory.mirsky@ericsson.com