Shepherd writeup
rfc7947-12

Based on Shepherd template: 2/24/2012 
Authors: Elisa Jasinka, NicK Hilliard, Robert Razuk, Niels Bakker 
Document Shepherd: Susan Hares 
WG chairs: Susan Hares, John Scudder
AD: Alvaro Retano 
Reviews done: Shepherd review
Reviews pending:  none 

Type of RFC: Proposed Standard

(1) Type of RFC checks: 
a) Why is this the proper type of RFC?  
This proposes a standard for an extension of the BGP protocol
to support router severs. This does not change the base BGP 
specification for basic BGP. 


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up.  

Technical Summary

 This document outlines a specification for multilateral
   interconnections at Internet exchange points (IXPs).  Multilateral
   interconnection is a method of exchanging routing information between
   three or more exterior BGP speakers using a single intermediate
   broker system, referred to as a route server.  Route servers are
   typically used on shared access media networks, such as Internet
   exchange points (IXPs), to facilitate simplified interconnection
   between multiple Internet routers.

Working Group Summary

 The document has been discussed for 2-3 years in the IDR and
 the GROW working group. The WG has discuss the implementations,
 and these implementations have been discussed at NANOG
 (an operators forum). 

Document Quality

 a) Are there existing implementations of the protocol? 
 Three implementations: Cisco, BIRD, Quagga.
 You can view the implementation survey at:
 http://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-ix-bgp-route-server%20implementations
 
 b) Have a significant number of vendors indicated their plan to 
  implement the specification?
   These three vendors have implemented the code, 
   and numerous test studies have been published. 
   See the report at: 
   
   ​https://www.nanog.org/meetings/nanog48/presentations/Monday/Jasinska_RouteServer_N48.pdf
   
 
 c) Are there any reviewers that  merit special mention as having
   done a thorough review,
   c-1) routing-QA review: Geoff Huston ()gih@apnic.net) - pending 
   
 d) Personnel for IESG REview 
  d-1: document shepherd: Susan Hares 
  d-2: Routing AD: Alvaro Retano 
  d-3: WG chairs: Susan Hares, John Scudder 
  d-4: RTR-Directorate Reviewer: Geoff Huston <gih@apnic.net>
  d-5: OPS-Directorate reviewers: TBD 
  d-6: GEN-ART reviewers: TBD 
  d-7: Security directorate reviewer: TBD 

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

The WG has discussed this for 3+ years, 
the code is implemented in 3 implementations
(Cisco, BIRD, Quaga), and the deployment issues have been discussed
at NANOG. 
​https://www.nanog.org/meetings/nanog48/presentations/Monday/Jasinska_RouteServer_N48.pdf

 
(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?  
took place.
  5-1: Routing Directorate:  yes 
  5-2: OPS Directorate: Yes 
  5-3: Security Directorate: Yes 
  5-4: Yang Directorate: No 
  5-5: Gen-ART Review: yes 


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

Yes. 

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

Nick Hilliard
http://www.ietf.org/mail-archive/web/idr/current/msg14680.html
Niels Bakker: 
http://www.ietf.org/mail-archive/web/idr/current/msg14682.html
Robert Raszuk
http://www.ietf.org/mail-archive/web/idr/current/msg14681.html
Elisa Jasinska
http://www.ietf.org/mail-archive/web/idr/current/msg14758.html

(9) How solid is the WG consensus behind this document?  
 WG LC, and 3 years of good consensus with lots of discussion in Grow. 

(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 https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The NITS find that RFC1863 is updated by RFC4223 which notes that
RFC1863 is historic.  The shepherd suggest the following addition to
the third paragraph in section 5. 

Please note that RFC1863 has been made historical by RFC4223.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
	12-1) formal review yang, URI 

(13) Have all references within this document been identified as
either normative or 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. 

Please note that the use of RFC1863 is informative and given in 
a acknowledgement of past effort. 

(16) Will publication of this document change the status of any
existing RFCs? 

No.  It is a unique implementation that does not change the 
base BGP drafts (RFC4271). 
 
(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.  

This document does not suggest any changes to IANA. 

(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 by this document. 

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

none required. 
Back