The MPLS WG Archive

[neil.2.harrison@bt.com]

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

> -----Original Message-----
> From:	Ramesh Bhandari [SMTP:bhandari1@lucent.com]
> Sent:	Tuesday, October 24, 2000 12:32 AM
> To:	Kireeti Kompella
> Cc:	neil.2.harrison@bt.com; sc@tellium.com; xuyg@lucent.com;
> yxue@UU.NET; ip-optical@lists.bell-labs.com; mpls@UU.NET
> Subject:	Re: [IP-Optical] RE: Optical link bundling. Was Re:
> DraftMinutes From Pittsburgh
> 
> 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:
> 
> > > > 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.