Re: [Idr] I-D Action: draft-ietf-idr-deprecate-as-set-confed-set-02.txt

["Sriram, Kotikalapudi (Fed)" <[e-mail]>]

Alejandro,
Sander,

[Alejandro]
>>As a comment, we did a small research and 
>>these are our findings (hope the table shows ok):
>>.....snip.....

[Sander]
>Those numbers are very manageable. If we gather a couple 
>of volunteers we could personally contact each AS.

Thanks for the measurement numbers and your comments.

We had earlier reported similar numbers (totals across all RIR regions)
with many more details:
https://mailarchive.ietf.org/arch/msg/idr/tE8o0HZeLLUEulMkszVBlxqILeU

The link to our detailed data is here:
https://www.nist.gov/sites/default/files/documents/2019/10/23/detailed-as_set-analysis.txt 

Our numbers and yours are consistent, except that we also showed that
globally there only 21 unique routes (prefixes) with AS_SET that seem meaningful!
The rest of the routes with AS_SET (about 450) seem meaningless; details at the link above.

Even the 21 will likely do fine if they did not use AS_SET. They can deaggregate and 
provide the full AS path or they can aggregate and put in AGGREGATOR and
ATOMIC_AGGREGATE.  If you look at this part of our data:

*** When there is AGGREGATOR without AS_SET ***
	# Unique prefixes (with or without AS_SET) : 826535
	# Unique prefixes without AS_SET but with AGGREGATOR: 75698
	% Unique prefixes without AS_SET but with AGGREGATOR: 9.158%
	# Unique prefixes with ATOMIC_AGGREGATE: 47258 
	# Unique prefixes with AGGREGATOR and ATOMIC_AGGREGATE: 44971
	# Unique prefixes with AGGREGATOR and without ATOMIC_AGGREGATE: 31769
           (the last three lines added newly)

it seems clear that a very large number of routes/ASes aggregate without AS_SET
and very likely many of them face similar scenario as those with AS_SET
and yet they do not seem to encounter problems (despite not using AS_SET).
I think the main reason is that even if the aggregate is received
via another upstream provider and gets installed in as AS that contributed to the aggregate,
the AS really never uses that aggregate to route data because it has received 
the other components (more specifics) of the aggregate from the provider who aggregated.
As Jeff has pointed out, if a more specific gets cut off (due to outage), then looping
in the data plane can occur. 
This would typically last only for a short period until recovery happens.
Now a days, the recovery times are fast. And possibly looping of data for a brief period
is not much worse than the data not reaching its destination for that period.  

Sriram