Milo, I am responsible for architecting SNMP over SF and Chicago NAPs. So, allow me to answer some of your network management questions. Dave, who is out of town, can take a shot at me or other business issues later.

To: sincos@gigabit.bellcore.com (Dave Sincoskie) Subject: Re: Comments From: "Milo S. Medin" (NASA Ames Research Center) <medin@nsipo.nasa.gov>

Dave, I haven't seen a followup on my reply back to you, but I've been doing some more thinking along these lines, and talking with several other people, and there are a few other points for the colocation method that I think also should be brought up.

One other advantage is that if the NAP is located in a telco CO that has IXC tenants, it should be possible to have IXC lines terminated in routers managed by the NSP's without any LEC loop at all. This will reduce the cost of attachments, in some cases such as DS-3 level attaches, by a significant amount, since just a cross connect would have to be run. This would improve the network management aspects by elimination of an

Among all the RBOCs I know, network management or network operations center is not the sme as COs. For economic and technical reasons, the operations of COs are remoted and centralized to one or two network operations center. So, "colocation" of router takes different meaning depending on which location you are referring to. If you want access to your router, colocation will then have to be at the operations center. In this case, digital cross connect at DS3 or OC3 rate can still be used, but you would then have to pay for the connection between COs and where the place you put your routers. In fact, even if the colocation is at CO, the interconnection of router to IXC is still not free. Moreover, you have to pay for the access line to the CO, which can be expensive depending on the kind of facility you use.

extra organization in the span, esp in cases where an IXC fast packet service is being used for inter-LATA transport. For SONET interconnects at

My understanding of where IXC or LEC should provide the fast packet servic is really determined by the price you want to pay. The pricing for NAP interconnect is basically "flat rate" such that it depends on the interface speed and independent of the distance. So, if IXCs also provide similar pricing structure, I am sure their average or "flat rate" will be different because of the difference in the network diameter and the size of customers they are catering to including those using the service for other purposes. I understand there are more IXC providing cell relay services than LEC tody. So, the choice is there for the customers.

OC-3c, this would also simplify timing issues, since the NAP connection wouldn't require synchronization between IXC and LEC timing sources (though this isn't an issue for DS-3 and T1 links).

Also, because no LEC fast packet service would be required, the time to implement the NAP should be shorter, since no new technology and network management services would have to be provided by the LEC. This would allow

Saying that using SONET requires no new network management technology or service is not exactly correct. There are several versions of SONET management tools that are being worked on by different vendors. Some are CMIP/CMISE based, and most others are TMN based proprietary systems. So, while the cross connect service is well-managed, you don't have too much hope to integrate those into you L3/SNMP network management system. Part of the advantage of moving over to ATM is that all the telcos agree to super-impose SNMP over their internal operations system for data customers. SNMP development for NAP is well underway, waiting for the NAP to be established.

decoupling of LEC fast-packet services from NAP service, and allow each to move on their appropriate timeframes. This would allow you to accelerate NAP implementation and testing schedules. Obviously, some NSP's might want to take advantage of such services, but they could start off with simple leased lines and might to LEC fast packet services in a gradual fashion, based on cost/reliability tradeoffs.

One more advantage, which I understand may not be a good thing from your viewpoint, is that CAP's and other bypass carriers would also have a shot at providing access to the Chicago and SF NAP's, which essentially require the use of LEC loop and fast-packet services now. This would encourage competition and assure lower prices to NAP users, and potentially provide access to advanced services on a faster timeframe than the normal PUC tarriff process allows. Obviously, this is something that you may view differently than your customers, but I still think it's a valid point.

But, I believe all NAPs have tarriff in place for their servic offering and are ready for business.

This is all consistent with the idea of Keeping It Simple Stupid (KISS), and allow tighter focus on the primary goal of transitioning away from the central backbone provisioning of connectivity between the regionals to the provision of this service through a distributed set of NSP's in a timely and very reliable manner. Again, I feel any aspect of NAP design and provision needs to be examined against this concise goal.

Thanks, Milo