doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc7419.txt b/doc/rfc/rfc7419.txt
new file mode 100644
index 0000000..fec548c
--- /dev/null
+++ b/doc/rfc/rfc7419.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          N. Akiya
+Request for Comments: 7419                               M. Binderberger
+Updates: 5880                                              Cisco Systems
+Category: Informational                                        G. Mirsky
+ISSN: 2070-1721                                                 Ericsson
+                                                           December 2014
+
+
+     Common Interval Support in Bidirectional Forwarding Detection
+
+Abstract
+
+   Bidirectional Forwarding Detection (BFD) requires that messages be
+   transmitted at regular intervals and provides a way to negotiate the
+   interval used by BFD peers.  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 value for the interval to run
+   BFD sessions.
+
+   This document updates RFC 5880 by defining a small set of interval
+   values for BFD that we call "Common Intervals" and recommends
+   implementations to support the defined intervals.  This solves the
+   problem of finding an interval value that both BFD speakers can
+   support while allowing a simplified implementation as seen for
+   hardware-based BFD.  It does not restrict an implementation from
+   supporting more intervals in addition to the Common Intervals.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7419.
+
+
+
+
+
+
+
+
+Akiya, et al.                 Informational                     [Page 1]
+
+RFC 7419             Common Interval Support in BFD        December 2014
+
+
+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  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  The Problem with Few Supported Intervals  . . . . . . . . . .   3
+   3.  Well-Defined, Common Intervals  . . . . . . . . . . . . . . .   4
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
+   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
+     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
+     5.2.  Informative References  . . . . . . . . . . . . . . . . .   5
+   Appendix A.  Why Some Values Are in the Common Interval Set . . .   6
+   Appendix B.  Timer Adjustment with Non-identical Interval Sets  .   6
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8
+
+1.  Introduction
+
+   The Bidirectional Forwarding Detection (BFD) standard [RFC5880]
+   describes how to calculate the transmission interval and the
+   detection time.  However, it does not make any statement about how to
+   solve a situation where one BFD speaker cannot support the calculated
+   value.  In practice, this may not have been a problem as long as
+   software-implemented timers were 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 small
+   compared to 25 percent jitter.
+
+   In the meantime, requests exist for very fast interval values, down
+   to 3.3 msec for the MPLS Transport Profile (MPLS-TP).  At the same
+   time, the requested scale for the number of BFD sessions is
+   increasing.  Both requirements have driven vendors to use Network
+   Processors (NP), Field Programmable Gate Arrays (FPGAs), or other
+   hardware-based solutions to offload the periodic packet transmission
+   and the timeout detection in the receive direction.  A potential
+
+
+
+Akiya, et al.                 Informational                     [Page 2]
+
+RFC 7419             Common Interval Support in BFD        December 2014
+
+
+   problem with this hardware-based BFD is the granularity of the
+   interval timers.  Depending on the implementation, only a few
+   intervals may be supported, which can cause interoperability
+   problems.  This document proposes a set of interval values that
+   should be supported by all implementations.  Details are laid out in
+   the following sections.
+
+2.  The Problem with Few Supported Intervals
+
+   Let's assume vendor "A" supports 10 msec, 100 msec, and 1 sec
+   interval timers in hardware, and vendor "B" supports every value from
+   20 msec onward, with a granularity of 1 msec.  For a BFD session, "A"
+   tries to set up the session with 10 msec while "B" uses 20 msec as
+   the value for RequiredMinRxInterval and DesiredMinTxInterval.  Rx and
+   Tx are negotiated as described in [RFC5880], which is 20 msec in this
+   case.  However, system "A" is not able to support the 20 msec
+   interval timer.  Multiple ways exist to resolve the dilemma, but none
+   of them is without problems.
+
+   a.  Realizing that it cannot support 20 msec, system "A" sends out a
+       new BFD packet advertising the next larger interval of 100 msec
+       with RequiredMinRxInterval and DesiredMinTxInterval.  The new
+       negotiated interval between "A" and "B" is then 100 msec, which
+       is supported by both systems.  However, the problem is that we
+       moved from the 10/20 msec range to 100 msec, which has far
+       deviated from operator expectations.
+
+   b.  System "A" could violate [RFC5880] and use the 10 msec interval
+       for the Tx direction.  In the receive direction, it could use an
+       adjusted multiplier value M' = 2 * M to match the correct
+       detection time.  Now, in addition to the fact that we explicitly
+       violate [RFC5880], there may be the problem that system "B" drops
+       up to 50% of the packets; this could be the case when "B" uses an
+       ingress rate policer to protect itself and the policer would be
+       programmed with an expectation of 20 msec receive intervals.
+
+   The example above could be worse when we assume that system "B" can
+   only support a few timer values itself.  Let's assume "B" supports 20
+   msec, 300 msec, and 1 sec.  If both systems would adjust their
+   advertised intervals, then the adjustment ends at 1 sec.  The example
+   above could even be worse when we assume that system "B" can only
+   support 50 msec, 500 msec, and 2 sec.  Even if both systems walk
+   through all of their supported intervals, the two systems will never
+   be able to agree on an interval to run any BFD sessions.
+
+
+
+
+
+
+
+Akiya, et al.                 Informational                     [Page 3]
+
+RFC 7419             Common Interval Support in BFD        December 2014
+
+
+3.  Well-Defined, Common Intervals
+
+   The problem can be reduced by defining interval values that are
+   supported by all implementations.  Then, the adjustment mechanism
+   could find a commonly supported interval without deviating too much
+   from the original request.
+
+   In technical terms, the requirement is as follows: a BFD
+   implementation should support all values in the set of Common
+   Interval values that are equal to or larger than the fastest (i.e.,
+   lowest) interval the particular BFD implementation supports.
+
+   This document defines the set of Common Interval values to be: 3.3
+   msec, 10 msec, 20 msec, 50 msec, 100 msec, and 1 sec.
+
+   In addition, both a 10 sec interval and multiplier values up to 255
+   are 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 the
+   precision with which a timer value must be implemented.  Supporting
+   an interval value means advertising this value in the
+   DesiredMinTxInterval and/or RequiredMinRxInterval field of the BFD
+   packets and providing 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 10 msec and thus would be
+   required to support all intervals in the Common Interval set that are
+   equal or larger than 10 msec, i.e., it would support 10 msec, 20
+   msec, 50 msec, 100 msec, and 1 sec.  Vendor "B" has a fastest
+   interval of 20 msec and thus would need to support 20 msec, 50 msec,
+   100 msec, and 1 sec.  As long as this requirement is met for the
+   common set of values, then both vendor "A" and "B" are free to
+   support additional values outside of the Common Interval set.
+
+4.  Security Considerations
+
+   This document does not introduce any additional security concerns.
+   The security considerations described in the BFD documents, [RFC5880]
+   and others, apply to devices implementing the BFD protocol,
+   regardless of whether or not the Common Interval set is implemented.
+
+
+
+
+
+
+Akiya, et al.                 Informational                     [Page 4]
+
+RFC 7419             Common Interval Support in BFD        December 2014
+
+
+5.  References
+
+5.1.  Normative References
+
+   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
+              (BFD)", RFC 5880, June 2010,
+              <http://www.rfc-editor.org/info/rfc5880>.
+
+5.2.  Informative References
+
+   [G.8013_Y.1731]
+              International Telecommunications Union, "OAM functions and
+              mechanisms for Ethernet based networks", ITU-T
+              Recommendation G.8013/Y.1731, November 2013.
+
+   [GR-253-CORE]
+              Telcordia Technologies, Inc., "Synchronous Optical Network
+              (SONET) Transport Systems: Common Generic Criteria",
+              GR-253-CORE Issue 05, October 2009.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Akiya, et al.                 Informational                     [Page 5]
+
+RFC 7419             Common Interval Support in BFD        December 2014
+
+
+Appendix A.  Why Some Values Are in the Common Interval 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,
+   fewer values produces larger gaps and adjustment jumps.  More values
+   in the lower interval range are thus seen as critical to support
+   customer needs for fast detection in setups with multiple vendors.
+
+   o  3.3 msec: required by MPLS-TP, to support the defect detection
+      time of 10 msec from [GR-253-CORE].
+
+   o  10 msec: general consensus is to support 10 msec.  Multiple
+      vendors plan to or do already implement 10 msec.
+
+   o  20 msec: basically avoids a larger gap in this critical interval
+      region.  Still allows 50-60 msec detect and restore (with
+      multiplier of 2) and covers existing software-based
+      implementations.
+
+   o  50 msec: widely deployed interval.  Supporting this value reflects
+      the reality of many BFD implementations today.
+
+   o  100 msec: similar to 10 msec, this value allows the reuse of
+      [G.8013_Y.1731] implementations, especially hardware.  It supports
+      a large number of 100 msec sessions with multiplier 9 (9 x 100
+      msec), which could be replacing of 3 x 300 msec configurations
+      used by customers to have a detection time slightly below 1 sec
+      for VoIP setups.
+
+   o  1 sec: as mentioned in [RFC5880].  While the interval for Down
+      packets can be 1 sec or larger, this document recommends use of
+      exactly 1 sec to avoid interoperability issues.
+
+   The recommended value for large intervals is 10 sec, allowing for a
+   timeout of 42.5 minutes with a multiplier of 255.  This value is kept
+   outside the Common Interval set, as it is not required for normal BFD
+   operations that occur in the sub-second range.  Instead, the expected
+   usage is for graceful restart, if needed.
+
+Appendix B.  Timer Adjustment with Non-identical Interval Sets
+
+   [RFC5880] implicitly assumes that a BFD implementation can support
+   any timer value equal to or above the advertised value.  When a BFD
+   speaker starts a Poll Sequence, then the peer must reply with the
+   Final (F) bit set and adjust the transmit and detection timers
+   accordingly.  With contiguous software-based timers, this is a valid
+   assumption.  Even in the case of a small number of supported interval
+
+
+
+Akiya, et al.                 Informational                     [Page 6]
+
+RFC 7419             Common Interval Support in BFD        December 2014
+
+
+   values, this assumption holds when both BFD speakers support exactly
+   the same interval values.
+
+   But what happens when both speakers support intervals that are not
+   supported by the peer?  An example is router "A" supporting the
+   Common Interval set plus 200 msec, while router "B" supports the
+   Common Intervals plus 300 msec.  Assume both routers are configured
+   and run at 50 msec.  Now, router A is configured for 200 msec.  We
+   know the result must be that both BFD speakers use 1 sec timers, but
+   how do they reach this endpoint?
+
+   First, router A sends a packet with 200 msec.  The P bit is set
+   according to [RFC5880].  The Tx timer stays at 50 msec, the detection
+   timer is 3 * 200 msec:
+
+      (A) DesiredTx: 200 msec, MinimumRx: 200 msec, P-bit
+      Tx: 50 msec, Detect: 3 * 200 msec
+
+   Router B now must reply with an F bit.  The problem is B is
+   confirming timer values that it cannot support.  The only setting to
+   avoid a session flap would be
+
+      (B) DesiredTx: 300 msec, MinimumRx: 300 msec, F-bit
+      Tx: 50 msec, Detect: 3 * 300 msec
+
+   immediately followed by a P-bit packet, as the advertised timer
+   values have been changed:
+
+      (B) DesiredTx: 300 msec, MinimumRx: 300 msec, P-bit
+      Tx: 50 msec, Detect: 3 * 300 msec
+
+   This is not exactly what Section 6.8.7 of [RFC5880] states about the
+   transmission rate.  On the other hand, as we will see, this state
+   does not last for long.  Router A would adjust its timers based on
+   the received Final bit:
+
+      (A) Tx: 200 msec, Detect: 3 * 1 sec
+
+   Router A is not supporting the proposed 300 msec and would use 1 sec
+   instead for the detection time.  It would then respond to the
+   received Poll Sequence from router B using 1 sec, as router A does
+   not support the Max(200 msec, 300 msec):
+
+      (A) DesiredTx: 1 sec, MinimumRx: 1 sec, F-bit
+      Tx: 200 msec, Detect: 3 * 1 sec
+
+
+
+
+
+
+Akiya, et al.                 Informational                     [Page 7]
+
+RFC 7419             Common Interval Support in BFD        December 2014
+
+
+   followed by its own Poll Sequence, as the advertised timer values
+   have been changed:
+
+      (A) DesiredTx: 1 sec, MinimumRx: 1 sec, P-bit
+      Tx: 200 msec, Detect: 3 * 1 sec
+
+   Router B would adjust its timers based on the received Final bit
+
+      (B) Tx: 300 msec , Detect: 3 * 1 sec
+
+   and would then reply to the Poll Sequence from router A:
+
+      (B) DesiredTx: 300 msec, MinimumRx: 300 msec, F-bit
+      Tx: 1 sec, Detect: 3 * 1 sec
+
+   which finally makes router A adjust its timers:
+
+      (A) Tx: 1 sec, Detect: 3 * 1 sec
+
+   In other words, router A and B go through multiple Poll Sequences
+   until they reach a commonly supported interval value.  Reaching such
+   a value is guaranteed by this document.
+
+Acknowledgments
+
+   We would like to thank Sylvain Masse and Anca Zamfir for bringing up
+   the discussion about the Poll Sequence, and Jeffrey Haas for helping
+   find the fine line between "exact" and "pedantic".
+
+Authors' Addresses
+
+   Nobo Akiya
+   Cisco Systems
+
+   EMail: nobo@cisco.com
+
+
+   Marc Binderberger
+   Cisco Systems
+
+   EMail: mbinderb@cisco.com
+
+
+   Greg Mirsky
+   Ericsson
+
+   EMail: gregory.mirsky@ericsson.com
+
+
+
+
+Akiya, et al.                 Informational                     [Page 8]
+