idnits 2.17.1 draft-ooamdt-rtgwg-ooam-requirement-01.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 (July 7, 2016) is 2849 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-bier-oam-requirements' is defined on line 405, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-bier-architecture-03 == Outdated reference: A later version (-12) exists of draft-ietf-bier-mpls-encapsulation-04 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-02 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-05 == Outdated reference: A later version (-15) exists of draft-ietf-sfc-oam-framework-01 == Outdated reference: A later version (-03) exists of draft-nordmark-nvo3-transcending-traceroute-02 == Outdated reference: A later version (-06) exists of draft-xu-bier-encapsulation-05 == Outdated reference: A later version (-15) exists of draft-ietf-bier-oam-requirements-01 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 rtgwg N. Kumar 3 Internet-Draft C. Pignataro 4 Intended status: Informational D. Kumar 5 Expires: January 8, 2017 Cisco Systems, Inc. 6 G. Mirsky 7 Ericsson 8 M. Chen 9 Huawei Technologies 10 E. Nordmark 11 Arista Networks 12 S. Pallagatti 13 Juniper Networks 14 D. Mozes 15 Mellanox Technologies Ltd 16 July 7, 2016 18 Overlay OAM Requirements 19 draft-ooamdt-rtgwg-ooam-requirement-01 21 Abstract 23 This document describes a list of functional requirements for 24 Operations Administration and Maintenance (OAM) in various Overlay 25 and Service networks like Service Function Chaining (SFC), Bit Index 26 Explicit Replication (BIER), Network Virtualization over Layer 3 27 (NVO3). 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 8, 2017. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 4. Detailed Requirement List . . . . . . . . . . . . . . . . . . 4 67 4.1. Fault Management . . . . . . . . . . . . . . . . . . . . 5 68 4.1.1. Pro-active Fault Management . . . . . . . . . . . . . 5 69 4.1.2. On-demand Fault Management . . . . . . . . . . . . . 5 70 4.2. Performance Management . . . . . . . . . . . . . . . . . 6 71 4.3. Alarm Indication Suppression . . . . . . . . . . . . . . 7 72 4.4. Overlay Network Resiliency . . . . . . . . . . . . . . . 7 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 75 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 78 8.2. Informative References . . . . . . . . . . . . . . . . . 9 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 81 1. Introduction 83 We have witnessed and participated in design of new paradigms in the 84 networking that are aimed to address network virtualization, service 85 function chaining, and multicast services. New paradigms require new 86 architectural concepts, principles and components. [RFC7365] defines 87 a framework for Data Center Network Virtualization over Layer 3 88 (NVO3). [RFC7665] describes the architecture for creating and 89 maintaining Service Function Chains (SFCs) in a network. 90 [I-D.ietf-bier-architecture] defines a stateless multicast 91 architecture for optimal multicast packet forwarding using "Bit Index 92 Explicit Replication" (BIER). These frameworks are defined in a 93 flexible manner that they are transport agnostic and may be deployed 94 on various underlay networks such as IPv4, IPv6 and MPLS. 96 The above mentioned new architectural concepts and principles have 97 been combined into new network layers with distinct encapsulation 98 headers. For example, [I-D.ietf-sfc-nsh] defines an encapsulation 99 header as Network Service Header (NSH) to realize Service Function 100 Path. While [RFC7348] (VxLAN) and [RFC7637] (NVGRE) are different 101 encapsulation header proposed for NVO3, [I-D.ietf-nvo3-vxlan-gpe] 102 extends VxLAN further to be used for Service Function Chain (SFC). 103 Similarly, [I-D.ietf-bier-mpls-encapsulation] defines the BIER 104 encapsulation header over MPLS network and 105 [I-D.xu-bier-encapsulation] describes the BIER encapsulation header 106 over IP network. 108 Introduction of the new Overlay networks, sets forth new Operations, 109 Administration and Maintenance (OAM) requirements that can be 110 addressed by enhancing the existing toolset or developing new 111 protocols. For example, [I-D.ietf-sfc-oam-framework] defines the 112 framework for SFC OAM, [I-D.nordmark-nvo3-transcending-traceroute] 113 proposes a way to perform traceroute in NVO3 networks and 114 [I-D.kumarzheng-bier-ping] proposes on-demand connectivity 115 verification and fault isolation procedure (Ping and Trace) on BIER 116 network. 118 The goal of this document is to identify and list the OAM 119 requirements commonly applicable to new Overlay networks which can 120 further be used to analyze the existing OAM tools. The identified 121 gaps can be addressed, either through enhancing existing OAM tools 122 and if necessary, constructing new OAM tools, that can be used as a 123 common unified OAM toolset to support and perform various OAM 124 functions including proactive and on-demand path monitoring and 125 service validation on the new Overlay network. 127 2. Requirements notation 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 3. Terminology 135 ECMP: Equal Cost Multipath 137 SFC: Service Function Chaining 139 BIER: Bit Index Explicit Replication 140 NVO3: Network Virtualization over L3 142 OAM: Operations, Administration and Maintenance 144 MPLS: Multiprotocol Label Switching 146 VxLAN: Virtual Extensible Local Area Network 148 NVGRE: Network Virtualization Using Generic Routing Encapsulation 150 Centralized Controller: An external standalone or virtual entity with 151 topology awareness and with an ability to interact with network 152 devices for OAM functionality. 154 Overlay nodes: Network nodes participating in the Overlay network. 156 Underlay Network or Underlay Layer: The network that provides 157 connectivity between the Overlay nodes. MPLS network providing LSP 158 connectivity between BIER nodes is an example for underlay layer. 160 Overlay Network or Overlay Layer: A network layer that is built on 161 top another network layer. VxLAN-GPE over IP network is an example 162 for Overlay layer. 164 4. Detailed Requirement List 166 This section lists the OAM requirement for different Overlay 167 networks. The below listed requirement MUST be supported with any 168 underlay transport network: 170 REQ#1: The listed requirements MUST be supported with any type of 171 transport layer over which the overlay network can be 172 realized. 174 REQ#2: It MUST be possible to initialize Overlay OAM between any 175 node towards any node(s) in the overlay network. 177 REQ#3: It SHOULD be possible to initialize an Overlay OAM from a 178 centralized controller. 180 REQ#4: Overlay OAM MUST support proactive and on-demand OAM 181 monitoring and measurement methods. 183 REQ#5: Overlay OAM MUST support unidirectional OAM methods for 184 continuity check, connectivity verification and performance 185 measurement. 187 REQ#6: Overlay OAM packets SHOULD be fate sharing with data traffic, 188 i.e. in-band with the monitored traffic, i.e. follow exactly 189 the same overlay and transport path as data plane traffic, 190 in forward direction, i.e. from ingress toward egress end 191 point(s) of the OAM test. 193 REQ#7: Overlay OAM MUST support bi-directional OAM methods. Such 194 OAM methods MAY combine in-band monitoring or measurement in 195 forward direction and out-of-band notification in the 196 reverse direction, i.e. from egress to ingress end point of 197 the OAM test. 199 REQ#8: Overlay OAM MUST support Path Maximum Transmission Unit (MTU) 200 Discovery from the overlay layer over any transport layer. 202 4.1. Fault Management 204 4.1.1. Pro-active Fault Management 206 Availability, not as performance metric, is understood as ability to 207 reach the node, i.e. the fact that path between ingress and egress 208 does exist. Such OAM mechanism also referred as Continuity Check. 210 REQ#9: Overlay OAM MUST support pro-active monitoring of any virtual 211 node availability in the given overlay network. 213 REQ#10: Overlay OAM MUST support Remote Defect Indication (RDI) 214 notification by egress to the ingress, i.e. source of 215 continuity checking. 217 REQ#11: Overlay OAM MUST support connectivity verification. 218 Definition of mis-connectivity defect entry and exit 219 criteria are outside the scope of this document. 221 4.1.2. On-demand Fault Management 223 REQ#12: Overlay OAM MUST support fault localization of Loss of 224 Continuity check at Overlay layer. 226 REQ#13: Overlay OAM MAY support fault localization of Loss of 227 Continuity check at transport layer. 229 REQ#14: Overlay OAM MUST support tracing path in overlay network 230 through the overlay nodes. 232 REQ#15: Overlay OAM MAY support tracing path in underlay network 233 connecting overlay border nodes. 235 REQ#16: Overlay OAM MAY support verification of the mapping between 236 its data plane state and client layer services. 238 REQ#17: Overlay OAM MUST have the ability to discover and exercise 239 equal cost multipath (ECMP) paths in its underlay network. 241 REQ#18: Overlay OAM MUST be able to trigger on-demand FM with 242 responses being directed towards initiator of such proxy 243 request. 245 4.2. Performance Management 247 Section 3.4 and Section 3.5 of [RFC7799] defines the definition for 248 Active and Passive mode of Performance Measurement (PM) methods. 249 This section lists the requirements for both active and passive PM 250 methods. Passive PM is a measurement method that should not modify 251 the actual data packet processing behavior on underlay and overlay 252 network. Accordingly, it should be supported by the Overlay nodes. 254 REQ#19: Overlay OAM MUST support active one-way packet delay 255 measurement. 257 REQ#20: Overlay OAM MUST support passive one-way packet delay 258 measurement. 260 REQ#21: Overlay OAM MUST support active two-way packet delay 261 measurement. 263 REQ#22: Overlay OAM MUST support packet delay variation measurement. 265 REQ#23: Overlay OAM MUST support active end to end packet loss 266 measurement. 268 REQ#24: Overlay OAM MUST support passive end to end packet loss 269 measurement. 271 REQ#25: Overlay OAM SHOULD support active per-segment packet delay 272 measurement. 274 REQ#26: Overlay OAM SHOULD support passive per-segment packet delay 275 measurement. 277 REQ#27: Overlay OAM SHOULD support active per-segment packet loss 278 measurement. 280 REQ#28: Overlay OAM SHOULD support passive per-segment packet loss 281 measurement. 283 REQ#29: Overlay OAM MUST support delivered packet throughput 284 measurement. 286 4.3. Alarm Indication Suppression 288 REQ#30: Overlay OAM MUST support defect notification mechanism, like 289 Alarm Indication Signal. 291 REQ#31: Any virtual node in the given overlay network MAY originate a 292 defect notification addressed to any node in that network. 294 4.4. Overlay Network Resiliency 296 REQ#32: Overlay OAM MUST support methods to enable survivability of 297 an overlay network. These recovery methods MAY use 298 protection switching and restoration. 300 5. IANA Considerations 302 This document does not propose any IANA consideration. 304 6. Security Considerations 306 This document list the OAM requirement for various Overlay 307 encapsulations and may have security implications. For example, if 308 proactive FM is required, the security implication is that a passive 309 eavesdropper can know when the session is down. Or, proactive FM may 310 be used either to launch DoS or to highjack session and impact state, 311 e.g. cause protection switchover. These security implications are 312 natural results of the requirements, and do not depend on the 313 particular implementation. Whether existing security mechanisms of 314 existing protocols proposed to be re-used in OAM for overlay networks 315 are adequate or require enhancements is for further study. New OAM 316 protocols for overlay networks must consider their security mechanism 317 to on per-solution basis. 319 7. Acknowledgement 321 The Authors would like to thank Ron Bonico, Tal Mizrahi, Alia Atlas 322 and Saumya Dikshit for their review and comments. 324 8. References 326 8.1. Normative References 328 [I-D.ietf-bier-architecture] 329 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 330 S. Aldrin, "Multicast using Bit Index Explicit 331 Replication", draft-ietf-bier-architecture-03 (work in 332 progress), January 2016. 334 [I-D.ietf-bier-mpls-encapsulation] 335 Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., and 336 S. Aldrin, "Encapsulation for Bit Index Explicit 337 Replication in MPLS Networks", draft-ietf-bier-mpls- 338 encapsulation-04 (work in progress), April 2016. 340 [I-D.ietf-nvo3-vxlan-gpe] 341 Kreeger, L. and U. Elzur, "Generic Protocol Extension for 342 VXLAN", draft-ietf-nvo3-vxlan-gpe-02 (work in progress), 343 April 2016. 345 [I-D.ietf-sfc-nsh] 346 Quinn, P. and U. Elzur, "Network Service Header", draft- 347 ietf-sfc-nsh-05 (work in progress), May 2016. 349 [I-D.ietf-sfc-oam-framework] 350 Aldrin, S., Krishnan, R., Akiya, N., Pignataro, C., and A. 351 Ghanwani, "Service Function Chaining Operation, 352 Administration and Maintenance Framework", draft-ietf-sfc- 353 oam-framework-01 (work in progress), February 2016. 355 [I-D.kumarzheng-bier-ping] 356 Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 357 and G. Mirsky, "BIER Ping and Trace", draft-kumarzheng- 358 bier-ping-03 (work in progress), July 2016. 360 [I-D.nordmark-nvo3-transcending-traceroute] 361 Nordmark, E., Appanna, C., and A. Lo, "Layer-Transcending 362 Traceroute for Overlay Networks like VXLAN", draft- 363 nordmark-nvo3-transcending-traceroute-02 (work in 364 progress), March 2016. 366 [I-D.xu-bier-encapsulation] 367 Xu, X., somasundaram.s@alcatel-lucent.com, s., Jacquenet, 368 C., and R. Raszuk, "A Transport-Independent Bit Index 369 Explicit Replication (BIER) Encapsulation Header", draft- 370 xu-bier-encapsulation-05 (work in progress), June 2016. 372 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 373 Requirement Levels", BCP 14, RFC 2119, 374 DOI 10.17487/RFC2119, March 1997, 375 . 377 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 378 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 379 eXtensible Local Area Network (VXLAN): A Framework for 380 Overlaying Virtualized Layer 2 Networks over Layer 3 381 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 382 . 384 [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 385 Rekhter, "Framework for Data Center (DC) Network 386 Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 387 2014, . 389 [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network 390 Virtualization Using Generic Routing Encapsulation", 391 RFC 7637, DOI 10.17487/RFC7637, September 2015, 392 . 394 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 395 Chaining (SFC) Architecture", RFC 7665, 396 DOI 10.17487/RFC7665, October 2015, 397 . 399 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 400 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 401 May 2016, . 403 8.2. Informative References 405 [I-D.ietf-bier-oam-requirements] 406 Mirsky, G., Nordmark, E., Pignataro, C., Kumar, N., 407 Aldrin, S., Zheng, L., Chen, M., Akiya, N., and S. 408 Pallagatti, "Operations, Administration and Maintenance 409 (OAM) Requirements for Bit Index Explicit Replication 410 (BIER) Layer", draft-ietf-bier-oam-requirements-01 (work 411 in progress), March 2016. 413 Authors' Addresses 415 Nagendra Kumar 416 Cisco Systems, Inc. 417 7200 Kit Creek Road 418 Research Triangle Park, NC 27709 419 US 421 Email: naikumar@cisco.com 422 Carlos Pignataro 423 Cisco Systems, Inc. 424 7200 Kit Creek Road 425 Research Triangle Park, NC 27709-4987 426 US 428 Email: cpignata@cisco.com 430 Deepak Kumar 431 Cisco Systems, Inc. 432 3700 Cisco Way 433 SJ 434 US 436 Email: dekumar@cisco.com 438 Greg Mirsky 439 Ericsson 441 Email: gregory.mirsky@ericsson.com 443 Mach Chen 444 Huawei Technologies 446 Email: mach.chen@huawei.com 448 Eric Nordmark 449 Arista Networks 451 Email: nordmark@acm.org 453 Santosh Pallagatti 454 Juniper Networks 456 Email: santosh.pallagatti@gmail.com 458 David Mozes 459 Mellanox Technologies Ltd 461 Email: davidm@mellanox.com