Last Call Review of draft-ietf-idr-ix-bgp-route-server-09
review-ietf-idr-ix-bgp-route-server-09-opsdir-lc-kumari-2016-06-20-00

Be ye not afraid -- I have reviewed this document as part of the
operations directorate's ongoing effort to review all IETF documents
being processed by the IESG.  These comments were written primarily
for the benefit of the operation area directors.  Document editors and
WG chairs should treat these comments just like any other last call
comments.

Version reviewed: draft-ietf-idr-ix-bgp-route-server-11

Summary:
Well, this is embarrassing - this section of the OpsDir review usually
points out issues that the OpsADs need to be aware of, and how much
attention they need to pay to the document. Unfortunately, I didn't
get around to this until after the ADs had already reviewed it, and
so, well, I suck. Sorry.



So, instead of offering useful pointers to the OpsADs I'll instead
just provide some readability nots / suggestions to the authors....


Section 1. Introduction to Multilateral Interconnection

 While bilateral external BGP sessions between exchange participants
 were previously the most common means of exchanging reachability
 information, the overhead associated with dense interconnection can
 cause substantial operational scaling problems for partipants of

[O] partipants
[P] participants
[R] typo
larger Internet exchange points.


[O] Multilateral interconnection is a method of interconnecting BGP
   speaking routers using a third party brokering system, commonly
   referred to as a route server and typically managed by the IXP
   operator. Each of the multilateral interconnection participants

   (usually referred to as route server clients) announces network
   reachability information to the route server using external BGP, and
   the route server in turn forwards this information to each other
   route server client connected to it, according to its configuration.

[P] Multilateral interconnection is a method of interconnecting
BGP-speaking routers, using a third party brokering system. This is
commonly referred to as a route server and is typically managed by the
IXP operator. Each multilateral interconnection participant (usually
referred to as a 'route server client') announces network reachability
information to the route server using external BGP. The route server,
in turn, forwards this information to every other route server client
connected to it, according to its configuration.

[R] readability


   A route server can be viewed as similar in function to an [RFC4456]
   route reflector, except that it operates using EBGP instead of iBGP.
   Certain adaptions to [RFC4271] are required to enable an EBGP router
   to operate as a route server; these are outlined in Section 2 of this
   document.  Route server functionality is not mandatory in BGP
   implementations.``

[O] ``
[R] I think these are end quotes, but there aren't corresponding
beginning quotes. Maybe just a typo?

   The term "route server" is often in a different context used to
   describe a BGP node whose purpose is to accept BGP feeds from
   multiple clients for the purpose of operational analysis and
   troubleshooting.  A system of this form may alternatively be known as
   a "route collector" or a "route-views server".  This document uses
   the term "route server" exclusively to describe multilateral peering
   brokerage systems.

[O] The term "route server" is often in a different context used to

   describe a BGP node whose purpose is to accept BGP feeds from
   multiple clients for the purpose of operational analysis and
   troubleshooting.  A system of this form may alternatively be known as
   a "route collector" or a "route-views server".  This document uses
   the term "route server" exclusively to describe multilateral peering
   brokerage systems.
[P] This document uses the term "route server" exclusively to describe
multilateral peering brokerage systems. In other contexts, the term
"route server" may be used to describe a BGP node whose purpose is to
accept BGP feeds from multiple clients for operational analysis and
troubleshooting. A system of that form may also be known as a "route
collector" or a "route-views server."


2.  Technical Considerations for Route Server Implementations

   Path hiding will only occur on route servers which employ per-client
   policy control; 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

[O] occur as
[P] occur, as
[R] grammar

  the point of view of the route server.

2.3.2.1.  Multiple Route Server RIBs

   The most portable method to allow for per-client policy control
   without the occurrence of path hiding, is by using a route server BGP

[O] by using
[P] to use
[R] grammar (the most portable method [...] is to use)

   implementation which performs the per-client best path calculation
   for each set of paths to a prefix, which results after the route
   server's client policies have been taken into consideration.


3.  Security Considerations


   The AS_PATH check described in Section 2.2.2 is normally enabled in
   order to check for malformed AS paths.  If this check is disabled,
   the route server client loses the ability to check incoming UPDATE
   messages for certain categories of problems.  This could potentially
   cause corrupted BGP UPDATE messages to be propagated where they might
   not be propagated if the check were enabled.  Regardless of any
   problems relating to malformed UPDATE messages, this check is also
   used to detect BGP loops, so removing the check could potentially
   cause routing loops to be formed.  Consequently, this check SHOULD

[O] Regardless of any

   problems relating to malformed UPDATE messages, this check is also
   used to detect BGP loops, so removing the check could potentially
   cause routing loops to be formed.
[P] Regardless of any problems relating to malformed UPDATE messages,
this check is also used to detect BGP loops; removing the check could
potentially cause routing loops to be formed.
[R] grammar/readability.

   NOT be disabled by IXP participants unless it is needed to establish
   BGP sessions with a route server, and if possible should only be
   disabled for peers which are route servers.

   Route server operators should carefully consider the security
   practices discussed in [RFC7454], "BGP Operations and Security".




-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf