Re: [Idr] Benoit Claise's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT)

joel jaeggli <joelja@bogus.com> Wed, 15 June 2016 15:16 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B37A12D89F; Wed, 15 Jun 2016 08:16:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.326
X-Spam-Level:
X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ul52kznhrfL1; Wed, 15 Jun 2016 08:16:45 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8D5812D883; Wed, 15 Jun 2016 08:16:44 -0700 (PDT)
Received: from mb-2.local ([8.18.217.194]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id u5FFGe0K026822 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 15 Jun 2016 15:16:40 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host [8.18.217.194] claimed to be mb-2.local
To: Robert Raszuk <robert@raszuk.net>, Benoit Claise <bclaise@cisco.com>
References: <20160615150104.20296.66089.idtracker@ietfa.amsl.com> <CA+b+ERkmOfVFrBp52zNg=iFVejKnsiUXhiH_D-=wRj77VOyy=g@mail.gmail.com>
From: joel jaeggli <joelja@bogus.com>
Message-ID: <bb530851-fde5-f9fe-d9b8-48133740fa38@bogus.com>
Date: Wed, 15 Jun 2016 08:16:41 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2
MIME-Version: 1.0
In-Reply-To: <CA+b+ERkmOfVFrBp52zNg=iFVejKnsiUXhiH_D-=wRj77VOyy=g@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="3JMixVoPRctxHjfoSBWgTPTO89xW6IOxv"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/HWSWoiIl4tgfO-Vym2fWsihLkQw>
Cc: idr wg <idr@ietf.org>, idr-chairs@ietf.org, The IESG <iesg@ietf.org>, Susan Hares <shares@ndzh.com>, draft-ietf-idr-ix-bgp-route-server@ietf.org
Subject: Re: [Idr] Benoit Claise's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jun 2016 15:16:46 -0000

On 6/15/16 8:04 AM, Robert Raszuk wrote:
> Benoit,
> 
> 
>> IXP, is this correct to say that all bilateral interconnections should be removed?
> 
> Not really. It is quite common to see IX participants having direct
> peerings as well as peerings via RS. All is driven by BGP policies both
> at the peering routers directly as well as on the RS.

When networks grow and add multiple ports to an IX it is common to
migrate neighbors from the mlpe to blp sessions in part so you have
better coordination and control (the hidden route problem again, also it
unreasonable to expect routes learned via the route servers to load
balance between ports etc).

So in fact both styles will almost always be well represented on an
exchange, with the cavaet that the more restrictive your peering policy
is the less likely you are to appear on or accept routes from the mlpe.

> Thx,
> R.
> 
> 
> On Wed, Jun 15, 2016 at 5:01 PM, Benoit Claise <bclaise@cisco.com
> <mailto:bclaise@cisco.com>> wrote:
> 
>     Benoit Claise has entered the following ballot position for
>     draft-ietf-idr-ix-bgp-route-server-11: No Objection
> 
>     When responding, please keep the subject line intact and reply to all
>     email addresses included in the To and CC lines. (Feel free to cut this
>     introductory paragraph, however.)
> 
> 
>     Please refer to
>     https://www.ietf.org/iesg/statement/discuss-criteria.html
>     for more information about IESG DISCUSS and COMMENT positions.
> 
> 
>     The document, along with other ballot positions, can be found here:
>     https://datatracker.ietf.org/doc/draft-ietf-idr-ix-bgp-route-server/
> 
> 
> 
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
> 
>     >From an operational point of view, when an ISP wants to go change from
>     bilateral interconnections to the multilateral interconnection
>     within one
>     IXP, is this correct to say that all bilateral interconnections
>     should be
>     removed?
>     So that basically the ISP must chose between the two models, and not
>     combined them? If this is the case, it should be mentioned.
>     I thought it was clear to me until I saw figure 1: The dotted line
>     is the
>     IXP or the IXP Route Server?
>     At first glance, I thought that it was the IXP and that AS1 was
>     connected
>     to the IXP Route Server while still having a bilateral connection with
>     AS4.
>     I hope now that the dotted line is the IXP Route Server, otherwise I've
>     confused.
> 
> 
>