Re: Comments

[ltwu () faline bellcore com (Liang T. Wu)]

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
- - - - - - - - - - - - - - - - -