Milo - >I think there is also an issue with the fact that the ADSU's can't deal >with anything other than PVC's. In my opinion, we really need to >move to an SVC environment ASAP to simplify the VC management issue s. >Large numbers of PVC's are going to be a royal pain to tend, esp. i f >they have to be configured manually. I can just imagine the proble ms >stemming from asynchonous updates of VC configurations by the vario us >attachees at the NAP's. I would agree except for the fact that the peering relationships are a) to be established only after humans negotiate, and then are So, let's say that you have a route server there that's distributing routes, and it tells you the next hop is some IP address that is talked to via a VC that isn't configured? You can't send the packet to the RS, since he's not acting as a forwarder. Do you really expect that if you end up with 40 or so providers at a NAP that everyone will have bilateral agreements with everyone else, AND that all the RS configuration information is going to kept in sync with this and the VC configuration (that the NAP providers does, not the RA right?)? This is a lot of human interaction, and I gurantee you short cuts are going to happen. Also, just because you have a bilateral agreement between parties, that doesn't mean necessarily a single VC, esp if an NSP ends up with multiple routers being physically or logically attached to a NAP (switched technology is great ain't it?) for redundancy or load balancing reasons. Also remember that at least some of the NSP's will have to carry R&E traffic without recharge, and that means lots of folks will be expecting more than just bilateral agreements with everyone at the NAPs. This will also likely swell the number of entities who will want attachment there. b) likely to be maintained long term. Equipment changes, and so does the number of participants at the NAPs. You may be assuming the the NAP is only catering to the needs of the big NSP's, and therefore so few parties will be involved that it's not a major effort, but that is inconsistent with the marketing literature I've seen from PacBell (who is actively trying to sell T1 access to Pacific Rim countries) and others. I'll agree if you can keep the total number of parties down to a few (like at the FIX'es), then I agree it's not as big an issue. But then someone ought to tell PacBell and the other NAP providers this. There are a wide variety of trade-off's that have to be made in building a robust interconnect. You can't optimize for everything. Right now, I wish people could just agree that's true and put in a process for deciding what is the most important and what isn't. This clearly isn't happening now, and I think different people all have different views and that's contributing to the confusion. Until people realize that the NAP's are not going to be all things to all people, we'll never get a good analysis of the tradeoffs for how we should implement and use them. And this will endanger the success of the backbone transition effort. Thanks, Milo