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

heasley <heas@shrubbery.net> Fri, 02 December 2016 17:14 UTC

Return-Path: <heas@shrubbery.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 46E4912952F; Fri, 2 Dec 2016 09:14:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level:
X-Spam-Status: No, score=-7.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, 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 WfUOeidUodoH; Fri, 2 Dec 2016 09:14:53 -0800 (PST)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F22129598; Fri, 2 Dec 2016 09:14:53 -0800 (PST)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 7DD7F7A673; Fri, 2 Dec 2016 17:14:53 +0000 (UTC)
Date: Fri, 2 Dec 2016 17:14:53 +0000
From: heasley <heas@shrubbery.net>
To: "Alvaro Retana (aretana)" <aretana@cisco.com>
Message-ID: <20161202171453.GG3403@shrubbery.net>
References: <CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com> <94f48779-14c8-0ec0-93ef-69eeba49e5be@gmail.com> <8B6BA07A-D636-4D8C-8B02-A5CB05538AAF@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8B6BA07A-D636-4D8C-8B02-A5CB05538AAF@cisco.com>
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/OdOcvulUBt2vwzKP7ahfZfh3teY>
Cc: "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-large-community@ietf.org" <draft-ietf-idr-large-community@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@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:14:55 -0000

Fri, Dec 02, 2016 at 01:46:50PM +0000, Alvaro Retana (aretana):
> On 12/2/16, 1:31 AM, "Ignas Bagdonas" <ibagdona.ietf@gmail.com>; wrote:
> > > C2. There seems to be a contradiction in the expected use of reserved Global Administrator
> 
> > > values.  Section 2 says that the “Global Administrator field…SHOULD either be one of the reserved
> 
> > > values as defined below, or an Autonomous System Number (ASN)”, but later Section 5 says: “The
> 
> > > following Global Administrator values are reserved: 0, 65535, and 4294967295.  Operators SHOULD
> 
> > > NOT use these Global Administrator values.”   IOW: “SHOULD use one if the reserved values” and
> 
> > > “SHOULD NOT use the reserved values” contradict each other.  It seems to me that because 0,
> 
> > > 65535, and 4294967295 are already reserved ASNs, *and* that “the Local Data Parts are to be
> 
> > > interpreted as defined by the owner of the ASN”, then only assigned ASNs should ever be used ---
> 
> > > *and* given that it is not an error to use an value, then there is no real advantage in reserving
> 
> > > anything (again!). Suggestion: reference the RFCs where 0, 65535, and 4294967295 are reserved
> 
> > > and just say that those numbers SHOULD NOT be used because if a Special Use Large Community is
> 
> > > ever defined, those values may be used.
> 
> > For section 2: Global Administrator field SHOULD be an Autonomous System Number (ASN) or one of
> 
> > the reserved values defined in Section 5.
> 
> > For section 5: Global Administrator values corresponding to reserved use Autonomous System
> 
> > Number values of 0 [RFC7607], 65535 [RFC7300], and 4294967295 [RFC7300] are reserved.
> 
> > Would this work?
> 
> Question for you:  do you want the operators to use 0, 65535, and 4294967295 whenever they want (which is what the new text says), OR, do you want them not to use them because they could be used later for a special purpose (which is what the original text seemed to indicate)??
> 
> I’m having a hard time with this document “reserving” any value because the number space is not really one where values are assigned (in the typical IANA sense: create a registry, etc. – and I doubt you want to make it that way)…but the contents can be (SHOULD) what is contained in an already existing registry (ASNs) that has distributed control.

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.

> 
> 
> If you really want operators not to use the Reserved ASNs ever because a special use may be though up later, then use “MUST NOT” above.
>