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 <marco@xxxxxxxxxxx>
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