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

[Robert Raszuk <[e-mail]>]

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 <[e-mail]> wrote:

> On 2016-06-01 13:17, Nick Hilliard wrote:
>
>> Marco Marzetti wrote:
>>
>>> 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.
>>>
>>
>> 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
>>
>
> 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
>
>