idnits 2.17.1 draft-ietf-bfd-intervals-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 : ---------------------------------------------------------------------------- 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 (July 27, 2014) is 3560 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: January 28, 2015 G. Mirsky 6 Ericsson 7 July 27, 2014 9 Common Interval Support in BFD 10 draft-ietf-bfd-intervals-02 12 Abstract 14 Some BFD implementations may be restricted to only support several 15 interval values. When such BFD implementations speak to each other, 16 there is a possibility of two sides not being able to find a common 17 interval value to run BFD sessions. 19 This document defines a small set of interval values for BFD that we 20 call "Common intervals", and recommends implementations to support 21 the defined intervals. This solves the problem of finding an 22 interval value that both BFD speakers can support while allowing a 23 simplified implementation as seen for hardware-based BFD. It does 24 not restrict an implementation from supporting more intervals in 25 addition to the Common intervals. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 28, 2015. 50 Copyright Notice 52 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. The problem with few supported intervals . . . . . . . . . . 3 69 3. Well-defined, common intervals . . . . . . . . . . . . . . . 3 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 75 7.2. Informative References . . . . . . . . . . . . . . . . . 5 76 Appendix A. Why some intervals are in the common set . . . . . . 5 77 Appendix B. Timer adjustment with non-identical interval sets . 6 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Introduction 82 The standard [RFC5880] describes how to calculate the transmission 83 interval and the detection time. It does not make any statement 84 though how to solve a situation where one BFD speaker cannot support 85 the calculated value. In practice this may not been a problem as 86 long as software-implemented timers have been used and as long as the 87 granularity of such timers was small compared to the interval values 88 being supported, i.e. as long as the error in the timer interval was 89 small compared to 25 percent jitter. 91 In the meantime requests exist for very fast interval values, down to 92 3.3msec for MPLS-TP. At the same time the requested scale for the 93 number of BFD sessions in increasing. Both requirements have driven 94 vendors to use Network Processors (NP), FPGAs or other hardware-based 95 solutions to offload the periodic packet transmission and the timeout 96 detection in the receive direction. A potential problem with this 97 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 how 163 exact a timer value must be implemented. Supporting an interval 164 value means to advertise this value in the DesiredMinTxInterval and/ 165 or RequiredMinRxInterval field of the BFD packets and to provide 166 timers that are reasonably close. [RFC5880] defines safety margins 167 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 issues. 187 6. Acknowledgements 189 We would like to thank Sylvain Masse and Anca Zamfir for bringing up 190 the discussion about the Poll sequence, and Jeffrey Haas helped 191 finding the fine line between "exact" and "pedantic". 193 7. References 195 7.1. Normative References 197 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 198 Requirement Levels", BCP 14, RFC 2119, March 1997. 200 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 201 (BFD)", RFC 5880, June 2010. 203 7.2. Informative References 205 [G.8013_Y.1731] 206 ITU-T G.8013/Y.1731, "ITU-T OAM functions and mechanisms 207 for Ethernet based network", November 2013. 209 [GR-253-CORE] 210 Telcordia Technologies, Inc., "Synchronous Optical Network 211 (SONET) Transport Systems: Common Generic Criteria", 212 October 2009. 214 Appendix A. Why some intervals are in the common set 216 The list of common interval values is trying to balance various 217 objectives. The list should not contain too many values as more 218 timers may increase the implementation costs. On the other hand less 219 values produces larger gaps and adjustment jumps. More values in the 220 lower interval range is thus seen as critical to support customer 221 needs for fast detection in setups with multiple vendors. 223 o 3.3msec: required by MPLS-TP, adopting the detection time of 224 10msec from [GR-253-CORE]. 226 o 10msec: general consensus is to support 10msec. Multiple vendors 227 plan to or do already implement 10msec. 229 o 20msec: basically avoids a larger gap in this critical interval 230 region. Still allows 50-60msec detect and restore (with 231 multiplier of 2) and covers existing software-based 232 implementations. 234 o 50msec: widely deployed interval. Supporting this value reflects 235 reality of many BFD implementations today. 237 o 100msec: similar to 10msec this value allows the reuse of 238 [G.8013_Y.1731] implementations, especially hardware. It allows 239 to support large scale of 9 x 100msec setups and would be a 240 replacement for 3 x 300msec configurations used by customers to 241 have a detection time slightly below 1sec for VoIP setups. 243 o 1sec: as mentioned in [RFC5880]. While the interval for Down 244 packets can be 1sec or larger this draft proposes to use exactly 245 1sec to avoid interoperability issues. 247 The proposed value for large intervals is 10sec, allowing for a 248 timeout of 42.5 minutes with a multiplier of 255. This value is kept 249 outside the common interval set as it is not required for normal BFD 250 operations, which occur in the sub-second range. Instead the 251 expected usage is for graceful restart, if needed. 253 Appendix B. Timer adjustment with non-identical interval sets 255 [RFC5880] implicitly assumes that a BFD implementation can support 256 any timer value equal or above the advertised value. When a BFD 257 speaker starts a poll sequence then the peer must reply with the 258 Final (F) bit set and adjust the transmit and detection timers 259 accordingly. With contiguous software-based timers this is a valid 260 assumption. Even in the case of a small number of supported interval 261 values this assumption holds when both BFD speakers support exactly 262 the same interval values. 264 But what happens when both speakers support intervals that are not 265 supported by the peer? An example is router "A" supporting the 266 common interval set plus 200msec while router "B" support the common 267 intervals plus 300msec. Assume both routers are configured and run 268 at 50msec. Now router A is configured for 200msec. We know the 269 result must be that both BFD speaker use 1sec timers but how do they 270 reach this endpoint? 272 First router A is sending a packet with 200msec. The P bit is set 273 according to [RFC5880]. The Tx timer stays at 50msec, the detection 274 timer is 3 * 200msec: 276 (A) DesiredTx: 200msec, MinimumRx: 200msec, P-bit 277 Tx: 50msec , Detect: 3 * 200msec 279 Router B now must reply with an F bit. The problem is B is 280 confirming timer values which it cannot support. The only setting to 281 avoid a session flap would be 283 (B) DesiredTx: 300msec, MinimumRx: 300msec, F-bit 284 Tx: 50msec , Detect: 3 * 300msec 286 immediately followed by a P-bit packet as the advertised timer values 287 have been changed: 289 (B) DesiredTx: 300msec, MinimumRx: 300msec, P-bit 290 Tx: 50msec , Detect: 3 * 300msec 292 This is not exactly what [RFC5880] states in section 6.8.7 about the 293 transmission rate. On the other hand as we will see this state does 294 not last for long. Router A would adjust its timers based on the 295 received Final bit 297 (A) Tx: 200msec , Detect: 3 * 1sec 299 Router A is not supporting the proposed 300msec and would use 1sec 300 instead for the detection time. It would then respond to the 301 received Poll sequence from router B, using 1sec as router A does not 302 support the Max(200msec, 300msec): 304 (A) DesiredTx: 1sec, MinimumRx: 1sec, F-bit 305 Tx: 200msec , Detect: 3 * 1sec 307 followed by its own Poll sequence as the advertised timer values have 308 been changed: 310 (A) DesiredTx: 1sec, MinimumRx: 1sec, P-bit 311 Tx: 200msec , Detect: 3 * 1sec 313 Router B would adjust its timers based on the received Final 315 (B) Tx: 300msec , Detect: 3 * 1sec 317 and would then reply to the Poll sequence from router A: 319 (B) DesiredTx: 300msec, MinimumRx: 300msec, F-bit 320 Tx: 1sec , Detect: 3 * 1sec 322 which finally makes router A adjusting its timers: 324 (A) Tx: 1sec , Detect: 3 * 1sec 326 In other words router A and B go through multiple poll sequences 327 until they reach a commonly supported interval value. Reaching such 328 a value is guaranteed by this draft. 330 Authors' Addresses 332 Nobo Akiya 333 Cisco Systems 335 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