Re: Final transition steps
Um, are these April 21 disconnections going to be permanent, or is this just a test of limited duration (six or seven hours, say)? If the turn-off is going to last a long time then the NSFNET International Connectivity Project will need MERIT to process and have installed, no later than this Wednesday, a NACR with changes to about 16000 prefixes. We can prepare the NACR this weekend. We will also need to know whether this is a full turn-off of the NSFNET backbone service next Friday as it will affect our immediate plans for turning up an ICM DS3 connection to MAE-EAST+, effectively moving the timing of that forward a few days. (To get the ICM DS3 up and running on time for the 21st (instead of before the 30th) we have some timing issues that are pretty critical, namely provisioning the DS3 and installing all the equipment. It is unclear that this is possible on the MFS side (never mind the paperwork process, which we probably will just have to ignore in the short run). What is clear though is that current connectivity to MAE-EAST is insufficient for making 21 April a happy day -- ICM is transiting SprintLink's (too full) DS3 to MAE-EAST, and using the FIX to reach the fednets and the networks which have not yet transitioned; the current DS3 can't support moving 10Mbps from the FIX, and don't even mention the ethernet that ICM still has today). I am not opposed to the idea, nor to the implementation of this push towards finding alternate connectivity. However, I'm pretty annoyed that we got very short notice of what appears to be an early shutdown of the NSFNET backbone service. This is especially irritating as a shutdown on the 21st will dramatically affect routing worldwide, and force a rewrite of a number of transition schedules which have been in place for quite some time. However, let's run with it. We'll know early in the week when Peter, Vadim and I have spent alot more time on moving ICM transition forward how bad things will be at 9am on the 21st as opposed to the evening of the 26th, and then again late at night on the 30th. Right now, I humbly request that MERIT wearing its RA hat quickly (i.e., this weekend, and certainly no later than Wednesday morning) locates an RS at FIX-EAST so that ICM can more rapidly bring up safe peering with the FIX-EAST connectees than we had initially planned (i.e., we need to have functional peering and transit set up this week instead of using this week to debug things with the fednets who are facing disconnectivity as of the 30th). This RS should be seeded from the ENSS145 configurations rather than any other source. Having something in place at FIX-EAST which does the same filtering that the AS 690 PRDB mechanism did has now been made much more urgent than it was yesterday, so that we can avoid rushing direct peerings, which traditionally has resulted in serious routing botches that the whole world notices. Sean. - -- Sean Doran <smd@icm1.icp.net>
(To get the ICM DS3 up and running on time for the 21st (instead of before the 30th) we have some timing issues that are pretty critical, namely provisioning the DS3 and installing all the equipment. It is unclear that this is possible on the MFS side (never mind the paperwork process, which we probably will just have to ignore in the short run). What is clear though is that current connectivity to MAE-EAST is insufficient for making 21 April a happy day --
I seriously doubt this will be a problem if you push. We had a T3 installed for Internet World In San Jose with 3 days notice. MFS & PacBell were both very cooperative. This move up date concerns us a lot, too. We're still waiting for MAE-west to come online completely to complete our west coast peering arrangements, and hoping to get connectivity to fix-west/sprint along the way soon as well. Dave -- Dave Siegel, Director of Engineering Network (99) Operations Center (800)638-9947 (602)249-1190 after hours dsiegel@net99.net
Sean,
Sean Doran writes:
Um, are these April 21 disconnections going to be permanent, or is this just a test of limited duration (six or seven hours, say)?
If no one notices and there are no problems, they will be permanent.
If the turn-off is going to last a long time then the NSFNET International Connectivity Project will need MERIT to process and have installed, no later than this Wednesday, a NACR with changes to about 16000 prefixes. We can prepare the NACR this weekend.
If this is temporary does that mean we have to do 16000 NACRs next week instead?
We will also need to know whether this is a full turn-off of the NSFNET backbone service next Friday as it will affect our immediate plans for turning up an ICM DS3 connection to MAE-EAST+, effectively moving the timing of that forward a few days.
This will be a semi-full turn-off of the NSFNET backbone service. The interconnects will remain in place. Those interconnects and the associated ASs are listed in a separate message to the wider world.
(To get the ICM DS3 up and running on time for the 21st (instead of before the 30th) we have some timing issues that are pretty critical, namely provisioning the DS3 and installing all the equipment. It is unclear that this is possible on the MFS side (never mind the paperwork process, which we probably will just have to ignore in the short run). What is clear though is that current connectivity to MAE-EAST is insufficient for making 21 April a happy day -- ICM is transiting SprintLink's (too full) DS3 to MAE-EAST, and using the FIX to reach the fednets and the networks which have not yet transitioned; the current DS3 can't support moving 10Mbps from the FIX, and don't even mention the ethernet that ICM still has today).
If there are serious problems, please contact merit-ie and the on-call engineer will work with you (we don't do paperwork though).
I am not opposed to the idea, nor to the implementation of this push towards finding alternate connectivity. However, I'm pretty annoyed that we got very short notice of what appears to be an early shutdown of the NSFNET backbone service. This is especially irritating as a shutdown on the 21st will dramatically affect routing worldwide, and force a rewrite of a number of transition schedules which have been in place for quite some time.
However, let's run with it. We'll know early in the week when Peter, Vadim and I have spent alot more time on moving ICM transition forward how bad things will be at 9am on the 21st as opposed to the evening of the 26th, and then again late at night on the 30th.
Right now, I humbly request that MERIT wearing its RA hat quickly (i.e., this weekend, and certainly no later than Wednesday morning) locates an RS at FIX-EAST so that ICM can more rapidly bring up safe peering with the FIX-EAST connectees than we had initially planned (i.e., we need to have functional peering and transit set up this week instead of using this week to debug things with the fednets who are facing disconnectivity as of the 30th).
We love to provide RA service everywhere and anywhere - it's just a matter of somebody contracting for the service. Any volunteers?
This RS should be seeded from the ENSS145 configurations rather than any other source.
Having something in place at FIX-EAST which does the same filtering that the AS 690 PRDB mechanism did has now been made much more urgent than it was yesterday, so that we can avoid rushing direct peerings, which traditionally has resulted in serious routing botches that the whole world notices.
Thanks for the vote of confidence. --Elise
participants (3)
-
Elise Gerich
-
net99@net99.net
-
Sean Doran