Skip to main content

Making Route Flap Damping Usable
draft-ietf-idr-rfd-usable-04

Revision differences

Document history

Date Rev. By Action
2014-05-16
04 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2014-03-31
04 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2014-03-31
04 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2014-03-07
04 Adrian Farrel Shepherding AD changed to Alia Atlas
2014-02-11
04 Amy Vezza IESG state changed to RFC Ed Queue from Approved-announcement sent
2014-02-11
04 (System) RFC Editor state changed to EDIT
2014-02-11
04 (System) Announcement was received by RFC Editor
2014-02-10
04 (System) IANA Action state changed to No IC from In Progress
2014-02-10
04 (System) IANA Action state changed to In Progress
2014-02-10
04 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2014-02-10
04 Amy Vezza IESG has approved the document
2014-02-10
04 Amy Vezza Closed "Approve" ballot
2014-02-10
04 Amy Vezza Ballot approval text was generated
2014-02-06
04 Cindy Morgan IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2014-02-06
04 Benoît Claise [Ballot Position Update] Position for Benoit Claise has been changed to No Objection from Discuss
2014-02-06
04 Stewart Bryant Ballot writeup was changed
2014-02-06
04 Barry Leiba
[Ballot comment]
Moved to a comment...
UPDATED after the IESG telechat:

In the telechat discussion, Joel's explanation and Adrian's analysis were significant in clearing up …
[Ballot comment]
Moved to a comment...
UPDATED after the IESG telechat:

In the telechat discussion, Joel's explanation and Adrian's analysis were significant in clearing up what it was that I didn't understand, and in figuring out how to resolve it.  Section 3 looks like general recommendations of default values, and Section 6 looks like it's telling everyone to use those default values.  The combination is confusing because it appears at the same time to be specific to two vendors, and yet perhaps to tell other vendors what values to use.  And I'm not sure what to do if I'm a new vendor aiming to support this.

Section 3 needs to make it clear what the purpose of the table is -- the text that's there is too minimal for anyone to understand the intent.  On the telechat, we agreed that the following text is clear, and the RTG ADs thought it correctly reflects what's intended:

OLD (version -03)
   The following RFD parameters are common to all implementations.  Some
   may be tuned by the operator, some not.
NEW
   This table shows key parameters for RFD implementations, and lists some
   existing default settings for those parameters.  Some may be tuned by the
   operator, some not.  There is currently no consensus on a single set of
   default values.
END

The part of Section 6 that talks about default configurable parameters needs to make it clear that it's not talking just to Cisco and Juniper, and that it's not telling other vendors to use the specific values in Table 1 (and how could it, as the values differ between the two vendors listed).  On the telechat, we agreed that the following text is clear, and the RTG ADs thought it correctly reflects what's intended:

OLD (version -03)
   Default Configurable Parameters:  In order not to break existing
      operational configurations, BGP implementations SHOULD NOT change
      the default values in Table 1.
NEW
   Default Configurable Parameters:  In order not to break existing
      operational configurations, deployed BGP implementations SHOULD
      NOT change their default values for the parameters listed in Table 1.
END
2014-02-06
04 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to Abstain from Discuss
2014-02-06
04 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2014-02-05
04 Spencer Dawkins
[Ballot comment]
Still No-Objection, but I support the Barry/Benoit Discusses.

Looking back, I said that in previous e-mail on those Discusses but never added it …
[Ballot comment]
Still No-Objection, but I support the Barry/Benoit Discusses.

Looking back, I said that in previous e-mail on those Discusses but never added it to my ballot position - sorry.
2014-02-05
04 Spencer Dawkins Ballot comment text updated for Spencer Dawkins
2014-02-05
04 Stewart Bryant Telechat date has been changed to 2014-02-06 from 2013-10-10
2014-02-05
04 Stewart Bryant
[Ballot comment]
Benoit and Barry agree on the text change, so I am looking using Barry's
proposed text.

As far as I can see the …
[Ballot comment]
Benoit and Barry agree on the text change, so I am looking using Barry's
proposed text.

As far as I can see the text used by the authors is semantically equivalent
and this is a matter of style, which is outside the DISCUSS criteria.

Because I am unable to see the difference I am unable to explain the
difference to the authors, and am therefore unwilling to force a text
change on them.

OLD (version -03)
  The following RFD parameters are common to all implementations.  Some
  may be tuned by the operator, some not.
NEW
  This table shows key parameters for RFD implementations, and lists some
  existing default settings for those parameters.  Some may be tuned by the
  operator, some not.  There is currently no consensus on a single set of
  default values.
END

The text in -04 actually says:

"The following RFD parameters are common to all implementations.  Some
may be tuned by the operator, some not.  There is currently no
consensus on a single set of default values."

The title of Table 1 is "Default RFD Paramaters of Juniper and Cisco" which
were the implementations studied.

=======

OLD (version -03)
  Default Configurable Parameters:  In order not to break existing
      operational configurations, BGP implementations SHOULD NOT change
      the default values in Table 1.
NEW
  Default Configurable Parameters:  In order not to break existing
      operational configurations, deployed BGP implementations SHOULD
      NOT change their default values for the parameters listed in Table 1.
END

The text in -04 says:

"Default Configurable Parameters:  In order not to break existing
      operational configurations, existing BGP implementations
      including, the examples in Table 1, SHOULD NOT change their
      default values."

The only significant difference seems to be s/deployed/existing/ which
are semantically the same and i/including, the examples in Table 1/
which is a subset of the statement requested by the discuss holders.
2014-02-05
04 Stewart Bryant Ballot comment text updated for Stewart Bryant
2013-10-15
04 Benoît Claise
[Ballot discuss]
See Barrry's DISCUSS for the latest proposed changes, as agreed during the IESG telechat; This would solve my DISCUSS.
Below is my initial …
[Ballot discuss]
See Barrry's DISCUSS for the latest proposed changes, as agreed during the IESG telechat; This would solve my DISCUSS.
Below is my initial DISCUSS text.

  Default Configurable Parameters:  In order not to break existing
      operational configurations, BGP implementations SHOULD NOT change
      the default values in Table 1.

Table 1 mentions
        +-------------------------+----------+-------+---------+
        | Parameter              | Tunable? | Cisco | Juniper |
        +-------------------------+----------+-------+---------+
        | Withdrawal              | No      |  1000 |    1000 |
        | Re-Advertisement        | No      |    0 |    1000 |

It's fine to say that Cisco and Juniper SHOULD NOT change their default values, but you also have to say what another new vendor must be doing for the Re-Advertisment parameter.
The choices are:
    1. 0 as default value
    2. 1000 as default value
    3. 0 or 1000 as default value

Let's not forget that this is a Standards Track document, to which all vendors want to be compliant.

Proposal:

  Default Configurable Parameters:  In order not to break existing
      operational configurations, BGP implementations SHOULD NOT change
      the default values in Table 1. New implementations MUST select either 0 or 1000
      for the Re-Advertisment parameter default value.
2013-10-15
04 Benoît Claise Ballot discuss text updated for Benoit Claise
2013-10-14
04 Barry Leiba
[Ballot discuss]
UPDATED after the IESG telechat:

In the telechat discussion, Joel's explanation and Adrian's analysis were significant in clearing up what it was that …
[Ballot discuss]
UPDATED after the IESG telechat:

In the telechat discussion, Joel's explanation and Adrian's analysis were significant in clearing up what it was that I didn't understand, and in figuring out how to resolve it.  Section 3 looks like general recommendations of default values, and Section 6 looks like it's telling everyone to use those default values.  The combination is confusing because it appears at the same time to be specific to two vendors, and yet perhaps to tell other vendors what values to use.  And I'm not sure what to do if I'm a new vendor aiming to support this.

Section 3 needs to make it clear what the purpose of the table is -- the text that's there is too minimal for anyone to understand the intent.  On the telechat, we agreed that the following text is clear, and the RTG ADs thought it correctly reflects what's intended:

OLD (version -03)
   The following RFD parameters are common to all implementations.  Some
   may be tuned by the operator, some not.
NEW
   This table shows key parameters for RFD implementations, and lists some
   existing default settings for those parameters.  Some may be tuned by the
   operator, some not.  There is currently no consensus on a single set of
   default values.
END

The part of Section 6 that talks about default configurable parameters needs to make it clear that it's not talking just to Cisco and Juniper, and that it's not telling other vendors to use the specific values in Table 1 (and how could it, as the values differ between the two vendors listed).  On the telechat, we agreed that the following text is clear, and the RTG ADs thought it correctly reflects what's intended:

OLD (version -03)
   Default Configurable Parameters:  In order not to break existing
      operational configurations, BGP implementations SHOULD NOT change
      the default values in Table 1.
NEW
   Default Configurable Parameters:  In order not to break existing
      operational configurations, deployed BGP implementations SHOULD
      NOT change their default values for the parameters listed in Table 1.
END
2013-10-14
04 Barry Leiba Ballot discuss text updated for Barry Leiba
2013-10-10
04 Randy Bush IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2013-10-10
04 Randy Bush New version available: draft-ietf-idr-rfd-usable-04.txt
2013-10-10
03 Cindy Morgan State changed to IESG Evaluation::AD Followup from IESG Evaluation
2013-10-10
03 Tero Kivinen Request for Last Call review by SECDIR Completed: Ready. Reviewer: Ben Laurie.
2013-10-10
03 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2013-10-09
03 Joel Jaeggli
[Ballot comment]
riff on benoit's comment


      Default Configurable Parameters:  In order not to break existing
      operational configurations, BGP implementations …
[Ballot comment]
riff on benoit's comment


      Default Configurable Parameters:  In order not to break existing
      operational configurations, BGP implementations SHOULD NOT change
      the default values in Table 1.

This is what I'd call the phenomena of least surprise. e.g. don't change unspecifed (and therefore default values). I'd personally prefer that it say something like:


    Default Configurable Parameters:  In order not to break existing
      operational configurations, existing BGP implementations inclusive
      of the examples in Table 1 SHOULD NOT change default values.

other than that I'm an un-equivocal yes to this.
2013-10-09
03 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2013-10-09
03 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2013-10-08
03 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2013-10-08
03 Benoît Claise
[Ballot discuss]
Along the same lines as Barrry's DISCUSS...

  Default Configurable Parameters:  In order not to break existing
      operational configurations, BGP …
[Ballot discuss]
Along the same lines as Barrry's DISCUSS...

  Default Configurable Parameters:  In order not to break existing
      operational configurations, BGP implementations SHOULD NOT change
      the default values in Table 1.

Table 1 mentions
        +-------------------------+----------+-------+---------+
        | Parameter              | Tunable? | Cisco | Juniper |
        +-------------------------+----------+-------+---------+
        | Withdrawal              | No      |  1000 |    1000 |
        | Re-Advertisement        | No      |    0 |    1000 |

It's fine to say that Cisco and Juniper SHOULD NOT change their default values, but you also have to say what another new vendor must be doing for the Re-Advertisment parameter.
The choices are:
    1. 0 as default value
    2. 1000 as default value
    3. 0 or 1000 as default value

Let's not forget that this is a Standards Track document, to which all vendors want to be compliant.

Proposal:

  Default Configurable Parameters:  In order not to break existing
      operational configurations, BGP implementations SHOULD NOT change
      the default values in Table 1. New implementations MUST select either 0 or 1000
      for the Re-Advertisment parameter default value.
2013-10-08
03 Benoît Claise [Ballot Position Update] New position, Discuss, has been recorded for Benoit Claise
2013-10-08
03 Richard Barnes [Ballot Position Update] New position, Yes, has been recorded for Richard Barnes
2013-10-08
03 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2013-10-07
03 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2013-10-07
03 Sean Turner [Ballot Position Update] New position, Yes, has been recorded for Sean Turner
2013-10-07
03 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2013-10-04
03 Barry Leiba
[Ballot discuss]
This is surely an issue of my barely knowing how to spell BGP and RFD, much less fully understand them, and so perhaps …
[Ballot discuss]
This is surely an issue of my barely knowing how to spell BGP and RFD, much less fully understand them, and so perhaps this just requires a little education:

1. Where are the RFD parameters in Table 1 in Section 3 defined?  Where can I find their meanings?  They aren't mentioned in RFC 2439 (nor in 4271, but I didn't expect to find them there).  The mao2002 and pelsser2011 references have similar tables, but also don't define these parameters.

2. Section 6 says that implementations SHOULD NOT change the default values in Table 1.  But the default value for Re-Advertisement is vastly different, depending upon whether I get my router from Cisco or from Juniper.  I don't understand what this SHOULD NOT is telling me.  If I'm someone else building a router, am I supposed to use 0 for Re-Advertisement, or 1000?
2013-10-04
03 Barry Leiba [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba
2013-10-04
03 Brian Haberman [Ballot Position Update] New position, Yes, has been recorded for Brian Haberman
2013-10-03
03 Ted Lemon [Ballot comment]
False flap attack?  Groan.
2013-10-03
03 Ted Lemon Ballot comment text updated for Ted Lemon
2013-10-03
03 Ted Lemon [Ballot comment]
False flap attack?  Ouch.
2013-10-03
03 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2013-10-02
03 Stewart Bryant Ballot writeup was changed
2013-10-01
03 Stewart Bryant Ballot writeup was changed
2013-09-30
03 Adrian Farrel
[Ballot comment]
Thanks for this simple and sensible document.

I'm an insufferable pedant :-(

In Section 6 you say "The following changes are recommended"
I …
[Ballot comment]
Thanks for this simple and sensible document.

I'm an insufferable pedant :-(

In Section 6 you say "The following changes are recommended"
I don't think it matters whether these are changes or not.
Maybe "The use of the following values is recommended."
2013-09-30
03 Adrian Farrel [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel
2013-09-30
03 Stewart Bryant Placed on agenda for telechat - 2013-10-10
2013-09-30
03 Stewart Bryant State changed to IESG Evaluation from Waiting for Writeup
2013-09-30
03 Stewart Bryant Ballot has been issued
2013-09-30
03 Stewart Bryant [Ballot Position Update] New position, Yes, has been recorded for Stewart Bryant
2013-09-30
03 Stewart Bryant Created "Approve" ballot
2013-09-30
03 Stewart Bryant Ballot writeup was changed
2013-09-23
03 (System) State changed to Waiting for Writeup from In Last Call (ends 2013-09-23)
2013-09-16
03 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2013-09-16
03 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-idr-rfd-usable-03, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-idr-rfd-usable-03, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion. IANA requests that the IANA Considerations section of the document remain in place upon publication.

If this assessment is not accurate, please respond as soon as possible.
2013-09-06
03 Vijay Gurbani Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Vijay Gurbani.
2013-09-05
03 Jean Mahoney Request for Last Call review by GENART is assigned to Vijay Gurbani
2013-09-05
03 Jean Mahoney Request for Last Call review by GENART is assigned to Vijay Gurbani
2013-09-05
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Ben Laurie
2013-09-05
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Ben Laurie
2013-09-03
03 Amy Vezza IANA Review state changed to IANA - Review Needed
2013-09-03
03 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Making Route Flap Damping Usable) …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Making Route Flap Damping Usable) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document:
- 'Making Route Flap Damping Usable'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-09-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Route Flap Damping (RFD) was first proposed to reduce BGP churn in
  routers.  Unfortunately, RFD was found to severely penalize sites for
  being well-connected because topological richness amplifies the
  number of update messages exchanged.  Many operators have turned RFD
  off.  Based on experimental measurement, this document recommends
  adjusting a few RFD algorithmic constants and limits, to reduce the
  high risks with RFD, with the result being damping a non-trivial
  amount of long term churn without penalizing well-behaved prefixes'
  normal convergence process.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-idr-rfd-usable/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-idr-rfd-usable/ballot/


No IPR declarations have been submitted directly on this I-D.


2013-09-03
03 Amy Vezza State changed to In Last Call from Last Call Requested
2013-09-02
03 Stewart Bryant Last call was requested
2013-09-02
03 Stewart Bryant Ballot approval text was generated
2013-09-02
03 Stewart Bryant Ballot writeup was generated
2013-09-02
03 Stewart Bryant State changed to Last Call Requested from Publication Requested
2013-09-02
03 Stewart Bryant Last call announcement was changed
2013-09-02
03 Stewart Bryant Last call announcement was generated
2013-08-21
03 Cindy Morgan
(1)What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Proposed standard 
Why? It modifies a proposed standard RFC2439 …
(1)What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Proposed standard 
Why? It modifies a proposed standard RFC2439
Is it proper?  RFC2439 specifies an algorithm implemented in BGP for timing of error messages and retransmissions. 
Is this type of RFC indicated in the title page header? Yes. 
(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
------
BGP Route Flap damping seeks to reduce the BGP churn in routers.
First described in operators forms (RIPE, [ripe178]) and RFC2430 it was harsh penalizing sites for being well-connected because topology riches amplified the number of updates. Therefore, many operators turned it off [ripe378].  However, now because new measurements f[plesser2011] indicates a different suppression hold (6000) BGP update rate can be reduced by 19%.  Ripe, a European Operator forum, has endorse these new settings [ripe580].    The Japanese operators have reported their use of the new RFD and their desires for implementation [shishio-grow-isp-rfd-implement-survey].

Working Group Summary:
---------
WG Group had consensus over the last call.  During the last call, a suggestion for addition features was made.  The chairs/WG suggested this would be a follow-on draft rather than an addition to the current draft.
Document Quality:
Existing implementation of RFD exist in Juniper and Cisco.  Protocol deployments [shishio-grow-isp-rfd-implement-survey] found bugs which have been fixed.  The Japanese operator and RIPE operator community have reviewed these documents, and the Japanese operator community given the response in [shishio-grow-isp-rfd-implement-survey].

Since these are changes to existing features with existing configurations, some of the features were tunable via configuration and some not (see table 1 in document). 
Since BGP configuration via MIB is not widely deployed, a specific MIB review or information model for this specific draft is not warranted. However, this draft will be added by the chairs to drafts to be examined by NM/OPS groups for BGP configuration.

Personnel:  Shepherd: Susan Hares (WG chair), AD: Stewart Bryant

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
    Reviewed of technical input: Read Draft, Grow draft, referenced documents

(4)Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No.  The Shepherd has read all referenced document.
 
(5)Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
Yes. It was looked at by 3 major BGP Communities: US, Japan, and Europe. 

(6)Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? 
This document may be followed up with a configuration drafts regarding this topic, but this is a good thing. 

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

IPR is unlikely, but authors have been

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosure has been filed.

(9) 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? Has anyone threatened an appeal or otherwise indicated extreme discomfort?

The operator community seems to be active although silent on the list.  Therefore, the document shepherd suggests the community is agreeable but silent.

No indication of an appeal.

(10) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
This nits have found something. However, it appears the ID-NITS are wrong.  Boilerplate checks are not enough; this check needs to be thorough.

(11)Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.
No MIB, no media talk, URI type reviews.

(12) Have all references within this document been identified as either normative or informative?
Yes – all references are normative or informative.
(13) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state?  No.

(14)Are there downward normative references  (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
No.

(15) Will publication of this document change the status of any existing RFCs?
yes, it will limits suggested by RFC2439 (Modification)

(16) IANA
a. No considerations – The specification only changes implementation knobs.
b. No new registries

  (17) No XML or BNF or MB

  (18) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. - not applicable

[Note: Japan/US Time is why draft is 8/22 and write-up is 8/21.]
2013-08-21
03 Cindy Morgan IESG process started in state Publication Requested
2013-08-21
03 Susan Hares Changed document writeup
2013-08-21
03 Susan Hares Changed document writeup
2013-08-21
03 Susan Hares Changed consensus to Yes from Unknown
2013-08-21
03 Susan Hares consensus call completed.  Shepherd's write-up done.  NITS in tracker are broken ID-HIDS problem.  Expe
2013-08-21
03 Susan Hares IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2013-08-21
03 Susan Hares modifies a standard
2013-08-21
03 Susan Hares Intended Status changed to Proposed Standard from None
2013-08-21
03 Susan Hares Changed document writeup
2013-08-21
03 Randy Bush New version available: draft-ietf-idr-rfd-usable-03.txt
2013-03-13
02 John Scudder IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document
2013-03-11
02 Randy Bush New version available: draft-ietf-idr-rfd-usable-02.txt
2013-02-21
01 Susan Hares Changed shepherd to Susan Hares
2012-12-17
01 Randy Bush New version available: draft-ietf-idr-rfd-usable-01.txt
2012-06-18
00 Randy Bush New version available: draft-ietf-idr-rfd-usable-00.txt