On 2016-05-27 08:59, Greg Skinner wrote:
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 [1]. 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
Links:
------
[1] http://peeringforum.bknix.co.th/2016/docs/Bob%20Lau%20(Akamai).pdf
Dear Greg,
I have had private chats with Niels and Nick before i submitted my rant
and i understand their reasons, but i really don't agree with them.
In fact I think that the community should firmly discourage that
practice.
About draft-ietf-grow-ix-bgp-route-server-operations: this is the
relevant excerpt:
"""
As [I-D.ietf-idr-ix-bgp-route-server] suggests that route servers
should not modify the AS_PATH attribute, a consistency check on the
AS_PATH of an BGP route received by a route server client would
normally fail. It is therefore RECOMMENDED that route server clients
disable the AS_PATH consistency check towards the route server.
"""
The words "RECOMMEND" and "SHOULD" imply that there could be a valid
reason, but i can't find any.
Now, we may address that in this draft only, but it would lack common
sense because the theory would let room to a practice that is denied in
the operations.
Regards
--
Marco