Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)

Jeffrey Haas <jhaas@pfrc.org> Tue, 18 October 2016 20:38 UTC

Return-Path: <jhaas@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 F3CC4129472 for <idr@ietfa.amsl.com>; Tue, 18 Oct 2016 13:38:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.332
X-Spam-Level:
X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.431, 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 jbsnCtc67E7Z for <idr@ietfa.amsl.com>; Tue, 18 Oct 2016 13:38:02 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4215E129460 for <idr@ietf.org>; Tue, 18 Oct 2016 13:38:02 -0700 (PDT)
Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 7FC171E1F0; Tue, 18 Oct 2016 16:40:10 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_6450A86E-BD00-4A38-AB01-42D1E18F2623"
Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <20161018191521.GT95811@Vurt.local>
Date: Tue, 18 Oct 2016 16:38:00 -0400
Message-Id: <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org>
References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local>
To: Job Snijders <job@ntt.net>
X-Mailer: Apple Mail (2.3226)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/27rqXSFEGxJvTlwLI64lJGHJB1Q>
Cc: heasley <heas@shrubbery.net>, IETF IDR WG <idr@ietf.org>, Sue Hares <shares@ndzh.com>
Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/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: Tue, 18 Oct 2016 20:38:04 -0000

> On Oct 18, 2016, at 3:15 PM, Job Snijders <job@ntt.net> wrote:
> 
>> 
>> Part of the idea behind reserving 65535:*:* was to reserve a space that
>> could later be used for well-knowns, if that was desired - but to not
>> spend time now arguing about details of what well-knowns are necessary.
>> 
>> 0:*:* and 4294967295:*:* mimics rfc1997 and the reserved ASNs.
> 
> Jeff argues that a justification should be added. Maybe someone can
> pitch in one or two sentences that explain why these are reserved?

That's certainly part of it.  While I think many people can see the reason why you might want to do such a reservation, to do so you should have a practical reason in the document.

For the 65535:*:* case, for symmetry with RFC 1997, you'd probably want to note that if it's used for that symmetry that either the existing well known community registry is used at IANA or that a new one would need to be created.  Alternatively, you just say the work is expected and defer to a future document.

Note by doing this, you're setting up some expectations about translation of communities from one space to another.  FWIW, I don't recommend this and simply suggest that you recommend *not* using these for common use in case someone decides that they want to do so.  I know your organization and others such as Deutsche Telecom have some thoughts about what translation infrastructure might look like, and such mechanisms would have impact.

With regard to the 0: and max-uint32: cases, after dealing with the headaches associated with helping with documents such as the as0 and RFC 7300 and putting in some restrictions in the configuration... followed by having to take them away, I'm very reluctant to put in anything beyond "we think it's a bad idea to use these, so pretty please don't"

-- Jeff (ask me about my RFC 7300 hate mail over beer...)