Hi Charley,
Well, now, I was in the same boat a few weeks ago, and asked if I should simply ignore the T1, and was told no, it was best if I did not.
The end result is I'm taking T1-only routes from the NSS and nothing from the ENSS, and pointing default at the ENSS. It seems to work fine, but I'm wondering what has changed such that a different recommendation is being made.
The reasons I got for continuing to take T1 routes were CLNP, relying on the T1-T3 interconnects as a single point of failure to T1-only nets, and being able to use the T1 as a backup for the T3 should the ENSS fail (this is not an issue anyway as apparently I can't take a default route from the ENSS so I can't tell when to fail default over to the T1).
In the last couple of weeks, the number of networks known only to the T1 network has been reduced significantly with the change in ESnet's status. EASInet has notified of us of their plans to start peering with the T3 network within a short time frame. And we are working with CA*net to try to help them migrate to the T3. Therefore, it is not as critical to maintain peering sessions with both backbones, from the point of view of the interconnect as a single point of failure. There are just not that many T1 only networks anymore. Regionals which require the ability to pass CLNP traffic still will want to peer with the T1. However, this too should change in the near future. So if there are regionals which want to consider changes to their routing configurations with the T1 and T3 backbones, we would be happy to address your individual requirements on a case-by-case basis. For instance, Matt Mathis and I discussed this on the telephone. Since his regional is not passing CLNP traffic and the T1 backup circuit to their T3 node is due to be installed this week, he is seriously considering discontinuing his peering session with the T1. We are glad to hear that. We are very anxious to complete the migration from the T1 to the T3. Discontinuing peering sessions with the T1 is the next step. --Elise