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