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.
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).
a) Are there existing implementations of the protocol?
Three implementations: Cisco, BIRD, Quagga.
You can view the implementation survey at:
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:
c) Are there any reviewers that merit special mention as having
done a thorough review,
c-1) routing-QA review: Geoff Huston ()firstname.lastname@example.org) - 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 <email@example.com>
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
(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?
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?
(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.
(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
(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
(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
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
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
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.