idnits 2.17.1 draft-akiya-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 (November 13, 2013) is 3817 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: May 17, 2014 November 13, 2013 7 Standardized interval support in BFD 8 draft-akiya-bfd-intervals-04 10 Abstract 12 This document defines a set of interval values that we call "Standard 13 intervals". Values of this set must be supported for transmitting 14 BFD control packets and for calculating the detection time in the 15 receive direction when the value is equal or larger than the fastest, 16 i.e. lowest, interval a particular BFD implementation supports. 18 This solves the problem of finding an interval value that both BFD 19 speakers can support while allowing a simplified implementation as 20 seen for hardware-based BFD. It does not restrict an implementation 21 from supporting more intervals in addition to the Standard intervals. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 17, 2014. 46 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. The problem with few supported intervals . . . . . . . . . . . 3 65 3. Well-defined, standardized intervals . . . . . . . . . . . . . 4 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 69 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 70 Appendix A. Why some intervals are in the standard set . . . . . . 5 71 Appendix B. Timer adjustment with non-identical interval sets . . 6 72 Appendix C. Open/upcoming topics . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 The standard [RFC5880] describes how to calculate the transmission 78 interval and the detection time. It does not make any statement 79 though how so solve a situation where one BFD speaker cannot support 80 the calculated value. In practice this may not been a problem as 81 long as software-implemented timers have been used and as long as the 82 granularity of such timers was small compared to the interval values 83 being supported, i.e. as long as the error in the timer interval was 84 small compared to 25 percent jitter. 86 In the meantime requests exist for very fast interval values, down to 87 3.3msec for MPLS-TP. At the same time the requested scale for the 88 number of BFD sessions in increasing. Both requirements have driven 89 vendors to use Network Processors (NP), FPGAs or other hardware-based 90 solutions to offload the periodic packet transmission and the timeout 91 detection in the receive direction. A potential problem with this 92 hardware-based BFD is the granularity of the interval timers. 93 Depending on the implementation only a few intervals may be 94 supported, which can cause interoperability problems. This document 95 proposes a set of interval values that must be supported by all 96 implementations. Details are laid out in the following sections. 98 2. The problem with few supported intervals 100 Lets assume vendor "A" supports 10msec, 100msec and 1sec interval 101 timers in hardware. Vendor "B" supports every value from 20msec 102 onward, with a granularity of 1msec. For a BFD session "A" tries to 103 set up the session with 10msec while "B" uses 20msec as the value for 104 RequiredMinRxInterval and DesiredMinTxInterval. RFC5880 describes 105 that the negotiated value for Rx and Tx is 20msec. But system "A" is 106 not able to support this. Multiple ways exist to resolve the dilemma 107 but none of them is without problems. 109 a. Realizing that it cannot support 20msec, system "A" sends out a 110 new BFD packet, advertising the next larger interval of 100msec 111 with RequiredMinRxInterval and DesiredMinTxInterval. The new 112 negotiated interval between "A" and "B" then is 100msec, which is 113 supported by both systems. The problem though is that we moved 114 from the 10/20msec range to 100msec, which has far deviated from 115 operator expectations. 117 b. System "A" could violate RFC5880 and use the 10msec interval for 118 the Tx direction. In the receive direction it could use an 119 adjusted multiplier value M' = 2 * M to match the correct 120 detection time. Now beside the fact that we explicitly violate 121 RFC5880 there may be the problem that system "B" drops up to 50% 122 of the packets; this could be the case when "B" uses an ingress 123 rate policer to protect itself and the policer would be 124 programmed with an expectation of 20msec receive intervals. 126 The example above could be worse when we assume that system "B" can 127 only support a few timer values itself. Lets assume "B" supports 128 "20msec", "300msec" and "1sec". If both systems would adjust their 129 advertised intervals, then the adjustment ends at 1sec. The example 130 above could even be worse when we assume that system "B" can only 131 support "50msec", "500msec" and "2sec". Even if both systems walk 132 their supported intervals, the two systems will never be able to 133 agree on a interval to run any BFD sessions. 135 3. Well-defined, standardized intervals 137 The problem can be reduced by defining interval values that are 138 supported by all implementations. Then the adjustment mechanism 139 could find a commonly supported interval without deviating too much 140 from the original request. 142 In technical terms the requirement is as follows: a BFD 143 implementation MUST support all values in the set of Standard 144 interval values which are equal to or larger than the fastest, i.e. 145 lowest, interval the particular BFD implementation supports. 147 The proposed set of Standard interval values is: 3.3msec, 10msec, 148 20msec, 50msec, 300msec and 1sec. 150 The adjustment is always towards larger, i.e. slower, interval values 151 when the initial interval proposed by the peer is not supported. 153 This document is not adding new requirements with respect to how 154 exact a timer value must be implemented. Supporting an interval 155 value means to advertise this value in the DesiredMinTxInterval 156 and/or RequiredMinRxInterval field of the BFD packets and to provide 157 timers that are reasonably close. RFC5880 defines safety margins for 158 the timers by defining a jitter range. 160 How is the "Standard interval set" used exactly? In the example 161 above, vendor "A" has a fastest interval of 10msec and thus would be 162 required to support all intervals in the standard set that are equal 163 or larger than 10msec, i.e. it would support 10msec, 20msec, 50msec, 164 300msec, 1sec. Vendor "B" has a fastest interval of 20msec and thus 165 would need to support 20msec, 50msec, 300msec and 1sec. As long as 166 this requirement is met for the standard set of values, then both 167 vendor "A" and "B" are free to support additional values outside of 168 the standard set. 170 4. IANA Considerations 172 No request to IANA. 174 5. Security Considerations 176 This document does not introduce any additional security issues and 177 the security mechanisms defined in [RFC5880] apply in this document. 179 6. Acknowledgements 181 We would like to thank Sylvain Masse and Anca Zamfir for bringing up 182 the discussion about the Poll sequence. Jeffrey Haas helped finding 183 the fine line between "exact" and "pedantic". 185 7. Normative References 187 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 188 Requirement Levels", BCP 14, RFC 2119, March 1997. 190 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 191 (BFD)", RFC 5880, June 2010. 193 Appendix A. Why some intervals are in the standard set 195 The list of standard interval values is trying to balance various 196 objectives. The list should not contain too many values as more 197 timers may increase the implementation costs. On the other hand less 198 values produces larger gaps and adjustment jumps. Larger values in 199 the lower interval range may be easier to support, potentially even 200 in software instead of hardware. 202 o 3.3msec: required by MPLS-TP 204 o 10msec and 20msec: both values allow to detect faster than 50msec, 205 when used with a multiplier of 2 or 3 (for 10msec). A compromise 206 could be a single interval of 15msec. 208 o 50msec: this seems an interval often supported by software 209 implementations, so the assumption here is that for convenience 210 this value should be supported. 212 o 300msec: this would support large scale of 3 x 300msec setups used 213 by customers to have a detection time slightly below 1sec for VoIP 214 setups. 216 o 1sec: as mentioned in RFC5880. While the interval for Down 217 packets can be 1sec or larger this draft proposes to use exactly 218 1sec to avoid interoperability issues. 220 With that stated, one of the primary intention of this first draft is 221 to seek feedback on the number of interval values in the standard set 222 as well as each value. 224 Candidates for larger intervals to be part of the Standard interval 225 set would be 10sec, 1min and 10min. Such larger BFD intervals may be 226 used for BFD graceful restarts. 228 Appendix B. Timer adjustment with non-identical interval sets 230 RFC5880 implicitly assumes that a BFD implementation can support any 231 timer value equal or above the advertised value. When a BFD speaker 232 starts a poll sequence then the peer must reply with the Final (F) 233 bit set and adjust the transmit and detection timers accordingly. 234 With contiguous software-based timers this is a valid assumption. 235 Even in the case of a small number of supported interval values this 236 assumption holds when both BFD speakers support exactly the same 237 interval values. 239 But what happens when both speakers support intervals that are not 240 supported by the peer? An example is router "A" supporting the 241 standard interval set plus 100msec while router "B" support the 242 standard intervals plus 200msec. Assume both routers are configured 243 and run at 50msec. Now router A is configured for 100msec. We know 244 the result must be that both BFD speaker use 300msec timers but how 245 do they reach this endpoint? 247 First router A is sending a packet with 100msec. The P bit is set 248 according to RFC5880. The Tx timer stays at 50msec, the detection 249 timer is 3 * 100msec: 251 (A) DesiredTx: 100msec, MinimumRx: 100msec, P-bit 252 Tx: 50msec , Detect: 3 * 100msec 254 Router B now must reply with an F bit. The problem is B is 255 confirming timer values which it cannot support. The only setting to 256 avoid a session flap would be 258 (B) DesiredTx: 200msec, MinimumRx: 200msec, F-bit 259 Tx: 50msec , Detect: 3 * 200msec 261 immediately followed by a P-bit packet as the advertised timer values 262 have been changed: 264 (B) DesiredTx: 200msec, MinimumRx: 200msec, P-bit 265 Tx: 50msec , Detect: 3 * 200msec 267 This is not exactly what RFC5880 states in section 6.8.7 about the 268 transmission rate. On the other hand as we will see this state does 269 not last for long. Router A would adjust it's timers based on the 270 received Final bit 272 (A) Tx: 100msec , Detect: 3 * 300msec 274 Router A is not supporting the proposed 200msec and would use 300msec 275 instead for the detection time. It would then respond to the 276 received Poll sequence from router B, using 300msec as router A does 277 not support the Max(100msec, 200msec): 279 (A) DesiredTx: 300msec, MinimumRx: 300msec, F-bit 280 Tx: 100msec , Detect: 3 * 300msec 282 followed by it's own Poll sequence as the advertised timer values 283 have been changed: 285 (A) DesiredTx: 300msec, MinimumRx: 300msec, P-bit 286 Tx: 100msec , Detect: 3 * 300msec 288 Router B would adjust it's timers based on the received Final 290 (B) Tx: 200msec , Detect: 3 * 300msec 292 and would then reply to the Poll sequence from router A: 294 (B) DesiredTx: 200msec, MinimumRx: 200msec, F-bit 295 Tx: 300msec , Detect: 3 * 300msec 297 which finally makes router A adjusting it's timers: 299 (A) Tx: 300msec , Detect: 3 * 100msec 301 In other words router A and B go through multiple poll sequences 302 until they reach a commonly supported interval value. Reaching such 303 a value is guaranteed by this draft. 305 Appendix C. Open/upcoming topics 307 As part of the ongoing BFD workgroup effort the following topics may 308 require more discussion and investigation: 310 Alignment of BFD intervals with Y.1731 intervals. Some contradicting 311 requirements. Ethernet OAM intervals do not fit intervals of 312 existing BFD implementations while adding more intervals to the 313 standards set would complicate hardware implementations. 315 Larger interval values. To simplify hardware implementation a 316 question would be if we want to make all the intervals above 1sec 317 part of the standard interval set. 319 Jitter. For the very fast interval of 3.3msec, do we want jitter. 320 Question comes up from hardware teams. 322 Authors' Addresses 324 Nobo Akiya 325 Cisco Systems 327 Email: nobo@cisco.com 329 Marc Binderberger 330 Cisco Systems 332 Email: mbinderb@cisco.com