As required by RFC 4858 template: 24 February 2012.
1) Resent Grow WG call (11/4/2015)
2) SEC-DIR and OPS-DIR early call also in progress.
3) Sent to Alvaro with the above two issues in progress.
(1) Type of RFC: Standards
Why: This draft extends RFC7752 to add passing
BGP topology information for regarding BGP Peers in BGP
for the use of traffic engineering E-BGP peering
links (BGP EPE from draft-ietf-spring-segment-routing-15,
The BGP-LS NLRI is adding a "protocol-ID" for BGP-LS
NLRI to indicate it is passing BGP peer information.
The BGP-LS NLRI in the Link NLRI is adding
BGP Router-ID and AS.
The BGP attribute for BGP-LS is adding link TLVs to
indicate a segment ID (SID) to identify a
BGP-Peering node (Peer-Node-SID),
a BGP Peering interface (Peer-Adj-SID) (if multipole interfaces exist),
and a BGP Peer grouping (Peer-Set-SID).
(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:
Segment Routing (SR) leverages source routing. A node steers a packet
through a controlled set of instructions (called segments) by prepending
the packet with an SR header. A segment can represent any instruction,
topological or service-based. SR allows SR instructions to enforce a
flow through any topological path and service chain while
maintaining per-flow state only at the ingress node of the SR domain.
The Segment Routing architecture can be directly applied to the
MPLS dataplane with no change on the MPLS forwarding plane, and
can be applied to a modified IPv6 forwarding plane (SRv6).
SR requires extensions to the existing link-state routing protocols
and BGP to support its features.
This document describes an extension to the BGP-LS NLRI and
BGP attribute for BGP-LS (RFC7752) in order to export
BGP peering node topology information (including
its peers, peering interfaces, and the AS numbers of the peers )
so that devices can compute efficient Segment Routing pathways
across inter-domain pathways.
Working Group Summary
The WG has reviewed the BGP-LS segment
routing drafts for 3-5 years in coordination with the
SPRING, MPLS, and BESS working groups.
Please read the draft-ietf-spring-segment-routing and
understand the architecture construct.
This draft is one of a family of BGP additions for BGP-LS
segment routing (SR) and and BGP Traffic
Engineering (TE) that IDR is standardizing after receiving
reports of 2 independent implementations.
Other drafts for segment routing reading for standardization
include: draft-ietf-idr-bgp-prefix-sid and
Other drafts for BGP-LS based TE include:
Are there existing implementations of the protocol?
yes - see links below
Reviews meriting special comments:
a) Shepherd review required document to alter the
manageabiltiy and security
b) Grow WG has been asked to review this document
for operational usefulness
c) early secdir review
Why the special attention?
The information contained in the BGP
extensions provides substantial information
regarding a network.
Summary of why shepherd has sent forward
-17.txt draft to IESG
The inclusion of the reference in the security consideration
in -17.txt of a specific reference to RFC8402 (SR architecture)
and a clear statement that these BGP-LS extensions
are to be operated in a trusted domain with
isolated BGP peers with filtering restrictions
so that this information cannot go outside this peers.
In my understandings, these restrictions form
a web of trusted BGP peers.
If these BGP peers operate in the SR-MPLS
environment, the security analysis provided
by RFC4381 should apply.
These security restrictions are in addition to the
RFC7752 security restrictions.
Since RFC7752 does not provide require
a trusted domain or BGP-LS isolation these
additional restrictions are important.
Document Shepherd: Susan Hares
Responsible AD: Alvaro Retana
RTG-DIR: Ravi Singh
2 implementations from Cisco (chairs check 6/14/2017)
Wiki report on implementations
. Cisco Router platforms running IOS-XR release 6.0.2
. Cisco Nexus Switch N9000/N3000 platforms running NX-OS 7.0(3)I5(1) or great
Error in Early allocation (Alvaro Retana) - 4/6/2018
Acee's response clearing this issue:
version-15 shepherd's report
(major issues: iBGP usage,
minor issue: error handling text
version-17 shepherd's comments:
IETF Adoption call (5/31 -6/16/2015)
WG LC (2/15/2017 to 3/1/2017)
Chair’s announcing the conclusion to WG LC
1 Week WG LC on changes during shepherding process
(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
Shepherd: scanned all emails regarding this draft.
Compared this draft against all SPRING drafts (which had conflicting
pointers (but that's an IDR problem)), BGP-LS drafts, BGP-LS drafts for
IDR, and upcoming BGP SRv6 drafts.
Shepherd worked with authors to improve document to
resolve unclear language in text on manageability,
error handling, and security consideratons.
Shepherd sent this document to Grow for operational
review and secdir for early security analysis.
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
The use of BGP-LS by segment routing is an emerging area of
technology. Those IETF people working on this area have been
pushing the technology forward in individual pieces. The
read through all the Spring, IDR, MPLS drafts related to
BGP-LS, BGP-LS based TE, general BGP-LS as a transport indicated
that the authors have not had time to create seamless document
groups. Two things need to be seamless for deployment:
1) operationally protocols with clear error handling and
manageability sections, and
2) cohesiveeasily readable documents to allow spread of the technology.
My concern is that the SR routing technology is not had enough
independent reviews to be seamless operationally. The seamless
cohesive document will come in time if this technology is successful.
Due to this status, the shepherd engaged in extra
reviews (which caused consternation of the authors at times),
in operational usefulness and security.
(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
RTR-DIR and OPS-DIR are aware of this work. However, it is
important that they review the final documents.
An early secdir review has been requested, but
due to IETF 103 - it may run into the publication.
(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?
Adding the BGP topology information to BGP-LS (RFC7752)
so that BGP Peers can offload TE for E-BGP peers to a centeralized controller
has strong benefits and risks. However, this
draft restricts those additions to the trusted domain
of RFC8402 with specific comments on BGP
With these additional restrictions to the
lack of security or isolation in BGP-LS (RFC7752)
have been resolved for this Segment-Routing document.
Other issues regarding BGP-LS as a transport for
this information or a whether new types of
TCP security should be required for BGP-LS
are more architectural issues for BGP or IGPs,
and not specific to this document.
(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.
Stefano Previdi (during adoption call)
(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
2 IPR disclosures prior to WG LC
Sent to WG on Wed, 02 December 2015
[Unclear, but before adoption call and WG LC]
(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?
A second call was done on:
(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 disconnect except with the extension of BGP-LS (RFC7752)
by Tony Li and Robert Raszuk. (see links below from
another BGP-LS routing draft)
(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
== Outdated reference: A later version (-08) exists of
We are modifying both this document and
to submit the IESG at the same time.
We will adjust both before submission.
(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
(13) Have all references within this document been identified as
either normative or informative?
The shepherd wishes the AD to review whether
is normative or informative. It is left as informative.
(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?
(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.
(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
No - these are extensions to BGP-LS as a standard.
(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 5226).
AFIK - this is IANA Ok. It has been through early review.
(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.
No expert guidance needed.
(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, etc.
No XML on final document.