(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.]