Shepherd writeup

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,
and draft-ietf-springsegement-routing-central-epe-10). 

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:

Technical Summary

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
draft-ietf-spring-segement-routing-central-epe-15 to 
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:  
draft-ietf-idr-bgp-ls-node-admin-tag-extension and
Document Quality

  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
the IESG.

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
took place.

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 
peer isolate. 

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)

Clarence Filsfils

Keyur Patel

S. Ray

Jie Dong

Mach Chen

Acee Lindem

(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 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 
draf-ietf-idr-bgp-ls-segement-routing-ext document 
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.

not applicable

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