The MPLS WG Archive

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



[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: Mark.Jones@mail.sprint.com
  • Date: Thu, 26 Oct 2000 16:15:37 -0500
  • CC: David.A.Holmes@disney.com, ip-optical@lists.bell-labs.com, mpls@UU.NET, sc@tellium.com, vpoudyal@telcordia.com, xuyg@lucent.com, yxue@UU.NET, zwlin@lucent.com
  • X-OpenMail-Hops: 1

Yakov,

"...what are the scenario(s) where UNI would be useful?" is an 
excellent question.  Before I could capture my thoughts on this, I 
received a better description than I could write from a different 
discussion list.  That correspondence and one set of comments is below. 
 In short, the best application for the UNI is a carrier's carrier type 
application or an OVPN, where the customer has leased a select set of 
resources with flexibility to change the connectivity of those 
resources at will.

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


> -----Original Message-----
> From: vpoudyal [mailto:vpoudyal@telcordia.com]
> Sent: Thursday, October 26, 2000 2:24 PM
> To: [long laundry list of addresses removed]
> Subject: Re: peer vs overlay (not this again!!)
> 
> 
> 
> 
> Zhi:
> I agree with your assertions.
> Two more comments (tagged [vijaya]) below:
> Vijaya
> 
> 
> 
> Zhi-Wei Lin <zwlin@lucent.com> on 10/26/2000 02:36:23 PM
> 
> To:   [long laundry list of addresses removed]
> Subject:  peer vs overlay (not this again!!)
> 
> 
> 
> OK,
> 
> I know you're all sick of this by now, but...I still want to get a
> better feel from you all.
> 
> For the interface between the user and the service provider:
> 1. user has router, service provider has ONE
> 2. user has router, service provider has router
> 3. user has ONE, servicer provider has ONE
> 
> For the interface within the service provider network:
> 4. The requestor is a router, the "servicer" is an ONE
> 5. The requestor is a router, the "servicer" is a router
> 6. The requestor is an ONE, the servicer is an ONE
> 
> 
> Which cases will peer model make sense (I assume all of 4-6), 
> and which
> cases will overlay model make sense (I assume all of 1-3, 
> plus possibly
> 4-6).
> 
> This means that when people say peer they actually mean the NNI (for
> 4-6)
> 

[Vijaya] I think that this is true for fully compatible NEs.  However, 
if the requestor NE is not complaint with the NNI specs., it could  
still be complaint with the UNI specs.

> When people say overlay they actually mean the UNI.
> 
> ==> I've heard UUNET state that both overlay and peer will be 
> used, and
> I've heard Level3 state this same. Do both companies mean to use peer
> model within their own network (which couls be between router 
> and ONE or
> ONE and ONE)?? Or use peer between the user and service provider?
> 
> If the latter, then in order for the customer (e.g., router) to make
> intelligent route determination decisions, they need not only the
> topology information, but also how much resources are 
> available in each
> link and in each node in order to determine how the route should
> traverse. Is this acceptable to everyone? If you only provide topology
> by itself, there is no way for the customer to know whether or not one
> path will have the resources...
> 

[Vijaya] The peer model could apply to the OVPN type of  service 
alluded to in
the OIF carriers requirement document. In this case, the user would 
ONLY have visibility and control over the portion of the network 
resource that it has "leased".

> 
> Looking forward to your responses!
> 
> Zhi
> 
> 
> 
> --
> 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
> 
> 
> 


> -----Original Message-----
> From: yakov [mailto:yakov@cisco.com]
> Sent: Thursday, October 26, 2000 8:19 AM
> To: Jones, Mark L.
> Cc: David.A.Holmes; ip-optical; mpls; sc; xuyg; yxue; zwlin; yakov
> Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re:
> DraftMinutes From Pittsburgh
> 
> 
> Mark,
>  
> > 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.
> 
> So, if you think that bandwidth on demand as a service offering
> isn't practical, what are the scenario(s) where UNI would be useful ?
>  
> Yakov.
>