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, 01 Jun 2016 12:51:02 +0200

On 2016-05-31 17:40, Nick Hilliard wrote:
> Marco Marzetti 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.
>> 
>> 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.
> 
> 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

Nick,

I agree with you that you can run a route server and insert your ASn in 
the path, but i think that is a lack of common sense which brings only 
contraries and no benefits.

About RFC2119: It says that "SHOULD NOT" implies a valid reason to 
accept a behavior, but i can't find any.

Regards

-- 
Marco

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 01 Jun 2016 12:17:00 +0100

> accept a behavior, but i can't find any.

I agree that it is not a clever thing to do. The valid reason to accept
the behaviour is that it works in practice: some IXPs have done this in
production, in many cases for years.

There is a secondary reason: some rs client bgp stacks don't support the
option to accept an AS path from the RS where the leftmost entry on the
AS path != peeras.

These are not "good" reasons in the sense that they mandate behaviour
which is suboptimal, but they are valid reasons.

Nick

---

From: Marco Marzetti <[email-masked]>
Date: Wed, 01 Jun 2016 14:12:23 +0200

Nick,

I think that we should define a standard that addresses and corrects 
those non-clever behaviors rather than embrace them.

My point is: even if they work in the real world, they do because of the 
workarounds that other people put in place and they bring no benefits.

Regards

-- 
Marco

---

From: David Huberman <[email-masked]>
Date: Wed, 1 Jun 2016 07:21:05 -0500

Pardon the top post. 

Marco, we do these things in the real world generally because we have to, not because we don't know any better. IX participants come in all kinds of flavors, and some have to turn some really weird BGP knobs to ensure everything works.  

I very much appreciate your position -- clean, optimal standards are a great goal -- but real world operability is the true MUST HAVE of a standard.

David

> On Jun 1, 2016, at 7:12 AM, Marco Marzetti <[email-masked]> wrote:
> 
> I think that we should define a standard that addresses and corrects those non-clever behaviors rather than embrace them.
> 
> My point is: even if they work in the real world, they do because of the workarounds that other people put in place and they bring no benefits.
> 
> Regards
> 
> -- 
> Marco
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 1 Jun 2016 14:35:45 +0200

Hi Marco,

Let's also observe that route server we are defining here which effectively
"reflects" between EBGP sessions has much more wider use then Internet
Exchange points.

There is more architectures which use EBGP and for scale full meshing them
is a headache (at least till we progress the auto discovery proposal
further). And some of those ASes may be private hence inserting your AS
during private removal is rather a must.

I would recommend that we focus on the recommendation how to build IX in
the companion draft in GROW. Here in IDR we should rather accommodate all
use cases.

Many thx,
Robert

On Wed, Jun 1, 2016 at 2:12 PM, Marco Marzetti <[email-masked]> wrote:

> I think that we should define a standard that addresses and corrects those
> non-clever behaviors rather than embrace them.
>

---

From: Marco Marzetti <[email-masked]>
Date: Wed, 01 Jun 2016 14:46:19 +0200

On 2016-06-01 14:35, Robert Raszuk wrote:
> Hi Marco,
> 
> Let's also observe that route server we are defining here which
> effectively "reflects" between EBGP sessions has much more wider use
> then Internet Exchange points.
> 
> There is more architectures which use EBGP and for scale full meshing
> them is a headache (at least till we progress the auto discovery
> proposal further). And some of those ASes may be private hence
> inserting your AS during private removal is rather a must.
> 
> I would recommend that we focus on the recommendation how to build IX
> in the companion draft in GROW. Here in IDR we should rather
> accommodate all use cases.
> 
> Many thx,
> Robert
> 
> My point is: even if they work in the real world, they do because of
> the workarounds that other people put in place and they bring no
> benefits.
> 
> Regards
> 
> --
> Marco

Dear Robert,

Noted, thanks.
Hence "SHOULD NOT" is the right choice.

Regards

-- 
Marco