To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>,
 Sander Steffann <sander@steffann.nl>
Cc: IDR <idr@ietf.org>, Warren Kumari <warren@kumari.net>,
 Jeffrey Haas <jhaas@pfrc.org>
References: <BN6PR09MB1331565B584CB3175FD97CCF84750@BN6PR09MB1331.namprd09.prod.outlook.com>
From: Alejandro Acosta <alejandroacostaalamo@gmail.com>
Message-ID: <4f6baac8-1466-e931-c123-5c29c2ec9ea1@gmail.com>
Date: Sun, 10 Nov 2019 19:03:34 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0)
 Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <BN6PR09MB1331565B584CB3175FD97CCF84750@BN6PR09MB1331.namprd09.prod.outlook.com>
Content-Type: multipart/mixed; boundary="------------4C7C4EFCF77A2ED9D98A580B"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/5O0E1IGekH0eb9RK02Oyw-Z3Kqs>
Subject: Re: [Idr] I-D Action:
 draft-ietf-idr-deprecate-as-set-confed-set-02.txt
Precedence: list

This is a multi-part message in MIME format.
--------------4C7C4EFCF77A2ED9D98A580B
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On 11/10/19 1:01 AM, Sriram, Kotikalapudi (Fed) wrote:
> Alejandro,
> Sander,
>
> [Alejandro]
>>> As a comment, we did a small research and=20
>>> these are our findings (hope the table shows ok):
>>> .....snip.....
> [Sander]
>> Those numbers are very manageable. If we gather a couple=20
>> 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=20


Thanks for this, happy to see our results are similar.

We also published something, a little bit longer that what I sent to the
list few days ago.

https://labs.lacnic.net/Una_mirada_al_uso_de_BGP_AS_SET_en_la_DFZ/


Regards,

P.S. Sorry, in Spanish :-{}



>
> Our numbers and yours are consistent, except that we also showed that
> globally there only 21 unique routes (prefixes) with AS_SET that seem m=
eaningful!
> The rest of the routes with AS_SET (about 450) seem meaningless; detail=
s at the link above.
>
> Even the 21 will likely do fine if they did not use AS_SET. They can de=
aggregate and=20
> provide the full AS path or they can aggregate and put in AGGREGATOR an=
d
> 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=20
> 	# 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 withou=
t 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_SE=
T).
> I think the main reason is that even if the aggregate is received
> via another upstream provider and gets installed in as AS that contribu=
ted to the aggregate,
> the AS really never uses that aggregate to route data because it has re=
ceived=20
> the other components (more specifics) of the aggregate from the provide=
r 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.=20
> This would typically last only for a short period until recovery happen=
s.
> Now a days, the recovery times are fast. And possibly looping of data f=
or a brief period
> is not much worse than the data not reaching its destination for that p=
eriod. =20
>
> Sriram   =20
>  =20
>
>
>
>
>
>
>

--------------4C7C4EFCF77A2ED9D98A580B
Content-Type: application/pgp-keys;
 name="pEpkey.asc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="pEpkey.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQENBFztkSoBCADJ6Eeff/C7+EifPImW8l/Ic7fslh/AtblJQeuoNCt681imYQN8
Jnvy3euOFGPBllOJDy7Vugc6LEePpOadHTG+m+6BYpBxTs6eqf7qH/TBtESpjMVT
8uf0MElbMJrby+0zF/fhRx5OEcEEiETByNskJhE0fviSwAikXvdzLrWrR6NjTaNG
ioZn2h9QXcx0cXCxoBrA/lTxEPs1Ncy3sky08E7KW7jmPSt4VesrQZ/JqcNXyGnt
NUi97Aa9TCUtO8PIe3PfzVN0MQeF6xql7XQJGQgocf0X/rYsWD/STX0wA7zVqbdn
kAIyicYx/Z8p6QoeiPcwWA5PbomTL0cz0uetABEBAAG0MUFsZWphbmRybyBBY29z
dGEgPGFsZWphbmRyb2Fjb3N0YWFsYW1vQGdtYWlsLmNvbT6JAVQEEwEIAD4CGwMF
CwkIBwIGFQoJCAsCBBYCAwECHgECF4AWIQR9NGXbSCvzsdzzAGBBGAwR8z/TYQUC
XPjj+gUJDTO7UAAKCRBBGAwR8z/TYcx1B/kB8VIHe0m7LbpiLAiNcpwdHmn6IrTm
IlYUcHPnR/Q6XXN9KQWl/BwQTH01f2FGowrHtZnPT5yh29xcZGuZJO/s/mZmTXAR
XZYvX0qPM2UNWg1inPNKea/n1+JopHwQYZPuXywF5hAqHk5BwPdkVzsKxFkvuHFQ
+BbG3/dyTCFtfnaRXCDJ5dusEP9c5004/5yRx2O+QQArANmBP4nKPi8xUaejPMdf
oEh1ku0EbG3WTzKF3CZR0QiCCeUwTzdrAMDmFpjSg4a50r1TY1fqQvcYPA3CMe4H
tJuxToHkk+NGqhAHiABBIJmtqqRm+547HLsfTXFVEi8+JlcUFl9LboR9uQENBFzt
kSoBCADFTEbxbHfnmhOMJhAsYjBoEDarMEXC3374KVeEAegF2bBYbnJzz+5/HeVy
lZsSJloEtpPwceCOa33x50Qa3VxsOCL5IkBjYHwePQb7Lz8cOfTGug03teH2XZ2g
mcr+3s6Mbr5rAPgWMUOIuNtGiDOJpu/xeKUGFn1vslWZAwcDDrDUeEF2j5u5006K
nHvwyACXHLUAy0NXbKYexvZPshCCTqavZlAmqRNxBqS6xTm9lmLyKvHzDPOcDLs5
rOYLOg9NoBOXhQib0nHrnY6vnXlQDUlUzYfXiFUoFAsZvwifMhTkVMzaVTcux9xn
U+rUx7td+eE0Q2MBgZbGMLam/8jvABEBAAGJATwEGAEIACYCGwwWIQR9NGXbSCvz
sdzzAGBBGAwR8z/TYQUCXPjj+gUJDTO7UAAKCRBBGAwR8z/TYdd6B/9wznTFjfQa
lkfrHl62M6k3ad4vWJmi2Zx3xOs8MtX89XGhTLBtSGSjxi9Mo6U/Dq86iPeIJaIw
EWnT+aw4Mq18bSeMeVilaUrNbhiYqve8a2FAtUXBT/ovwvFY6BrZFrKaeK0k0vqL
b9TEr/LNqotLOgQV5BktwM7TQ8Dap1onOkVil2uDnvKR0LBRTf6yddxJXLYJUPXE
zJxUCPXodvHWggqrnG7xWHXk4UNWIgNQjSXpI9lXooH/VhRmO2bCpaIba6eRoohG
2c/SDKWXD4qENMpWsLfRtPUZcX7vgF7afIuTvm8F95BfIsOMLMA1K39+s1x2oB9m
IlyxqGNfdzAV
=3D++GG
-----END PGP PUBLIC KEY BLOCK-----

--------------4C7C4EFCF77A2ED9D98A580B--