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