Re: [Idr] AD Review of draft-ietf-idr-large-community-09

Job Snijders <job@ntt.net> Fri, 02 December 2016 17:28 UTC

Return-Path: <job@ntt.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 553B51295CE; Fri, 2 Dec 2016 09:28:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.831
X-Spam-Level:
X-Spam-Status: No, score=-4.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_SOFTFAIL=0.665] 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 h0MPI7GgCHOU; Fri, 2 Dec 2016 09:28:34 -0800 (PST)
Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 220681295B6; Fri, 2 Dec 2016 09:28:34 -0800 (PST)
Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <job@ntt.net>) id 1cCrdP-0000y9-Pc (job@us.ntt.net); Fri, 02 Dec 2016 17:28:32 +0000
Date: Fri, 02 Dec 2016 18:28:28 +0100
From: Job Snijders <job@ntt.net>
To: heasley <heas@shrubbery.net>
Message-ID: <20161202172828.GA26987@hanna.meerval.net>
References: <CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com> <94f48779-14c8-0ec0-93ef-69eeba49e5be@gmail.com> <8B6BA07A-D636-4D8C-8B02-A5CB05538AAF@cisco.com> <20161202171453.GG3403@shrubbery.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20161202171453.GG3403@shrubbery.net>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/BSwGT634TCgkF2DbW_U0lmoUu9A>
Cc: "draft-ietf-idr-large-community@ietf.org" <draft-ietf-idr-large-community@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] AD Review of draft-ietf-idr-large-community-09
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, 02 Dec 2016 17:28:35 -0000

On Fri, Dec 02, 2016 at 05:14:53PM +0000, heasley wrote:
> 0 and 4294967295 are reserved ASNs, as is 65535 and 65535 is used by
> RFC 1997 communities for well-known communities.  It is the intention
> to use 65535 if in the future it is desirable to define large
> well-known communities.  The other two should not be used because they
> are invalid ASNs and could lead to collision.  This all seems prudent
> to me.
> 
> > Assuming that you would prefer the operators NOT to use 0, 65535,
> > and 4294967295, then here’s my suggestion:
> > 
> > OLD> (Section 2)
> > 
> >    The Global Administrator field is intended to allow different
> >    Autonomous Systems to define BGP Large Communities without collision.
> >    This field SHOULD either be one of the reserved values as defined
> >    below, or an Autonomous System Number (ASN).  If it is a reserved
> >    value, then the Local Data Parts are as defined by the reserved
> >    value.  If it is an ASN then the Local Data Parts are to be
> >    interpreted as defined by the owner of the ASN.
> > 
> > NEW>
> > 
> >    The Global Administrator field is intended to allow different
> >    Autonomous Systems to define BGP Large Communities without collision.
> >    This field SHOULD be an Autonomous System Number (ASN).  The use of
> >    Reserved ASNs (0 [RFC7607], 65535 and 4294967295 [RFC7300]) is NOT
> >    RECOMMENDED.
> > 
> > …and then eliminate Section 5…
> 
> no, do not eliminate section 5.

The text that used to be section 5 is better served through a separate
document I think. Jon Mitchell and myself are working on a document to
assist in that matter. This document is not published yet.

The first sentence of section 5 was moved into the section 2. The second
sentence says what the document is _not_, and a forward looking
statement of what could happen. There is no cost to removing that if we
carry that torch over into a new document. Let me know if you want to
help work on draft-mitchell-idr-large-communities-registry.

Kind regards,

Job