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