Re: [Idr] [GROW] Measurements on Regular, Extended, and Large Communities
Colin Petrie <colin@spakka.net> Mon, 27 April 2020 18:42 UTC
Return-Path: <colin@spakka.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 4A9F23A169F; Mon, 27 Apr 2020 11:42:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 LOzkZkV6yGAD; Mon, 27 Apr 2020 11:42:46 -0700 (PDT)
Received: from mailhosting.spakka.net (mailhosting.spakka.net [IPv6:2a02:af8:cafe:f00d::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 125343A16A7; Mon, 27 Apr 2020 11:42:45 -0700 (PDT)
Received: from [2a02:a210:2204:e270:6df5:8804:7c6f:dc6c] by mailhosting.spakka.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from <colin@spakka.net>) id 1jT8iF-000368-KG; Mon, 27 Apr 2020 19:42:39 +0100
To: Nick Hilliard <nick@foobar.org>, "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram=40nist.gov@dmarc.ietf.org>
Cc: "idr@ietf.org" <idr@ietf.org>, GROW WG <grow@ietf.org>, "Hannachi, Lilia (IntlAssoc)" <lilia.hannachi@nist.gov>, "draft-heitz-idr-wklc@ietf.org" <draft-heitz-idr-wklc@ietf.org>
References: <BL0PR0901MB36846BDD28B524EFE086F3C884D00@BL0PR0901MB3684.namprd09.prod.outlook.com> <BL0PR0901MB3684AAB7355DC31D94C5192584D00@BL0PR0901MB3684.namprd09.prod.outlook.com> <ded390a3-568f-49d4-706b-54a224358118@foobar.org>
From: Colin Petrie <colin@spakka.net>
Message-ID: <60e115b3-607d-f3c6-8ced-8db5fafea39e@spakka.net>
Date: Mon, 27 Apr 2020 20:42:39 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <ded390a3-568f-49d4-706b-54a224358118@foobar.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-SMTP-Authenticated-User: colin@spakka.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/IUl36a4VCCmLYMXBUTmzbgBQnWc>
Subject: Re: [Idr] [GROW] Measurements on Regular, Extended, and 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: Mon, 27 Apr 2020 18:42:57 -0000
If you are analysing Route-Views table dumps (and not updates) then you won't see ECs because Quagga/FRR only dumps selected attributes into the MRT files [0]. ECs are not on the list of dumped attributes. LCs were added to the list as part of the LC implementation patch. RIPE's RIS implementation records all the received attributes opaquely so you will see ECs in there. They are also present within the route-views updates files (as these are dumped raw by Quagga). Cheers, Colin [0]: bgp_dump_routes_attr(): https://github.com/FRRouting/frr/blob/master/bgpd/bgp_attr.c#L4146 On 24-04-2020 15:50, Nick Hilliard wrote: > Sriram, Kotikalapudi (Fed) wrote on 24/04/2020 14:14: >> ** Question: Any insights why we don't see any ECs at all? ** > > possibilities: > > - there are many types of EC and router config grammar is implemented > inconsistently across different platforms, and there's no guarantee that > the grammar is capable of expressing anything other than the commoner types > > - they can't handle asn32:asn32, so there's no compelling reason to > prefer them over rfc1997 communities. > > - the more common EC types already have specific meanings, e.g. RT/SOO/etc > > I've never seen them in the wild used for generic purposes. It's always > rfc1997, or more recently LC. > > Nick > > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow
- [Idr] Measurements on Regular, Extended, and Larg… Sriram, Kotikalapudi (Fed)
- Re: [Idr] [GROW] Measurements on Regular, Extende… Nick Hilliard
- Re: [Idr] [GROW] Measurements on Regular, Extende… Colin Petrie
- Re: [Idr] [GROW] Measurements on Regular, Extende… Sriram, Kotikalapudi (Fed)