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

[Marco Marzetti <[e-mail]>]

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
> 
> 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

Dear Robert,

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

Regards

-- 
Marco