We (at NIST) performed some additional data analysis to characterize AS_SETs in BGP updates in RIB entries. The results can be found in the slides at this link: http://www.antd.nist.gov/~ksriram/AS_SET_Aggregator_Stats.pdf This work was presented at the IETF SIDR WG meeting in Maastricht in July 2010. Please look at mainly slides #3 and #4. The findings are consistent with Olaf Maennel's (that Randy posted) in term of how few updates have AS_SETs in them. We additionally looked at the the question of -- when AS_SET is present, how often does the ASN in the AGGRGATOR field in the update matches the originating AS? This question has relevance to origin AS validation using ROAs in RPKI -- to try to propose how origin validation can be done if AS_SET is present in an update. Please look into my slides if you are interested in the details. I will be happy to answer any questions. Currently, the push from several of us (Warren Kumari, Randy, many others -- I support it too) is to deprecate AS_SETs altogether in future BGP enhancements such as RPKI. This would mean an update will not pass origin validation (in fact, origin validation using ROAs will not even be attempted) if AS_SET is present in an update. Comments/reaction/feedback to this from ops people who currently use AS_SETs would be very useful. (This would be good for discussion of Warren's draft in the IDR WG. http://tools.ietf.org/html/draft-wkumari-deprecate-as-sets-00 ) Sriram ====================================================

Date: Thu, 23 Sep 2010 10:59:07 -0400 From: Randy Bush <randy@psg.com> Subject: Re: Odd BGP AS Path To: Warren Kumari <warren@kumari.net> Cc: nanog@nanog.org

just to uncloak a bit. when we first decided to look at deprecating as-sets et alia, we begged olaf maennel to analyse the use thereof. the following is edited from internal email from early august. we then begged one of our number, warren, to do the dirty, and he was kind enough to do so. we owe him.

---

using data from ripe r00

years total real stable as-sets as-sets 7 4 2 6 6 2 5 20 3 4 22 5 3 64 16 2 214 87 1 875 289

years stable is how many years that as-set was announced for that prefix.

total as-sets is the number of prefixes that had any as-set.

real as-sets is the number of prefixes with as-sets which were not singleton asns and were not private asns.

olaf scanned for ten years but none were stable for more than seven.

in ten years, 1205 different prefixes with as-sets were seen. removing private asns and removing singletons left only 404 prefixes over the ten years.

he did not check for covering prefixes, i.e. two prefixes with the same as-set where one was a sub-prefix of the other, longer, one.

and i suspect the data are somewhat self-similar. i.e. the 289 that were stable for the last year may have shorter term components which were much higher. i.e. looking at data for a week or a day may give higher values.

a graph which should be pretty self-explanitory may be found at

http://archive.psg.com/fraction-and-absolute-number-of-ASsets-in-table-over-...

it is interesting that, at no time, i.e. in no single rib dump, were there more than 23 prefixes with as-sets. while this is suspicious, it seems to be true.

randy