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

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

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

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.

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

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.

Kireeti.

---

From: Zhi-Wei Lin <[email-masked]>
Date: Mon, 23 Oct 2000 14:09:15 -0400

Hi Kireeti,

I agree that the judge of relevancy is the SPs. The SPs will tell us
(vendors) what their business models are, and what we need to support
first. 

In your example, you suggest that a router is setting up diverse paths
for protection without the service provider knowing about this. Is the
router part of the service provider network or part of the customer
network?

What is the reason for requesting those two diverse paths? Is it to meet
some availability requirement? Or is it for something else?

Thanks in advance for your clarification.

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: "Angela Chiu" <[email-masked]>
Date: Mon, 23 Oct 2000 14:42:45 -0400

Kireeti,

Some followup discussions in line.

Regards,
Angela

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Kireeti
Kompella
Sent: Monday, October 23, 2000 1:58 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re:
DraftMinutes From Pittsburgh

[AC] I think you have a good point here. I also heard the same kind if
reasoning (i.e., have a layer-3 like protection switching) for supporting
the peer model. But after discussing with others, it seems that overlay
model should be able to provide the same capability. Normally, the primary
LSP X->Y is set up first, and becomes a forwarding adjacency (FA) according
to your LSP Hierarchy draft. Then the associated information of the FA X->Y
including its exact path and SRLG information should be propagated via IGP
extensions, same as with any other link in the network. Thus if router A
sends a request to OXC W to set up a backup lightpath from W->Z to be
diversely router from the existing FA X->Y, OXC W should already have the
right information to perform proper routing.

Comparing with the peer model solution where routers need to know all the
SRLG information of the optical domain as well as all relevant physical
impairments in the optical signal in the case of transparent optical
network, it is still not clear to me which one is simpler.

I think it is very good to have this kind of technical discussion openly on
the list. Hope others can provide more technical and business (after all
carriers need to pay for these features) evidences for the need of each
model. Some other reasoning I heard includes that peer model can improve the
IGP scalability in terms of the number of neighbors a router needs to peer
with. But since large ISPs today seem to cope well with the IGP scalability
today, I don't see why the problem will get significant worst when optical
networks come into play.

Regards,

Angela

BTW, the draft John Strand mentioned on the list earlier should be at
http://search.ietf.org/internet-drafts/draft-chiu-strand-unique-olcp-00.txt
with all lower cases.
A new version will be out in a few weeks before the deadline since we are
still working on a few details and editing.

---

From: "John Strand" <[email-masked]>
Date: Mon, 23 Oct 2000 15:34:35 -0400

Kireeti,
What's needed is a way for you to ask for a lightpath that's physically
diverse from one or more other lightpaths, whether or not the other
lightpaths have the same terminals as the new lightpath. This is done
routinely at DS3 and (I think) OC-n levels today by PL services like
AT&T's EDRO (Enhanced Diversity Routing Option). There are 2 general
options:
(1) If all the circuits are new, they can be routed simultaneously.
    This is an NP-complete problem and probably would have to be done
    in the management plane. This is essentially the EDRO approach.
(2) To do dynamically (real time) a pragmatic approach would be to request the
    circuits sequentially, one at a time, with each request including
    a requirement that it be diverse from the previously routed ones.
    This ought to be easy to implement algorithmically but won't
    always work (give diverse paths). The problem cases would come if
    (in your example) X and W are close together (same metro), and
     Y and Z are also, and the 2 metros are far apart. Then the 1st lightpath
    routed might inadvertently mess up routing options for the 2nd.

The heuristics to simultaneously route a number of circuits simultaneously
subject to diversity constraints essentially require zillions of calls
to a Dijkstra algorithm and so don't seem to lend themselves to incorporation
in the control plane. (Am I being too pessimistic?) This however is not just an 
Optical Layer problem - the IP layer would have the same computation to do.

I'd be interested in hearing more about the drivers for your example. I would
expect that if you want physical diversity you are setting up lightpaths that
are going to be around for a while. If this is the case would it be OK to take
a little longer (but < 1 minute) to do the provisioning? If so simultaneous
routing ought to be possible. I'd be interested in hearing from control plane
developers their reactions to incorporating an algorithm requiring (say)
10**2 calls to a Dijkstra algorithm on a large (10**3 node) network.

There's a book by Ramesh Bhandari that addresses some of the algorithm issues.
I don't believe that the heuristics used for services like EDRO are in the
public domain though. I have a long-standing interest in these algorithms (I
did the ones used in EDRO) and would be most interested in hearing from people
working in this area.

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 Kireeti
Kompella
Sent: Monday, October 23, 2000 1:58 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re:
DraftMinutes From Pittsburgh

Kireeti.

_______________________________________________
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 21:03:42 -0400

Hi Folks,

There has been a flurry of email exchanges on issues and algorithms pertaining to
paths routed diversely within a network (e.g., the OTN) in accordance with client's
request. Several interesting scenarios were briefly discussed: path routed
diversely from existing paths, simultaneous calculation of diverse paths,
efficiency of the algorithms, diverse paths requested by a client ingressing and
egressing through the OTN network through different points( and how to achieve
that), etc. In the process, my book on diversity algorithms was pointed out by John
Strand. In light of the interest in diversity , I thought I mention a few important
details about my book "Survivable Networks - Algorithms or Diverse Routing", Kluwer
Academic Publishers (1999):

1) The book points out the pitfalls of finding the shortest path first and then
routing the second path diversely from the first path; this approach produces
nonoptimal solutions, and is sometimes unable to determine a diverse pair of paths,
even when such a pair actually exists.

2) It provides detailed algorithms for simultaneously calculating the diverse pair
of paths in an optimal (least total cost) manner. The algorithms are simple and
efficient, basically requiring two runs of a (modified) Dijkstra algorithm. They
are easily extended to finding K(>2) disjoint paths in he network (this is useful
for protection against multiple failures and network and also efficient network
design) When diversity simply does not exist due to insufficient network
connectivity, maximally disjoint paths are found (this is important, since a
customr may accept less than 100% diversity).

3) It provides extensions to the real-life physical networks, involving
span-sharing links (or SRLG's, as they are now called)

4) It provides extensions to the types of cases brought out by Kireeti Kompella
(different ingress and egress points for diverse routes)

Although the construction of algorithms in the book is driven by optimality, for
complicated situations where fast, optimal solutions are not possible, suitable
(fast) heuristics can be derived (see, e.g., Section 6.2 of the book) using the
developed algorithms. Clearly, heuristic approaches which involve running the
Dijkstra algorithm over and over again are to be avoided, as they become
inefficient.

Regards,

Ramesh