idnits 2.17.1 draft-ietf-bfd-intervals-03.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 (August 16, 2014) is 3534 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force N. Akiya 3 Internet-Draft M. Binderberger 4 Intended status: Informational Cisco Systems 5 Expires: February 17, 2015 G. Mirsky 6 Ericsson 7 August 16, 2014 9 Common Interval Support in BFD 10 draft-ietf-bfd-intervals-03 12 Abstract 14 BFD requires that messages are transmitted at regular intervals and 15 provides a way to negotiate the interval used by BFD peers. Some BFD 16 implementations may be restricted to only support several interval 17 values. When such BFD implementations speak to each other, there is 18 a possibility of two sides not being able to find a common interval 19 value to run BFD sessions. 21 This document defines a small set of interval values for BFD that we 22 call "Common intervals", and recommends implementations to support 23 the defined intervals. This solves the problem of finding an 24 interval value that both BFD speakers can support while allowing a 25 simplified implementation as seen for hardware-based BFD. It does 26 not restrict an implementation from supporting more intervals in 27 addition to the Common intervals. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on February 17, 2015. 51 Copyright Notice 53 Copyright (c) 2014 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 2. The problem with few supported intervals . . . . . . . . . . 3 70 3. Well-defined, common intervals . . . . . . . . . . . . . . . 4 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 76 7.2. Informative References . . . . . . . . . . . . . . . . . 5 77 Appendix A. Why some intervals are in the common set . . . . . . 5 78 Appendix B. Timer adjustment with non-identical interval sets . 6 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 81 1. Introduction 83 The standard [RFC5880] describes how to calculate the transmission 84 interval and the detection time. It does not make any statement 85 though how to solve a situation where one BFD speaker cannot support 86 the calculated value. In practice this may not been a problem as 87 long as software-implemented timers have been used and as long as the 88 granularity of such timers was small compared to the interval values 89 being supported, i.e. as long as the error in the timer interval was 90 small compared to 25 percent jitter. 92 In the meantime requests exist for very fast interval values, down to 93 3.3msec for MPLS-TP. At the same time the requested scale for the 94 number of BFD sessions is increasing. Both requirements have driven 95 vendors to use Network Processors (NP), FPGAs or other hardware-based 96 solutions to offload the periodic packet transmission and the timeout 97 detection in the receive direction. A potential problem with this 98 hardware-based BFD is the granularity of the interval timers. 99 Depending on the implementation only a few intervals may be 100 supported, which can cause interoperability problems. This document 101 proposes a set of interval values that should be supported by all 102 implementations. Details are laid out in the following sections. 104 2. The problem with few supported intervals 106 Let's assume vendor "A" supports 10msec, 100msec and 1sec interval 107 timers in hardware. Vendor "B" supports every value from 20msec 108 onward, with a granularity of 1msec. For a BFD session "A" tries to 109 set up the session with 10msec while "B" uses 20msec as the value for 110 RequiredMinRxInterval and DesiredMinTxInterval. [RFC5880] describes 111 that the negotiated value for Rx and Tx is 20msec. But system "A" is 112 not able to support this. Multiple ways exist to resolve the dilemma 113 but none of them is without problems. 115 a. Realizing that it cannot support 20msec, system "A" sends out a 116 new BFD packet, advertising the next larger interval of 100msec 117 with RequiredMinRxInterval and DesiredMinTxInterval. The new 118 negotiated interval between "A" and "B" then is 100msec, which is 119 supported by both systems. The problem though is that we moved 120 from the 10/20msec range to 100msec, which has far deviated from 121 operator expectations. 123 b. System "A" could violate [RFC5880] and use the 10msec interval 124 for the Tx direction. In the receive direction it could use an 125 adjusted multiplier value M' = 2 * M to match the correct 126 detection time. Now beside the fact that we explicitly violate 127 [RFC5880] there may be the problem that system "B" drops up to 128 50% of the packets; this could be the case when "B" uses an 129 ingress rate policer to protect itself and the policer would be 130 programmed with an expectation of 20msec receive intervals. 132 The example above could be worse when we assume that system "B" can 133 only support a few timer values itself. Let's assume "B" supports 134 "20msec", "300msec" and "1sec". If both systems would adjust their 135 advertised intervals, then the adjustment ends at 1sec. The example 136 above could even be worse when we assume that system "B" can only 137 support "50msec", "500msec" and "2sec". Even if both systems walk 138 their supported intervals, the two systems will never be able to 139 agree on a interval to run any BFD sessions. 141 3. Well-defined, common intervals 143 The problem can be reduced by defining interval values that are 144 supported by all implementations. Then the adjustment mechanism 145 could find a commonly supported interval without deviating too much 146 from the original request. 148 In technical terms the requirement is as follows: a BFD 149 implementation SHOULD support all values in the set of Common 150 interval values which are equal to or larger than the fastest, i.e. 151 lowest, interval the particular BFD implementation supports. 153 The proposed set of Common interval values is: 3.3msec, 10msec, 154 20msec, 50msec, 100msec and 1sec. 156 In addition support for 10sec interval together with multiplier 157 values up to 255 is recommended to support graceful restart. 159 The adjustment is always towards larger, i.e. slower, interval values 160 when the initial interval proposed by the peer is not supported. 162 This document is not adding new requirements with respect to the 163 precision with which a timer value must be implemented. Supporting 164 an interval value means to advertise this value in the 165 DesiredMinTxInterval and/or RequiredMinRxInterval field of the BFD 166 packets and to provide timers that are reasonably close. [RFC5880] 167 defines safety margins for the timers by defining a jitter range. 169 How is the "Common interval set" used exactly? In the example above, 170 vendor "A" has a fastest interval of 10msec and thus would be 171 required to support all intervals in the common set that are equal or 172 larger than 10msec, i.e. it would support 10msec, 20msec, 50msec, 173 100msec, 1sec. Vendor "B" has a fastest interval of 20msec and thus 174 would need to support 20msec, 50msec, 100msec and 1sec. As long as 175 this requirement is met for the common set of values, then both 176 vendor "A" and "B" are free to support additional values outside of 177 the common set. 179 4. IANA Considerations 181 No request to IANA. 183 5. Security Considerations 185 This document does not introduce any additional security concerns. 186 The security considerations described in the BFD documents, [RFC5880] 187 and others, apply to devices implementing the BFD protocol, 188 regardless of whether or not the common interval set is implemented. 190 6. Acknowledgements 192 We would like to thank Sylvain Masse and Anca Zamfir for bringing up 193 the discussion about the Poll sequence, and Jeffrey Haas helped 194 finding the fine line between "exact" and "pedantic". 196 7. References 198 7.1. Normative References 200 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 201 Requirement Levels", BCP 14, RFC 2119, March 1997. 203 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 204 (BFD)", RFC 5880, June 2010. 206 7.2. Informative References 208 [G.8013_Y.1731] 209 ITU-T G.8013/Y.1731, "ITU-T OAM functions and mechanisms 210 for Ethernet based network", November 2013. 212 [GR-253-CORE] 213 Telcordia Technologies, Inc., "Synchronous Optical Network 214 (SONET) Transport Systems: Common Generic Criteria", 215 October 2009. 217 Appendix A. Why some intervals are in the common set 219 The list of common interval values is trying to balance various 220 objectives. The list should not contain too many values as more 221 timers may increase the implementation costs. On the other hand less 222 values produces larger gaps and adjustment jumps. More values in the 223 lower interval range is thus seen as critical to support customer 224 needs for fast detection in setups with multiple vendors. 226 o 3.3msec: required by MPLS-TP, adopting the detection time of 227 10msec from [GR-253-CORE]. 229 o 10msec: general consensus is to support 10msec. Multiple vendors 230 plan to or do already implement 10msec. 232 o 20msec: basically avoids a larger gap in this critical interval 233 region. Still allows 50-60msec detect and restore (with 234 multiplier of 2) and covers existing software-based 235 implementations. 237 o 50msec: widely deployed interval. Supporting this value reflects 238 reality of many BFD implementations today. 240 o 100msec: similar to 10msec this value allows the reuse of 241 [G.8013_Y.1731] implementations, especially hardware. It allows 242 to support large scale of 9 x 100msec setups and would be a 243 replacement for 3 x 300msec configurations used by customers to 244 have a detection time slightly below 1sec for VoIP setups. 246 o 1sec: as mentioned in [RFC5880]. While the interval for Down 247 packets can be 1sec or larger this draft proposes to use exactly 248 1sec to avoid interoperability issues. 250 The proposed value for large intervals is 10sec, allowing for a 251 timeout of 42.5 minutes with a multiplier of 255. This value is kept 252 outside the common interval set as it is not required for normal BFD 253 operations, which occur in the sub-second range. Instead the 254 expected usage is for graceful restart, if needed. 256 Appendix B. Timer adjustment with non-identical interval sets 258 [RFC5880] implicitly assumes that a BFD implementation can support 259 any timer value equal or above the advertised value. When a BFD 260 speaker starts a poll sequence then the peer must reply with the 261 Final (F) bit set and adjust the transmit and detection timers 262 accordingly. With contiguous software-based timers this is a valid 263 assumption. Even in the case of a small number of supported interval 264 values this assumption holds when both BFD speakers support exactly 265 the same interval values. 267 But what happens when both speakers support intervals that are not 268 supported by the peer? An example is router "A" supporting the 269 common interval set plus 200msec while router "B" support the common 270 intervals plus 300msec. Assume both routers are configured and run 271 at 50msec. Now router A is configured for 200msec. We know the 272 result must be that both BFD speaker use 1sec timers but how do they 273 reach this endpoint? 275 First router A is sending a packet with 200msec. The P bit is set 276 according to [RFC5880]. The Tx timer stays at 50msec, the detection 277 timer is 3 * 200msec: 279 (A) DesiredTx: 200msec, MinimumRx: 200msec, P-bit 280 Tx: 50msec , Detect: 3 * 200msec 282 Router B now must reply with an F bit. The problem is B is 283 confirming timer values which it cannot support. The only setting to 284 avoid a session flap would be 285 (B) DesiredTx: 300msec, MinimumRx: 300msec, F-bit 286 Tx: 50msec , Detect: 3 * 300msec 288 immediately followed by a P-bit packet as the advertised timer values 289 have been changed: 291 (B) DesiredTx: 300msec, MinimumRx: 300msec, P-bit 292 Tx: 50msec , Detect: 3 * 300msec 294 This is not exactly what [RFC5880] states in section 6.8.7 about the 295 transmission rate. On the other hand as we will see this state does 296 not last for long. Router A would adjust its timers based on the 297 received Final bit 299 (A) Tx: 200msec , Detect: 3 * 1sec 301 Router A is not supporting the proposed 300msec and would use 1sec 302 instead for the detection time. It would then respond to the 303 received Poll sequence from router B, using 1sec as router A does not 304 support the Max(200msec, 300msec): 306 (A) DesiredTx: 1sec, MinimumRx: 1sec, F-bit 307 Tx: 200msec , Detect: 3 * 1sec 309 followed by its own Poll sequence as the advertised timer values have 310 been changed: 312 (A) DesiredTx: 1sec, MinimumRx: 1sec, P-bit 313 Tx: 200msec , Detect: 3 * 1sec 315 Router B would adjust its timers based on the received Final 317 (B) Tx: 300msec , Detect: 3 * 1sec 319 and would then reply to the Poll sequence from router A: 321 (B) DesiredTx: 300msec, MinimumRx: 300msec, F-bit 322 Tx: 1sec , Detect: 3 * 1sec 324 which finally makes router A adjusting its timers: 326 (A) Tx: 1sec , Detect: 3 * 1sec 328 In other words router A and B go through multiple poll sequences 329 until they reach a commonly supported interval value. Reaching such 330 a value is guaranteed by this draft. 332 Authors' Addresses 334 Nobo Akiya 335 Cisco Systems 337 Email: nobo@cisco.com 339 Marc Binderberger 340 Cisco Systems 342 Email: mbinderb@cisco.com 344 Greg Mirsky 345 Ericsson 347 Email: gregory.mirsky@ericsson.com