The MPLS WG Archive

[Yakov Rekhter <yakov@cisco.com>]

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.