Help Please - Reducing Routes
Dear colleagues, I would like you all to help me a little with the text of an e-mail message I am about to program into a new robot. This robot detects redundant BGP routes and brings them to the attention of the contact persons of the ASes concerned. This is the direct result of the discussion we had at the last RIPE meeting about the need for reducing the number of routes and the consensus that we should mount a community effort to do something about it. I would like you to read the example message below and give me sugestions for improvements. It would also be useful to receive a short note saying "I could understand it, no suggestions", so that I can see how many actually tried to grok it. Note that this is not picking in any way on AS1273. I picked them because this message was the first one I saw that has all the optional elements in it. I also know that the ECRC crew is good humoured in general ;-). I hope to have the robot running sometime next week; but it is no good if people do not understand what they need to do. So please help! Daniel From: Less Routes <less-routes@ripe.net> To: "Dave F. Morton" <dave@ECRC.DE>, "Todd Ferguson" <todd@ECRC.DE>, "Kurt Kayser" <kurt@ecrc.de>, "Kurt Kayser" <kurt@ecrc.de>, "Waltraud Erber" <wer@ecrc.de>, Subject: Routes AS1273 can help eleminate Dear AS1273 contact persons, as you may know the Internet routing system is quite strained at the moment. The major cause of this is the number of routes in the system. This has already caused some service providers to restrict the number of routes they propagate. The RIPE NCC has analysed BGP routing tables and found that a significant number of routes (as many as 22% of the total) are apparently redundant. Your autonomous system is either originating some of those redundant routes or one of your immediate neighbors is doing so. We have found redundant routes by looking separately at each set of routes which we observe coming to us though a unique set of BGP paths. We believe that no routing information will be lost by eliminating redundant routes in in each set independently. We have included all information about the redundant routes your AS is directly involved with and included it in the message below. For each unique set of BGP paths observed in the routing table you will see a number of lines like - Paths: <as-path> [/ <as-path> ...] This is the set of AS paths observed in BGP routing. - Drop: <prefix> covered by <less-specific-prefix> These prefixes can be dropped from global routing because they are covered by a less specific (shorter) prefix observed via the same set of paths. - Aggregate: <prefix> from <more-specific-prefix> & <more-specific-prefix> The more specific prefixes can be aggregated (combined) into a less specific one. This works recursively, i.e. aggregates of aggregates may appear. This serves to show you how the aggregation was derived by us. - Announce: <prefix> The announce lines show you all non-redundant routes for this set of paths including those that could not be improved. This is what should be announced ideally. - Prefixes: <n> <n> is the number of prefixes observed via the set of paths. - Dropable: <n> <n> is the number of prefixes that can be dropped because they are covered by less specific prefixes (see above). - Agg-able: <n> <n> is the number of prefixes that can be dropped because they can be aggregated into less specific prefixes (see above). - Gainable: <n> <n> is the total number of prefixes that can be dropped without loosing information or routing functionality. We have compiled the information in two different sets: routes originated by your AS and routes originated by your AS's immediate neighbor ASes. We only consider neighbor ASes that appear to be 'downstream' from you from our point of view. If your AS originates routes, please consider reducing the announcements as indicated by dropping and/or aggregating routes. If you have multiple connections to (some of) your neighbors and you cannot aggregate or drop the announcements yourself because your immediate neighbor(s) need separate routes to choose the proper connection, please ask your neighbor(s) to do the aggregation for you. If you have a legitimate reason for announcing prefixes that our model considers redundant, we are *very* interested to hear from you, so that we can improve our model. Of course we are also interested in any feedback from you about the usefulness of this information to you and your willingnewss to use it. If the routes are originated by your neighbors, please contact them and bring this to their attention. We will be collecting this information regularly and make it available at ftp://ftp.ripe.net/ripe/less-routes/ in file names of the form AS<num> where <num> is the AS number. We will also regularly publish reports on the progress of this effort. Please act now. reducing the number of prefixes in the Internet routing system is absolutely required to make routing more stable for everyone. This affects you! Thank you The RIPE NCC Routing Team # BGP routes from amsterdam.ripe.net # at Thu Feb 1 07:54:35 1996 UTC # Possible improvementss for routes you originate: Paths: 1755 1273 Incomplete / 1128 1673 1239 1800 1755 1273 Incomplete Drop: 194.24.193/24 covered by 194.24.192/19 Aggregate: 194.24/23 from 194.24/24 & 194.24.1/24 Aggregate: 194.45.208/21 from 194.45.208/22 & 194.45.212/22 Aggregate: 194.115.102/23 from 194.115.102/24 & 194.115.103/24 Aggregate: 194.139.100/23 from 194.139.100/24 & 194.139.101/24 Aggregate: 194.139.102/23 from 194.139.102/24 & 194.139.103/24 Aggregate: 194.139.100/22 from 194.139.100/23 & 194.139.102/23 Announce: 193.22.160/22 Announce: 193.26.103/24 Announce: 193.29.189/24 Announce: 193.30.202/24 Announce: 193.96.229/24 Announce: 193.97.129/24 Announce: 193.97.140/24 Announce: 193.101.21/24 Announce: 193.102.110/24 Announce: 193.141.37/24 Announce: 193.141.94/24 Announce: 194.24/23 Announce: 194.24.4/24 Announce: 194.24.192/19 Announce: 194.31.6/23 Announce: 194.31.193/24 Announce: 194.45.160/22 Announce: 194.45.173/24 Announce: 194.45.186/24 Announce: 194.45.208/21 Announce: 194.55.32/24 Announce: 194.77.146/23 Announce: 194.99.111/24 Announce: 194.115.101/24 Announce: 194.115.102/23 Announce: 194.127.245/24 Announce: 194.139.100/22 Prefixes: 34 Dropable: 1 Agg-able: 6 Gainable: 7 # Possible improvements for routes originated # by your immediate neighbors. Paths: 1755 1273 2861 IGP / 1128 1673 1239 1800 1755 1273 2861 IGP Aggregate: 194.138.16/23 from 194.138.16/24 & 194.138.17/24 Announce: 194.138.16/23 Prefixes: 2 Dropable: 0 Agg-able: 1 Gainable: 1 Paths: 1755 1273 5401 IGP / 1128 1673 1239 1800 1755 1273 5401 IGP Aggregate: 194.77.60/23 from 194.77.60/24 & 194.77.61/24 Aggregate: 194.77.182/23 from 194.77.182/24 & 194.77.183/24 Aggregate: 194.77.196/23 from 194.77.196/24 & 194.77.197/24 Announce: 193.16.1/24 Announce: 193.96.105/24 Announce: 193.96.240/24 Announce: 193.100.124/23 Announce: 193.101.23/24 Announce: 193.101.68/24 Announce: 193.101.120/23 Announce: 193.101.166/24 Announce: 193.102.58/24 Announce: 193.102.128/22 Announce: 193.103.149/24 Announce: 194.15.215/24 Announce: 194.55.171/24 Announce: 194.77.46/23 Announce: 194.77.48/22 Announce: 194.77.52/23 Announce: 194.77.60/23 Announce: 194.77.65/24 Announce: 194.77.88/24 Announce: 194.77.111/24 Announce: 194.77.156/23 Announce: 194.77.160/24 Announce: 194.77.164/23 Announce: 194.77.166/24 Announce: 194.77.168/24 Announce: 194.77.176/24 Announce: 194.77.180/24 Announce: 194.77.182/23 Announce: 194.77.189/24 Announce: 194.77.196/23 Announce: 194.115.31/24 Announce: 194.127.100/24 Prefixes: 35 Dropable: 0 Agg-able: 3 Gainable: 3 Paths: 1755 1273 5401 IGP / 1128 1804 1800 1755 1273 5401 IGP Aggregate: 194.77.66/23 from 194.77.66/24 & 194.77.67/24 Announce: 193.16.3/24 Announce: 193.98.8/22 Announce: 193.98.92/23 Announce: 193.98.225/24 Announce: 193.100.96/24 Announce: 193.100.167/24 Announce: 193.101.2/24 Announce: 193.101.45/24 Announce: 193.101.62/23 Announce: 193.102.21/24 Announce: 193.102.83/24 Announce: 193.102.94/24 Announce: 193.103.134/24 Announce: 193.103.226/24 Announce: 194.64.169/24 Announce: 194.76.211/24 Announce: 194.77.56/22 Announce: 194.77.66/23 Announce: 194.77.94/24 Announce: 194.77.105/24 Announce: 194.77.110/24 Announce: 194.77.113/24 Announce: 194.77.138/24 Announce: 194.77.215/24 Prefixes: 25 Dropable: 0 Agg-able: 1 Gainable: 1
Daniel this looks very good. The message is clear, as is the syntax of the summary. Question: how often will the robot run? Question: should the mail refer to policy-based routing and the aspiration for coincidence between reality and policy as formally expressed in the routing registry, or would this dilute the purpose of the exercise? I've added a few comments. Cheers. Mike Dear colleagues, I would like you all to help me a little with the text of an e-mail message I am about to program into a new robot. This robot detects redundant BGP routes and brings them to the attention of the contact persons of the ASes concerned. This is the direct result of the discussion we had at the last RIPE meeting about the need for reducing the number of routes and the consensus that we should mount a community effort to do something about it. I would like you to read the example message below and give me sugestions for improvements. It would also be useful to receive a short note saying "I could understand it, no suggestions", so that I can see how many actually tried to grok it. Note that this is not picking in any way on AS1273. I picked them because this message was the first one I saw that has all the optional elements in it. I also know that the ECRC crew is good humoured in general ;-). That's true. Also, their To: field looks almost like a limerick ;-) I hope to have the robot running sometime next week; but it is no good if people do not understand what they need to do. So please help! Daniel From: Less Routes <less-routes@ripe.net> To: "Dave F. Morton" <dave@ECRC.DE>, "Todd Ferguson" <todd@ECRC.DE>, "Kurt Kayser" <kurt@ecrc.de>, "Kurt Kayser" <kurt@ecrc.de>, "Waltraud Erber" <wer@ecrc.de>, Subject: Routes AS1273 can help eleminate Dear AS1273 contact persons, as you may know the Internet routing system is quite strained at the moment. The major cause of this is the number of routes in the system. This has already caused some service providers to restrict the number of routes they propagate. The RIPE NCC has analysed BGP routing tables and found that a significant number of routes (as many as 22% of the total) are apparently redundant. Your autonomous system is either originating some of those redundant routes or one of your immediate neighbors is doing so. Give the source of authority for this mail by rewording the first sentence as follows: At the request of its user community, the RIPE NCC has undertaken to analyse BGP routing tables and finds that a significant number of routes (as many as 22% of the total) are redundant. We have found redundant routes by looking separately at each set of routes which we observe coming to us though a unique set of BGP paths. We believe that no routing information will be lost by eliminating redundant routes in in each set independently. ^^ No need for final adverb. Sentence should end "..routes in each set." We have included all information about the redundant routes your AS is directly involved with and included it in the message below. For each unique set of BGP paths observed in the routing table you will see a number of lines like Rewrite the first sentence in the above par as: We have summarised all information about the redundant routes your AS is directly involved with and listed it in the message below. - Paths: <as-path> [/ <as-path> ...] This is the set of AS paths observed in BGP routing. Explain what "Incomplete" means in sets of paths. People could get worried by this term. - Drop: <prefix> covered by <less-specific-prefix> These prefixes can be dropped from global routing because they are covered by a less specific (shorter) prefix observed via the same set of paths. - Aggregate: <prefix> from <more-specific-prefix> & <more-specific-prefix> The more specific prefixes can be aggregated (combined) into a less specific one. This works recursively, i.e. aggregates of aggregates may appear. This serves to show you how the aggregation was derived by us. Where possible, use the positive voice in the last sentence above: This serves to show you how we derived the aggregation. - Announce: <prefix> The announce lines show you all non-redundant routes for this set of paths including those that could not be improved. This is what should be announced ideally. - Prefixes: <n> <n> is the number of prefixes observed via the set of paths. - Dropable: <n> <n> is the number of prefixes that can be dropped because they are covered by less specific prefixes (see above). - Agg-able: <n> <n> is the number of prefixes that can be dropped because they can be aggregated into less specific prefixes (see above). - Gainable: <n> <n> is the total number of prefixes that can be dropped without loosing information or routing functionality. Typo: "losing" We have compiled the information in two different sets: routes originated by your AS and routes originated by your AS's immediate neighbor ASes. We only consider neighbor ASes that appear to be 'downstream' from you from our point of view. If your AS originates routes, please consider reducing the announcements as indicated by dropping and/or aggregating routes. If you have multiple connections to (some of) your neighbors and you cannot aggregate or drop the announcements yourself because your immediate neighbor(s) need separate routes to choose the proper connection, please ask your neighbor(s) to do the aggregation for you. If you have a legitimate reason for announcing prefixes that our model considers redundant, we are *very* interested to hear from you, so that ^^^^^^^^^^ Use "keen" or "anxious". we can improve our model. Of course we are also interested in any feedback from you about the usefulness of this information to you and your willingnewss to use it. ^^^^^^^^^^^^ Typo: willingness If the routes are originated by your neighbors, please contact them and bring this to their attention. We will be collecting this information regularly and make it available at ftp://ftp.ripe.net/ripe/less-routes/ in file names of the form AS<num> where <num> is the AS number. We will also regularly publish reports on the progress of this effort. Please act now. reducing the number of prefixes in the Internet routing ^^^^^^^^ Typo: Reducing system is absolutely required to make routing more stable for everyone. ^^^^^^^^ Use "essential"? This affects you! Thank you The RIPE NCC Routing Team
"Mike Norris" <mnorris@dalkey.hea.ie> writes:
Question: how often will the robot run?
Not decided yet. At this stage it requires some manual steps. Initially I aim for about once a week.
Question: should the mail refer to policy-based routing and the aspiration for coincidence between reality and policy as formally expressed in the routing registry, or would this dilute the purpose of the exercise?
This optimisation step does not require the RR. Later ones probably will. I prefer not to confuse things too much at this stage.
I've added a few comments.
thanks. Daniel
Quoting from Daniel Kerrenberg's message:
I would like you to read the example message below and give me sugestions for improvements. It would also be useful to receive a short note saying "I could understand it, no suggestions", so that I can see how many actually tried to grok it.
Understandable, I agree with Mike Norris's suggestions. ---------- ---------- Antonio-Blasco Bonito E-Mail: bonito@nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 50 593246 Via S. Maria, 36 Fax: +39 50 904052 I-56126 PISA Telex: 500371 CNUCE I Italy Url: http://www.nis.garr.it/nis/staff/bonito.html ---------- ----------
participants (3)
-
Antonio_Blasco Bonito -
Daniel Karrenberg -
Mike Norris