idnits 2.17.1 draft-mwnpkazcap-rtgwg-common-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 19, 2015) is 3105 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-bier-oam-requirements-00 == Outdated reference: A later version (-02) exists of draft-ietf-rtgwg-dt-encap-00 == Outdated reference: A later version (-15) exists of draft-ietf-sfc-oam-framework-00 == Outdated reference: A later version (-03) exists of draft-ietf-spring-sr-oam-requirement-00 == Outdated reference: A later version (-06) exists of draft-kumarkini-mpls-spring-lsp-ping-04 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 draft-mwnpkazcap-rtgwg-common-oam-00 4 RTG Working Group G. Mirsky 5 Internet-Draft R. White 6 Intended status: Informational Ericsson 7 Expires: April 21, 2016 E. Nordmark 8 Arista Networks 9 C. Pignataro 10 N. Kumar 11 Cisco Systems, Inc. 12 S. Aldrin 13 Google 14 L. Zheng 15 M. Chen 16 Huawei Technologies 17 N. Akiya 18 Big Switch Networks 19 S. Pallagatti 20 Juniper Networks 21 October 19, 2015 23 Rationale for Transport-independent Common Operations, Administration 24 and Maintenance (OAM) 25 draft-mwnpkazcap-rtgwg-common-oam-00 27 Abstract 29 This document discusses set of Operations, Administration and 30 Maintenance (OAM) tools that can be used as common OAM independent of 31 specific encapsulation at server layer. Requirements toward server 32 layer to support common OAM are listed as well. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on April 21, 2016. 51 Copyright Notice 53 Copyright (c) 2015 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 1.1. Conventions used in this document . . . . . . . . . . . . 3 70 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 71 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 72 2. Use Case for Common OAM . . . . . . . . . . . . . . . . . . . 3 73 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 75 5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 4 76 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 78 6.2. Informative References . . . . . . . . . . . . . . . . . 4 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 81 1. Introduction 83 The introduction and development of new service layers such as 84 Service Function Chaining (SFC) and Bit-Ingress Explicit Replication 85 (BIER), is driving the need for new Operations, Administration and 86 Maintenance (OAM) tools. This document discusses benefits of Common 87 transport independent OAM solution to support components of network 88 management framework known as Fault, Configuration, Accounting, 89 Performance, and Security (FCAPS): 91 o Fault monitoring and defect localization; 93 o Performance measurement, both passive and active. 95 1.1. Conventions used in this document 97 1.1.1. Terminology 99 The term "OAM" used in this document interchangeably with longer 100 version "set of OAM protocols, methods and tools for a particular 101 layer". 103 BIER: Bit-Ingress Explicit Replication 105 FCAPS: Fault, Configuration, Accounting, Performance, and Security 107 OAM: Operations, Administration and Maintenance 109 SFC: Service Function Chaining 111 1.1.2. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in 116 [RFC2119]. 118 2. Use Case for Common OAM 120 Recently several new service layers have been developed in IETF. 121 Each of responsible groups, e.g. SPRING, NVO3, SFC, BIER, have 122 formulated a set of OAM requirements, specific to their respective 123 layer [I-D.ietf-spring-sr-oam-requirement], 124 [I-D.ashwood-nvo3-oam-requirements], [I-D.ietf-sfc-oam-framework], 125 and [I-D.ietf-bier-oam-requirements]. Proposals have already been 126 put forward to satisfy those requirements, though mostly by enhancing 127 existing OAM tools, such as LSP Ping 128 [I-D.kumarkini-mpls-spring-lsp-ping]. Enhancing existing tools 129 certainly leads to faster deployment of OAM but may create 130 operational issues later on. For instance, these new service layers 131 may be implemented a wide range of transport layers, e.g. MPLS or 132 IPv6, so OAM tools that are transport-oriented like LSP Ping would 133 not be able to perform end-to-end for inter-domain scenario. 135 At the same time, the Bidirectional Forwarding Detection (BFD) 136 protocol is being successfully adopted for IPv6 and MPLS networks, 137 and efforts are moving forward to define transport-independent OAM 138 tool based only on the requirements of one of these new services, 139 BIER. 141 [I-D.ietf-rtgwg-dt-encap] raised question of common OAM for NVO3, 142 SFC, and BIER. We want to take this further and: 144 o analyze relevant OAM requirements and document common set of 145 requirements towards OAM as well as requirements toward aservice 146 layer to enable its ability to support OAM; 148 o analyze OAM solutions (proactive and on-demand CC/CV, PM, FM) 149 being proposed and formulate approach to structure OAM tools that 150 may be re-used across several types on encapsulation. 152 3. IANA Considerations 154 This document does not propose any IANA consideration. This section 155 may be removed. 157 4. Security Considerations 159 This document does not raise any security concerns or issues in 160 addition to ones common to networking. 162 5. Acknowledgement 164 TBD 166 6. References 168 6.1. Normative References 170 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 171 Requirement Levels", BCP 14, RFC 2119, 172 DOI 10.17487/RFC2119, March 1997, 173 . 175 6.2. Informative References 177 [I-D.ashwood-nvo3-oam-requirements] 178 Chen, H., Ashwood-Smith, P., Xia, L., Iyengar, R., Tsou, 179 T., Sajassi, A., Boucadair, M., Jacquenet, C., Daikoku, 180 M., Ghanwani, A., and R. Krishnan, "NVO3 Operations, 181 Administration, and Maintenance Requirements", draft- 182 ashwood-nvo3-oam-requirements-04 (work in progress), 183 October 2015. 185 [I-D.ietf-bier-oam-requirements] 186 Mirsky, G., Nordmark, E., Pignataro, C., Kumar, N., 187 Aldrin, S., Zheng, L., Chen, M., Akiya, N., and J. 188 Networks, "Operations, Administration and Maintenance 189 (OAM) Requirements for Bit Index Explicit Replication 190 (BIER) Layer", draft-ietf-bier-oam-requirements-00 (work 191 in progress), September 2015. 193 [I-D.ietf-rtgwg-dt-encap] 194 Nordmark, E., Tian, A., Gross, J., Hudson, J., Kreeger, 195 L., Garg, P., Thaler, P., and T. Herbert, "Encapsulation 196 Considerations", draft-ietf-rtgwg-dt-encap-00 (work in 197 progress), July 2015. 199 [I-D.ietf-sfc-oam-framework] 200 Aldrin, S., Krishnan, R., Akiya, N., Pignataro, C., and A. 201 Ghanwani, "Service Function Chaining Operation, 202 Administration and Maintenance Framework", draft-ietf-sfc- 203 oam-framework-00 (work in progress), August 2015. 205 [I-D.ietf-spring-sr-oam-requirement] 206 Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G., 207 and S. Litkowski, "OAM Requirements for Segment Routing 208 Network", draft-ietf-spring-sr-oam-requirement-00 (work in 209 progress), June 2015. 211 [I-D.kumarkini-mpls-spring-lsp-ping] 212 Kumar, N., Swallow, G., Pignataro, C., Akiya, N., Kini, 213 S., Gredler, H., and M. Chen, "Label Switched Path (LSP) 214 Ping/Trace for Segment Routing Networks Using MPLS 215 Dataplane", draft-kumarkini-mpls-spring-lsp-ping-04 (work 216 in progress), July 2015. 218 Authors' Addresses 220 Greg Mirsky 221 Ericsson 223 Email: gregory.mirsky@ericsson.com 225 Russ White 226 Ericsson 228 Email: russ@riw.us 230 Erik Nordmark 231 Arista Networks 233 Email: nordmark@acm.org 234 Carlos Pignataro 235 Cisco Systems, Inc. 237 Email: cpignata@cisco.com 239 Nagendra Kumar 240 Cisco Systems, Inc. 242 Email: naikumar@cisco.com 244 Sam Aldrin 245 Google 247 Email: aldrin.ietf@gmail.com 249 Lianshu Zheng 250 Huawei Technologies 252 Email: vero.zheng@huawei.com 254 Mach Chen 255 Huawei Technologies 257 Email: mach.chen@huawei.com 259 Nobo Akiya 260 Big Switch Networks 262 Email: nobo.akiya.dev@gmail.com 264 Santosh Pallagatti 265 Juniper Networks 267 Email: santoshpk@juniper.net