Internet Exchange BGP Route Server
RFC 7947

Received changes through RFC Editor sync (created alias RFC 7947, changed abstract to 'This document outlines a specification for multilateral interconnections at Internet Exchange Points (IXPs).  Multilateral interconnection is a method of exchanging routing information among three or more External BGP (EBGP) 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 IXPs, to facilitate simplified interconnection among multiple Internet routers.', changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2016-09-07, changed IESG state to RFC Published)

[Ballot comment]
From an operational point of view, when an ISP wants to go change from bilateral interconnections to the multilateral interconnection within one IXP, is this correct to say that all bilateral interconnections should be removed?
So that basically the ISP must chose between the two models, and not combined them? If this is the case, it should be mentioned.
I thought it was clear to me until I saw figure 1: The dotted line is the IXP or the IXP Route Server?
At first glance, I thought that it was the IXP and that AS1 was connected to the IXP Route Server while still having a bilateral connection with AS4.
I hope now that the dotted line is the IXP Route Server, otherwise I've confused.

[Ballot comment]
I'm at a bit of a loss to understand why path hiding would be a considered an undesirable property of an MLPE routeserver.  IMHO as an operator that peers on MLPE exchanges as well as bilaterally on exchange fabrics and via PNIs. blinding a client of the MLPE which I  may have a session already with at the exchange or via PNI is basically mandatory. Likewise without per-asn export policy at exchanges my ability to advertise anycast prefixes via the MLPE is basically noexistant

  If an IXP operator deploys a route server without
  implementing a per-client routing policy control system, then path
  hiding does not occur as all paths are considered equally valid from
  the point of view of the route server.

Does not seem like a particularly desirable outcome.

While I'm fine with 2.3 not being normative, it does seem desirable that an MLPE service offer the client control, it greatly increases the sorts of clients that can safely use the service.

[Ballot comment]
Quick question: Why is the following statement a SHOULD and not a MUST:
"the route server SHOULD NOT prepend its own AS number to the AS_PATH
  segment nor modify the AS_PATH segment in any other way. "
Is this because the clients might eitherwise not accept the message?
Maybe add one sentence to explain the SHOULD!

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

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

No

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

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-idr-ix-bgp-route-server-10.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: aretana@cisco.com, idr@ietf.org, shares@ndzh.com, idr-chairs@ietf.org, draft-ietf-idr-ix-bgp-route-server@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Internet Exchange BGP Route Server) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document:
- 'Internet Exchange BGP Route Server'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-06-07. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


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




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-idr-ix-bgp-route-server/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-idr-ix-bgp-route-server/ballot/


No IPR declarations have been submitted directly on this I-D.

AD Review:

I just finished reading this document.  Please find my comments below.

As you can see, the comments I labeled as Major are mostly related to security considerations, where I think there's more to add, and clarity with respect to the behavior in RFC4271.  I don't think that any of the comment will be hard to address.

I will wait for your comments/discussion and/or an update before starting the IETF Last Call.

Thanks!

Alvaro.


Major:

(1) Should this document be marked as updating rfc4271?  There are several places in Section 2 where the behavior is different than what is specified in rfc4271.  Given that the route server functionality is an optional enhancement, I don't think this document should be marked as updating rfc4271 (I.e. It changes the behavior only for the functionality specified here).  I'm assuming the authors/WG agree since there is no indication of an update.  Please include a clear statement (maybe in the Introduction) to the fact that the mechanism is optional.

(2) Section 2.1. (Client UPDATE Messages). "The route server SHOULD forward UPDATE messages where appropriate…to its clients."  When is it appropriate?  I'm guessing that you mean something like "where local policy permits"..  Please be clear.

(3) Section 2.2.2. (AS_PATH Attribute)  Not prepending the route server's AS_PATH brings up a couple of issues/questions:
- RFC4271 talks about prepending the local ASN (when advertising to an EBGP peer), and it doesn't mention any exceptions.  This document includes an exception.  Clearly indicate the modifications to Section 5.1.2. (AS_PATH) of RFC4271.

- Section 6.3. (UPDATE Message Error Handling) of rfc4271 says that when an "…UPDATE message is received from an external peer, the local system MAY check whether the leftmost…AS in the AS_PATH attribute is equal to the autonomous system number of the peer that sent the message", and MUST send a NOTIFICATION if it doesn't.
-- Please be explicit about the required behavior for both the route server, and the clients.
-- Even though this check is optional in RFC4271, mandating that is not be done could be interpreted as a security issue.  Please include some text around it (and mitigation) in the Security Considerations section.

- Independent of the check, not including an ASN in the AS_PATH could (in the general case) result in loops; which I also interpret as a potential security issue.  Please include some text about this too — a mitigation option is clearly to not check the first ASN only when known route servers are peers.

(4) Section 2.2.4. (Communities Attributes) says that Communities "SHOULD NOT be modified, processed or removed.  However, if such an attribute is intended for processing by the route server itself, it MAY be modified or removed."  How does the route server know if the sender intended for a community to be processed by it, or not?  Please add details.

(5) Section 3. (Security Considerations) 
- Besides the points above, because clients rely on the route server to implement outbound route filtering for them, there can be a privacy issue/route leak scenario where the route server can send routes to clients that it shouldn't have.  Not much can be done to mitigate this because it will mostly be due to a bad implementation or simply a "bad operator".
- You should point at relevant sections of RFC7454.


Minor:
(1) Please be consistent:
s/exterior BGP/external BGP..or even just EBGP (yes, a nit..but that's how rfc4271 calls EBGP)
s/best path selection process/Decision Process
s/IX/IXP

(2) Section 2.2.3. (MULTI_EXIT_DISC Attribute) specifically calls out the MED, but you already said in Section 2.2. (Attribute Transparency) that all optional attributes "SHOULD NOT be updated by the route server…and SHOULD be passed on to other route server clients."  Is there anything special about the MED that I'm missing?  If not, then you should be able to delete the section.

(3) In Section 2.3.1. (Path Hiding on a Route Server) policy implementation is described in terms of outbound route filtering.  The description of the example says that if "AS1's policy prevents AS2's path from being accepted, then AS1 would never receive a path to this prefix".  To be consistent with the outbound filtering description, you might want to change that text to something like "AS2's policy prevents AS1 from receiving the path, …".

(4) Section 2.3.2.2. (Advertising Multiple Paths) says that if the route server sends "more than a single path to a route server client,…the path hiding problem described in Section 2.3.1 would disappear."  That statement is true, but only if all the paths are propagated, not just "more than a single" one. [You do talk about that in 2.3.2.2.1, but not the general case.]

(5) Section 2.3.2.2.2. (BGP ADD-PATH Approach)
- This section says that if "the route server client propagates multiple paths for the same prefix to the route server, then this could potentially cause the propagation of inactive, invalid or suboptimal paths to the route server, thereby causing loss of reachability to other route server clients."  I can see how suboptimal (= non best) paths can be propagated by the clients, but what about invalid?

- To be consistent, there's no such thing as send-only and receive-only modes negotiated with ADD-PATH.  For the result in the text (having only the route server send), the route server should advertise the Send/Receive field in the ADD_PATH capability set to 2 (only able to send).  It doesn't matter what the client sets the value to (as long as it is not 2).

(6) References:  I think the following can be made Informational: RFC1997, RFC4360


Nits:
(1) Given that Section 2.3 is "included for information purposes only", you might want to consider making it an Appendix.
(2) Section 2.3.3. (Implementation Suggestions) seems superfluous to me.

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

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

No

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

No

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

Please note this draft is in Routing-QA Review by Geoff Houston which I have asked to be changed to a final review.  This document references RFC1863 as a historical document, to make this clear, I have suggested one minor editorial change.