Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016)

Job Snijders <job@instituut.net> Fri, 10 June 2016 09:43 UTC

Return-Path: <job@instituut.net>
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 6DBFF12D0E3 for <idr@ietfa.amsl.com>; Fri, 10 Jun 2016 02:43:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com
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 reuTlXU9-e2B for <idr@ietfa.amsl.com>; Fri, 10 Jun 2016 02:43:28 -0700 (PDT)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45944128E18 for <idr@ietf.org>; Fri, 10 Jun 2016 02:43:28 -0700 (PDT)
Received: by mail-wm0-x235.google.com with SMTP id m124so94229459wme.1 for <idr@ietf.org>; Fri, 10 Jun 2016 02:43:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=8TaR8wBR4jngovQTgY3FHOHosAi+hUGTOi1qmoqHYKo=; b=sqIW7ki8dtK1eW9IQCEyz0CX2nZxJatdriyjOfMWY/PWFyIO7IxFh5203wwyNp+ocv vppD+KweFJMH7iS9BZVgrWolpow5mAnHK50kUtBGgqJVkq3nJUmA+Y67amX3G1p1zIks zqaX1fc+qTJ/cabDvnC38spOzDZqBh95wG08UUsDZLgdynHs/6xuBULxylBcDbGXCBij 1WlzWyNKAV+1HDp7PqY9QCyibSIBXbk+5X+4QkxaNWKElmEBK3lsEXlHwvd195icNXhO xlZ4Jio0c9lGHH+qCc0owqtEjncHyTs+zJH5tpUe6+aY2FRHV/2RQDPWmsJEgveyszJ8 RBeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=8TaR8wBR4jngovQTgY3FHOHosAi+hUGTOi1qmoqHYKo=; b=e5KnHtvGhYTx6olQVZXQDz9QEaEOve3GlNWIrAoDXozziQsFNY8susHzn1VrpmeN0T YlAMrODIw2wFGlDk7u+0iITCnqxrQhKJ0M1Wo7VbrhC5skAI49CM5Fl6QDkAkfmw6QtN daGBr4GjBSiE836k62wy1AfChNeDfaiO+NaEcPj9sd4INGuunnprvUkFX6FtFNmtjryL bACNmUkU7yiZRo7rWcY+7IYb5KG/2Z3q/NSsk0LVuFDhf0QMW12uSHV5lFk64RYgFTxR cA8/7UV6zn6OcC1bv3i7Z+7NsRmrFKZxN81M7TzorDqK5yAlJmafk35qT5TJptZUfMkl iIeg==
X-Gm-Message-State: ALyK8tK41MnhZl4VE8HGDLuXlW5T+mjWOoORifJWWDJOlseSo6gJJ8MjJVO3ODpi1OLyYA==
X-Received: by 10.194.114.193 with SMTP id ji1mr1371841wjb.55.1465551806562; Fri, 10 Jun 2016 02:43:26 -0700 (PDT)
Received: from localhost ([2001:67c:208c:10:f948:e3f7:3d8c:2db8]) by smtp.gmail.com with ESMTPSA id zg2sm11492818wjb.1.2016.06.10.02.43.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Jun 2016 02:43:25 -0700 (PDT)
Date: Fri, 10 Jun 2016 11:43:24 +0200
From: Job Snijders <job@instituut.net>
To: Randy Bush <randy@psg.com>
Message-ID: <20160610094324.GH2524@Vurt.local>
References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> <20160609163225.GC2524@Vurt.local> <m2mvmuupax.wl%randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <m2mvmuupax.wl%randy@psg.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/TtEvM48q3uTBAE2HUDFmuCd2VVU>
Cc: idr@ietf.org, draft-ietf-idr-route-leak-detection-mitigation@ietf.org, "'John G. Scudder'" <jgs@bgp.nu>, Susan Hares <shares@ndzh.com>
Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016)
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: Fri, 10 Jun 2016 09:43:30 -0000

Hi Randy,

On Thu, Jun 09, 2016 at 12:37:10PM -0700, Randy Bush wrote:
> > Secondly (and more importantly), the roles are not necessarily a BGP
> > session-specific characteristic, but rather a prefix-specific
> > property.  The proposed OPEN method does not provide for this level
> > granularity if I am reading it correctly. The method would affect all
> > prefixes exchange over a BGP session, without exception.
> 
> i can not be sure, as you lack example. but the example i commonly use
> is when A gives B local peering and also sells B global transit.
> today, this is two separate sessions. do you use another approach; not
> can think of, but actualy use?

Yes, using two separate sesssions to deliver the two separate products
is a common (and valid) approach. 

> are there other real-world examples?  just trying to understand.

I won't share the company names involved, but on multiple occasions, my
employer has engaged in providing transit between two peering partners.
This was either done unilaterally (when my employer has a desire to keep
the internet together), or part of a bilateral commerical agreement. In
other words I cannot assume the BGP peer will cooperate with its role
assignment.

In all those cases, under the "OPEN" approach, we'd flag all involved
parties as 'peer', and the peer would have assigned us the role 'peer'
too, except that they weren't in some specific contexts.

There are at least two use-cases:

    - some prefixes are 'peering', others are 'transit': this has
      happened for instance when redistributing root-server prefixes
      that were behind a peer to other peers.
    - all prefixes are peering, except they should be redistributed to
      peer X too (can be decided unilaterally or bilaterally).

Reflecting on the two examples, the common theme is that if you are a
stub network (e.g. one does NOT provide IP Transit using BGP to your
customers) the "OPEN"-approach may be a reasonable approach, but for a
transit network the approach feels too restrictive.

Kind regards,

Job