Skip to main content

Bidirectional Forwarding Detection (BFD)
RFC 5880

Revision differences

Document history

Date Rev. By Action
2020-01-21
11 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2019-02-04
Jenny Bui Posted related IPR disclosure: Juniper's Statement about IPR related to draft-ietf-bfd-base
2015-10-14
11 (System) Notify list changed from bfd-chairs@ietf.org, draft-ietf-bfd-base@ietf.org to (None)
2012-08-22
11 (System) post-migration administrative database adjustment to the No Objection position for Pasi Eronen
2012-08-22
11 (System) post-migration administrative database adjustment to the No Objection position for Alexey Melnikov
2012-08-22
11 (System) post-migration administrative database adjustment to the Yes position for Adrian Farrel
2012-08-22
11 (System) post-migration administrative database adjustment to the No Objection position for Lars Eggert
2012-08-22
11 (System) post-migration administrative database adjustment to the No Objection position for Ross Callon
2012-08-22
11 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2010-10-06
(System)
Posted related IPR disclosure: Tellabs Oy's Statement about IPR related to RFC 5880, RFC 5881, RFC 5882, RFC 5883, and RFC …
Posted related IPR disclosure: Tellabs Oy's Statement about IPR related to RFC 5880, RFC 5881, RFC 5882, RFC 5883, and RFC 5884
2010-06-01
11 Cindy Morgan State Changes to RFC Published from RFC Ed Queue by Cindy Morgan
2010-06-01
11 Cindy Morgan [Note]: 'RFC 5880' added by Cindy Morgan
2010-06-01
11 (System) RFC published
2010-03-30
11 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2010-03-30
11 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2010-03-30
11 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-03-30
11 (System) IANA Action state changed to Waiting on Authors from In Progress
2010-03-23
11 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2010-03-23
11 (System) IANA Action state changed to In Progress
2010-03-23
11 Amy Vezza IESG state changed to Approved-announcement sent
2010-03-23
11 Amy Vezza IESG has approved the document
2010-03-23
11 Amy Vezza Closed "Approve" ballot
2010-03-23
11 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2010-03-21
11 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to Yes from No Objection by Adrian Farrel
2010-03-21
11 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss by Adrian Farrel
2010-03-12
11 Ross Callon [Ballot Position Update] Position for Ross Callon has been changed to No Objection from Discuss by Ross Callon
2010-02-04
(System) Posted related IPR disclosure: Juniper's Statement of IPR related to draft-ietf-bfd-base-11
2010-02-04
(System) Posted related IPR disclosure: Cisco's Statement of IPR relating to draft-ietf-bfd-base-11
2010-01-25
11 Adrian Farrel
[Ballot discuss]
This Discuss is a place holder to ensure that process is completed with respect to all IPR disclosures not just those that Ross …
[Ballot discuss]
This Discuss is a place holder to ensure that process is completed with respect to all IPR disclosures not just those that Ross notes in his Discuss.

It appears that there are two related disclosures in the system
https://datatracker.ietf.org/ipr/516/ (Nortel 2005-01-06)
https://datatracker.ietf.org/ipr/1143/ (Juniper 2009-05-07)

The first of these was in place when working group and IETF last calls were held, but does not appear to have been flagged. The second is more recent.

It is my intention to pursue the disclosures Ross refers to and then to ensure that the WG and the wider community are consulted.
2010-01-25
11 Adrian Farrel
[Ballot discuss]
This Discuss is a place holder to ensure that process is completed with respect to all IPR disclosures not just those that Ross …
[Ballot discuss]
This Discuss is a place holder to ensure that process is completed with respect to all IPR disclosures not just those that Ross notes in his Discuss.

It appears that there are two related disclosures in the system
https://datatracker.ietf.org/ipr/516/ (Nortel 2005-01-06)
https://datatracker.ietf.org/ipr/1143/ (Juniper 2009-05-07)

The first of these was in place when working group and IETF last calls were held, but does not appear to have been flagged. The second is more recent.

It is my intention to pursue the disclosures Ross refers to and then to ensure that the WG and the wider community are consulted.
2010-01-25
11 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to Discuss from Yes by Adrian Farrel
2010-01-25
11 Ross Callon
[Ballot discuss]
It is possible that there might be an IPR statement forthcoming. This discuss is just here until this is cleared up (one way …
[Ballot discuss]
It is possible that there might be an IPR statement forthcoming. This discuss is just here until this is cleared up (one way or another).
2010-01-25
11 Ross Callon [Ballot Position Update] Position for Ross Callon has been changed to Discuss from Yes by Ross Callon
2010-01-15
11 Adrian Farrel [Ballot Position Update] New position, Yes, has been recorded by Adrian Farrel
2010-01-15
11 Adrian Farrel [Note]: 'Adrian has taken over as responsible AD to avoid a single company having an excessive presence with this I-D' added by Adrian Farrel
2010-01-15
11 Adrian Farrel Responsible AD has been changed to Adrian Farrel from Ross Callon
2010-01-15
11 Pasi Eronen [Ballot comment]
2010-01-15
11 Pasi Eronen
[Ballot discuss]
The "secret-suffix" (or "append-only") method for authenticated
MD5/SHA1 has known problems, and that's why most IETF protocols use
HMAC.

However, the security requirements …
[Ballot discuss]
The "secret-suffix" (or "append-only") method for authenticated
MD5/SHA1 has known problems, and that's why most IETF protocols use
HMAC.

However, the security requirements for this protocol are rather
unusual, since we're basically interested in "liveness" rather than
authentication of some content (and loss of packets moves us to "down"
state) -- so having a weak MAC construction could be acceptable
(but there needs to be text describing why it was done this way).

It would help if the security considerations section had slightly more
text about the threats, and what threats are mitigated by the security
mechanisms (authentication section and GTSM), and what threats still
exist (this is probably quite obvious to the authors -- but in that
case, writing it down should be easy). Also, the Echo function should
be mentioned somewhere here.
2010-01-15
11 Pasi Eronen [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Discuss by Pasi Eronen
2010-01-14
11 (System) New version available: draft-ietf-bfd-base-11.txt
2010-01-07
11 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert
2010-01-06
11 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss by Alexey Melnikov
2010-01-05
11 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-01-05
10 (System) New version available: draft-ietf-bfd-base-10.txt
2009-05-07
(System) Posted related IPR disclosure: Juniper's Statement of IPR related to draft-ietf-bfd-base-08
2009-04-08
11 Alexey Melnikov
[Ballot discuss]
Carrying over DISCUSS from Chris Newman:

Section 4.2

If password is human enterred text string, you need to state a charset
and any …
[Ballot discuss]
Carrying over DISCUSS from Chris Newman:

Section 4.2

If password is human enterred text string, you need to state a charset
and any sort of mandatory-to-implement preparation.  BCP 18 mandates
use of UTF-8 unless you request a variance (that we require a restart of
IETF last call). We have two choices on the standards track for
mandatory-to-implement preparation of human enterred text used for this
sort of security purposes (e.g. SASLprep / RFC 4013 or Net-Unicode / RFC
5198
).  We do not have a BCP that requires preparation so I'm not going
to hold a discuss over the preparation issue but I recommend you fix it.
There is not likely to be a significant change to net unicode, but there
may be a significant change to SASLprep in the future.  However,
SASLprep will have someone better interoperability for non-ASCII
password characters.

While you could make the password binary so charset issues do not apply,
that's only reasonable if there's a way to bootstrap the binary
password.  If it really is human enterred, as it is with WEP and WPA,
then the WPA approach (where it's a human enterred password rather than
a human enterred hex string -- but some implementations found that user
hostile and invented a non-interoperable string-to-key as a result) has
proved to be more interoperable in practice, IMHO.

Section 4.3, 4.4

You need to define the key management for these keys.  Are they
passwords configured by humans into config files?  If so, the
charset and canonicalization issues apply.
2009-04-08
11 Alexey Melnikov [Ballot Position Update] New position, Discuss, has been recorded by Alexey Melnikov
2009-03-20
11 Ross Callon State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Ross Callon
2009-03-06
11 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2009-03-05
11 Cullen Jennings [Ballot comment]
support Lars discuss
2009-03-05
11 Chris Newman
[Ballot discuss]
Version 09 did not add new text to address the first issue (charset of
password).

New text was added about key management ruling …
[Ballot discuss]
Version 09 did not add new text to address the first issue (charset of
password).

New text was added about key management ruling it out-of-scope.  That,
by itself, is not sufficient for interoperability.  If keys in an
unspecified format which may or may not be textual, need to be
provisioned in an unspecified fashion, I'm unsure how this will
interoperate.  40-bit WEP took this approach and we got
non-interoperable UIs on different platforms (some require 0x prefix,
some support a text-to-binary on a password, some do not).

---
Section 4.2

If password is human enterred text string, you need to state a charset
and any sort of mandatory-to-implement preparation.  BCP 18 mandates
use of UTF-8 unless you request a variance (that we require a restart of
IETF last call). We have two choices on the standards track for
mandatory-to-implement preparation of human enterred text used for this
sort of security purposes (e.g. SASLprep / RFC 4013 or Net-Unicode / RFC
5198
).  We do not have a BCP that requires preparation so I'm not going
to hold a discuss over the preparation issue but I recommend you fix it.
There is not likely to be a significant change to net unicode, but there
may be a significant change to SASLprep in the future.  However,
SASLprep will have someone better interoperability for non-ASCII
password characters.

While you could make the password binary so charset issues do not apply,
that's only reasonable if there's a way to bootstrap the binary
password.  If it really is human enterred, as it is with WEP and WPA,
then the WPA approach (where it's a human enterred password rather than
a human enterred hex string -- but some implementations found that user
hostile and invented a non-interoperable string-to-key as a result) has
proved to be more interoperable in practice, IMHO.

Section 4.3, 4.4

You need to define the key management for these keys.  Are they
passwords configured by humans into config files?  If so, the
charset and canonicalization issues apply.
2009-02-12
11 Pasi Eronen
[Ballot discuss]
The "secret-suffix" (or "append-only") method for authenticated
MD5/SHA1 has known problems, and that's why most IETF protocols use
HMAC.

However, the security requirements …
[Ballot discuss]
The "secret-suffix" (or "append-only") method for authenticated
MD5/SHA1 has known problems, and that's why most IETF protocols use
HMAC.

However, the security requirements for this protocol are rather
unusual, since we're basically interested in "liveness" rather than
authentication of some content (and loss of packets moves us to "down"
state) -- so having a weak MAC construction could be acceptable
(but there needs to be text describing why it was done this way).

It would help if the security considerations section had slightly more
text about the threats, and what threats are mitigated by the security
mechanisms (authentication section and GTSM), and what threats still
exist (this is probably quite obvious to the authors -- but in that
case, writing it down should be easy). Also, the Echo function should
be mentioned somewhere here.
2009-02-12
11 Pasi Eronen
[Ballot comment]
In Section 8, values 9-31 (for diagnostic code) and 6-255 (for
authentication types) should be marked as "unassigned", not
"reserved".

Section 8, the …
[Ballot comment]
In Section 8, values 9-31 (for diagnostic code) and 6-255 (for
authentication types) should be marked as "unassigned", not
"reserved".

Section 8, the table of BFD Authentication Types still talks about
diagnostic codes in the column header.

Section 10.2: RFC 2434 has been obsoleted by 5226
2009-02-05
11 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-02-05
09 (System) New version available: draft-ietf-bfd-base-09.txt
2008-06-05
11 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan
2008-06-05
11 Pasi Eronen
[Ballot discuss]
The "secret-suffix" (or "append-only") method for authenticated
MD5/SHA1 has known problems, and that's why most IETF protocols use
HMAC.

However, the security requirements …
[Ballot discuss]
The "secret-suffix" (or "append-only") method for authenticated
MD5/SHA1 has known problems, and that's why most IETF protocols use
HMAC.

However, the security requirements for this protocol are rather
unusual, since we're basically interested in "liveness" rather than
authentication of some content (and loss of packets moves us to "down"
state) -- so having a weak MAC construction could be acceptable
(but there needs to be text describing why it was done this way).

It would help if the security considerations section had slightly more
text about the threats, and what threats are mitigated by the security
mechanisms (authentication section and GTSM), and what threats still
exist (this is probably quite obvious to the authors -- but in that
case, writing it down should be easy). Also, the Echo function should
be mentioned somewhere here.

The protocol has several fields where new values could be allocated in
the future, but no description about how that's done (e.g. by IANA or
otherwise) or what the requirements are (e.g. standards track or first
come first served).

From Alexey Melnikov's SecDir review:

The document should explicitly say that the key for MD5 (SHA1) must be
exactly 128 (160) bits (there's no padding or truncation) -- or if
this is not true, describe how padding/truncation/whatever is done.
2008-06-05
11 Pasi Eronen [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen
2008-06-05
11 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2008-06-05
11 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2008-06-05
11 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2008-06-05
11 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2008-06-05
11 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2008-06-05
11 Chris Newman
[Ballot discuss]
Section 4.2

If password is human enterred text string, you need to state a charset
and any sort of mandatory-to-implement preparation.  BCP 18 …
[Ballot discuss]
Section 4.2

If password is human enterred text string, you need to state a charset
and any sort of mandatory-to-implement preparation.  BCP 18 mandates
use of UTF-8 unless you request a variance (that we require a restart of
IETF last call). We have two choices on the standards track for
mandatory-to-implement preparation of human enterred text used for this
sort of security purposes (e.g. SASLprep / RFC 4013 or Net-Unicode / RFC
5198
).  We do not have a BCP that requires preparation so I'm not going
to hold a discuss over the preparation issue but I recommend you fix it.
There is not likely to be a significant change to net unicode, but there
may be a significant change to SASLprep in the future.  However,
SASLprep will have someone better interoperability for non-ASCII
password characters.

While you could make the password binary so charset issues do not apply,
that's only reasonable if there's a way to bootstrap the binary
password.  If it really is human enterred, as it is with WEP and WPA,
then the WPA approach (where it's a human enterred password rather than
a human enterred hex string -- but some implementations found that user
hostile and invented a non-interoperable string-to-key as a result) has
proved to be more interoperable in practice, IMHO.

Section 4.3, 4.4

You need to define the key management for these keys.  Are they
passwords configured by humans into config files?  If so, the
charset and canonicalization issues apply.
2008-06-05
11 Chris Newman [Ballot Position Update] New position, Discuss, has been recorded by Chris Newman
2008-06-04
11 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2008-06-04
11 Lars Eggert [Ballot comment]
INTRODUCTION, paragraph 10:
>    Comments on this draft should be directed to rtg-bfd@ietf.org.

  Remove this sentence.
2008-06-04
11 Lars Eggert
[Ballot discuss]
Section 6.8.3., paragraph 0:
> 6.8.3. Timer Manipulation

  DISCUSS: BFD is congestion-unresponsive, i.e., it doesn't react to
  loss by taking load …
[Ballot discuss]
Section 6.8.3., paragraph 0:
> 6.8.3. Timer Manipulation

  DISCUSS: BFD is congestion-unresponsive, i.e., it doesn't react to
  loss by taking load off the path. For many uses of BFD, especially
  ones that it seems to have been specifically designed for, I don't
  have an issue with this approach. For example, using BFD to monitor
  liveness of directly adjacent routers connected through a single link
  can probably be safely achieved by configuring timers based on
  knowledge of the link capacity and delays, such that BFD will not
  consume significant resources. (An addition to the applicability text,
  by the way, that discusses guidelines for this configuration would be
  very helpful IMO.)
 
  But BFD aims to be a generic protocol to detect the liveness between
  components that can be connected via arbitrary means, over paths
  with many hops and unknown traffic loads. When used for such
  purposes, BFD cannot simply punt on congestion control (see RFC2914).

  I see two ways forward: significantly restrict the scope of
  applicability for BFD, or describe a scheme that adapts transmission
  intervals (= transmission rates) based on RTTs and loss rates.
 
  (After writing this, I saw Jari's DISCUSS and I realize we raise similar
  issues.)
2008-06-04
11 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert
2008-06-04
11 Russ Housley
[Ballot comment]
The title page header should indicate that the intended status for
  this document: Proposed Standard.

  Section 4.3 says:
  >
  …
[Ballot comment]
The title page header should indicate that the intended status for
  this document: Proposed Standard.

  Section 4.3 says:
  >
  >  Reserved
  >
  >      This byte must be set to zero on transmit, and ignored on
  > receipt.
  >
  As Spencer Dawkins raised in his Gen-ART Review: s/must/MUST/

  Section 6.6 includes:
  >
  > Note that this mechanism requires that the Detection Time negotiated
  > is greater than the round trip time between the two systems, or the
  > Poll mechanism will always fail.  Enforcement of this requirement is
  > outside the scope of this specification.
  >
  Based on the discussion of the Gen-ART Review by Spencer Dawkins, it
  might be better to say "Enforcing the requirement to meet the
  constraint ...".
2008-06-04
11 Russ Housley
[Ballot discuss]
IANA has questions:

  - Shouldn't you have a registry of Diagnostic codes (section 4.1)?

  - Shouldn't you have a registry of …
[Ballot discuss]
IANA has questions:

  - Shouldn't you have a registry of Diagnostic codes (section 4.1)?

  - Shouldn't you have a registry of Auth Types (section 4.1)?

  If the answer to both questions is "no," we understand this document
  to have NO IANA Actions.

  I'll clear this DISCUSS position when IANA's questions are resolved.
2008-06-04
11 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2008-06-03
11 Lisa Dusseault [Ballot Position Update] Position for Lisa Dusseault has been changed to No Objection from Undefined by Lisa Dusseault
2008-06-03
11 Lisa Dusseault [Ballot Position Update] Position for Lisa Dusseault has been changed to Undefined from No Objection by Lisa Dusseault
2008-06-03
11 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2008-06-03
11 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2008-06-02
11 David Ward [Ballot Position Update] New position, Recuse, has been recorded by David Ward
2008-06-01
11 Ross Callon [Ballot Position Update] New position, Yes, has been recorded for Ross Callon
2008-06-01
11 Ross Callon Ballot has been issued by Ross Callon
2008-06-01
11 Ross Callon Created "Approve" ballot
2008-06-01
11 Ross Callon
Proto writeup by Dave Ward (as WG co-chair and author):

1. Have the chairs personally reviewed this version of the Internet
    Draft (ID), …
Proto writeup by Dave Ward (as WG co-chair and author):

1. Have the chairs personally reviewed this version of the Internet
    Draft (ID), and in particular, do they believe this ID is ready
    to forward to the IESG for publication?

    Yes


  2. Has the document had adequate review from both key WG members and
    key non-WG members?

    Yes. BT had brought together multiple vendors and implementors a year before publishing the docs to make sure every issue was cleared up and intention documented.


    Do you have any concerns about the depth or breadth of the reviews
    that have been performed?
   
    No.


3. Do you have concerns that the document needs more review from a
    particular (broader) perspective (e.g., security, operational
    complexity, someone familiar with AAA, etc.)?

    No


  4. Do you have any specific concerns/issues with this document that
    you believe the ADs and/or IESG should be aware of? For example,
    perhaps you are uncomfortable with certain parts of the document,
    or have concerns whether there really is a need for it. In any
    event, if your issues have been discussed in the WG and the WG has
    indicated it that it still wishes to advance the document, detail
    those concerns in the write-up.

    No concerns


  5. How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with
    others being silent, or does the WG as a whole understand and
    agree with it?

It represents strong consensus of a large group of implementors.


6. Has anyone threatened an appeal or otherwise indicated extreme
    discontent? If so, please summarise the areas of conflict
    in separate email to the Responsible Area Director.

    No


  7. Have the chairs verified that the document adheres to all
    of the ID Checklist items ?

    Yes


8. Is the document split into normative and informative references?
    Are there normative references to IDs, where the IDs are not
    also ready for advancement or are otherwise in an unclear state?
    (note here that the RFC editor will not publish an RFC with 
    normative references to IDs, it will delay publication until all
    such IDs are also ready for publication as RFCs.)

    Yes, No


  9. What is the intended status of the document? (e.g., Proposed
    Standard, Informational?)

    Proposed Standard


10. For Standards Track and BCP documents, the IESG approval
    announcement includes a write-up section with the following 
    sections:

    * Technical Summary:

BFD and the corollary documents define a mechanism for layer 3 forwarding plane failure detection. There are multiple modes (async, echo, demand) for different circumstances. One interesting aspect of BFD is that it has adaptive timers thus, parameters can be modified without tearing down adjacencies. In addition, the amount of BW and overhead incurred by the network and network nodes is completely under the control of the operator.

  * Working Group Summary

There was no opposition to this document.

    * Protocol Quality

The protocol is widely implemented and deployed and has become part of default deployments on the internet. The drafts reflect the lessons learned from the deployed and operation.
2008-05-30
11 Ross Callon Telechat date was changed to 2008-06-05 from 2008-06-19 by Ross Callon
2008-05-30
11 Ross Callon Telechat date was changed to 2008-06-19 from 2008-06-05 by Ross Callon
2008-05-22
11 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Alexey Melnikov.
2008-05-15
11 Ross Callon State Changes to IESG Evaluation from DNP-waiting for AD note by Ross Callon
2008-05-15
11 Ross Callon State Changes to DNP-waiting for AD note from IESG Evaluation by Ross Callon
2008-05-15
11 Ross Callon State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Ross Callon
2008-05-15
11 Ross Callon Placed on agenda for telechat - 2008-06-05 by Ross Callon
2008-05-07
11 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2008-05-02
11 Samuel Weiler Request for Last Call review by SECDIR is assigned to Alexey Melnikov
2008-05-02
11 Samuel Weiler Request for Last Call review by SECDIR is assigned to Alexey Melnikov
2008-05-01
11 Amanda Baber
IANA Last Call comments:

IANA has questions:

- Shouldn't you have a registry of Diagnostic codes (section 4.1)?

- Shouldn't you have a registry of …
IANA Last Call comments:

IANA has questions:

- Shouldn't you have a registry of Diagnostic codes (section 4.1)?

- Shouldn't you have a registry of Auth Types (section 4.1)?

If the answer to both questions is "no," we understand this document
to have NO IANA Actions.
2008-04-23
11 Cindy Morgan Last call sent
2008-04-23
11 Cindy Morgan State Changes to In Last Call from Last Call Requested by Cindy Morgan
2008-04-23
11 Ross Callon Last Call was requested by Ross Callon
2008-04-23
11 Ross Callon State Changes to Last Call Requested from Publication Requested by Ross Callon
2008-04-23
11 (System) Ballot writeup text was added
2008-04-23
11 (System) Last call text was added
2008-04-23
11 (System) Ballot approval text was added
2008-04-16
11 Ross Callon Draft Added by Ross Callon in state Publication Requested
2008-03-24
08 (System) New version available: draft-ietf-bfd-base-08.txt
2008-01-16
07 (System) New version available: draft-ietf-bfd-base-07.txt
2007-03-07
06 (System) New version available: draft-ietf-bfd-base-06.txt
2006-06-14
05 (System) New version available: draft-ietf-bfd-base-05.txt
2005-10-24
04 (System) New version available: draft-ietf-bfd-base-04.txt
2005-07-12
03 (System) New version available: draft-ietf-bfd-base-03.txt
2005-03-22
02 (System) New version available: draft-ietf-bfd-base-02.txt
2005-02-22
01 (System) New version available: draft-ietf-bfd-base-01.txt
2005-01-06
(System) Posted related IPR disclosure: Nortel Networks Statement about IPR claimed in draft-ietf-bfd-base
2004-07-13
00 (System) New version available: draft-ietf-bfd-base-00.txt