idnits 2.17.1 draft-ietf-bfd-intervals-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: ---------------------------------------------------------------------------- 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 (June 11, 2014) is 3605 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: December 13, 2014 G. Mirsky 6 Ericsson 7 June 11, 2014 9 Common Interval Support in BFD 10 draft-ietf-bfd-intervals-01 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 December 13, 2014. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. The problem with few supported intervals . . . . . . . . . . . 3 69 3. Well-defined, common intervals . . . . . . . . . . . . . . . . 4 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . . 8 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. 98 Depending on the implementation only a few intervals may be 99 supported, which can cause interoperability problems. This document 100 proposes a set of interval values that should be supported by all 101 implementations. Details are laid out in the following sections. 103 2. The problem with few supported intervals 105 Let's assume vendor "A" supports 10msec, 100msec and 1sec interval 106 timers in hardware. Vendor "B" supports every value from 20msec 107 onward, with a granularity of 1msec. For a BFD session "A" tries to 108 set up the session with 10msec while "B" uses 20msec as the value for 109 RequiredMinRxInterval and DesiredMinTxInterval. [RFC5880] describes 110 that the negotiated value for Rx and Tx is 20msec. But system "A" is 111 not able to support this. Multiple ways exist to resolve the dilemma 112 but none of them is without problems. 114 a. Realizing that it cannot support 20msec, system "A" sends out a 115 new BFD packet, advertising the next larger interval of 100msec 116 with RequiredMinRxInterval and DesiredMinTxInterval. The new 117 negotiated interval between "A" and "B" then is 100msec, which is 118 supported by both systems. The problem though is that we moved 119 from the 10/20msec range to 100msec, which has far deviated from 120 operator expectations. 122 b. System "A" could violate [RFC5880] and use the 10msec interval 123 for the Tx direction. In the receive direction it could use an 124 adjusted multiplier value M' = 2 * M to match the correct 125 detection time. Now beside the fact that we explicitly violate 126 [RFC5880] there may be the problem that system "B" drops up to 127 50% of the packets; this could be the case when "B" uses an 128 ingress rate policer to protect itself and the policer would be 129 programmed with an expectation of 20msec receive intervals. 131 The example above could be worse when we assume that system "B" can 132 only support a few timer values itself. Let's assume "B" supports 133 "20msec", "300msec" and "1sec". If both systems would adjust their 134 advertised intervals, then the adjustment ends at 1sec. The example 135 above could even be worse when we assume that system "B" can only 136 support "50msec", "500msec" and "2sec". Even if both systems walk 137 their supported intervals, the two systems will never be able to 138 agree on a interval to run any BFD sessions. 140 3. Well-defined, common intervals 142 The problem can be reduced by defining interval values that are 143 supported by all implementations. Then the adjustment mechanism 144 could find a commonly supported interval without deviating too much 145 from the original request. 147 In technical terms the requirement is as follows: a BFD 148 implementation SHOULD support all values in the set of Common 149 interval values which are equal to or larger than the fastest, i.e. 150 lowest, interval the particular BFD implementation supports. 152 The proposed set of Common interval values is: 3.3msec, 10msec, 153 20msec, 50msec, 100msec and 1sec. 155 In addition support for 10sec interval together with multiplier 156 values up to 255 is recommended to support graceful restart. 158 The adjustment is always towards larger, i.e. slower, interval values 159 when the initial interval proposed by the peer is not supported. 161 This document is not adding new requirements with respect to how 162 exact a timer value must be implemented. Supporting an interval 163 value means to advertise this value in the DesiredMinTxInterval 164 and/or RequiredMinRxInterval field of the BFD packets and to provide 165 timers that are reasonably close. [RFC5880] defines safety margins 166 for the timers by defining a jitter range. 168 How is the "Common interval set" used exactly? In the example above, 169 vendor "A" has a fastest interval of 10msec and thus would be 170 required to support all intervals in the common set that are equal or 171 larger than 10msec, i.e. it would support 10msec, 20msec, 50msec, 172 100msec, 1sec. Vendor "B" has a fastest interval of 20msec and thus 173 would need to support 20msec, 50msec, 100msec and 1sec. As long as 174 this requirement is met for the common set of values, then both 175 vendor "A" and "B" are free to support additional values outside of 176 the common set. 178 4. IANA Considerations 180 No request to IANA. 182 5. Security Considerations 184 This document does not introduce any additional security issues. 186 6. Acknowledgements 188 We would like to thank Sylvain Masse and Anca Zamfir for bringing up 189 the discussion about the Poll sequence, and Jeffrey Haas helped 190 finding the fine line between "exact" and "pedantic". 192 7. References 194 7.1. Normative References 196 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 197 Requirement Levels", BCP 14, RFC 2119, March 1997. 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 Appendix A. Why some intervals are in the common set 210 The list of common interval values is trying to balance various 211 objectives. The list should not contain too many values as more 212 timers may increase the implementation costs. On the other hand less 213 values produces larger gaps and adjustment jumps. More values in the 214 lower interval range is thus seen as critical to support customer 215 needs for fast detection in setups with multiple vendors. 217 o 3.3msec: required by MPLS-TP 219 o 10msec: general consensus is to support 10msec. 221 o 20msec: basically avoids a larger gap in this critical interval 222 region. Still allows 50-60msec detect and restore (with 223 multiplier of 2) and covers existing software-based 224 implementations. 226 o 50msec: widely deployed interval. Supporting this value reflects 227 reality of many BFD implementations today. 229 o 100msec: similar to 10msec this value allows the reuse of 230 [G.8013_Y.1731] implementations, especially hardware. It allows 231 to support large scale of 9 x 100msec setups and would be a 232 replacement for 3 x 300msec configurations used by customers to 233 have a detection time slightly below 1sec for VoIP setups. 235 o 1sec: as mentioned in [RFC5880]. While the interval for Down 236 packets can be 1sec or larger this draft proposes to use exactly 237 1sec to avoid interoperability issues. 239 The proposed value for large intervals is 10sec, allowing for a 240 timeout of 42.5 minutes with a multiplier of 255. This value is kept 241 outside the common interval set as it is not required for normal BFD 242 operations, which occur in the sub-second range. Instead the 243 expected usage is for graceful restart, if needed. 245 Appendix B. Timer adjustment with non-identical interval sets 247 [RFC5880] implicitly assumes that a BFD implementation can support 248 any timer value equal or above the advertised value. When a BFD 249 speaker starts a poll sequence then the peer must reply with the 250 Final (F) bit set and adjust the transmit and detection timers 251 accordingly. With contiguous software-based timers this is a valid 252 assumption. Even in the case of a small number of supported interval 253 values this assumption holds when both BFD speakers support exactly 254 the same interval values. 256 But what happens when both speakers support intervals that are not 257 supported by the peer? An example is router "A" supporting the 258 common interval set plus 200msec while router "B" support the common 259 intervals plus 300msec. Assume both routers are configured and run 260 at 50msec. Now router A is configured for 200msec. We know the 261 result must be that both BFD speaker use 1sec timers but how do they 262 reach this endpoint? 263 First router A is sending a packet with 200msec. The P bit is set 264 according to [RFC5880]. The Tx timer stays at 50msec, the detection 265 timer is 3 * 200msec: 267 (A) DesiredTx: 200msec, MinimumRx: 200msec, P-bit 268 Tx: 50msec , Detect: 3 * 200msec 270 Router B now must reply with an F bit. The problem is B is 271 confirming timer values which it cannot support. The only setting to 272 avoid a session flap would be 274 (B) DesiredTx: 300msec, MinimumRx: 300msec, F-bit 275 Tx: 50msec , Detect: 3 * 300msec 277 immediately followed by a P-bit packet as the advertised timer values 278 have been changed: 280 (B) DesiredTx: 300msec, MinimumRx: 300msec, P-bit 281 Tx: 50msec , Detect: 3 * 300msec 283 This is not exactly what [RFC5880] states in section 6.8.7 about the 284 transmission rate. On the other hand as we will see this state does 285 not last for long. Router A would adjust its timers based on the 286 received Final bit 288 (A) Tx: 200msec , Detect: 3 * 1sec 290 Router A is not supporting the proposed 300msec and would use 1sec 291 instead for the detection time. It would then respond to the 292 received Poll sequence from router B, using 1sec as router A does not 293 support the Max(200msec, 300msec): 295 (A) DesiredTx: 1sec, MinimumRx: 1sec, F-bit 296 Tx: 200msec , Detect: 3 * 1sec 298 followed by its own Poll sequence as the advertised timer values have 299 been changed: 301 (A) DesiredTx: 1sec, MinimumRx: 1sec, P-bit 302 Tx: 200msec , Detect: 3 * 1sec 304 Router B would adjust its timers based on the received Final 306 (B) Tx: 300msec , Detect: 3 * 1sec 308 and would then reply to the Poll sequence from router A: 310 (B) DesiredTx: 300msec, MinimumRx: 300msec, F-bit 311 Tx: 1sec , Detect: 3 * 1sec 313 which finally makes router A adjusting its timers: 315 (A) Tx: 1sec , Detect: 3 * 1sec 317 In other words router A and B go through multiple poll sequences 318 until they reach a commonly supported interval value. Reaching such 319 a value is guaranteed by this draft. 321 Authors' Addresses 323 Nobo Akiya 324 Cisco Systems 326 Email: nobo@cisco.com 328 Marc Binderberger 329 Cisco Systems 331 Email: mbinderb@cisco.com 333 Greg Mirsky 334 Ericsson 336 Email: gregory.mirsky@ericsson.com