Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt

Nick Hilliard <nick@foobar.org> Wed, 05 October 2016 15:16 UTC

Return-Path: <nick@foobar.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 A4956129703 for <idr@ietfa.amsl.com>; Wed, 5 Oct 2016 08:16:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 r8nbeWgTUjbW for <idr@ietfa.amsl.com>; Wed, 5 Oct 2016 08:16:13 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 957A01296C2 for <idr@ietf.org>; Wed, 5 Oct 2016 08:16:13 -0700 (PDT)
X-Envelope-To: idr@ietf.org
Received: from crumpet.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u95FG8pj035914 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Oct 2016 16:16:09 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be crumpet.local
Message-ID: <57F51937.70103@foobar.org>
Date: Wed, 05 Oct 2016 16:16:07 +0100
From: Nick Hilliard <nick@foobar.org>
User-Agent: Postbox 5.0.3 (Macintosh/20160930)
MIME-Version: 1.0
To: Job Snijders <job@ntt.net>
References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local>
In-Reply-To: <20161003095936.GC20697@Vurt.local>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/18nb5qikFQY9oaDBNJL0CdsEF0Y>
Cc: idr@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.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: Wed, 05 Oct 2016 15:16:15 -0000

Job Snijders wrote:
> On Mon, Oct 03, 2016 at 10:13:02AM +0100, t.petch wrote:
>> I think Section 3 needs qualifying; it should allow for there being no
>> communities in the routes being aggregated; and what happens if the
>> communities are a mix of large and not large?  (Something that RFC4360
>> s.6 addresses)
> 
> If we add the following, would that address your concern?
> 
>     "A route may carry both the BGP Communities attribute, as defined in
>     [RFC1997]), and the Extended BGP Communities attribute, as defined
>     in [RFC4360], and the Large BGP Community attribute. In this case,
>     the BGP Communities attribute is handled as specified in [RFC1997],
>     and the Extended BGP Communities attribute is handled as specified
>     in [RFC4360], and the Large BGP Community is handed as specified in
>     this document."

There are two germane issues when there are multiple types of
communities attached to a route: exclusivity and precedence.

For exclusivity, the issue is whether you can you attach a large bgp
community to a prefix as well as an another type of community. It would
be so bizarre an idea to suggest you couldn't do this that it doesn't
even need to be mentioned that it's legit. If the document doesn't
mention exclusivity, the only possible interpretation is that it must be
permitted.  TBH it would be rather peculiar to even mention that it's
ok, almost as if these new large bgp communities were the new cool kids
on the block and they're like totes ok co-existing with other types of
communities that have been around for ages.  It's faintly ridiculous.

Precedence must a locally defined issue because anything else would
result in an enormous bunfight about whose BGP Communities rfc was the
biggest and most important.  Again, it is better not to say anything
here, because if nothing is said, then the ietf is not making any
judgements about how to interpret community values, which is fully
consistent with how communities have always been interpreted in the past.

This paragraph should be omitted completely. It adds nothing.

Nick