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

From: Kireeti Kompella <[email-masked]>
Date: Mon, 23 Oct 2000 12:40:35 -0700 (PDT)

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

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: Zhi-Wei Lin <[email-masked]>
Date: Mon, 23 Oct 2000 16:07:32 -0400

Hi,

Maybe I can set up a scenario where we can see how these routings work.

Let's take an example where we have a service provider XYZ serving the
NY metro area. Let's also assume that the offered service is the
switched optical service.
Let's also assume that XYZ has several customers such as Citibank,
JPMorgan, Turner Cable, Verizon.

1. Citibank wants to set up a connection between its NYC office and its
Atlanta office. In order to reach Atlanta, service provider XYZ may need
to connect with a secondary (intermediate) service provider ABC for
connectivity. 

2. And let's say Citibank wants to be able to specify the explicit
route. That means the Citibank router doing the path computation needs
to know how the nodes are connected, the resources available at the
node, and probably other information such as the SRGs of these links.
Not only that, but it also needs to know the inner topology (and other)
details of the ABC network to do explicit routing. 

3. This means that if other XYZ and ABC customers want explicit routing,
they would also be provided to them (let's say they are all IP over
optical via the POS or the new GFP mapping). 

==> Given this example, how realistic is it (from both a customer
expectation and carrier expectation) to share the type of information
needed to allow the client router to perform explicit routing? 
==> What about the seemingly need to share information across carriers
into customers?

I think this is not a question of whether the vendors can build this
type of box and the mechanisms to support this (clearly vendors can
build whatever customer want -- the issue is what is the customer
getting for the price), but the question really is:

==> How comfortable are carriers in giving this information out, and how
comfortable are customers (especially financial institutions that may
have qualms about their resource use being visible by other customers)
in sharing their network use with other customers.

Again, I don't think this is a question for vendors, but more for
carriers. Vendors of course can have our own opinions and we can offer
what our customer tell us, but let's allow the carriers to formulate
their opinion first and follow what they have to say instead of simply
hand-waving and say "this is what our customers want".

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

---

From: "John Strand" <[email-masked]>
Date: Mon, 23 Oct 2000 17:06:19 -0400

Zhi,
Before complicating the problem by inserting the XYZ and ABC service provider,
consider the problem where one of the customers you mentioned has
direct connectivity to a backbone optical network. In this case I think
the Carrier Requirements document discusses a couple of specific options:
For a major customer, perhaps an OVPN (see my previous Email for a high-level
business model of this) with information sharing about the resources the
customer has contracted for and customer control of them. 

When you introduce XYZ and ABC, things get much more difficult:
(1) As I mentioned in an earlier Email there is no mechanism now being
    contemplated that would allow the definition of SRLG's across carriers,
    so Citibank or whoever would not be able to get the information needed
    to do diverse routing - the carriers just don't have it to give.
(2) There is not yet any work underway on interdomain protocols that I'm
    aware of in the OIF, ITU, or IETF. (I just got some stuff from Canarie in
    Canada, but I haven't looked at it yet.)
(3) For Citibank (say) to get the information needed about XYZ, ABC, and the
    backbone optical network(s) presumably all of these optical network providers would
    end up sharing not only topology information but information on spare
    capacity with each other as well as with citibank. I don't know much about Internet peering,
    but there doesn't seem to be a whole lot of topology information
    shared between ISP's now. It's hard for me to see why optical network
    providers are going to be any more trusting than ISP's are.
(4) There also will presumably be peering relationships between optical networks
    that will constrain Citbank's routing options. For example, what if XYZ and
    ABC don't have an arrangement for splitting revenues?

John

John Strand
AT&T
Lightwave Networks Research Dept.
100 Schulz Drive, Room 4-212
Red Bank, N.J. 07701-7033
(732)345-3255
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Zhi-Wei Lin
Sent: Monday, October 23, 2000 4:08 PM
To: Kireeti Kompella
Cc: [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

Hi,

Zhi

_______________________________________________
IP-Optical mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/ip-optical

---

From: Ramesh Bhandari <[email-masked]>
Date: Mon, 23 Oct 2000 19:32:23 -0400

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).