Re: [Idr] Mirja Kühlewind's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT)

Marco Marzetti <> Thu, 23 June 2016 13:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E70D8128874 for <>; Thu, 23 Jun 2016 06:27:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7u2IZKsVESRM for <>; Thu, 23 Jun 2016 06:27:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0DB3D12D126 for <>; Thu, 23 Jun 2016 06:18:38 -0700 (PDT)
Received: by (Postfix, from userid 33) id B77E274391; Thu, 23 Jun 2016 15:18:36 +0200 (CEST)
To: Robert Raszuk <>
X-PHP-Originating-Script: 0:rcube.php
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Thu, 23 Jun 2016 15:18:36 +0200
From: Marco Marzetti <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Message-ID: <>
User-Agent: Roundcube Webmail/1.1.5
Archived-At: <>
Cc: idr wg <>,
Subject: Re: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?=
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Jun 2016 13:27:47 -0000

On 2016-06-20 23:56, Robert Raszuk wrote:
> Hi Marco,
> Altering AS_PATH indeed does not happen that often. Let's put that one
> aside keeping in mind that practical use cases exists where adding an
> AS is needed which to me precludes "MUST".
> But I can't agree with statement that IXP RS "should be as transparent
> as possible to route propagation" as every IX which assists in routes
> handling offers extensive RS to client (and to some level even client
> to RS) filtering policies.
> Ref:
> That proves black on white that "transparency" is gone. Now the
> question is if we should RFC something which would be completely
> unpractical or unusable ?
> Many thx,
> R.


My apologies if it took me so long to reply.

Even if i agree on some of your points we obviously have very different 
And it is kinda funny that you've linked a documents that says

Maintain your peering policy
The route server has built in filters that allow you to maintain your 
peering policies

How could I maintain my peering policy if for whatever reasons the route 
server is adding its ASn in the PATH?

Anyway, as said, i agree that the are some very particular cases in 
which that is needed.
On top of all of them: the BGP stacks that rely on that behavior for 
whatever reason.

That said i would like to clarify that i'd really prefer that the author 
use MUST instead of SHOULD (because, in my opinion, we should have those 
stacks fixed instead of adjusting a standard to embrace them) but i 
agree that it may not be advisable for the time being.

So i think that we can use SHOULD and add further clarification that 
explains why that should be avoided when possible.