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