ietf
[Top] [All Lists]

Re: [Idr] Last Call: <draft-ietf-idr-ix-bgp-route-server-10.txt> (Internet Exchange BGP Route Server) to Proposed Standard

2016-05-27 02:00:29

On May 25, 2016, at 6:11 AM, Marco Marzetti <marco(_at_)lamehost(_dot_)it> 
wrote:

On 2016-05-25 00:43, The IESG wrote:
The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document:
- 'Internet Exchange BGP Route Server'
 <draft-ietf-idr-ix-bgp-route-server-10.txt> 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(_at_)ietf(_dot_)org mailing lists by 2016-06-07. Exceptionally, 
comments may be
sent to iesg(_at_)ietf(_dot_)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.
_______________________________________________
Idr mailing list
Idr(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/idr

All,

Beside i agree on the most part of this draft i would like to underline how 
bullet 2.2.2 breaks the the nature of BGP itself.

The exact part i am referring to is:
"""
As a route server does not participate in the process of forwarding
  data between client routers, and because modification of the AS_PATH
  attribute could affect route server client BGP Decision Process, 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.
"""

I firmly think that it really has to state "MUST NOT" instead of "SHOULD NOT".

From a route-server client point of view that breaks the natural BGP best 
selection process and forces you to purely rely on LOCAL_PREFERENCE which in 
turns breaks your traffic engineering because it forces you to 
prefer/not-prefer the prefixes learned over the route server in place of 
those learned, for instance, over a private session or another IXP.

Regards

-- 
Marco


Marco,

There are some IXP route servers that prepend their AS number to the AS_PATH, 
according to some things I’ve read, such as this Akamai presentation 
<http://peeringforum.bknix.co.th/2016/docs/Bob%20Lau%20(Akamai).pdf>.  My guess 
is the use of “SHOULD NOT” here reflects that this is not a recommended 
procedure.

Since your concerns about traffic engineering are operational in nature, 
perhaps you could address them via 
draft-ietf-grow-ix-bgp-route-server-operations.

Incidentally, idnits turned up an outdated reference: a later version (-15) 
exists of
draft-ietf-idr-add-paths-13.

—gregbo