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

From: [email-masked]
Date: Mon, 23 Oct 2000 18:55:33 +0100

Sounds fine to me Zhi.  I keep trying to make the point that availability
SLAs and QoS SLAs are quite different animals....the latter only has
relevance when a connection (eg an LSP) is in the up-state.  So I need to be
able to know the former before I can do the latter.  This is indeed why I
also have a problem with the 'DiffServ' only approach which mutates failures
into QoS hits, ie the forwarding behaviour of a traffic type (eg voice that
needs EF) bears no relationship to its survivability requirements.  I want
to be able to offer my VPN customers different avail SLAs and this needs
some notion of hard BW partitioning and overall VPN topology survival (vs
other peer, different customer, VPNs)....if I merge all their traffic, then
how can I do this?

Of course this (ie hard BW partitioning) is forced once we start using
CO/cct-sw fabrics like SDH and the OTN as 'LSPs' (I am not getting into the
common control-plane issue here!....but you know my views on this by now).
But the *principle* still applies everywhere else.

Bottom-line.....I am only interested in QoS once I know the availability
issue is cracked.  To crack availability all defects, and there correct
(user-plane) handling, must be defined.  We are not there yet.

Neil

> -----Original Message-----
> From:	Zhi-Wei Lin [SMTP:[email-masked]]
> Sent:	Monday, October 23, 2000 5:17 PM
> To:	Sid Chaudhuri
> Cc:	'Kireeti Kompella'; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> 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
> 
>

---

From: [email-masked]
Date: Mon, 23 Oct 2000 17:27:24 +0100

Hi Zhi,

Your description sounds fine.  Note that we may also wish to offer shared
protection and other protection options as well as your three examples
though.

Regards,
Darren.

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: 23 October 2000 17:17
To: Sid Chaudhuri
Cc: 'Kireeti Kompella'; [email-masked]; [email-masked];

Hi Sid,

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
> 
>                 From:   Kireeti Kompella [mailto:[email-masked]]
>                 Sent:   Monday, October 23, 2000 11:43 AM
>                 To:     [email-masked]; [email-masked]
>                 Cc:     [email-masked]; [email-masked]
>                 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
> [email-masked]
> 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: [email-masked]

---

From: [email-masked]
Date: Mon, 23 Oct 2000 13:21:55 -0500

[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
[email-masked]

> From: zwlin [mailto:[email-masked]]
> Sent: Monday, October 23, 2000 11:17 AM
> To: sc
> Cc: zwlin; kireeti; xuyg; yxue; ip-optical; mpls
> > it requires.  Based on its traffic flow a router only needs 
> to know between
> > which
bundling.
optical
including

---

From: "Lazer, Monica A, NNAD" <[email-masked]>
Date: Mon, 23 Oct 2000 14:36:31 -0400

Following the ongoing discussions, I would like to add a couple of points. 
The optical network is essentially used to set-up facilities=circuits. This
is done by having cross-connects set physical connections between
appropriate ports. The actual flow of traffic or packets is transparent to
the optical network.
From a functional perspective this looks more like setting up a very, very
fat modem pipe between two pieces of equipment using optical network
facilities. So from this perspective I don't see why the peer model should
be preferred over the client model.
Furthermore, there are several standards documents co-authored by multiple
carriers indicating the need to support a client model. The T1X1 version of
requirements (ftp://ftp.t1.org/pub/t1x1/x1.0/0x100490.doc) which has been
proposed as a USA contribution to the ITU-T for G.ason discusses needs such
as support of third party signaling, support of multiple client naming
schemes and connection scheduling. .  The OIF Carrier Document is public as
a T1X1 document going to the ITU-T
(ftp://ftp.t1.org/pub/t1x1/x1.0/0x100510.doc) and it also discusses in some
detail both requirements and the motivations behind them. 

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Monday, October 23, 2000 2:22 PM
To:	[email-masked]; [email-masked]
Cc:	[email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject:	RE: [IP-Optical] RE: Optical link bundling. Was Re:
DraftMinutes From         Pittsburgh

Mark Loyd Jones
Sprint

bundling.
optical
including

---

From: Yangguang Xu <[email-masked]>
Date: Mon, 23 Oct 2000 14:48:54 -0400

Kireeti,

Several ways to do:
1) A can request the first LSP to optical network (x-y), then request another
one which different the first one (w-z, also with LSP ID of x-y to avoid). 

2) A can send one request for two disjointed paths (x-y) and (w-z) together.

The key point is whatever routers can do to optical network, optical switches
can do by themselves (as easy as router can do). Why bother?

Yangguang

>Suppose router A wants to get to router B, and wants to take two
>different ingress and egress points in the optical domain, X->Y
>for the primary LSP, and W->Z for the backup.  A does not require
>optical protection for the X->Y path, nor for the W->Z path.  A
>*does* require that the X->Y path and the W->Z path do not share
>common links.  How is this to be done?

>If A did the full path computation, this is simplicity itself.

---

From: "Lazer, Monica A, NNAD" <[email-masked]>
Date: Mon, 23 Oct 2000 14:49:25 -0400

My 2c: when selling service, availability numbers are often used.
On the other hand, there are multiple networking methods that can be used to
deliver given availability numbers.  The overall solution to providing
network reliability is much more complex than simply deciding: it shall be
rings, or it shall be mesh, or...
The overall network will use a mix of protection and restoration techniques
according to reliability of different network components, such as (but not
limited to individual network elements expectations of failure rates)
After careful consideration of all factors, a carrier will choose certain
sets of protection and restoration mechanisms to be implemented in its
network. So, the specifics of the mechanisms should not be negotiated over
the UNI. However, the actual class of service (including availability
numbers are negotiable). Then routing of a given circuit will follow routes
as appropriate to meet the class of service.

Monica A. Lazer

908 234 8462
[email-masked]

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Monday, October 23, 2000 12:27 PM
To:	[email-masked]; [email-masked]
Cc:	[email-masked]; [email-masked]; [email-masked];

Hi Zhi,

Regards,
Darren.

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: 23 October 2000 17:17
To: Sid Chaudhuri
Cc: 'Kireeti Kompella'; [email-masked]; [email-masked];

Hi Sid,

Thanks
Zhi

between
bundling.
optical
including

---

From: "Holmes, David A." <[email-masked]>
Date: Mon, 23 Oct 2000 12:18:52 -0700

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: [email-masked] [mailto:[email-masked]]
Sent: Monday, October 23, 2000 11:22 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]

Mark Loyd Jones
Sprint

bundling.
optical
including

---

From: [email-masked]
Date: Mon, 23 Oct 2000 19:40:24 +0100

> If A did the full path computation, this is simplicity itself.
	NH=> Kireeti, I don't this can be a general answer.  The request
(from whatever the client) is for two phyically disjoint paths between two
points A and B.  How the server delivers this request is not a function of
the client.  To fully answer the question also requires the duct network
routing to be fully known....all availability is inherited from this layer
since it is the bottom layer in the stack.  But what if the client does not
own the server layers, let alone the duct? (this is a layering problem).
And what happens when two operators connect via an NNI? (this is a
partitioning problem).  Note - to fully satisfy the example you gave on a
truly global case across all customers requires that the world only has 1 SP
(assuming SPs would not want to share all their duct/server layer routing
with everyone else, irrespective of the scalability issues this implies).  I
don't think this scenrario is likely however.

	The only consistent/generic model I see working here is that a
client makes a request of the server and the server says whether this can be
honoured.

> > Based on its traffic flow a router only needs to know between
> > which
> It's not up to you or me to say "irrelevant to TE"; the judge of
> relevancy is the user (SP), and it depends very much on how
> integrated the TE is between the optical domain and the routing
> domain.  I know several SPs that would like *in the long term* to
> have a tightly integrated TE between the two domains; of course
> the majority today prefer loose or no coupling, as that fits their
> current mode of operation.
> 
> From an analytical point of view, though, if you define TE as the
> mapping of flows to physical links, then it seems to me that how
> the lightpath is routed in the optical domain is very relevant.
	NH=> I don't describe TE like this....but I have to say this is
predicated on today's (and the foreseeable) networks where I have to
consider multiple client layers.  TE to me has 3 time constants.
	Large (+ large BW quanta) -> physical duct/L1 build
	Medium (+ medium BW quanta) -> client layer topology built from
server layer trails (ie "client layer link connections = server layer
trails")......and this is the one I want to focus on wrt the OTN, ie move
from slow management-plane trail provisioning to faster control-plane based
trail provisioning (this would be a really good 1st step for now!).
	Small (+ small BW quanta) -> within layer bypass of some general
constraint, like an IGP
	The latter 2 only buy time until you can do real TE via the
first....assuming we are discussing a mismatch of observred traffic trends
vs predicted (ie from forecasts) and not getting over some transient hump.

---

From: Anil Rao <[email-masked]>
Date: Mon, 23 Oct 2000 14:06:49 -0700

Neil/Kireeti,

> Note - to fully satisfy the example 
> you gave on a

I think there is value to both the models.  There are various carriers and
service providers who want to run both the client and server with a well
distributed information model(in which the client understands the
shortcomings of the server) and also in a client/server model where the
client requests the server for services.  

The gmpls model should support both.  In one model, as Neil pointed out
information will not be available for an explicit route object while in the
other case information will be available for explicit route object.

-anil.

---

From: [email-masked]
Date: Tue, 24 Oct 2000 11:51:30 +0100

Ramesh thanks.....I was going to write back to Kireeti and say the key
points of my mail were ignored/unanswered by the snipped extract....however,
you have addressed them here.  Others have also pointed out the
impossibility of 'knowing to the duct' in all networks....esp for NNI case,
ie includes both layering and partitioning.

neil

> From:	Ramesh Bhandari [SMTP:[email-masked]]
> Sent:	Tuesday, October 24, 2000 12:32 AM
> To:	Kireeti Kompella
> Cc:	[email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Hi Kireeti,
> I think the problem you are trying to pose pertains to the calculation of
> the
> pair of disjoint paths from A to B through an intemediate OTN network. The
> solution consists of three parts:
> 
> 1) Calculate diverse paths from A to ingress points X and W, i.e., path A
> to X
> and path A to W, which are physically-disjoint from each other, except at
> the
> common source point A
> 2) Calculate two disjoint paths paths through the OTN network connecting
> the
> ingress points X and W to the egress points Y and Z (two possibilities
> arise in
> general: the diverse paths within the OTN are i) X to Y and W to Z ii)  X
> to Z
> and W to Y)
> 3) Calculate paths Y to B and Z to B, which are diverse from each other,
> except
> at the end point B.
> 
> For A to do all the calculation would require a massive amount of data at
> B,
> including all the necessary details of the (physical) OTN ( not to mention
> the
> fact that in a catastrophic disaster like a fiber cable cut, thousands of
> LSP's
> with different pairs of endpoints would be affected simultaneoulsy, and
> need to
> be also restored simultaneously by the routers for fast restoration).
> 
> In the Overlay/Client model, the requests are received at the ingress
> points X
> and W from the router A, and diverse paths are computed within the OTN,
> using
> network information at each of the OXC controllers (basically part 2 above
> of
> the solution for the peer model).
> 
> Regards,
> 
> Ramesh
> 
> PS Algorithms for finding disjoint paths of the type - parts 1), 2) and 3)
> of
> thesolution above- exist, and can be found in my book "Survivable Networks
> -
> Algorithms for Diverse Routing", Kluwer Academic Publishers (1999).
> 
> Kireeti Kompella wrote:
> 
> > > points A and B.
> > Neil, A *is* the client.  And A wants two disjoint paths to B via
> > *different ingress points in the OTN*.  This is a very reasonable
> > request.
> >
> > Also, A doing a full path computation is *not* a general answer.
> > It is an illustration of an advantage of the peer model, and of
> > routers doing a full path computation across the OTN.  To achieve
> > what A wants in an overlay/client/UNI model would require a fair
> > amount of work in extending routing/signalling/UNI protocols.
> >
> > Kireeti.

---

From: "Lazer, Monica A, NNAD" <[email-masked]>
Date: Tue, 24 Oct 2000 10:21:08 -0400

David,
From our perspective, having the tools to support sub-minute automated
provisioning of circuits is one of the main drivers of this work. This is
one of the reasons that drives us to push for support of multiple clients by
the control plane optical network.   

Monica A. Lazer

908 234 8462
[email-masked]

 -----Original Message-----
From: 	Holmes, David A. [mailto:[email-masked]] 
Sent:	Monday, October 23, 2000 3:19 PM
To:	[email-masked]; [email-masked];
[email-masked]

David Holmes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, October 23, 2000 11:22 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]

Mark Loyd Jones
Sprint

bundling.
optical
including

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 24 Oct 2000 16:05:39 -0700

Monica,
 
> be preferred over the client model.

Nobody is forcing you to use the peer model - it is completely your
choice to use, or not to use it.

> carriers indicating the need to support a client model. 

Nobody is forcing you not to use the overlay (aka client) model.
It is completely your choice to use, or not to use it.

Yakov.

---

From: "Lazer, Monica A, NNAD" <[email-masked]>
Date: Wed, 25 Oct 2000 12:45:25 -0400

Yakov,
As of today I am not convinced that any given alternative is "the best".
However, I do know that from a network operator's perspective the choice for
the best alternative is based on analysis of the capabilities of the
potential options. The basic item here is that there are certain
capabilities that have to be supported by the OTN. I (with other
representatives at T1X1) am working on putting together a list of needed
capabilities, based on several existing requirements documents already
presented in different forums with additional input, if needed from willing
participants. That should form criteria for figuring out which is the best
standard solution for OTN.
We are looking at vendor representatives to help assess the degree to which
different architectures and signaling schemes can support or can be extended
to support these capabilities, and we are looking at interested network
operators to help sift through these requirements and build the criteria
needed for this assessment. I believe that this approach is sound.

In the mean time I can refer you to several documents which are relevant to
our concerns.
ftp://ftp.t1.org/pub/t1x1/x1.0/0x100490.doc and ITU-T
ftp://ftp.t1.org/pub/t1x1/x1.0/0x100510.doc

P.S. We are also in the process of reformatting
ftp://ftp.t1.org/pub/t1x1/x1.0/0x100510.doc and posting it as a draft for
the IETF community. (we would have done it earlier, but putting all the
figures in the stick format .....).

Monica A. Lazer

908 234 8462
[email-masked]

 -----Original Message-----
From: 	Yakov Rekhter [mailto:[email-masked]] 
Sent:	Tuesday, October 24, 2000 6:57 PM
To:	Lazer, Monica A, NNAD
Cc:	'Yakov Rekhter'; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject:	Re: [IP-Optical] RE: Optical link bundling. Was Re:
DraftMinutes From Pittsburgh 

Monica,

> From: 	Yakov Rekhter [mailto:[email-masked]] 
> Sent:	Tuesday, October 24, 2000 1:58 PM
> To:	[email-masked]
> Cc:	[email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Neil,
> [clipped...]
> > 	(i)	are traditional IP control-plane facets (so that is, for
> > example, v4 addressing, RSVP signalling and a IGP) the correct choice
for
> an
> > OTN?....though to be honest no-one it seems dare raise this most basic
of
> > questions too loudly;
> 
> 
> [MAL] Neil is right. I have not seen any overwhelming evidence as to why a
> protocol used for routing individual packets is the best possible
> alternative to be used to set-up circuits.
> 
yakov > If you have "the correct choice" for an OTN, which is other than 
yakov > GMPLS, please share it with the rest of us (by the way, don't
yakov > forget to include detailed description of why your "correct choice"
yakov > is any better than GMPLS).

If you think that Neil is right, then please share with the rest
of us what do you think is "the best possible alternative"
(please include an explanation on why it is any better than GMPLS).

Yakov.

P.S. On being constructive, let me suggest that rather than continue
telling us that GMPLS is not "the best possible alternative to be used
to set-up circuits", folks who subscribe to this point of view should
start working on "the best possible alternative".

---

From: [email-masked]
Date: Thu, 26 Oct 2000 16:15:37 -0500

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

> From: vpoudyal [mailto:[email-masked]]
> 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 <[email-masked]> 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

> From: yakov [mailto:[email-masked]]
> Sent: Thursday, October 26, 2000 8:19 AM
> To: Jones, Mark L.
> Cc: David.A.Holmes; ip-optical; mpls; sc; xuyg; yxue; zwlin; yakov
> 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.
>

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 26 Oct 2000 17:38:37 -0400

> resources with flexibility to change the connectivity of those 

Agree with this. And here is an example.

A few weeks ago, my daughter is about to go off to school (vet school). I
have to set up her PC to use the school's network. Sitting at home, in this
case about 150 miles away from school, it's no problem. Why? Because I can
layer IP over something else, and make it appear to IP as if I were there.
In this case, it was a modem dial-in over PSTN. It could have been an ATM
UNI setup too. Or some such (tunnel over MPLS?).

To tie this back to the redundant provisioning discussion. Let's say I
wanted redundant data paths from my broadband provider. I had suggested that
using IP "options" and carefully chosen OSPF areas, you could achieve this
without anything else.

I was told, and I agree, that this doesn't guarantee that the data paths
will be separate. Because trunks for the two IP data paths might share the
same cable, or cableway. Of course.

The point is, I'm not sure I understand how you can avoid this situation
OTHER THAN by having the service provider know the physical topology of his
network. How can _any_ UNI/NNI scheme ensure that physical paths of
different routes are far apart, except by someone knowing the physical
structure? I don't see how using just IP "options" is any less effective
than any other method.

Bert
[email-masked]