Subject: Re: Re: Next hop Change

From: "Hemant P. Kelkar" <[email-masked]>
Date: Mon, 10 Sep 2001 14:07:58 -0400 (EDT)

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 <[email-masked]>
To: Hemant P. Kelkar <[email-masked]>
Cc: [email-masked], [email-masked]
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

---

From: Eric Gray <[email-masked]>
Date: Mon, 10 Sep 2001 18:30:30 -0400

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