Odd BGP AS Path

Sun Sep 26 16:46:55 UTC 2010

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 at psg.com>
>Subject: Re: Odd BGP AS Path
>To: Warren Kumari <warren at kumari.net>
>Cc: nanog at 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-time-valids-only.pdf
>
>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