Template version: 11/1/2019
(1) Type of RFC: Proposed standard
Why: Modifies a standard document (RFC8955)
(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:
This document describes a modification to the validation procedure
defined in RFC8955 for the dissemination of BGP Flow
Specifications. RFC8955 requires that the originator of the
Flow Specification matches the originator of the best-match unicast
route for the destination prefix embedded in the Flow Specification.
This allows only BGP speakers within the data forwarding path (such
as autonomous system border routers) to originate BGP Flow
Specifications.
Though it is possible to disseminate such Flow
Specifications directly from border routers, it may be operationally
cumbersome in an autonomous system with a large number of border
routers having complex BGP policies. The modification proposed
herein enables Flow Specifications to be originated from a
centralized BGP route controller.
Working Group Summary:
The WG had strong approval and strong request to "get this standardized soon.".
There are 4 interoperable vendor implementations (cisco, Huawei, Juniper,
Nokia), and deployments in a wide range of networks (large carriers to small
enterprise networks) to aid in denial of service protection.
Document Quality:
Are there existing implementations of the protocol?
5 implementations, 4 vendors see
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-flowspec-oid%20implementations
Personnel:
Document Shepherd: Susan Hares
AD: Alvaro Retana
(3) Briefly describe the review of this document that was performed by the
Document Shepherd.
a) 4 rounds of document review and editing.
b) targetted review by an RFC8955 author (besides the shepherd)
c) Discussion on the mail list
https://mailarchive.ietf.org/arch/msg/idr/hm5MyHemDZpSR-stTpWnxB81Jt0/
(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?
No. The RTG-DIR and OPS-DIR have been asked to do early reviews.
This reviews are being requested in parallel with IESG publication.
RTG-DIR review: (Geoff Houston): Suggests that RFC8955 and RFC8956draft-ietf-idr-bgp-flowspec-oid-12.txt should be merged into 1 document. The
idr wg-chairs
took the approach of splitting the work into pieces.
(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.
No other additional reviews (RTG-DIR, OPS-DIR early reviews).
(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?
My introduction indicates the operator community believes they have waited
too long for this draft to turn into an RFC. The additional review in the
WG have tightened the text, but the key point to the operators is 4
vendors with 5 interoperable implementations.
(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?
James Uttaro:
https://mailarchive.ietf.org/arch/msg/idr/yYX9bhbeV68ckYrqV_G0gk9AlMY/
David Smith:
https://mailarchive.ietf.org/arch/msg/idr/Xap8H10MBkHXr-tqdUnC2MeHX64/
Juan Alcaide
https://mailarchive.ietf.org/arch/msg/idr/whOmzyVhWJrTz9O3_30nsKX8A0A/
Clarence Filsfils
https://mailarchive.ietf.org/arch/msg/idr/apEj5VGyWs7OZIiXe1HPMT3p4Qw/
Pradosh Mohapatra
Sproute Networks (Email: mpradosh@yahoo.com)
https://mailarchive.ietf.org/arch/msg/idr/OhO4yk4fEd7ihmjZEtlcRgx9GM0/
(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures. No
disclosure
(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?
Solid consensus. Strong desires for deployment from operators.
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)
No.
(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
Boilerplate checks are not enough; this check needs to be thorough.
a) NITs that AD indicated should be fixed
b) AD concerns should be fixed.
(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No
requirement for formal review.
(13) Have all references within this document been identified as either
normative or informative? All referenances are normative. All references are
published RFCs.
(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?
No.
(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the Last
Call procedure. No.
(16) Will publication of this document change the status of any existing RFCs?
Updates RFC8955. This document points to this draft.
(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes are
associated with the appropriate reservations in IANA registries. Confirm that
any referenced IANA registries have been clearly identified. Confirm that newly
created IANA registries include a detailed specification of the initial
contents for the registry, that allocations procedures for future registrations
are defined, and a reasonable name for the new registry has been suggested (see
RFC 8126).
No IANA considerations are necessary.
The change is within the protocol and does not require registration.
(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries. None requested.
(19) 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, YANG modules, etc.
No automated check required.
(20) If the document contains a YANG module, has the module been checked with
any of the recommended validation tools
(https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module comply
with the Network Management Datastore Architecture (NMDA) as specified in
RFC8342?
No Yang modules.
This draft will require draft which augmentation of the base BGP model - after
that BGP model is approved.