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

From: Sid Chaudhuri <[email-masked]>
Date: Mon, 23 Oct 2000 11:56:28 -0400

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:[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.

---

From: Zhi-Wei Lin <[email-masked]>
Date: Mon, 23 Oct 2000 12:17:26 -0400

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:
> _______________________________________________
> 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: Jim Boyle <[email-masked]>
Date: Mon, 23 Oct 2000 12:09:14 -0600 (MDT)

if the lambda's are unprotected (which is debatable), then the routers can
communicate amongst themselves and decide what are the failure scenarios,
and request more or less capacity based on that analysis.  

A complex alternative is to support things like:

a) "setup these two circuits in a diverse manner"
b) same as (a) but over different UNIs, in fact in different towns
(e.g. setup nyc-sfo diverse from wdc-lax)
c) "setup this circuit diverse from SRLG A,B,C" (which may be infeasible
if the circuit which those SRLGs were derived from preclude a diverse
route).

As for path selection in general, a knowledge of the underlying topology
is probably necessary for most optimal path selection when establishing
lightpaths for non-direct traffic.

This only makes sense in the 2001 timeframe to support one's ISP over
one's optical network.  An argument can be made that a good OSS makes a
lot of this level of integration unnecessary.  Inter-company is a whole
other issue.

regards,

Jim

---

From: "John Strand" <[email-masked]>
Date: Mon, 23 Oct 2000 14:44:00 -0400

That you're describing is basically what the OIF Carrier Group
included in our requirements document. Some snippets:

From the assumptions:
(6) Carriers will want to differentiate their services by defining their own "branded" bundles of functionality, service quality, support, and pricing plans. 
(7) The network is a prime asset for carriers. As such, a carrier will not relinquish control of its resources outside of its administrative boundaries.

From the Objectives section:
(3) Provide restoration, diverse routing, and other Quality of Service features within the control plane on a per-service-path basis.  Per-circuit control of these capabilities is important because of the anticipated diversity of needs of the OL users.
(8) Provide the ability for the carrier to control usage of its network resources. The carrier will control what network resources are available to individual services or users. Therefore, in the event of capacity shortages this ability will allow the carrier to ensure that critical and priority services get capacity.

From the introduction to the restoration options discussion:
We use "service level" to describe priority related characteristics of connections, such as holding priority, set-up priority, or restoration priority. The intent currently is to allow each carrier to define the actual service level in terms of priority, protection, and restoration options. Therefore, mapping of individual service levels to a specific set of priorities will be determined by individual carriers. Service levels are discussed in more detail as connection attributes in oif2000.061.

John

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Zhi-Wei Lin
Sent: Monday, October 23, 2000 12: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,

Thanks
Zhi

---

From: Yong Xue <[email-masked]>
Date: Tue, 24 Oct 2000 09:15:30 -0400 (EDT)

Sid,

You are correct. The requirement for connection is generated
from router and it can be serviced by network in the overlay model
or by the router if it's peer model.

/Yong