Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-00.txt]

Jeffrey Haas <jhaas@pfrc.org> Tue, 01 November 2016 18:55 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 7210E1293F5 for <idr@ietfa.amsl.com>; Tue, 1 Nov 2016 11:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level:
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 vrkOhmY7xt9p for <idr@ietfa.amsl.com>; Tue, 1 Nov 2016 11:55:29 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD9812989F for <idr@ietf.org>; Tue, 1 Nov 2016 11:55:29 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 432711E337; Tue, 1 Nov 2016 14:58:00 -0400 (EDT)
Date: Tue, 1 Nov 2016 14:58:00 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Nick Hilliard <nick@foobar.org>
Message-ID: <20161101185759.GA23458@pfrc.org>
References: <20161031205515.GA25507@pfrc.org> <5818E126.2090202@foobar.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5818E126.2090202@foobar.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/-fQI_TrZXaQ4lRFzCs7OZ0NR_MY>
Cc: idr@ietf.org
Subject: Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-00.txt]
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: Tue, 01 Nov 2016 18:55:31 -0000

On Tue, Nov 01, 2016 at 06:38:30PM +0000, Nick Hilliard wrote:
> Jeffrey Haas wrote:
> > There's a larger conversation to be had about proper stewardship and use of
> > code points of all sorts, but path attributes have our attention for the
> > moment.
> > 
> > A quick draft for consideration and to motivate discussion.
> 
> this is an interesting approach and I like it.  Despite the warnings in
> the document, vendors are likely to want to do vendor-specific things on
> a permanent basis, but this is probably unavoidable and not necessarily
> a bad thing either - there are plenty of other situations where
> vendor-specific attributes are used to good effect.

As I mentioned, discussion. :-)

One of the general issues with vendor code spaces is that it *does* motivate
vendor-specific work.  That's not necessarily a bad thing in the general
case, but when we talk BGP we have to have a firm focus toward what the
global implications of such a thing means.

The document attempts to setup the expectation of filterability.  Right now,
path attribute filtering as a general practice is hazardous to the
incremental deployment of features on expects to work across the global
Internet.  

A feature such as this one, perhaps extended with a per-attribute form of
draft-ietf-idr-bgp-attribute-announcement along with enough information to
figure out when filtering wasn't done could provide some safety.

The related changes to this proposal would be to simply add the 4-octets of
the attribute announcement scoping and potentially the attaching AS.
However, given even such vendor features are likely to need to work in an
inter-as fashion, generating scopes of containment become tricky.

> 
> I'd like to see this idea progress.
> 
> Nick