draft-ietf-bfd-intervals-03.txt   draft-ietf-bfd-intervals-04.txt 
Internet Engineering Task Force N. Akiya Internet Engineering Task Force N. Akiya
Internet-Draft M. Binderberger Internet-Draft M. Binderberger
Intended status: Informational Cisco Systems Intended status: Informational Cisco Systems
Expires: February 17, 2015 G. Mirsky Expires: March 6, 2015 G. Mirsky
Ericsson Ericsson
August 16, 2014 September 2, 2014
Common Interval Support in BFD Common Interval Support in Bidirectional Forwarding Detection
draft-ietf-bfd-intervals-03 draft-ietf-bfd-intervals-04
Abstract Abstract
BFD requires that messages are transmitted at regular intervals and Bidirectional Forwarding Detection (BFD) requires that messages are
provides a way to negotiate the interval used by BFD peers. Some BFD transmitted at regular intervals and provides a way to negotiate the
implementations may be restricted to only support several interval interval used by BFD peers. Some BFD implementations may be
values. When such BFD implementations speak to each other, there is restricted to only support several interval values. When such BFD
a possibility of two sides not being able to find a common interval implementations speak to each other, there is a possibility of two
value to run BFD sessions. sides not being able to find a common value for the interval to run
BFD sessions.
This document defines a small set of interval values for BFD that we This document defines a small set of interval values for BFD that we
call "Common intervals", and recommends implementations to support call "Common Intervals", and recommends implementations to support
the defined intervals. This solves the problem of finding an the defined intervals. This solves the problem of finding an
interval value that both BFD speakers can support while allowing a interval value that both BFD speakers can support while allowing a
simplified implementation as seen for hardware-based BFD. It does simplified implementation as seen for hardware-based BFD. It does
not restrict an implementation from supporting more intervals in not restrict an implementation from supporting more intervals in
addition to the Common intervals. addition to the Common Intervals.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. 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 This Internet-Draft is submitted in full conformance with the
skipping to change at page 2, line 4 skipping to change at page 2, line 6
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 17, 2015.
This Internet-Draft will expire on March 6, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The problem with few supported intervals . . . . . . . . . . 3 2. The problem with few supported intervals . . . . . . . . . . 3
3. Well-defined, common intervals . . . . . . . . . . . . . . . 4 3. Well-defined, Common Intervals . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . 5
Appendix A. Why some intervals are in the common set . . . . . . 5 Appendix A. Why some values are in the Common Interval set . . . 5
Appendix B. Timer adjustment with non-identical interval sets . 6 Appendix B. Timer adjustment with non-identical interval sets . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
The standard [RFC5880] describes how to calculate the transmission The Bidirectional Forwarding Detection (BFD) standard [RFC5880]
interval and the detection time. It does not make any statement describes how to calculate the transmission interval and the
though how to solve a situation where one BFD speaker cannot support detection time. It does not make any statement though how to solve a
the calculated value. In practice this may not been a problem as situation where one BFD speaker cannot support the calculated value.
long as software-implemented timers have been used and as long as the In practice this may not been a problem as long as software-
granularity of such timers was small compared to the interval values implemented timers have been used and as long as the granularity of
being supported, i.e. as long as the error in the timer interval was such timers was small compared to the interval values being
small compared to 25 percent jitter. 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 In the meantime requests exist for very fast interval values, down to
3.3msec for MPLS-TP. At the same time the requested scale for the 3.3msec for MPLS-TP. At the same time the requested scale for the
number of BFD sessions is increasing. Both requirements have driven number of BFD sessions is increasing. Both requirements have driven
vendors to use Network Processors (NP), FPGAs or other hardware-based vendors to use Network Processors (NP), FPGAs or other hardware-based
solutions to offload the periodic packet transmission and the timeout solutions to offload the periodic packet transmission and the timeout
detection in the receive direction. A potential problem with this detection in the receive direction. A potential problem with this
hardware-based BFD is the granularity of the interval timers. hardware-based BFD is the granularity of the interval timers.
Depending on the implementation only a few intervals may be Depending on the implementation only a few intervals may be
supported, which can cause interoperability problems. This document supported, which can cause interoperability problems. This document
skipping to change at page 4, line 5 skipping to change at page 4, line 5
The example above could be worse when we assume that system "B" can 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 only support a few timer values itself. Let's assume "B" supports
"20msec", "300msec" and "1sec". If both systems would adjust their "20msec", "300msec" and "1sec". If both systems would adjust their
advertised intervals, then the adjustment ends at 1sec. The example advertised intervals, then the adjustment ends at 1sec. The example
above could even be worse when we assume that system "B" can only above could even be worse when we assume that system "B" can only
support "50msec", "500msec" and "2sec". Even if both systems walk support "50msec", "500msec" and "2sec". Even if both systems walk
their supported intervals, the two systems will never be able to their supported intervals, the two systems will never be able to
agree on a interval to run any BFD sessions. agree on a interval to run any BFD sessions.
3. Well-defined, common intervals 3. Well-defined, Common Intervals
The problem can be reduced by defining interval values that are The problem can be reduced by defining interval values that are
supported by all implementations. Then the adjustment mechanism supported by all implementations. Then the adjustment mechanism
could find a commonly supported interval without deviating too much could find a commonly supported interval without deviating too much
from the original request. from the original request.
In technical terms the requirement is as follows: a BFD In technical terms the requirement is as follows: a BFD
implementation SHOULD support all values in the set of Common implementation SHOULD support all values in the set of Common
interval values which are equal to or larger than the fastest, i.e. Interval values which are equal to or larger than the fastest, i.e.
lowest, interval the particular BFD implementation supports. lowest, interval the particular BFD implementation supports.
The proposed set of Common interval values is: 3.3msec, 10msec, The proposed set of Common Interval values is: 3.3msec, 10msec,
20msec, 50msec, 100msec and 1sec. 20msec, 50msec, 100msec and 1sec.
In addition support for 10sec interval together with multiplier In addition support for 10sec interval together with multiplier
values up to 255 is recommended to support graceful restart. values up to 255 is recommended to support graceful restart.
The adjustment is always towards larger, i.e. slower, interval values The adjustment is always towards larger, i.e. slower, interval values
when the initial interval proposed by the peer is not supported. when the initial interval proposed by the peer is not supported.
This document is not adding new requirements with respect to the This document is not adding new requirements with respect to the
precision with which a timer value must be implemented. Supporting precision with which a timer value must be implemented. Supporting
an interval value means to advertise this value in the an interval value means to advertise this value in the
DesiredMinTxInterval and/or RequiredMinRxInterval field of the BFD DesiredMinTxInterval and/or RequiredMinRxInterval field of the BFD
packets and to provide timers that are reasonably close. [RFC5880] packets and to provide timers that are reasonably close. [RFC5880]
defines safety margins for the timers by defining a jitter range. defines safety margins for the timers by defining a jitter range.
How is the "Common interval set" used exactly? In the example above, How is the "Common Interval" set used exactly? In the example above,
vendor "A" has a fastest interval of 10msec and thus would be 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 required to support all intervals in the Common Interval set that are
larger than 10msec, i.e. it would support 10msec, 20msec, 50msec, equal or larger than 10msec, i.e. it would support 10msec, 20msec,
100msec, 1sec. Vendor "B" has a fastest interval of 20msec and thus 50msec, 100msec, 1sec. Vendor "B" has a fastest interval of 20msec
would need to support 20msec, 50msec, 100msec and 1sec. As long as and thus would need to support 20msec, 50msec, 100msec and 1sec. As
this requirement is met for the common set of values, then both long as this requirement is met for the common set of values, then
vendor "A" and "B" are free to support additional values outside of both vendor "A" and "B" are free to support additional values outside
the common set. of the Common Interval set.
4. IANA Considerations 4. IANA Considerations
RFC Ed.: RFC-editor please remove this section
No request to IANA. No request to IANA.
5. Security Considerations 5. Security Considerations
This document does not introduce any additional security concerns. This document does not introduce any additional security concerns.
The security considerations described in the BFD documents, [RFC5880] The security considerations described in the BFD documents, [RFC5880]
and others, apply to devices implementing the BFD protocol, and others, apply to devices implementing the BFD protocol,
regardless of whether or not the common interval set is implemented. regardless of whether or not the Common Interval set is implemented.
6. Acknowledgements 6. Acknowledgements
We would like to thank Sylvain Masse and Anca Zamfir for bringing up We would like to thank Sylvain Masse and Anca Zamfir for bringing up
the discussion about the Poll sequence, and Jeffrey Haas helped the discussion about the Poll sequence, and Jeffrey Haas helped
finding the fine line between "exact" and "pedantic". finding the fine line between "exact" and "pedantic".
7. References 7. References
7.1. Normative References 7.1. Normative References
skipping to change at page 5, line 32 skipping to change at page 5, line 39
[G.8013_Y.1731] [G.8013_Y.1731]
ITU-T G.8013/Y.1731, "ITU-T OAM functions and mechanisms ITU-T G.8013/Y.1731, "ITU-T OAM functions and mechanisms
for Ethernet based network", November 2013. for Ethernet based network", November 2013.
[GR-253-CORE] [GR-253-CORE]
Telcordia Technologies, Inc., "Synchronous Optical Network Telcordia Technologies, Inc., "Synchronous Optical Network
(SONET) Transport Systems: Common Generic Criteria", (SONET) Transport Systems: Common Generic Criteria",
October 2009. October 2009.
Appendix A. Why some intervals are in the common set Appendix A. Why some values are in the Common Interval set
The list of common interval values is trying to balance various The list of Common Interval values is trying to balance various
objectives. The list should not contain too many values as more objectives. The list should not contain too many values as more
timers may increase the implementation costs. On the other hand less timers may increase the implementation costs. On the other hand less
values produces larger gaps and adjustment jumps. More values in the values produces larger gaps and adjustment jumps. More values in the
lower interval range is thus seen as critical to support customer lower interval range is thus seen as critical to support customer
needs for fast detection in setups with multiple vendors. needs for fast detection in setups with multiple vendors.
o 3.3msec: required by MPLS-TP, adopting the detection time of o 3.3msec: required by MPLS-TP, adopting the detection time of
10msec from [GR-253-CORE]. 10msec from [GR-253-CORE].
o 10msec: general consensus is to support 10msec. Multiple vendors o 10msec: general consensus is to support 10msec. Multiple vendors
skipping to change at page 6, line 20 skipping to change at page 6, line 25
to support large scale of 9 x 100msec setups and would be a to support large scale of 9 x 100msec setups and would be a
replacement for 3 x 300msec configurations used by customers to replacement for 3 x 300msec configurations used by customers to
have a detection time slightly below 1sec for VoIP setups. have a detection time slightly below 1sec for VoIP setups.
o 1sec: as mentioned in [RFC5880]. While the interval for Down o 1sec: as mentioned in [RFC5880]. While the interval for Down
packets can be 1sec or larger this draft proposes to use exactly packets can be 1sec or larger this draft proposes to use exactly
1sec to avoid interoperability issues. 1sec to avoid interoperability issues.
The proposed value for large intervals is 10sec, allowing for a The proposed value for large intervals is 10sec, allowing for a
timeout of 42.5 minutes with a multiplier of 255. This value is kept 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 outside the Common Interval set as it is not required for normal BFD
operations, which occur in the sub-second range. Instead the operations, which occur in the sub-second range. Instead the
expected usage is for graceful restart, if needed. expected usage is for graceful restart, if needed.
Appendix B. Timer adjustment with non-identical interval sets Appendix B. Timer adjustment with non-identical interval sets
[RFC5880] implicitly assumes that a BFD implementation can support [RFC5880] implicitly assumes that a BFD implementation can support
any timer value equal or above the advertised value. When a BFD any timer value equal or above the advertised value. When a BFD
speaker starts a poll sequence then the peer must reply with the speaker starts a poll sequence then the peer must reply with the
Final (F) bit set and adjust the transmit and detection timers Final (F) bit set and adjust the transmit and detection timers
accordingly. With contiguous software-based timers this is a valid accordingly. With contiguous software-based timers this is a valid
assumption. Even in the case of a small number of supported interval assumption. Even in the case of a small number of supported interval
values this assumption holds when both BFD speakers support exactly values this assumption holds when both BFD speakers support exactly
the same interval values. the same interval values.
But what happens when both speakers support intervals that are not But what happens when both speakers support intervals that are not
supported by the peer? An example is router "A" supporting the supported by the peer? An example is router "A" supporting the
common interval set plus 200msec while router "B" support the common Common Interval set plus 200msec while router "B" support the Common
intervals plus 300msec. Assume both routers are configured and run Intervals plus 300msec. Assume both routers are configured and run
at 50msec. Now router A is configured for 200msec. We know the at 50msec. Now router A is configured for 200msec. We know the
result must be that both BFD speaker use 1sec timers but how do they result must be that both BFD speaker use 1sec timers but how do they
reach this endpoint? reach this endpoint?
First router A is sending a packet with 200msec. The P bit is set First router A is sending a packet with 200msec. The P bit is set
according to [RFC5880]. The Tx timer stays at 50msec, the detection according to [RFC5880]. The Tx timer stays at 50msec, the detection
timer is 3 * 200msec: timer is 3 * 200msec:
(A) DesiredTx: 200msec, MinimumRx: 200msec, P-bit (A) DesiredTx: 200msec, MinimumRx: 200msec, P-bit
Tx: 50msec , Detect: 3 * 200msec Tx: 50msec , Detect: 3 * 200msec
 End of changes. 22 change blocks. 
41 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/