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