The MPLS WG Archive

[Ramesh Bhandari <bhandari1@lucent.com>]

Folks,

Joint routing is expected to produce a solution which takes up less total resources compared to independent routing and, as was mentioned by me in a previous email from me and also noted below by Yakov, the latter may not produce a solution in certain cases even when the solution exists. This point is  addressed in detail in the book "Survivable networks - Algorithms for Diverse Routing" (Chapter 3).

Regards,

Ramesh

Yakov Rekhter wrote:

Mark,

> The concept of jointly routing primary and protection paths has been
> well accepted by Bell heads looking at optimizing their networks for a
> long time. Part of the reason for this is the assumption that protection
> path(s) must also be conformant to the same SLA as the primary path, and
> joint routing is the most likely to achieve this.
>
> This does not of course address your concerns about race conditions at
> connection establishment. But joint routing is guaranteed to produce a
> solution not worse than independent routing, and results in a lower
> commitment of network resources.

Moreover, in certain cases independent routing would not be able to
produce a solution at all, while joint routing would be able to produce
a solution.

Yakov.

>
> ciao
>
> mark
>
>
>
>
>
>
> David Allan wrote:
>
> >
> >
> > Angela:
> >
> > Jointly routing the paths intuitively does not strike me as optimal.
> > Not unless we are periodically performing path maintenance on the
> > entire set of network resources. I would have to assume that the
> > overall configuration of the network occurred incrementally, and with
> > a desire to minimize service interruption of the already established
> > paths.
> >
> > With that in mind, I would assume the routing of the primary path
> > should always be chosen as the optimal route. The backup path is then
> > required to be diverse (node, fiber, conduit, trench) with the optimal
> > primary path and would frequently be less optimal as the physical
> > routing would frequently be in the form of a longer path.
> >
> > I do not understand how whether this is done sequentially or
> > simultaneously affects these basics, except in the possible deadlock
> > scenario where the optimal routing of the primary path precludes a
> > viable backup. In the meantime, I would assume sequential
> > establishment of primary then backup would stand an overall greater
> > chance of success, especially if the path computing node does not have
> > a comprehensive and authoritative view of the network state. It
> > strikes me that routing the backup should have the ability to
> > intelligently crank back with knowledge of what to avoid to maintain
> > diversity with the primary path.
> >
> > regards
> > Dave
> >
> >      -----Original Message-----
> >      From:   Angela Chiu [SMTP:alchiu@research.att.com]
> >      Sent:   Wednesday, October 25, 2000 10:03 AM
> >      To:     'Yakov Rekhter'
> >      Cc:     ip-optical; mpls; sc; xuyg; yxue
> >      Subject:        RE: [IP-Optical] RE: Optical link bundling. Was
> >      Re: DraftMinutes From  Pittsburgh
> >
> >      Yakov,
> >
> >      Yes, you are right. Routing the primary and backup paths jointly
> >      is always
> >      more optimal than fixing the path for primary first then routing
> >      the backup
> >      accordingly. The same argument can be applied to comparing
> >      centralized
> >      routing with distributed routing. Even distributed routing is
> >      less optimal,
> >      it is the trend today. I think the real issue is at what cost the
> >      additional
> >      optimality is gained, and how much the additional optimality is
> >      in a typical
> >      network setting. In this case the cost is all the topological
> >      information
> >      including SRLG information as well as physical impairment
> >      constraints in the
> >      optical network that routers need to obtain in order to make
> >      proper routing
> >      decision.
> >
> >      I have an idea, this will be a valid master/PhD thesis for some
> >      graduate
> >      students who would like to work on real world problems.
> >
> >      Regards,
> >
> >      Angela
> >
> >      -----Original Message-----
> >      From: ip-optical-admin@lists.bell-labs.com
> >      [mailto:ip-optical-admin@lists.bell-labs.com]On Behalf Of Yakov
> >      Rekhter
> >      Sent: Wednesday, October 25, 2000 7:35 AM
> >      To: alchiu@research.att.com
> >      Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET; sc@tellium.com;
> >      xuyg@lucent.com; yxue@UU.NET
> >      Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re:
> >      DraftMinutes From Pittsburgh
> >
> >      Angela,
> >
> >      > Some followup discussions in line.
> >
> >      more in line...
> >
> >      > Regards,
> >      > Angela
> >      >
> >      > -----Original Message-----
> >      > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
> >      Kireeti
> >      > Kompella
> >      > Sent: Monday, October 23, 2000 1:58 PM
> >      > To: kireeti@juniper.net; sc@tellium.com; xuyg@lucent.com;
> >      yxue@UU.NET
> >      > Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET
> >      > Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re:
> >      > DraftMinutes From Pittsburgh
> >      >
> >      >
> >      > > 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.
> >      >
> >      > [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.
> >
> >      Not really... for more on this see below...
> >
> >      > 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.
> >
> >      It is a known fact that for computing disjoint paths the approach
> >
> >      you outlined above may result in a situation where no backup
> >      path will be found, despite the fact that that it is possible
> >      (using some other approach) to find two disjoint paths.
> >
> >      > 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.
> >
> >      In the end it is not the discussion on this list, but the
> >      competition
> >      in the marketplace that will determine the viability of different
> >
> >      models.
> >
> >      Yakov.
> >
> >      _______________________________________________
> >      IP-Optical mailing list
> >      IP-Optical@lists.bell-labs.com
> >      http://lists.bell-labs.com/mailman/listinfo/ip-optical
> >
>