The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Oct> msg00351



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

[IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh

  • From: "Holmes, David A." <David.A.Holmes@disney.com>
  • Date: Mon, 23 Oct 2000 12:18:52 -0700
  • Cc: kireeti@juniper.net, sc@tellium.com, xuyg@lucent.com, yxue@UU.NET, zwlin@lucent.com

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