Proposed change at the Interconnect
The T1 backbone and the T3 backbone have provided a backup path to mid-level networks which peered with both backbones. x / \ / \ +------+ +------+ | | | | | T1 |------| T3 | | | | | +------+ +------+ / \ / \ / \ / \ a \ / \ \ y / b This was done by announcing all known networks from one backbone to the other via the interconnection between the two. One of the benefits of doing this was that it provided a transition from the T1 backbone to the deployment of the T3 backbone. Now that almost all of the peers that were known to the T1 are also known directly to the T3 and the T3 has implemented backup plans in addition to the T1 backbone, we would like to stop announcing the networks associated with dual homed peers from the T3 to the T1. This means that T1 only networks will no longer have a backup path through the T3 if a dual homed site loses its connectivity to the T1 backbone. In this proposed configuration, at the interconnection, the T1 will announce networks a, x and y to the T3. At the interconnection, the T3 will announce network b to the T1. This plan will have the following affect: 1) if the connection between x and the T1 breaks, b will reach x via the T3 y will reach x via the T3 a will find x unreachable or 2) if the connection between x and the T3 breaks, b will reach x via the interconnect to the T1 y will reach x via the interconnect with the return path via the T1 a will reach x via the T1 CA*net and EASInet are the only peers which remain T1 only. We have contacted them previously concerning this proposal and they are aware of the proposed change. We are also in the process of working with those two organizations to convert them to the T3 backbone. We would like to make this configuration change by the end of this week, November 6, 1992. This step will help to maintain the T1 backbone until the remaining peers have transitioned to the T3 by reducing the amount of routing information that the RTs need to assimilate. It is also another step in preparation to the eventual dismantlement of the T1 backbone. If you have any questions concerning this proposal please notify us as soon as possible. Thank you. --Elise
I would much rather go in the other direction: to stop peering with the T1 backbone and to rely on the crossover for all T1 only traffic. This has several advantages: - The next transition (disconnecting the T1) is a NOOP as far as most sites are concerned. - Conversly there will be a flag day when the T1 is turned off - can you prove in advance that there will be no side effects? - We (the mid-levels) can move on to simpler routing configurations now - Merit can start to dismantle the fringes of the T1 backbone - Simpler diagnosis, because fall back to the T1 will not confuse pingers - Only a small subset of the T1 continues to be production critical to anyone. - With your plan, other possible changes become more difficult becuase sites can not stop peering w/ the T1. - It motivates all people who MUST have the T1 to move on. The NSF is spending a lot of money on T1 lines and electricity for NSSs which could be better spent elsewhere: I bet just a few months of bills will pay for the migration. Disadvantages: - It should wait until the all T1 safety tails are installed in the T3 backbone Ours is scheduled for later this week. - Lower performance to the remaing T1 only sites. - Sites using clnp..... Perhaps the decision can be made on a per site basis? How about just asking all regionals to drop their T1 announcements from 3 or 4 AS's to 1 or 2? Their choice... --MM--
participants (2)
-
epg
-
mathis@pele.psc.edu