Skip to main content

Common Interval Support in Bidirectional Forwarding Detection
draft-ietf-bfd-intervals-05

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    bfd mailing list <rtg-bfd@ietf.org>,
    bfd chair <bfd-chairs@tools.ietf.org>
Subject: Document Action: 'Common Interval Support in Bidirectional Forwarding Detection' to Informational RFC (draft-ietf-bfd-intervals-05.txt)

The IESG has approved the following document:
- 'Common Interval Support in Bidirectional Forwarding Detection'
  (draft-ietf-bfd-intervals-05.txt) as Informational RFC

This document is the product of the Bidirectional Forwarding Detection
Working Group.

The IESG contact persons are Adrian Farrel and Alia Atlas.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-bfd-intervals/


Ballot Text

Technical Summary

   Bidirectional Forwarding Detection (BFD) requires that messages are
   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 defines 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.

Working Group Summary:

   Discussion in the working group among known implementers of BFD 
   was relatively quiet but supportive of this document.  The only
   discussion that generated any significant amount of "noise" was the
   discussion of whether these well known common intervals should
   have an IANA registry to permit the maintenance of this document
   without requiring a RFC revision.  The consensus of that discussion
   was that an IANA registry was not desired.

Document Quality:

   Multiple implementations support the full range of documented values
   in either hardware or software, depending on the implementation.
   The only value that doesn't have very wide support is the 3.3ms value,
   but support for this value seems to be becoming more common.

Personnel:

   Document Shepherd: Jeffrey Haas
   Responsible Area Director: Adrian Farrel

RFC Editor Note