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

Alejandro Acosta <[email protected]> Sun, 10 Nov 2019 19:03:34 -0400
Newsgroups gmane.ietf.idr
Message-ID <[email protected]>
On 11/10/19 1:01 AM, Sriram, Kotikalapudi (Fed) wrote:
> 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 


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 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    
>   
>
>
>
>
>
>
>

_______________________________________________
Idr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/idr
pEpkey.asc (application/pgp-keys, 1.7 KB)
-----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
=++GG
-----END PGP PUBLIC KEY BLOCK-----