Jeroen Massar wrote:

Btw, if you postponed the 'experiment', how come I did pick up this one:

84.205.73.0/24 12654 12654 {1221,1221,1221,1221,1221,1221,1221,1221,1221,1221, 1221,1221,1221,1221,1221,1221,1221,1221,1221,1221, 1221,1221,1221,1221,1221,1221,1221,1221,1221,1221, 1221,1221,1221,1221,1221,1221,1221,1221,1221,1221, 1221,1221,1221,1221,1221,1221,1221,1221,1221,1221, 1221,1221,1221,1221,1221,1221,1221,1221,1221,1221, 1221,1221,1221,1221,1221,1221,1221,1221,1221,1221, 1221,1221,1221,1221,1221}

That path was announced during the window of notice we had given for the announcements. However, you will notice that that was not the complete set of announcements we intended to make, which included 25-, 50-, 75-. and 100-element AS-sets. Since we were not able to send all the announcements within the window of notice we had provided, we postponed them to avoid sending announcements when people were not expecting them.

PS: Is the 'technical difficulty' your own router falling over? :)

No. :) Regards, Lorenzo -- lorenzo@ripe.net colitti@dia.uniroma3.it www.ripe.net www.dia.uniroma3.it/~compunet RIPE NCC Roma Tre Computer Networks research group

On Mon, 2005-06-20 at 12:33 +0200, MarcoH wrote:

On Mon, Jun 20, 2005 at 11:58:33AM +0200, Lorenzo Colitti wrote:

...

Jeroen Massar wrote:

...

Btw, if you postponed the 'experiment', how come I did pick up this one:

84.205.73.0/24 12654 12654 {1221,1221,1221,1221,1221,1221,1221,1221,1221,1221, 1221,1221,1221,1221,1221,1221,1221,1221,1221,1221, 1221,1221,1221,1221,1221,1221,1221,1221,1221,1221, 1221,1221,1221,1221,1221,1221,1221,1221,1221,1221, 1221,1221,1221,1221,1221,1221,1221,1221,1221,1221, 1221,1221,1221,1221,1221,1221,1221,1221,1221,1221, 1221,1221,1221,1221,1221,1221,1221,1221,1221,1221, 1221,1221,1221,1221,1221}

That path was announced during the window of notice we had given for the announcements. However, you will notice that that was not the complete set of announcements we intended to make, which included 25-, 50-, 75-. and 100-element AS-sets.

By the way, accoording to your annoucement:

| The prefixes involved will be 84.205.73.0/24 and 84.205.89.0/24, both | orignating in AS12654. The AS-sets will consist of AS12654 repeated n | times, thus the paths will look like 12654 {12654, 12654, ..., 12654}. | No other AS numbers will be used. The values of n we will use are 25, | 50, 75 and 100.

What's the '1221' doing there ?

That is the RIPE Meeting AS apparently, which is not used at the moment. This was mentioned in todays mail (not in the original one). According to whois though, I hope that you enlightened Geoff of taking over his AS: aut-num: AS1221 as-name: ASN-TELSTRA descr: Telstra Pty Ltd I also do hope that people are not going to filter out 1221 btw as that would sever connectivity of that AS when it is needed. Another thing to note is that neither of those two AS's have any reference to these experiments in whois. aut-num: AS12654 as-name: RIPE-NCC-RIS-AS descr: RIPE NCC RIS Project. descr: http://www.ripe.net/ris/ admin-c: HU266-RIPE tech-c: RISM-RIPE remarks: Different subsets of the routes in AS12654:RS-RIS are announced remarks: at each location. remarks: Please send peering requests to rispeering@ripe.net. mnt-by: RIPE-NCC-RIS-MNT source: RIPE # Filtered It would be nice to list it there too as mentioned before, not everybody reads the various mailinglists and there is no mention on that site either.... Greets, Jeroen

On Wed, 22 Jun 2005, Andrew Staples wrote:

A global company (the group) is headquartered in Scandinavia. 25+ companies comprise the group around the world, each company with its own mailserver and mailserver software. The group encourages the companies to act in a decentralized manner, except in some things...the group wants to consolidate email addresses across the group, i.e.. Xx.yy@groupname.com, regardless of where the mail account lives, yet still give local control over the email server.

You need a table of name -> location mappings which each mail server can use to route email. You could distribute the table using whatever technology you like, e.g. LDAP. Google for Schlumberger Exim LDAP for a complicated example, though it can be done much more simply. Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD.

Valdis.Kletnieks@vt.edu wrote:

On Wed, 22 Jun 2005 17:23:22 BST, Tony Finch said:

...

You need a table of name -> location mappings which each mail server can use to route email. You could distribute the table using whatever technology you like, e.g. LDAP. Google for Schlumberger Exim LDAP for a complicated example, though it can be done much more simply.

That's all fine and good once the mail gets into his e-mail infrastructure.

The problem he's going to hit is that he wants *my* mail server to send mail to 'fred@example.com' to get routed to the MX in San Fran where Fred is, and *my* mail server to send mail 'johann@example.com' to get routed to the MX in Geneva where Johann is, and avoid having a central MX that then does routing.

And basically, he's screwed, because the MX lookup is only based on the RHS of the target address. AT *best* he can deploy a @NN.example.com and have different MX entries for US.example.com and FR.example.com and so on (but he already said that's a suboptimal).

He needs something like the distributed clustering of qmail-ldap. Any mail- cluster member can accept messages for all others and does direct internal redistribution without going through HQ. No country specific subdomains needed. Everything has user@example.com. -- Andre

On Wed, 22 Jun 2005 17:57:52 BST, Tony Finch said:

You don't need a central MX if each site MTA knows which users are at which sites. Incoming email may have to take an extra hop if it comes in to the wrong site, but that's a consequence of the specification that no implementation can fix.

Exactly. The problem is that Andrew already labeled that as "suboptimal":

Doesn't solve the problem of an email being sent to the wrong mx server (all mailservers would need to be able to handle an email delivered to it even if the account isn't local...more centralization). This would solve some of the problems with one centralized server farm if there was a globally distributed network of core mail servers, but sacrifices autonomy.

He *might* be able to sell the various branch offices on a solution that uses LDAP or similar (Andre Oppermann suggested qmail-ldap), where each branch manages its section of the LDAP tree, and the only centralized part the offices would have to trust HQ to do is possibly run a robust redirector to the various LDAP servers. Sorry Andrew - but that's probably the "best suboptimal" that you'll be able to actually deploy within the context of SMTP....

At 6:36 PM +0100 2005-06-22, Tony Finch wrote:

I don't think you can do that because you need to consolidate the branches into a single namespace with some means of dealing with clashes. Most of the complexity of the SLB Exim/LDAP system is for handling fuzzy matching and name clashes - though see http://www.sendmail.org/faq/section3.html#3.5

That one has been a favourite of mine for many years. I'm glad that there's at least one other person in this world that remembers it.

...

and the only centralized part the offices would have to trust HQ to do is possibly run a robust redirector to the various LDAP servers.

That's not necessary if the sites have local LDAP database replicas.

The last version of the Lachman-LASER draft (the one that was issued just before the draft was withdrawn) works well with sendmail and postfix pretty much out-of-the-box for handling LDAP routing. Unfortunately, you're going to have a problem finding a copy of this version of the draft, but you might get lucky if you're good with Google. Of course, LDAP works best when all changes are made to a central master repository and then distributed out to slave replicas, and all LDAP queries are made exclusively to the slave replicas. It's easy enough to set up slave replicas that you can put one on each mail server, if you like. Now, I can tell you that you absolutely, positively, do *NOT* want to list 25 MXes for @groupname.com. First off, unless you are exceedingly creative, you're not going to get 25 MXes to fit into a single UDP datagram, and if you cause DNS packet truncation, you will run into all sorts of bizarre stuff that you do not want to see. Secondly, even if you can manage to cram 25 MX IP addresses into a single UDP datagram, most servers can't handle that many addresses. For example, lets say you list five names with five IP addresses each. Well, if someone connects to the first IP of the first name and gets a "connection refused", then they won't connect to any of the other IPs for that name. Also note that many resolvers do not properly do round-robin or properly honor DNS TTLs. Finally, keep in mind that some MTAs are screwed-up and will only ever talk to the first server on the list. If you go this route, I guarantee that you will see serious load imbalances on the servers -- you will forever have situations where some are virtually unused while others are constantly overloaded, and which ones are which will vary from time-to-time. Been there, done that. Trust me, you do not ever want to go down these roads. If you are forced to stick with username.YY@groupname.com instead of being able to go with username@YY.groupname.com, then you will need to set up a small number of higher-powered servers (no more than five to seven) that are distributed to your main office facilities, and use them to front-end all mail routing for the group. The more centralized you can make this process, the more manageable it will be, to a point -- you should have at least one or two offsite facilities that can take over if the main site is down. If you're putting multiple servers at a site, you should also look into using L4 load-balancing switches to hide the number of back-end servers you're using and to make it easier to pull old servers out of service or to put new servers into service. A lot of the same concepts are covered in the slides for my talk "Scalable IMAP Services: Theory, Practice, and Non-technical Issues" (see <http://www.shub-internet.org/brad/papers/sistpni/>). -- Brad Knowles, <brad@stop.mail-abuse.org> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info.

You don't need a central MX if each site MTA knows which users are at which sites. Incoming email may have to take an extra hop if it comes in to the wrong site, but that's a consequence of the specification that no implementation can fix.

In other words, SMTP does not have the equivalent of an HTTP redirect which is what he wants here. Maybe SMTP really is broken? ;-) --Michael Dillon

In the case where XREDIRECT cannot be negotiated, the server will just have to accept and forward the message itself.

There's obviously a lot of work involved in deciding the exact mechanism. Is gb.example.net looked up via MX, SRV, or something else? Can clients cache the name, and for how long, or do they need to initiate a new SMTP connection to the MXer for each new message, just to be told to redirect? Would extending the MX lookup mechanism with SRV records to direct to the correct server in the first place help? What about the spam implications?

All good questions that probably need to be discussed on some email services mailing list rather than NANOG. But don't be shy, go all the way. We are really saying that the UUCP style relaying inherent in the current SMTP mail system is not necessarily a good thing and mail server operators should not be forced into relaying. But when you follow this through to giving mail server operators the ability to redirect SMTP connections, then you are really saying, "Let's seperate email routing from email delivery". Perhaps this is the time to find a new general solution rather than continuing to tack extensions on the existing email service? I don't have the answers but I think the 10 years of failure to put a dent in spam have shown beyond the shadow of a doubt that Internet email is broken by design and bandaids are not going to fix this, no matter how many different bandaids are applied. It is time to re-engineer with the benefit of hindsight. --Michael Dillon

On Thu, 23 Jun 2005 Michael.Dillon@btradianz.com wrote:

Perhaps this is the time to find a new general solution rather than continuing to tack extensions on the existing email service?

None of the email replacement proposals I have seen are likely to get any significant deployment because none of them is sufficiently better than SMTP. Without a compelling incentive it won't happen because network effects strongly favour staying with what the majority of people use.

I don't have the answers but I think the 10 years of failure to put a dent in spam have shown beyond the shadow of a doubt that Internet email is broken by design and bandaids are not going to fix this, no matter how many different bandaids are applied.

One of the most important features of email is that it allows you to receive messages from people you have not previously communicated with. That, combined with the fact that email is cheap, makes spam inevitable whatever technical infrastructure you use. It is not a failure of SMTP. Another way to see that spam is not caused by weaknesses in SMTP is by observing that it occurs in other protocols: usenet spam, blog spam, wiki spam, spim, etc. Wherever there is an audience there will be spam. Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD.

On Thu, 23 Jun 2005, Dave Crocker wrote:

i seem to recall a similar redirect mechanism in SMTP some time ago. not worth the effort; broken; or somesuch.

The 251 and 551 forwarding address responses. Many mail servers don't know a user's forwarding address at SMTP time; most mail servers treat any 5xx response to RCPT TO the same way; mail servers don't want to maintain a local database of forwarding addresses culled from 251 responses... Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD.

On Thu, 23 Jun 2005 Michael.Dillon@btradianz.com wrote:

...

You don't need a central MX if each site MTA knows which users are at which sites. Incoming email may have to take an extra hop if it comes in to the wrong site, but that's a consequence of the specification that no implementation can fix.

In other words, SMTP does not have the equivalent of an HTTP redirect which is what he wants here. Maybe SMTP really is broken? ;-)

HTTP is 100% client-server protocol so redirect is server telling client to go somewhere else (which is exactly what HTTP redirect does). But SMTP is store-forward system like ip itself. In store-forward redirection is changing of connection path by intermediate system. So with ip this is handled by routers and transparent proxy servers. In SMTP this is handled by forwarding systems which change mail transmission connection and redirect and pass message somewhere else. So we do have redirect functionality SMTP, its just not done same way as HTTP because of differences in system infrastructure. P.S. Somewhat related work of mine: http://www.elan.net/~william/emailsecurity/draft-leibzon-emailredirection-tr... -- William Leibzon Elan Networks william@elan.net

Stepping out of the lurker's doorway for the first time..... On Jun 23, 2005 at 20:27 +0530, Suresh Ramasubramanian wrote: =>Wild idea and there's just too much good german beer here at MAAWG =>(www.maawg.org) in Dusseldorf, but .. anybody tried anycasting a =>mailserver? => =>Operationally that is ... I replied privately to the original poster since I was not on NANOG-post, but this would be interesting if the anycasting was tied into some load balancers doing geographical balancing. That is all I dare say because I am already beyond my realm of comfort. :) (I am a Solaris/Linux sys admin/mail admin/whatever-else-gets-thrown-at-me worker bee. :) =>On 23/06/05, Michael.Dillon@btradianz.com <Michael.Dillon@btradianz.com> wrote: =>> =>> > You don't need a central MX if each site MTA knows which users are at =>> > which sites. Incoming email may have to take an extra hop if it comes in =>> > to the wrong site, but that's a consequence of the specification that no =>> > implementation can fix. =>> =>> In other words, SMTP does not have the equivalent of an =>> HTTP redirect which is what he wants here. Maybe SMTP =>> really is broken? ;-) But certain vendors do have MTAs that can kind of do this. I am thinking about Sun's Messaging Server. Chapter 12 of their Deployment Planning Guide <http://docs.sun.com/source/819-0063/ms-topology.html> mentions a "Distributed Topology" that I thinks fits the original posters requirement pretty closely. You can abstract the mail reception (SMTP/MSA) routing behind the MTAs and also abstract the mail retrieval (IMAP/POP/Webmail) behind the Messaging MultiPlexors (MMPs). I would think if further discussion on this vendors product is wanted, then please see a web site <ims.balius.com> that has information on the user mailing list. Stepping back into the lurker's door way as the sun is to bright..... :) -- *********************************************************************** Derek Diget Office of Information Technology Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/ ***********************************************************************

Or do you want me to go back into ancient history and dig up UUCP and the route mapping tables that were developed?

Don't make me laugh, dredging up old obsolete technology like that! Why that would be like designing a space ship using an old sailing ship as a model. ROTFL... No, wait... http://science.howstuffworks.com/solarsail3.htm Maybe old technology really can be applied to new problems? --Michael Dillon

At 11:56 AM +0200 2005-06-24, Peter Dambier wrote:

|>Or do |>you want me to go back into ancient history and dig up UUCP and the |>route mapping tables that were developed?

They still do work today.

Does UUCP and UUCP route maps scale? No. Can a trivially small portion of the entire population of the world continue to use this technology, while the rest of the world has moved beyond the 1960s? Yes. And your point is? -- Brad Knowles, <brad@stop.mail-abuse.org> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info.

On 2005-06-23, at 10:57, Suresh Ramasubramanian wrote:

Wild idea and there's just too much good german beer here at MAAWG (www.maawg.org) in Dusseldorf, but .. anybody tried anycasting a mailserver?

Operationally that is ...

I know of people who have anycasted the address used by their clients for mail submission using SMTP (so that clients connect to a stable address, and the node which services their request varies according to where they are connecting from). Like all applications of service distribution using anycast, care is required: e.g. a stable, internal network with a well-known topology, and anycast nodes placed such that node selection by clients is consistent, packet-to-packet, for periods of time far exceeding the expected maximum transaction time. The places I have seen this done have had POPs connected with expensive and congested links, so keeping mail submission from customers local and snappy was a big win. I think you're talking about anycasting a server across the Internet to act as a low-numbered MX, though. I haven't met anybody who thought that was a good idea, yet. :-) Joe

-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Valdis.Kletnieks@vt.edu

The problem he's going to hit is that he wants *my* mail server to send mail to 'fred@example.com' to get routed to the MX in San Fran where Fred is, and *my* mail server to send mail 'johann@example.com' to get routed to the MX in Geneva where Johann is, and avoid having a central MX that then does routing.

And basically, he's screwed, because the MX lookup is only based on the RHS of the target address. AT *best* he can deploy a @NN.example.com and have different MX entries for US.example.com and FR.example.com and so on (but he already said that's a suboptimal).

Valdis has present the situation perhaps better than I did in my original post. The replies have confirmed my thoughts, but I wanted to probe the brighter-minds-than-mine that exist on this list. The women in my life expect me to read their minds...with the RFC's I'm based on, it should be easy for DNS to read mine. Andrew (morphs nicely into Anscrewed)

...

3. Change company policy to reflect names like xx.yy@us.groupname.com, xx.yy@uk.groupname.com, etc, where DNS would resolve to the correct server. Doesn't give corporate the "email image" they are after.

unfortunately, all public routing to email servers is based only on domain names, so the domain name has to contain differential information if differential routing is needed.

In his case, it sounds like he actually has a business case for solution 3 above. It only requires putting a dollar figure on the cost of losing the partner relationship and some risk percentages based on his own company being unreliable and a pain in the rear to work with. That should allow him to set up the infrastructure which allows critical workers (such as engineers exchanging CAD files) to use the region-specific addresses. --Michael Dillon

Andrew Staples <andrews@ltinet.net> wrote:

[...] the group wants to consolidate email addresses across the group, i.e.. Xx.yy@groupname.com, regardless of where the mail account lives, yet still give local control over the email server.

Due to the potential for namespace clashes, you *must* have a single central organisation to manage the localpart namespace. MX records can also only route mail on a domain basis, and not by localpart. Again, this tends to drive centralisation. [...]

Has anyone got any other ideas on how to skin this cat with a technological solution not mentioned?

I would probably be tempted to just contract the whole lot out to a third party that is not involved in your internal politics, including maintaining a localpart registry. The third party can then make a commercial decision as to the best way to design the network is an complicated geographically load-balanced cluster, or just to waste bandwidth and take a simpler system. Unless they've got somebody CV-polishing, KISS will probably prevail as bandwidth is cheap. -- PGP key ID E85DC776 - finger abuse@mooli.org.uk for full key Please contribute to the beer fund and a tidier house: http://search.ebay.co.uk/_W0QQfgtpZ1QQfrppZ25QQsassZpndc

Hank wrote:

Wrong again. You used both AS1221 and AS2121:

I logged pretty much the same thing with max-as limit blocking/logging the announcements (of course, the paths, and time stamp seconds are different, YMMV) Perhaps the unforeseen technical difficulties have something to do with not sticking to the original plan? Announce something different to get around filters, and thus, detect who put filters in place? Or more innocent..... maybe fat fingers, or copy/paste gone horribly wrong? Doesn't really matter what happened though, because a controlled announce is a lot better than a malicious one. Since a stupid person is the most dangerous type of person (fifth basic law of human stupidity), a malicious announcement is even safer than a clueless one. I'd much rather see this done by someone with clue that's going to announce and withdraw them, then check for damage, than by someone that might not know what the heck they're doing. If there is damage, we'll all hear about it, and figure out how to stop it in the future when someone else tries to be malicious. Or when someone else is just plain clueless. Apparently that's not the case since this whole experiment was so disruptive that it took 16 hours for someone to notice and point out on NANOG that it neither did nor did not go off as previously announced. (I'm guilty of looking it over in the logs, and not even noticing the difference between 2121 and 1221) The internet is our playground... can't we just all get along? If someone's going to load 50 kids on a merry-go-round, and get 50 more kids to push it.... I'll just stand over by the monkey bars and try to avoid the flying vomit. :-) -Jerry

Can the people responsible for this please reconsider and put things on hold until certain conditions are met: Publish a detailed workplan including AS-es used, windows and risk analysis to the various mailinglists.

given they are using their own prefixes, can you please tell us what risk there might be.

Some assurance that input files are checked for typos.

hopefully better than the mean of operators doing so :-)/2 randy

...

...

Can the people responsible for this please reconsider and put things on hold until certain conditions are met: Publish a detailed workplan including AS-es used, windows and risk analysis to the various mailinglists. given they are using their own prefixes, can you please tell us what risk there might be. Not much, but I guess people in the audience might get happy from the small note that labtests showed IOS won't crash when it encounters these annoucements.

showing that ios won't crash is very difficult because the number of versions of ios, and the amazing dependencies of things on which blade is in which slot and what phase is the moon. but reading the roma gang's papers and the main email note leads me to feel they have done as good a job on this as we can reasonably expect. considering that we have fellow isps dumping horrifying garbage in the rib, it's amusing how we attack a seemingly well-run very small experiment. randy

On Tue, 21 Jun 2005, Pete Templin wrote:

Randy Bush wrote:

...

showing that ios won't crash is very difficult because the number of versions of ios, and the amazing dependencies of things on which blade is in which slot and what phase is the moon.

Thank you. You've provided a clean, concise counter to Lorenzo's original claim that long AS sets won't trip on IOS bugs.

..

Alternatively, why can't the test be conducted in a lab, with interested operators providing router configurations and xOS versions to give the test bed the most realistic sample of the 'net, without using the production 'net?

Has anyone considered that the project may have indeed done testing of available IOS/$ROUTER versions in a lab environment before even considering testing on the 'live' internet? Reading the cited material might be of benefit to the vocal complainers. I think Lorenzo would be the first to admit that the timing of operator notifications, and more importantly the wording, may be less than desired, however this does not detract from the caution, and professionalism exhibited thus far in this set of experiments.

This may be a well-run, very small experiment, but it's experimenting with a space that's rarely explored and therefore less likely to have encountered the same level of operational testing that horrifying garbage leaks have tested.

Part of the problem is that because it is, as you put it, a rarely explored problem space, the number of interested parties with sufficient and varied resources is extremely small, resulting in a less-than-complete testing environment. Another part of the problem is that you cannot put the concept back in the box. The black-hats do read operational lists, and with all the fuss being made over possible breakage caused by AS-sets, some of them will do will perform their own, possibly destructive experiments in order to find out what specific $ROUTER versions do under various inputs. So, which would you prefer.. Lorenzo at a known contact number with known working hours (+31 20 535 4444, 10am to 5pm GMT +1), and with the Internet's best interests at heart, or some malcontent with unknown contacts, unknown hours, and very definitely not your best interests at heart ? --==-- Bruce. Unfortunately, option 3, do nothing to see whether it is actually a problem, is no longer valid.

And finally, "we're doing it", "we're not doing it", "Surprise, we did it" is a crappy way to "notify" the community that they're about to piss in the global pool. At least there was some level of notification, but why bother if you're not going to stick to what you publicize?

One might suspect that the change of plans was due to the impact of operational reality. I would expect some small amount of sympathy from those on this list for those types of events. Tony

Thank you. You've provided a clean, concise counter to Lorenzo's original claim that long AS sets won't trip on IOS bugs.

no problem. you're quite welcome.

This may be a well-run, very small experiment, but it's experimenting with a space that's rarely explored and therefore less likely to have encountered the same level of operational testing that horrifying garbage leaks have tested. As such, I'm frustrated that the testers consider requests to provide more advance notice to be so "obtuse".

could you please give me the command to configure ios to not crash if given advance notice?

Why is this operational test supposed to be given freer reign on the 'net than our own operations? Alternatively, why can't the test be conducted in a lab, with interested operators providing router configurations and xOS versions to give the test bed the most realistic sample of the 'net, without using the production 'net?

the first announcement of this experiment was months ago. randy

Many of us in the operational community are required to conduct testing in lab environments, followed by well-announced maintenance windows.

Thanks for this funny post. I needed a good laugh. It has been years since people have needed a reminder that as the biggest and most complex telecommunications network in the world, the Internet cannot be tested in a lab because it is not possible to construct a lab environment that matches the scale and complexity of the Internet.

Why is this operational test supposed to be given freer reign on the 'net than our own operations?

It's not. Your operations are also an EXPERIMENT as are the operations of every other ISP. People can pretend that this is not so and make claims to the contrary in their marketing literature, but the Internet by its very nature is and will always remain, AN EXPERIMENT. Your network probably poses more threat to the net than the long AS experiment. That is because you haven't tested all the possible configurations of fat-finger mistakes in your announcements and therefore your peers do not know if their routers can handle it when your network goes nuts. And no matter how much you test it and how tightly you manage it, you can never get that probability down to zero. At least the long-AS folks are warning in advance that their area of the net could be acting strange soon. How many other ISPs provide their peers with warnings about misconfigurations? If, after this advance warning, your network falls over because of the long AS tests then I suggest that your own lab testing has been inadequate. --Michael Dillon

Edward B. Dreger wrote:

Considering Lorenzo's attitude, I'm sure he's taking into account the requests for more heads up. If he tickles an IOS bug, I'd rather have it happen in this scenario than when a less-clued individual or a miscreant tries announcing wacky routes.

Bull. His attitude (at least to me) was he needed a "consensus" of the operational community before he would feel compelled to provide more notice and/or postpone the testing to provide said notice. pt