idnits 2.17.1 draft-manral-trill-bfd-encaps-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 9) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2011) is 4793 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TRILLoam' is mentioned on line 256, but not defined == Missing Reference: 'RFCbfdtlv' is mentioned on line 232, but not defined == Unused Reference: 'RFC4634' is defined on line 340, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4634 (Obsoleted by RFC 6234) == Outdated reference: A later version (-08) exists of draft-ietf-pppext-trill-protocol-02 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Manral, Ed. 3 Internet-Draft IPInfusion Inc. 4 Intended status: Standards Track D. Eastlake 5 Expires: September 14, 2011 Huawei Inc. 6 D. Ward 7 Juniper Networks 8 A. Banerjee 9 Cisco Systems 10 March 13, 2011 12 Rbridges: Bidirectional Forwarding Detection (BFD) support for TRILL 13 draft-manral-trill-bfd-encaps-01 15 Abstract 17 This document specifies use of the BFD (Bidirectional Forwarding 18 Detection) protocol in RBridge campuses based on the OAM (Operations, 19 Administration, and Maintenance) Channel extension to the TRILL 20 (TRansparent Interconnection of Lots of Links) protocol. 22 BFD is a widely deployed OAM mechanism in IP and MPLS networks. 23 However, in the present form a BFD packet cannot be sent over a TRILL 24 network as it is either IP/ UDP encapsulated or encapsulated directly 25 over MPLS or using ACH encapsulation. This document also defines BFD 26 encapsulation over TRILL to address this shortcoming. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 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." 48 This Internet-Draft will expire on September 14, 2011. 50 Copyright Notice 52 Copyright (c) 2011 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. BFD over TRILL . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4. Sessions and Initialization . . . . . . . . . . . . . . . . . 5 71 5. Relationship to MPLS OAM . . . . . . . . . . . . . . . . . . . 6 72 6. TRILL BFD Control Protocol . . . . . . . . . . . . . . . . . . 6 73 7. One-Hop TRILL BFD Control . . . . . . . . . . . . . . . . . . 7 74 8. BFD Control Frame Processing . . . . . . . . . . . . . . . . . 7 75 9. TRILL BFD Echo Protocol . . . . . . . . . . . . . . . . . . . 7 76 9.1. BFD Echo Frame Processing . . . . . . . . . . . . . . . . 8 77 10. Management and Operations Considerations . . . . . . . . . . . 8 78 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 79 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 80 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 81 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 14.1. Normative References . . . . . . . . . . . . . . . . . . . 9 83 14.2. Informative References . . . . . . . . . . . . . . . . . . 9 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 86 1. Introduction 88 Faster convergence is a very critical feature of TRILL networks. The 89 TRILL IS-IS Hellos used between RBridges provide a basic neighbor and 90 continuity check for TRILL links. However, failure detection by non- 91 receipt of such Hellos is based on the holding time parameter which 92 is commonly set to a value of tens of seconds and, in any case, has a 93 minimum expressible value of one second. 95 Some applications, including voice over IP, may wish, with high 96 probability, to detect interruptions in continuity within a much 97 shorter time period. In some cases physical layer failures can be 98 detected very rapidly but this is not always possible, such as when 99 there is a failure between two bridges that are in turn between two 100 RBridges. There are also many subtle failures possible at higher 101 levels. For example, some forms of failure could affect unicast 102 frames while still letting multicast frames through; since all TRILL 103 IS-IS Hellos are multicast such a failure cannot be detected with 104 Hellos. Thus, a low overhead method for frequently testing 105 continuity for the TRILL Data between neighbor RBridges is necessary 106 for some applications. BFD protocol provides a low-overhead, short- 107 duration detection of failures in the path between forwarding 108 engines. 110 This document describes a TRILL encapsulation for BFD packets for 111 networks that do not use IP addressing or for ones where it is not 112 desireable. 114 2. Terminology 116 BFD: Bi-directional Forwarding Detection 118 OAM: Operations, Administration, and Maintenance 120 MPLS: Multi Protocol Label Switching 122 IS-IS: Intermediate-System to Intermediate-System 124 TTL: Time To Live 126 3. BFD over TRILL 128 TRILL supports neighbor BFD Echo and one-hop and multi-hop BFD 129 Control, as specified below, over the TRILL OAM Channel facility. 130 Multi-destination BFD is beyond the scope of this document. The OAM 131 Channel facility is specified in [TRILLoam]. 133 BFD over TRILL support is similar to BFD over IP support except where 134 it is explicitly so mentioned. When running BFD over TRILL both 135 Single Hop as well as in Multi Hop sessions are supported. 137 Asynchronous mode is supported, however the demand mode is not 138 supported for TRILL. BFD over TRILL supports the Echo function, 139 however this can be used for only Single hop sessions. 141 The TRILL Header Hop count in the BFD packets sent out with a value 142 of 63. To prevent spoofing attacks, the TRILL Hop count of a 143 received session is checked. For a single Hop session if the Hop 144 count is less than 63 the packet is discarded if the GTSM mode 145 [RFC5082] is set. For Multi Hop sessions the Hop count check can be 146 disabled or the bfdTrillAcceptedHopCount value can be configured. If 147 a packet is received with a hop count of less than 148 bfdTrillAcceptedHopCount, the packet is discarded. 150 The format of the echo packet is not defined. 152 A new BFD TRILL header is defined. 154 Authentication mechanisms as supported in BFD are also supported for 155 BFD running over TRILL. 157 4. Sessions and Initialization 159 Within an RBridge campus, there will be only a single TRILL BFD 160 Control session between two RBridges over a given interface visible 161 to TRILL. This BFD session must be bound to this interface. As 162 such, both sides of a session MUST take the "Active" role (sending 163 initial BFD Control packets with a zero value of Your Discriminator), 164 and any BFD packet from the remote machine with a zero value of Your 165 Discriminator MUST be associated with the session bound to the remote 166 system and interface. 168 Note that TRILL BFD provides OAM facilities for the TRILL Data plane. 169 This is above whatever protocol is in use on a particular link, such 170 as a PPP [TrillPPP] link or an Ethernet link. Link technology 171 specific OAM protocols may be used on a link between neighbor 172 RBridges, for example Continuity Fault Management [802.1ag] if the 173 link is Ethernet. But such link layer OAM and coordination between 174 it and TRILL data plaen layer OAM, such as TRILL BFD, is beyond the 175 scope of this document. 177 If lower level mechanisms, such as link aggregation [802.1AX], are in 178 use that present a single logical interface to TRILL IS-IS, only a 179 single TRILL BFD session can be established to any other RBridge over 180 this logical interface. However, lower layer OAM could be aware of 181 and/or run separately on each of the components of an aggregation. 183 5. Relationship to MPLS OAM 185 TRILL BFD uses the TRILL OAM Channel [TRILLoam] is the same way that 186 MPLS OAM protocols use the MPLS Generic Associated Channel [RFC5586]. 187 However, the RBridges that implement TRILL are IS-IS based routers, 188 not label switched routers; thus TRILL BFD is closer to IPv4/IPv6 BFD 189 than to MPLS BFD. 191 TRILL BFD optionally includes support of BFD Echo which is not 192 specified for MPLS BFD. 194 6. TRILL BFD Control Protocol 196 TRILL BFD Control frames are unicast TRILL OAM Message Channel frames 197 [TRILLoam]. The TRILL OAM Protocol value is given in Section 4. 199 The protocol specific data associated with the TRILL BFD Control 200 protocol is as shown below. See [RFC5880] for further information on 201 these fields. 203 TRILL BFD Control Protocol Data: 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 |Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | My Discriminator | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Your Discriminator | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Desired Min TX Interval | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Required Min RX Interval | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Required Min Echo RX Interval | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Optional Authentication Section: 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Auth Type | Auth Len | Authentication Data... | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 7. One-Hop TRILL BFD Control 224 One-hop TRILL BFD Control is typically used to rapidly detect link 225 and RBridge failures. TRILL BFD frames over one hop for such 226 purposes SHOULD be sent with priority 7. 228 For neighbor RBridges RB1 and RB2, each RBridge sends one-hop TRILL 229 BFD Control frames to the other only if TRILL IS-IS has detected bi- 230 directional connectivity and both RBridges indicate support of TRILL 231 BFD is enabled. The BFD Enabled TLV is used to indicate this as 232 specified in [RFCbfdtlv]. The indication of TRILL BFD support with 233 the BFD Enabled TLV overrides any indication of lack of support 234 through failure to indicate support of the OAM-Channel TRILL Header 235 extended flag. 237 8. BFD Control Frame Processing 239 The following tests SHOULD be performed on received TRILL BFD Control 240 frames before generic BFD processing. 242 Is the M bit in the TRILL Header non-zero? If so, discard the frame. 243 TRILL support of multi-destination BFD Control is beyond the scope of 244 this document. 246 If the OAM Header MH flag is zero, indicating one-hop, test that the 247 TRILL Header hop count received was 0x3F (i.e., is 0x3E if it has 248 already been decremented) and if it is any other value discard the 249 frame. If the MH OAM flag is one, indicating multi-hop, test that 250 the TRILL Header hop count received was not less than a configurable 251 value that defaults to 0x30. If it is less, discard the frame. 253 9. TRILL BFD Echo Protocol 255 A TRILL BFD Echo frame is a unicast TRILL OAM Message Channel frame, 256 as specified in [TRILLoam], which should be bounced back by an 257 immediate neighbor because both the ingress and egress nicknames are 258 set to a nickname of the originating RBridge. Normal TRILL Data 259 frame forwarding will cause the frame to be returned. The TRILL OAM 260 protocol number for BFD Echo is given in Section 4. 262 TRILL BFD Echo frames SHOULD only be sent on a link if 264 A TRILL BFD Control session has been established, 266 TRILL BFD Echo support is indicated by the potentially echo 267 responding RBridge, and 268 The TRILL BFD Echo originating RBridge wishes to make use of this 269 optional feature. 271 Since the originating RBridge is the RBridge that will be processing 272 a returned Echo frame, the entire TRILL BFD Echo protocol specific 273 data area is considered opaque and left to the discretion of the 274 originating RBridge. Nevertheless, it is RECOMMENDED that this data 275 include information by which the originating RBridge can authenticate 276 the returned BFD Echo frame and confirm the neighbor that echoed the 277 frame back. For example, it could include its own SystemID, the 278 neighbor's SystemID, a session identifier and a sequence count as 279 well as a Message Authentication Code. 281 9.1. BFD Echo Frame Processing 283 The following tests SHOULD be performed on returned TRILL BFD Echo 284 frames before other processing. (In some implementations, the TRILL 285 Header may not be available to the TRILL BFD Echo module in which 286 case these check are not possible.) 288 Is the M bit in the TRILL Header non-zero? If so, discard the frame. 289 TRILL support of multi-destination BFD Echo is beyond the scope of 290 this document. 292 The TRILL BFD Echo frame should have gone exactly two hops so test 293 that the TRILL Header hop count as received was 0x3E (i.e., 0x3D if 294 it has already been decremented) and if it is any other value discard 295 the frame. The TRILL OAM Header in the frame should have the MH bit 296 equal to one and if it is zero, the frame is discarded. 298 10. Management and Operations Considerations 300 The TRILL BFD parameters at an RBridge are configurable... The 301 default values are ... TBD. 303 It is required that the operator of an RBridge campus configure the 304 rates at which TRILL BFD frames are transmitted on a link to avoid 305 congestion (e.g., link, I/O, CPU) and false failure detection. 307 11. Security Considerations 309 This draft raises no new security considerations than those already 310 mentioned in the BFD [RFC5880]. By keeping a seperate flag for 311 Single Hop and Multihop sessions it allows the TTL check to be 312 performed thus preventing spoofing of packets. 314 However the same is possible even without the changes mentioned in 315 this document. A device should rate limit the LSP ping packets 316 redirected to the CPU so that the CPU is not overwhelmed. 318 12. IANA Considerations 320 IANA is request to allocate two TRILL OAM Protocol numbers from the 321 range allocated by Standards Actions, as follows: 323 Protocol Number 324 -------- ------ 325 BFD Control TBD (2 suggested) 326 BFD Echo TBD (3 suggested) 328 13. Acknowledgements 330 The authors would like to thank a lot of folks. Names will be 331 disclosed soon. 333 14. References 335 14.1. Normative References 337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 338 Requirement Levels", BCP 14, RFC 2119, March 1997. 340 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 341 (SHA and HMAC-SHA)", RFC 4634, July 2006. 343 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 344 Pignataro, "The Generalized TTL Security Mechanism 345 (GTSM)", RFC 5082, October 2007. 347 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 348 Associated Channel", RFC 5586, June 2009. 350 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 351 (BFD)", RFC 5880, June 2010. 353 14.2. Informative References 355 [802.1AX] IEEE, "IEEE Standard for Local and metropolitan area 356 networks / Link Aggregation", 802.1AX-2008, 1 January 2008. 358 [802.1ag] IEEE, "IEEE Standard for Local and metropolitan area 359 networks / Virtual Bridged Local Area Networks / Connectivity Fault 360 Management", 802.1ag-2007, 17 December 2007. 362 [TrillPPP] Carlson, J., "PPP TRILL Protocol Control Protocol", 363 draft-ietf-pppext-trill-protocol-02.txt, work in progress, May 2010. 365 Authors' Addresses 367 Vishwas Manral (editor) 368 IPInfusion Inc. 369 1188 E. Arques Ave. 370 Sunnyvale, CA 94085 371 USA 373 Phone: 408-400-1900 374 Email: vishwas@ipinfusion.com 376 Donald Eastlake 3rd 377 Huawei Inc. 378 155 Beaver Street 379 Milford, MA 01757 380 USA 382 Phone: 508-333-2270 383 Email: d3e3e3@gmail.com 385 Dave Ward 386 Juniper Networks 387 1194 N. Mathilda Ave. 388 Sunnyvale, CA 94089-1206 389 USA 391 Phone: 408-745-2000 392 Email: dward@juniper.net 394 Ayan Banerjee 395 Cisco Systems 396 170 W. Tasman Drive 397 San Jose, CA 95138 398 USA 400 Phone: 408-525-8781 401 Email: ayabaner@cisco.com