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

From: Marco Marzetti <[email-masked]>
Date: Wed, 25 May 2016 15:11:55 +0200

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
> [email-masked] mailing lists by 2016-06-07. Exceptionally, comments may 
> be
> sent to [email-masked] 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
> [email-masked]
> 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

---

From: Marco Marzetti <[email-masked]>
Date: Wed, 25 May 2016 16:22:44 +0200

All,

Regards

-- 
Marco

---

From: Greg Skinner <[email-masked]>
Date: Thu, 26 May 2016 23:59:57 -0700

> On May 25, 2016, at 6:11 AM, Marco Marzetti <[email-masked]> wrote:
> 
>> The IESG has received a request from the Inter-Domain Routing WG (idr) to
>> [email-masked] mailing lists by 2016-06-07. Exceptionally, comments may be
>>   interconnection is a method of exchanging routing information between
> 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.
> 
> 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

---

From: Marco Marzetti <[email-masked]>
Date: Fri, 27 May 2016 12:08:08 +0200

On 2016-05-27 08:59, Greg Skinner wrote:
>> 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.
>> 
>> 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.
> 
> 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

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 31 May 2016 16:40:16 +0100

> those learned, for instance, over a private session or another IXP.

It doesn't "break" the decision process mechanism.  Localpref might be
ugly, but using it doesn't violate the bgp protocol.

This statement needs to be "MUST NOT".  Technically you can run a route
server even if you insert the intermediate ASN into the path.  The only
absolute "MUST" is that you mustn't change the next-hop; otherwise you
end up with a router instead of a route server.

RFC2119 is a pain because there is no way of differentiating between
"SHOULD NOT", meaning "on balance it would be a better idea not to do X"
and "SHOULD NOT", meaning "if you even _think_ about doing X, you need
your head examined and the only reason we specified SHOULD NOT instead
of MUST NOT in this situation because of some technicality that
prevented us from doing so".  The text in 2.2.2 veers slightly in the
direction of the latter interpretation.

Nick