The MPLS WG Archive

[Eric Gray <eric.gray@sandburst.com>]

Hemant,

    On #1, there are plenty of reasons not to allow LSPs to change to a new
next hop and there are ways to prevent it.  Complexity in re-routing may lead
to plenty of reason not to allow it.  #2 was answered by someone else already
(routing 'triggers' the change).  I think #3 is correct - but let me make sure I
understand what you're saying.

    You're saying that a change in next hop - possibly due to a new shortest
path route - occurs at an LSR for some LSPs.  For any LSP that is 'pinned',
the LSP remains unchanged while for all others, the LSPs are re-routed.  If
this is what you're saying, then that is correct.  Note that this is true when
the new next hop is better than the old next hop, but is not true when the
new next hop is a default result of the old next hop becoming unavailable.
In the old next hop no longer available case, LSPs are torn down at least to
the last hop of the intact segment where local repair is permitted, but often
preferably to the ingress.

--
Eric Gray

You wrote:

> Eric,
> Thanks for the explaination. Now there are 3 complications associated:
>
> #1. Connection and traffic flow states for all the FECs on the LSP are
> changed, when the next hop is changed. For "one" hop change, the QoS/SLAs
> for other FECs may change depending on the New QoS connection matrix.
> This indeed is a complex problem to solve.
>
> consider a simple case:
> there are 2 QoS+connection matrices M1 and M2.
> for few FECs M1 is preferred, for others M2 is ok.
> So, does the LSR calculate a "weighted" advantage based on the priorities
> of LSPs, to decide whether to change the next hop or not ?
>
> #2. Who "triggers" the event or availability of the best next hop ? Should
> LSRs let free to choose best next hops, as and when required ?
>
> #3. Suppose for "N" FECs the next hop earlier is "NH1". Out of these "N"
> FECs, few are of source routed type. Now if the LSR takes a decision to
> switch to the hop "NH2" as the next hop, then still it has to maintain
> and manage itself for the prvious hop "NH1" for these source routed LSPs.
>
> Please correct me in above 3 points.
>
> Regards,
> Hemant
>
> Date: Mon, 10 Sep 2001 09:43:00 -0400
> From: Eric Gray <eric.gray@sandburst.com>
> To: Hemant P. Kelkar <hemant@cyberspace.org>
> Cc: mpls-ops@mplsrc.com, mpls@UU.NET
> Subject: Re: Next hop Change
>
> Hemant,
>
>     This is an implementation detail.  :-)
>
>     When an LSP is established, the local LSR is able to determine whether
> or not it can (or should) detect a change in optimal next hop.  If the LSP
> is
> pinned, or the next hop is a strict hop that is not an abstract node (i.e.
> - an
> AS or address prefix), then the LSR cannot and should not attempt to find
> a better next hop for the life of the LSP.  Otherwise, the LSR needs to do
> whatever implementation specific trick is required in order to ensure that
> it is notified by the appropriate software entity (e.g. - routing) when
> the
> 'best path' to the LSP next hop (not necessarily the same as a routing
> next
> hop, for instance), or LSP destination, changes.
>
>     This is not hard to do.
>
> --
> Eric Gray