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

Job Snijders <job@ntt.net> Thu, 20 October 2016 21:59 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 0CAB212967B for <idr@ietfa.amsl.com>; Thu, 20 Oct 2016 14:59:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.365
X-Spam-Level:
X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_SOFTFAIL=0.665, WEIRD_QUOTING=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 ZWeCnLZp4Am7 for <idr@ietfa.amsl.com>; Thu, 20 Oct 2016 14:59:49 -0700 (PDT)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 964DB1294F9 for <idr@ietf.org>; Thu, 20 Oct 2016 14:59:49 -0700 (PDT)
Received: by mail3.dllstx09.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 1bxLNK-0004hW-Qz (job@us.ntt.net); Thu, 20 Oct 2016 21:59:48 +0000
Date: Thu, 20 Oct 2016 16:59:38 -0500
From: Job Snijders <job@ntt.net>
To: Jeffrey Haas <jhaas@pfrc.org>
Message-ID: <20161020215938.GE1074@Vurt.local>
References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.0 (2016-08-17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Q6O7LH2HKZ5sRuYHnrskmRxk9DE>
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: Thu, 20 Oct 2016 21:59:51 -0000

Hi working group,

On Tue, Oct 18, 2016 at 04:38:00PM -0400, Jeffrey Haas wrote:
> 
> > 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"

After some off-list back and forth with John Heasley, Adam Chappell,
Jeff Haas and the authors, we came up with the following text to address
the above raised concern.

This will be part of -04.

""""
5.  Reserved Large BGP Community values

   The following Global Administrator values are reserved: 0 (the first
   ASN) [RFC7607], 65535 (UINT_MAX) and 4294967295 (the last ASN)
   [RFC7300].  Operators SHOULD NOT use these Global Administrator
   values.

   Although this document does not define any Special-Use Large BGP
   Communities, the Global Administrator values specified above could be
   used if there is a future need for them.
"""

A preview of the -03 / -04 diff is available here:

https://htmlpreview.github.io/?https://github.com/large-bgp-communities/large-bgp-communities/blob/master/draft-ietf-idr-large-community-04-from-3.diff.html

Kind regards,

Job