--- 1/draft-ietf-bfd-intervals-01.txt 2014-07-27 14:14:31.030804765 -0700 +++ 2/draft-ietf-bfd-intervals-02.txt 2014-07-27 14:14:31.050805256 -0700 @@ -1,20 +1,20 @@ Internet Engineering Task Force N. Akiya Internet-Draft M. Binderberger Intended status: Informational Cisco Systems -Expires: December 13, 2014 G. Mirsky +Expires: January 28, 2015 G. Mirsky Ericsson - June 11, 2014 + July 27, 2014 Common Interval Support in BFD - draft-ietf-bfd-intervals-01 + draft-ietf-bfd-intervals-02 Abstract Some BFD implementations may be restricted to only support several interval values. When such BFD implementations speak to each other, there is a possibility of two sides not being able to find a common interval value to run BFD sessions. This document defines a small set of interval values for BFD that we call "Common intervals", and recommends implementations to support @@ -23,66 +23,66 @@ simplified implementation as seen for hardware-based BFD. It does not restrict an implementation from supporting more intervals in addition to the Common intervals. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. -Status of this Memo +Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 13, 2014. + This Internet-Draft will expire on January 28, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. The problem with few supported intervals . . . . . . . . . . . 3 - 3. Well-defined, common intervals . . . . . . . . . . . . . . . . 4 - 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 - 7.2. Informative References . . . . . . . . . . . . . . . . . . 5 - Appendix A. Why some intervals are in the common set . . . . . . . 5 - Appendix B. Timer adjustment with non-identical interval sets . . 6 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. The problem with few supported intervals . . . . . . . . . . 3 + 3. Well-defined, common intervals . . . . . . . . . . . . . . . 3 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 + 7.2. Informative References . . . . . . . . . . . . . . . . . 5 + Appendix A. Why some intervals are in the common set . . . . . . 5 + Appendix B. Timer adjustment with non-identical interval sets . 6 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction The standard [RFC5880] describes how to calculate the transmission interval and the detection time. It does not make any statement though how to solve a situation where one BFD speaker cannot support the calculated value. In practice this may not been a problem as long as software-implemented timers have been used and as long as the granularity of such timers was small compared to the interval values being supported, i.e. as long as the error in the timer interval was @@ -153,22 +154,22 @@ 20msec, 50msec, 100msec and 1sec. In addition support for 10sec interval together with multiplier values up to 255 is recommended to support graceful restart. The adjustment is always towards larger, i.e. slower, interval values when the initial interval proposed by the peer is not supported. This document is not adding new requirements with respect to how exact a timer value must be implemented. Supporting an interval - value means to advertise this value in the DesiredMinTxInterval - and/or RequiredMinRxInterval field of the BFD packets and to provide + value means to advertise this value in the DesiredMinTxInterval and/ + or RequiredMinRxInterval field of the BFD packets and to provide timers that are reasonably close. [RFC5880] defines safety margins for the timers by defining a jitter range. How is the "Common interval set" used exactly? In the example above, vendor "A" has a fastest interval of 10msec and thus would be required to support all intervals in the common set that are equal or larger than 10msec, i.e. it would support 10msec, 20msec, 50msec, 100msec, 1sec. Vendor "B" has a fastest interval of 20msec and thus would need to support 20msec, 50msec, 100msec and 1sec. As long as this requirement is met for the common set of values, then both @@ -198,32 +199,39 @@ [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010. 7.2. Informative References [G.8013_Y.1731] ITU-T G.8013/Y.1731, "ITU-T OAM functions and mechanisms for Ethernet based network", November 2013. + [GR-253-CORE] + Telcordia Technologies, Inc., "Synchronous Optical Network + (SONET) Transport Systems: Common Generic Criteria", + October 2009. + Appendix A. Why some intervals are in the common set The list of common interval values is trying to balance various objectives. The list should not contain too many values as more timers may increase the implementation costs. On the other hand less values produces larger gaps and adjustment jumps. More values in the lower interval range is thus seen as critical to support customer needs for fast detection in setups with multiple vendors. - o 3.3msec: required by MPLS-TP + o 3.3msec: required by MPLS-TP, adopting the detection time of + 10msec from [GR-253-CORE]. - o 10msec: general consensus is to support 10msec. + o 10msec: general consensus is to support 10msec. Multiple vendors + plan to or do already implement 10msec. o 20msec: basically avoids a larger gap in this critical interval region. Still allows 50-60msec detect and restore (with multiplier of 2) and covers existing software-based implementations. o 50msec: widely deployed interval. Supporting this value reflects reality of many BFD implementations today. o 100msec: similar to 10msec this value allows the reuse of