: (1) What type of RFC is being requested:
Proposed Standard
: Why is this the proper type of RFC?
Replaces RFC7752
: 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:
In a number of environments, a component external to a network is called upon
to perform computations based on the network topology and the current state of
the connections within the network, including Traffic Engineering (TE)
information. This is information typically distributed by IGP routing
protocols within the network.
This document describes a mechanism by which link-state and TE information can
be collected from networks and shared with external components using the BGP
routing protocol. This is achieved using a new BGP Network Layer Reachability
Information (NLRI) encoding format. The mechanism is applicable to physical
and virtual IGP links. The mechanism described is subject to policy control.
Applications of this technique include Application-Layer Traffic Optimization
(ALTO) servers and Path Computation Elements (PCEs).
This document obsoletes RFC 7752 by completely replacing that document. It
makes some small changes and clarifications to the previous specification.
This document also obsoletes RFC 9029 by incorporating the updates which it
made to RFC 7752.
: Working Group Summary:
Work on this document primarily happened off the Working Group mail list. A
substantial amount of the original content was produced in the original
document, draft-ketant-idr-rfc7752bis. Refinements that happened to the draft
occurred through discussions including those at IETF to address known issues in
the original RFC 7752.
: Was there anything in WG process that is worth noting?
Participation was light, but the participants were deeply versed in the
technology under consideration.
: Document Quality:
The document is of high quality. Since this is a -bis document, the original
content had been through the RFC process and started in good shape. The new
text and clarifications that were introduced in each revision were well
considered and cleanly worded.
: Are there existing implementations of the protocol?
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-RFC7752bis%20implementations%20
:
: Have a significant number of vendors indicated their plan to implement the
: specification?
RFC7752 is widely deployed.
This draft corrects the specification for things learned from deployment.
: Personnel:
: Document Shepherd:
Jeffrey Haas <jhaas@pfrc.org>
: Area Director:
Alvaro Retana
: (3) Briefly describe the review of this document that was performed by the
: Document Shepherd.
A thorough review of the document was done. There were some small number of
nits to be resolved.
During review, three error handling considerations were highlighted that were
not covered in the draft:
- NLRI keying consistency when optional TLVs can be used.
- BGP-LS Attribute consistency created by multiple BGP-LS Producers.
- A desire for more discussion about error handling procedures for BGP-LS
Consumers in the face of syntactically valid but semantically invalid
protocol state.
This discussion resulted in small updates to the document to address the raised
points.
: (4) Does the document Shepherd have any concerns about the depth or breadth of
: the reviews that have been performed?
The changes to the document are straight-forward alterations providing clarity
vs. clearly traceable requirements for the covered IGP state in most cases. In
the other cases, protocol ambiguities are addressed that are mostly based in BGP
route propagation semantics.
: (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. The changes are largely either clarifications with clear reference to the
source IGP material, or localized to BGP impacts of the protocol.
: (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?
No.
: (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?
Author:
K. Talaulikar, Cisco:
Cisco Systems
India
Email: ketant@cisco.comhttps://mailarchive.ietf.org/arch/msg/idr/xp-9imj9pabQdgb6Gly0otv8MNE/
Contributors:
Hannes Gredler
Rtbrick
Email: hannes@rtbrick.comhttps://mailarchive.ietf.org/arch/msg/idr/Vk3mubVmkXHVbtAsNVlzys_EiV0/
Jan Medved
Cisco Systems Inc.
USA
Email: jmedved@cisco.comhttps://mailarchive.ietf.org/arch/msg/idr/Rq3f4I7m-paP-qait53APbEWIYE/
Stefano Previdi
Huawei Technologies
Italy
Email: stefano@previdi.nethttps://mailarchive.ietf.org/arch/msg/idr/2-8I787YxhuSZpv_MjBhbGK-JcQ/
Adrian Farrel
Old Dog Consulting
Email: adrian@olddog.co.ukhttps://mailarchive.ietf.org/arch/msg/idr/Na0eFQFG9S6oxYiWmV_6l5d4Boo/
Saikat Ray
Individual
USA
Email: raysaikat@gmail.comhttps://mailarchive.ietf.org/arch/msg/idr/q4q_C8wViQH2JolotJHlDXCQhG4/
: (8) Has an IPR disclosure been filed that references this document? If so,
: summarize any WG discussion and conclusion regarding the IPR disclosures.
Prior IPR vs. RFC 7752 was disclosed by a third-party:
https://datatracker.ietf.org/ipr/3623/
Juniper Networks provided the overlapping first-party disclosure at a later date.
: (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?
Being a technology heavily focused on IGP and TE state, participation in the
Working Group Last Call was low. Of those pariticipants, several individuals
who have heavy focus on those technologies supported it. This included one of
the LSR Working Group chairs.
: (10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
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.
No substantive nits.
: (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 formal review
: (13) Have all references within this document been identified as either
normative or informative?
Yes.
: (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)?
No.
: (16) Will publication of this document change the status of any existing RFCs?
Obsolete RFC 7752 and RFC 9029.
: Are those RFCs listed on the title page header, listed in the abstract,
: and discussed in the introduction?
Yes.
: (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).
A review of all code points vs. registries was completed.
Three new registries were identified that were not previously created via
RFC 7752:
- 6.1.4. BGP-LS Node Flags Registry
- 6.1.5. BGP-LS MPLS Protocol Mask Registry
- 6.1.6. BGP-LS IGP Prefix Flags Registry
Each of these registries have a policy of RFC Required.
: (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.
: (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.
N/A.
: (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?
N/A. There is currently no YANG module for BGP-LS.