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

Job Snijders <job@instituut.net> Thu, 09 June 2016 16:32 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 C8F5D12D87C for <idr@ietfa.amsl.com>; Thu, 9 Jun 2016 09:32:48 -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=ham 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 zbonRDJ6mMtk for <idr@ietfa.amsl.com>; Thu, 9 Jun 2016 09:32:47 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 C6BF712D861 for <idr@ietf.org>; Thu, 9 Jun 2016 09:32:46 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id v199so115223252wmv.0 for <idr@ietf.org>; Thu, 09 Jun 2016 09:32:46 -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=YYH3f438f8+F2Cckpb6ptz14JLrygX1Nj6eD4+Q6kDU=; b=GKWvw9uqYoybLY8MbgWgH303uBjioHLJL2ApdwYREJ7s8885dT/J1XwaJbojYhJSgY uJF87ADieg7oeTl5ISwIXz5fl1PaSc+qvuMtuVnzaStPmvzHzO47EZaxxu6wUVZV1E+d 7ONpn+z5Nani+1t+L4Mk9lwBN9MNw44Ug6auY0A+Ba/4DSReE3b93pQ/opUyb+L72Rb2 qyLWJK2L1NuyQDHxi3DuTVhzLfTiLK88eqk2sePEZ6XzV6SGBWMhN16nYlFycIPPA8Bn /EKFkrKzHeTzYTGezTKRYFMA8Zt3WcRA72D/PAS6LhbcohFFHKm3J3F8IA6v3WON6Kjs LpSQ==
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=YYH3f438f8+F2Cckpb6ptz14JLrygX1Nj6eD4+Q6kDU=; b=UHYS7rysJCoqlYGfyIJ6ZW+mi0m5geDSjh5z0a7SPAHUeV9doB9V9t8hGgWCsZ8EjX DpzG2E0LoTcahORnZXeYG3WmsgsegFEGPangy5SK7puyeeRP7wX/tZaa30cXhR/DTnXD DJhtGmdZ0ScDfk3brnh5w0srzfQwjzfr5Upa3bj+2RyIXCDcu1ukC8rF7RoYgheLZkEJ +tsAzAii8Gh/yP4iF98BPnWsUeZklspcHTjLEDBLEnQi7NxCwLWctL3YP+130VSzybuC dH6lp9KLlBhRML7NHmIQtWp3IZwSPJ+Phb1SJJxk5U7OzLQH1nLTeKSlSkXey+O+3XCi cGxA==
X-Gm-Message-State: ALyK8tIzQNr7ie9EjsgyBzllejCIy9+05g6CfdjRA+PwjSmzo7zdpMqU+aBh9cseGVooKg==
X-Received: by 10.28.46.71 with SMTP id u68mr10581786wmu.97.1465489964425; Thu, 09 Jun 2016 09:32:44 -0700 (PDT)
Received: from localhost ([2001:67c:208c:10:f948:e3f7:3d8c:2db8]) by smtp.gmail.com with ESMTPSA id u70sm21423517wmd.4.2016.06.09.09.32.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jun 2016 09:32:43 -0700 (PDT)
Date: Thu, 09 Jun 2016 18:32:25 +0200
From: Job Snijders <job@instituut.net>
To: Susan Hares <shares@ndzh.com>
Message-ID: <20160609163225.GC2524@Vurt.local>
References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.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/U5lPXjvG-Gz3sqTUBDjqO60ME9o>
Cc: idr@ietf.org, draft-ietf-idr-route-leak-detection-mitigation@ietf.org, "'John G. Scudder'" <jgs@bgp.nu>
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: Thu, 09 Jun 2016 16:32:49 -0000

Dear Authors, IDR group, 

I'd like to start by thanking you for putting thought and time into the
route leak problem space. It is encouring to see fellow operators engage
with the IETF community to address actual, day to day issues.

On Mon, Jun 06, 2016 at 12:40:19PM -0400, Susan Hares wrote:
> This begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-policy.
> You can find the draft at: 
> 
> https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/.
> 
> In your comments on adopting this draft, please indicate: 
> 
> 1)      "Support" or "no Support" 

No support.

> 2)      Do you feel this is a way to prevent route leaks? 

It certainly is a way.

> 3)      Are there any deployment issues that might prevent deployment
> of this enhancement to BGP Open? 

I do not think that the OPEN moment in the lifecycle of a BGP session is
the appropiate place for policy constructs like this. In practise it is
probably not an issue when you have to flap a BGP session to change the
relation between two ASNs, but it would be nice if this is not required
(like today on most platforms).

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.

> 4) Does this interact with
> draft-ietf-idr-route-leak-detection-mitigation? 

Yes, in terms of the problem being addressed.

Kind regards,

Job