The MPLS WG Archive

[Mark.Jones@mail.sprint.com]

David,

Great point!  The need to automate features like provisioning is one of 
the key reasons we are all looking at optical networking.  However, the 
fast provisioning we all desire does not require the peer model.  (Many 
problems with the peer model for large multi-service carriers like 
Sprint have already been raised in this discussion, so I won't repeat 
them.)  I expect end-to-end provisioning in seconds or at least in 
minutes to be possible with the overlay model too.

The question we should be asking is, who will be able to actually take 
advantage of that capability regardless of the model you adopt?  My 
guess is that it will primarily be an internal network feature that few 
network customers will ever use directly.

Here's why.  Even if you find a carrier to support the peer model, you 
will be required to pay for connections that you MIGHT use in the event 
that you want to add bandwidth to your connection.  No carrier or 
customer wants to build out capacity without some level of commitment 
that the equipment will be needed.  How much do you want to pay for the 
privilege of having bandwidth on demand?  For sub-wavelength bandwidth, 
packet level aggregation minimizes the costs of bandwidth on demand for 
carriers and customers.  I believe that exists in limited ways in 
service offerings already.  However, wavelength level bandwidth on 
demand may never be profitable due to the price of wavelength level 
port cards and systems.  So, the carrier may deploy optical networking 
with seconds required for provisioning, but the bandwidth will still 
have to be built out to the customer after an order before it's 
available.  I don't want to burst anyone's dream of bandwidth on 
demand, but please consider the practical aspects required to make it a 
reasonable service offering.

Even if customers don't have direct access to bandwidth on demand, I 
expect many of the automated features of optical networking to 
drastically improve the speed of service delivery to customers.

Mark Loyd Jones
Sprint
Technology Planning & Integration
913-534-5247
mark.jones@mail.sprint.com


> -----Original Message-----
> From: David.A.Holmes [mailto:David.A.Holmes@disney.com]
> Sent: Monday, October 23, 2000 2:19 PM
> To: Jones, Mark L.; ip-optical; mpls
> Cc: kireeti; sc; xuyg; yxue; zwlin
> Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re:
> DraftMinutes From Pittsburgh
> 
> 
> I have not been following this entire thread either, but as 
> an Enterprise
> customer, I take issue with the following remarks:
> 
> "... The availability and BER are all a customer wants or 
> needs.  If I can 
> give you 99.999% availability (or whatever availability you 
> want to pay 
> for) with a BER to satisfy your needs, why do you care whether I use 
> ring, mesh, or some other scheme?  Grade of service is sufficient."
> 
> In addition to availability, what is critical to this 
> customer is reasonable
> circuit provisioning lead times. It is not uncommon to wait 6 
> months for a
> DS3 or higher speed circuit to be provisioned. The Sprints, 
> MCIs, AT&Ts,
> etc. appear to believe that this is business as usual, and is 
> acceptable to
> the customer. From the customer's standpoint, time is money. My
> understanding of the IP/MPLambdaS mesh model proposals, is 
> that optical
> transport network circuit provisioning can be done in seconds. Fast
> provisioning is a necessary requirement in my view.  
> 
> David Holmes
> 
> -----Original Message-----
> From: Mark.Jones@mail.sprint.com [mailto:Mark.Jones@mail.sprint.com]
> Sent: Monday, October 23, 2000 11:22 AM
> To: ip-optical@lists.bell-labs.com; mpls@UU.NET
> Cc: kireeti@juniper.net; sc@tellium.com; xuyg@lucent.com; yxue@UU.NET;
> zwlin@lucent.com
> Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re:
> DraftMinutes From Pittsburgh
> 
> 
> [I haven't had time to follow this entire thread, so please 
> correct me 
> if I'm off track with the discussion.]
> 
> Zhi and Sid are correct.  I have trouble seeing any kind of peering 
> model fitting in a multi-client network like Sprints, so I come with 
> that assumption.  For an overlay or client model, the 
> specification of 
> protection types doesn't make sense across the UNI.  We argued this 
> point at the OIF in Barcelona.
> 
> Carriers have their own schemes for providing the protection for 
> services, and every implementation of the different architectures 
> provide different results.  What I mean is that a Sprint ring 
> network, 
> deployed over our fiber plant using equipment from vendor X, 
> will give 
> you different availability than a ring in another carrier's network 
> using their fiber plant and vendor Y.  That's just one example.
> 
> The availability and BER are all a customer wants or needs.  If I can 
> give you 99.999% availability (or whatever availability you 
> want to pay 
> for) with a BER to satisfy your needs, why do you care whether I use 
> ring, mesh, or some other scheme?  Grade of service is sufficient.  
> What is needed is standardization of the service grades, so Gold 
> service is the same thing across every network (independent of the 
> unlying protection architecture).  Though I haven't followed the 
> details, I seem to remember seeing work on this in another standards 
> body.
> 
> Mark Loyd Jones
> Sprint
> Technology Planning & Integration
> 913-534-5247
> mark.jones@mail.sprint.com
> 
> 
> > -----Original Message-----
> > From: zwlin [mailto:zwlin@lucent.com]
> > Sent: Monday, October 23, 2000 11:17 AM
> > To: sc
> > Cc: zwlin; kireeti; xuyg; yxue; ip-optical; mpls
> > Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re:
> > DraftMinutes From Pittsburgh
> > 
> > 
> > Hi Sid,
> > 
> > And to generalize even further, if a service provider sets up three
> > grades of service (e.g., bronze, gold, platinum), the protection
> > information should already be embedded within those service 
> > grades. For
> > example, bronze is no protection at all, gold is dynamic mesh
> > restoration, and platinum is 1+1 protection. 
> > 
> > I think what is most important to a service provider and 
> > their customers
> > are the availability of the connection, i.e., is the connection up
> > 99.99% or 99.999% or some other number. How the service 
> > provider chooses
> > to handle how to meet that availability number is up to the service
> > provider and their TE.
> > 
> > Am I mis-representing the service provider here? Maybe some service
> > providers can comment on whether the above description 
> sounds right???
> > 
> > Thanks
> > Zhi
> > 
> > 
> > Sid Chaudhuri wrote:
> > > 
> > > I don't see why TE and protection require the routers to 
> > specify explicit
> > > routes.
> > > The routers can simply specify to the optical layer what 
> > type of optical
> > > layer protection
> > > it requires.  Based on its traffic flow a router only needs 
> > to know between
> > > which
> > > two routers it needs to establish a new lightpath.  How the 
> > lightpath is
> > > routed in the
> > > optical layer seems to me irrelevant to TE.
> > > 
> > > Sid Chaudhuri
> > > 
> > >                 -----Original Message-----
> > >                 From:   Kireeti Kompella 
> [mailto:kireeti@juniper.net]
> >                 Sent:   Monday, October 23, 2000 11:43 AM
> >                 To:     xuyg@lucent.com; yxue@UU.NET
> >                 Cc:     ip-optical@lists.bell-labs.com; mpls@UU.NET
> >                 Subject:        Re: [IP-Optical] RE: Optical link 
> bundling.
> > Was Re: DraftMinutes From         Pittsburgh
> > 
> >                 Hi,
> > 
> >                 > > (router determines the explicit routes).
> >                 >
> >                 > This point has been raised by several folks. It 
> really
> > confuses me. If the
> >                 > optical switches are equipped with path 
> calculation
> > ability, what's the benefit
> >                 > to bother router to determine the explicit routes 
> within
> > optical domain
> >                 > (assuming router can be smart enough to 
> handle all 
> optical
> > network specific
> >                 > attributes and constrains) than just have 
> routers to
> > determine the end points of
> >                 > optical trails.
> > 
> >                 Why does this confuse you?  Routers may want to 
> determine
> > the exact
> >                 path that their LSPs take for a number of reasons, 
> including
> > TE and
> >                 protection.  If a router doesn't care where 
> its LSPs 
> are
> > laid out,
> >                 it can install loose hops at the boundaries of the 
> optical
> > cloud.
> > 
> >                 Kireeti.
> > 
> > _______________________________________________
> > IP-Optical mailing list
> > IP-Optical@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> 
> -- 
> Zhi-Wei Lin
> Lucent Technologies                       Tel: +1 732 949 5141
> 101 Crawfords Corner Rd, Rm 3C-512        Fax: +1 732 949 3210
> Holmdel, New Jersey 07733-3030 USA      Email: zwlin@lucent.com
>