Re: [Idr] [GROW] Question about BGP Large Communities

Nick Hilliard <nick@foobar.org> Wed, 05 February 2020 10:15 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 55DC31207FD; Wed, 5 Feb 2020 02:15:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 pmWbNFJwa5Rb; Wed, 5 Feb 2020 02:15:14 -0800 (PST)
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 2DAA71207FC; Wed, 5 Feb 2020 02:15:13 -0800 (PST)
X-Envelope-To: idr@ietf.org
Received: from cupcake.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 015AErJH030031 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Feb 2020 10:14:55 GMT (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 cupcake.local
To: Zhuangshunwan <zhuangshunwan@huawei.com>
Cc: "idr@ietf.org" <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org>
References: <DM6PR09MB54489301E52DD711E031400984030@DM6PR09MB5448.namprd09.prod.outlook.com> <BN6PR11MB1890AA431F63030DFE310902C0030@BN6PR11MB1890.namprd11.prod.outlook.com> <CAOj+MMH-xff0VUBy5UZZp7FH7_ES5A5ZCcUqFin2UP0hOnpjug@mail.gmail.com> <5603F4C9-7ECD-4A9C-AF81-49AE292CEE83@cisco.com> <CAOj+MMF3K6jCp+CDg92ua7qH5hkQ1V+g0JoFt_zf+zCogwVZ7g@mail.gmail.com> <90fab3d5ec794e95be0d86cae2d4a235@huawei.com> <CAH1iCirCG8vXXRJPJgaYbCCvsxNtFvBha39Hs2a3xVYkCV=SEQ@mail.gmail.com> <19AB2A007F56DB4E8257F949A2FB9858E5FFFD27@NKGEML515-MBX.china.huawei.com>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <5bdaf912-5fa7-0bab-6f4d-b18f5a2ee016@foobar.org>
Date: Wed, 05 Feb 2020 10:14:52 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.11
MIME-Version: 1.0
In-Reply-To: <19AB2A007F56DB4E8257F949A2FB9858E5FFFD27@NKGEML515-MBX.china.huawei.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/o7_9klgIBZ3iM6ox6QpBesipzFQ>
Subject: Re: [Idr] [GROW] Question about BGP Large Communities
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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 Feb 2020 10:15:19 -0000

Zhuangshunwan wrote on 05/02/2020 09:00:
> In my opinion, when we apply a new function from IANA, we will have to 
> deploy some extra route policies to set and parse the specific function 
> as your suggested way.
> 
> With the increase of new functions, the route policies deployed will 
> become more and more complicated.

A WKC will generally describe a specific function or set of actions to 
be applied to a prefix. If the WKC also encodes an administrator ASN or 
a target ASN, then it becomes a domain-specific community rather than a 
well-known community.

I'm not against the idea of LC WKCs in theory, but there would need to 
be compelling reasons as to why the existing rfc1997 wkc range didn't 
work.  IOW, we should think twice about setting aside a range unless 
there are specific deployment cases which need LCs, and where rfc 1997 
communities wouldn't work.

Nick