idnits 2.17.1 draft-ietf-trill-oam-req-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 : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 20, 2012) is 4199 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4377' is defined on line 463, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5101 (Obsoleted by RFC 7011) -- Obsolete informational reference (is this intentional?): RFC 2680 (Obsoleted by RFC 7680) -- Obsolete informational reference (is this intentional?): RFC 2679 (Obsoleted by RFC 7679) == Outdated reference: A later version (-16) exists of draft-ietf-opsawg-oam-overview-06 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Tissa Senevirathne 2 Internet Draft CISCO 3 Intended status: Informational David Bond 4 IBM 5 Sam Aldrin 6 Yizhou Li 7 Huawei 8 Rohit Watve 9 CISCO 11 October 20, 2012 12 Expires: April 2013 14 Requirements for Operations, Administration and Maintenance (OAM) in 15 TRILL 16 draft-ietf-trill-oam-req-02.txt 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as 31 reference material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 This Internet-Draft will expire on April 20,2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with 51 respect to this document. Code Components extracted from this 52 document must include Simplified BSD License text as described in 53 Section 4.e of the Trust Legal Provisions and are provided without 54 warranty as described in the Simplified BSD License. 56 Abstract 58 OAM (Operations, Administration and Maintenance) is a general term 59 used to identify functions and toolsets to troubleshoot and monitor 60 networks. This document presents, OAM Requirements applicable to 61 TRILL. 63 Table of Contents 65 1. Introduction...................................................3 66 1.1. Scope.....................................................3 67 2. Conventions used in this document..............................3 68 3. Terminology....................................................3 69 4. OAM Requirements...............................................4 70 4.1. Data Plane................................................4 71 4.2. Connectivity Verification.................................5 72 4.2.1. Unicast..............................................5 73 4.2.2. Multicast............................................5 74 4.3. Continuity Check..........................................5 75 4.4. Path Tracing..............................................6 76 4.5. General Requirements......................................6 77 4.6. Performance Monitoring....................................7 78 4.6.1. Packet Loss..........................................7 79 4.6.2. Packet Delay.........................................8 80 4.7. ECMP Utilization..........................................8 81 4.8. Security and Operational considerations...................8 82 4.9. Fault Indications.........................................9 83 4.10. Defect Indications.......................................9 84 4.11. Live Traffic monitoring..................................9 85 5. Security Considerations.......................................10 86 6. IANA Considerations...........................................10 87 7. References....................................................10 88 7.1. Normative References.....................................10 89 7.2. Informative References...................................10 91 8. Acknowledgments...............................................11 92 9. Contributing Authors..........................................11 94 1. Introduction 96 OAM (Operations, Administration and Maintenance) generally covers 97 various production aspects of a network. In this document we use the 98 term OAM as defined in [RFC6291]. 100 Success of any mission critical network depends on the ability to 101 proactively monitor networks for faults, performance, etc. as well 102 as its ability to efficiently and quickly troubleshoot defects and 103 failures. A well-defined OAM toolset is a vital requirement for 104 wider adoption of TRILL as the next generation data forwarding 105 technology in larger networks such as data centers. 107 In this document we define the Requirements for TRILL OAM. It is 108 assumed that the readers are familiar with the OAM concepts and 109 terminologies defined in other OAM standards such as [8021ag], 110 [RFC5860]. This document does not attempt to redefine the terms and 111 concepts specified elsewhere. 113 1.1. Scope 115 The scope of this document is OAM between RBridges of a TRILL campus 116 over links selected by TRILL routing. 118 2. Conventions used in this document 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC-2119 [RFC2119]. 123 Although this document is not a protocol specification, the use of 124 this language clarifies the instructions to protocol designers 125 producing solutions that satisfy the requirements set out in this 126 document. 128 3. Terminology 130 Section: The term Section refers to a partial segment of a path 131 between any two given RBridges. As an example, consider the case 132 where RB1 is connected to RBx via RB2,RB3 and RB4. The segment 133 between RB2 to RB4 is referred to as a Section of the path RB1 to 134 RBx. 136 Flow: The term Flow indicates a set of packets that share the same 137 path and per-hop behavior (such as priority). A flow is typically 138 identified by a portion of the inner payload that affects the hop-by 139 hop forwarding decisions. This may contain Layer 2 through Layer 4 140 information. 142 All Selectable Least Cost Paths: The term "all selectable least cost 143 paths" refers to a subset of all potentially available least cost 144 paths to a specified destination RBridge that are available (and 145 usable) for forwarding of frames. It is important to note, in 146 practice, due to limitations in implementations, not all available 147 least cost paths may be selectable for forwarding. 149 Connectivity: The term connectivity indicates reachability between 150 an arbitrary RBridge RB1 and any other RBridge RB2. The specific 151 path can be either explicit (i.e. associated with a specific flow) 152 or unspecified. Unspecified means that messages used for 153 connectivity verification take whatever that path the RBs happen to 154 select. 156 Continuity Verification: Continuity Verification refers to proactive 157 verification of Connectivity between two RBridges at periodic 158 intervals and generation of explicit notification when Connectivity 159 failures occur. 161 Fault: The term Fault refers to an inability to perform a required 162 action, e.g., an unsuccessful attempt to deliver a packet. 164 Defect: The term Defect refers to an interruption in the normal 165 operation, such that over a period of time no packets are delivered 166 successfully. 168 Failure: The term Failure refers to the termination of the required 169 function over a longer period of time. Persistence of a defect for a 170 period of time is interpreted as a failure. 172 4. OAM Requirements 174 4.1. Data Plane 176 OAM frames, utilized for connectivity verification, continuity 177 checks, performance measurements, etc., will by default take 178 whatever the path TRILL chooses based on the current topology and 179 per-hop equal cost path choices. In some cases, it may be required 180 that the OAM frames utilize specific paths. Thus, it MUST be 181 possible to arrange that OAM frames follow the path taken by a 182 specific flow. 184 RBridges MUST have the ability to identify OAM frames destined for 185 them or which require processing by the OAM plane from normal data 186 frames. 188 TRILL OAM frames MUST NOT be forwarded out as native frames on end 189 station service enabled ports. 191 OAM MUST have ability to include all Ethernet traffic types carried 192 by TRILL, including both IP and non-IP traffic. 194 4.2. Connectivity Verification 196 4.2.1. Unicast 198 From an arbitrary RBridge RB1, OAM MUST have the ability to verify 199 connectivity to any other RBridge RB2. 201 From an arbitrary RBridge RB1, OAM MUST have the ability to verify 202 connectivity to any other RBridge RB2 for a specific flow via the 203 path associated with the specified flow 205 An RBridge SHOULD have the ability to verify the above connectivity 206 tests on sections. As an example, assume RB1 is connected to RB5 via 207 RB2, RB3 and RB4. An operator SHOULD be able to verify the RB1 to 208 RB5 connectivity on the section from RB3 to RB5. The difference is 209 that the ingress and egress TRILL nicknames in this case are RB1 and 210 RB5 as opposed to RB3 and RB5, even though the message itself may 211 originate at RB3. 213 4.2.2. Multicast 215 OAM MUST have the ability to verify connectivity, from an arbitrary 216 RBridge RB1, to either to specific set of RBridges or all member 217 RBridges, for a specified multicast tree. This functionality is 218 referred to as verification of the un-pruned multicast tree. 220 OAM MUST have the ability to verify connectivity, from an arbitrary 221 RBridge RB1, to either to a specific set of RBridges or all member 222 RBridges, for a specified multicast tree and for a specified flow. 223 This functionality is referred to as verification of the pruned 224 tree. 226 4.3. Continuity Check 228 OAM MUST provide functions that allow any arbitrary RBridge RB1 to 229 perform a Continuity Check to any other RBridge. 231 OAM MUST provide functions that allow any arbitrary RBridge RB1 to 232 perform a Continuity Check to any other RBridge using a path 233 associated with a specified flow. 235 OAM SHOULD provide functions that allow any arbitrary RBridge to 236 perform a Continuity Check to any other RBridge over all selectable 237 least cost paths. 239 OAM SHOULD provide the ability to perform a Continuity Check on 240 sections of any selectable path within the network. 242 OAM SHOULD provide the ability to perform a multicast Continuity 243 Check for specified multi-destination tree(s) as well as specified 244 multi-destination tree and flow combinations. The former is referred 245 to as an un-pruned multi-destination tree Continuity Check and the 246 latter is referred to as a pruned tree Continuity Check. 248 4.4. Path Tracing 250 OAM MUST provide the ability to trace a path between any two 251 RBridges per specified unicast flow. 253 OAM SHOULD provide the ability to trace all selectable least cost 254 paths between any two RBridges. 256 OAM SHOULD provide functionality to trace all branches of a 257 specified multi-destination tree (un-pruned tree) 259 OAM SHOULD provide functionality to trace all branches of a 260 specified multi-destination tree for a specified flow (pruned tree). 262 4.5. General Requirements 264 OAM MUST provide the ability to initiate and maintain multiple 265 concurrent sessions for multiple OAM functions between any arbitrary 266 RBridge RB1 to any other RBridge. In general, multiple OAM 267 operations will run concurrently. For example, proactive continuity 268 checks may take place between RB1 and RB2 at the same time an 269 operator decides to test connectivity between the same two RBs. 270 Multiple OAM functions and instances of those functions MUST be able 271 to run concurrently without interfering with each other. 273 OAM MUST provide a single OAM framework for all TRILL OAM functions 274 within the scope of this document. 276 OAM, as practical and as possible, SHOULD provide a single framework 277 between TRILL and other similar standards. 279 OAM MUST maintain related error and operational counters. Such 280 counters MUST be accessible via network management applications 281 (e.g. SNMP). 283 OAM functions related to continuity and connectivity checks MUST be 284 able to be invoked either proactively or on-demand. 286 OAM SHOULD NOT require extensions to the TRILL header. OAM MAY be 287 required to provide the ability to specify a desired response mode 288 for a specific OAM message. The desired response mode can be either 289 in-band, out-of band or none. 291 The OAM Framework MUST be extensible to future needs of TRILL and 292 the needs of other standard organizations. 294 OAM MAY provide methods to verify control plane and forwarding plane 295 alignments. 297 OAM SHOULD leverage existing OAM technologies, where practical. 299 4.6. Performance Monitoring 301 4.6.1. Packet Loss 303 In this document, term loss of a packet is used as defined in 304 [RFC2680] (see Section 2.4 of RFC2680). 306 NOTE: The term simulated flow below indicates a flow that is 307 generated by an RBRidge RB1 for OAM purposes. The fields of the 308 simulated flow may or may not be identical to the actual data. 309 However, simulated flow is required to follow the intended path. 311 OAM SHOULD provide the ability to measure packet loss statistics for 312 a simulated flow from any arbitrary RBridge RB1 to any other 313 RBridge. 315 OAM SHOULD provide the ability to measure packet loss statistics 316 over a segment, for a simulated flow between any arbitrary RBridge 317 RB1 to any other RBridge. 319 OAM SHOULD provide the ability to measure simulated packet loss 320 statistics between any two RBridges over all least cost paths. 322 An RBridge SHOULD be able to perform the above packet loss 323 measurement functions either proactively or on-demand. 325 4.6.2. Packet Delay 327 There are two types of packet delays -- one-way delay and two-way 328 delay (Round Trip Delay). 330 One-way delay is defined in [RFC2679] as the time elapsed from the 331 start of transmission of the first bit of a packet by an RBridge 332 until the reception of the last bit of the packet by the destination 333 RBridge. 335 Two-way delay is also referred to as Round Trip Delay is defined 336 similar to [RFC2681]; i.e. the time elapsed from the start of 337 transmission of the first bit of a packet by an RBridge until the 338 reception of the last bit of the packet by the same RBridge. 340 OAM SHOULD provide functions to measure two-way delay between two 341 RBridges for a specified flow. 343 OAM SHOULD provide functions to measure two-way delay between two 344 RBridges for a specified flow over a specific section. 346 OAM MAY provide functions to measure one-way delay between two 347 RBridges for a specified flow. 349 OAM MAY provide functions to measure one-way delay between two 350 RBridges for a specified flow over a specific section. 352 4.7. ECMP Utilization 354 OAM MAY provide functionality to monitor the effectiveness of per- 355 hop ECMP hashing. For example, individual RBridges could maintain 356 counters that show how packets are being distributed across equal 357 cost next hops for a specified destination RBridge or RBridges as a 358 result of ECMP hashing. 360 4.8. Security and Operational considerations 362 Methods MUST be provided to protect against exploitation of OAM 363 framework for security and denial of service attacks. 365 Methods SHOULD be provided to prevent OAM messages causing 366 congestion in the networks. Periodically generated messages with 367 high frequencies may lead to congestion, hence methods such as 368 shaping or rate limiting SHOULD be utilized. 370 4.9. Fault Indications 372 The term Fault refers to an inability to perform a required action, 373 e.g., an unsuccessful attempt to deliver a packet [OAMOVER]. The 374 unsuccessful attempt may be due to Hop Count expiry, invalid 375 nickname, etc. 377 OAM MUST provide a Fault Indication framework to notify faults to 378 the ingress RBRidge of the packet or other interested parties (such 379 as syslog servers). 381 OAM MUST provide functions to selectively enable or disable 382 different types of Fault Indications. 384 4.10. Defect Indications 386 [OAMOVER] defines "The term Defect refers to an interruption in the 387 normal operation, such as a consecutive period of time where no 388 packets are delivered successfully." 390 OAM SHOULD provide a framework for Defect Detection and Indication. 392 OAM implementations that provide Defect Indication MUST provide 393 methods to selectively enable or disable Defect Detection per defect 394 type. 396 OAM implementations that provide Defect Indication MUST provide 397 methods to configure Defect Detection thresholds per different types 398 of defects. 400 OAM implementations that provide Defect Indication facilities MUST 401 provide methods to log defect indications to a locally defined 402 archive such as log buffer or SNMP traps. 404 OAM implementations that provide Defect Indication facilities SHOULD 405 provide a Remote Defect Indication framework that facilitates 406 notifying the originator/owner of the flow experiencing the defect, 407 which is the ingress RBridge. 409 Remote Defect Indication MAY be either in-band or out-of-band. 411 4.11. Live Traffic monitoring 413 OAM implementations MAY provide methods to utilize live traffic for 414 troubleshooting and performance monitoring. 416 Implementations MAY leverage Data Driven CFM [8021Q] or IPFIX 417 [RFC5101] for the purpose of performance monitoring. 419 5. Security Considerations 421 Security Requirements are specified in section 4.8. For general 422 TRILL security considerations please refer to [RFC6325] 424 6. IANA Considerations 426 None 428 7. References 430 7.1. Normative References 432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 433 Requirement Levels", BCP 14, RFC 2119, March 1997. 435 7.2. Informative References 437 [RFC6325] Perlman, R., et.al., "Routing Bridges (RBridges): Base 438 Protocol Specification", RFC 6325, July 2011. 440 [RFC5101] Claise, B., "Specification of the IP Flow Information 441 Export (IPFIX) Protocol for the Exchange of IP Traffic 442 Flow Information", RFC5101, January 2008. 444 [RFC2680] Almes, G., et.al. "A One-way Packet Loss Metric for IPPM", 445 RFC 2680, September 1999. 447 [RFC2679] Almes, G., et.al. "A One-way Delay Metric for IPPM", RFC 448 2679, September 1999. 450 [RFC2681] Almes, G., et.al. "A Round-trip Delay Metric for IPPM", 451 RFC 2681, September 1999. 453 [RFC6291] Anderson, L., et.al. "Guidelines for the Use of the "OAM" 454 Acronym in the IETF", RFC 6291, June 2011. 456 [8021ag] IEEE, "Virtual Bridged Local Area Networks Amendment 5: 457 Connectivity Fault Management", 802.1ag, 2007. 459 [8021Q] IEEE, "Media Access Control (MAC) Bridges and Virtual 460 Bridged Local Area Networks", IEEE Std 802.1Q-2011, 461 August, 2011. 463 [RFC4377] Nadeau, T., et.al. "Operations and Management (OAM) 464 Requirements for Multi-protocol Label Switched 465 (MPLS)Networks", RFC 4377, February 2006. 467 [OAMOVER] Mizrahi, T, et.al., "An Overview of Operations, 468 Administration, and Maintenance (OAM) Mechanisms", draft- 469 ietf-opsawg-oam-overview-06, Work in Progress, March 2012. 471 [RFC5860] Vigoureux, M., et.al., "Requirements for Operations, 472 Administration and Maintenance (OAM) in MPLS Transport 473 Networks", RFC5860, May 2010. 475 8. Acknowledgments 477 Special acknowledgments to IEEE 802.1 chair, Tony Jeffree for 478 allowing us to solicit comments from IEEE 802.1 group. Also 479 recognized are the comments received from IEEE group, Ayal Lior and 480 others. 482 This document was prepared using 2-Word-v2.0.template.dot. 484 9. Contributing Authors 486 Tissa Senevirathne 487 CISCO Systems 488 375 East Tasman Drive 489 San Jose, CA 95134 490 USA. 492 Phone: +1-408-853-2291 493 Email: tsenevir@cisco.com 495 David Bond 496 IBM 497 2051 Mission College Blvd 498 Santa Clara, CA 95054 499 USA 501 Phone: +1-603-339-7575 502 Email: mokon@mokon.net 503 Sam Aldrin 504 Huawei Technologies 505 2330 Central Express Way 506 Santa Clara, CA 95951 507 USA 509 Email: aldrin.ietf@gmail.com 511 Yizhou Li 512 Huawei Technologies 513 101 Software Avenue, 514 Nanjing 210012 515 China 517 Phone: +86-25-56625375 518 Email: liyizhou@huawei.com 520 Rohit Watve 521 CISCO Systems 522 375 East Tasman Drive 523 San Jose, CA 95134 524 USA. 526 Phone: +1-408-424-2091 527 Email: rwatve@cisco.com 529 Thomas Narten 530 IBM Corporation 531 3039 Cornwallis Avenue, 532 PO Box 12195 533 Research Triangle Park, NC 27709 534 USA 536 Email:narten@us.ibm.com 538 Donald Eastlake 539 Huawei Technologies 540 155 Beaver Street, 541 Milford, MAC 01757 542 USA. 544 Email: d3e3e3@gmail.com 545 Anoop Ghanwani 546 DELL 547 350 Holger Way 548 San Jose, CA 95134 549 USA. 551 Phone: +1-408-571-3500 552 Email: Anoop@alumni.duke.edu 554 Jon Hudson 555 Brocade 556 120 Holger Way 557 San Jose, CA 95134 558 USA. 560 Email: jon.hudson@gmail.com 562 Naveen Nimmu 563 Broadcom 564 9th Floor, Building no 9, Raheja Mind space 565 Hi-Tec City, Madhapur, 566 Hyderabad - 500 081, INDIA 568 Phone: +1-408-218-8893 569 Email: naveen@broadcom.com 571 Radia Perlman 572 Intel Labs 573 2700 156th Ave NE, Suite 300, 574 Bellevue, WA 98007 575 USA. 577 Phone: +1-425-881-4824 578 Email: radia.perlman@intel.com 580 Tal Mizrahi 581 Marvell 582 6 Hamada St. 583 Yokneam, 20692 Israel 585 Email: talmi@marvell.com