Subject: LSP Failure/Recovery

From: Sachin Kalra <[email-masked]>
Date: Tue, 09 Oct 2001 12:10:23 -0400

Dear All:

I have a question about LSP Failure/Recovery Mechanism

Let's say
If I have an LSP traversing through 20 routers, and somewhere along the 
path link fails between Router 16 and Router 17. So I believe that in this 
case Router 16 will inform Ingress Router about the link failure and 
Ingress Router will try to reroute the LSP and if it is not able to do that 
then Ingress will fail the LSP.

Now if after some time link between Router 16 and Router 17 comes up again. 
Then
Q1> Will Router 16 inform Ingress Router back that link has recovered?
Q2> If Yes why would it inform the Ingress Router? And How will it know who 
the Ingress Router is? Does it saves the state or some information about 
all the LSPs that once passed through that Router but which are broken now?

Any information is appreciated.

Thanks,
Sachin Kalra

---

From: "S.Manikantan" <[email-masked]>
Date: Tue, 9 Oct 2001 09:33:28 -0700

Hello Sachin

If you have a "local repair" support implemented, Router 16 will
reroute the LSP from itself (Router16) to the destination. It is not
required for the rerouting to be done from the Ingress or the head
of the LSP - which is known as "Global repair".

Secondly Router 16 can reroute avoiding Router 17, only when
Router 17 is not an explicit Hop to be reached from Router 16 for
the rerouted LSP

W.r.to your questions, If Router 16, has indicated the ingress
and done the reroute (global repair), It will not indicate the
ingress to reroute again when the link between 16 and 17 comes
up.

Whereas if Router 16 has done a local repair, i.e. has
rerouted the LSPs via some other router to destination say
Router 20 and when the link between 16 and 17 comes up,
Router 16 will/can reestablish (reroute) the link back
via Router 17.

I appreciate any correction of my comments :)

regards
mani

-----Original Message-----
From:	Sachin Kalra [SMTP:[email-masked]]
Sent:	Tuesday, October 09, 2001 9:10 AM
To:	[email-masked]
Subject:	LSP Failure/Recovery

Dear All:

Let's say

Thanks,
Sachin Kalra

---

From: "Naidu, Venkata" <[email-masked]>
Date: Tue, 9 Oct 2001 13:00:54 -0400

Mani:

-> If you have a "local repair" support implemented, Router 16 will
-> reroute the LSP from itself (Router16) to the destination. It is not
-> required for the rerouting to be done from the Ingress or the head
-> of the LSP - which is known as "Global repair".

  Strictly speaking, there is no requirement that only the
  affected router (Router 16 here) should do "local repair".
  Any router/LSR which has sufficient information can do 
  local repair (for example router 15 or 14 etc)
 
-> Secondly Router 16 can reroute avoiding Router 17, only when
-> Router 17 is not an explicit Hop to be reached from Router 16 for
-> the rerouted LSP

  Not necessarily true. If one of the links between Router 16 
  and Router 17 fails, the _only_ requirement is to avoid the
  failed "link" and not the complete "node" (Router 17 here).

  So Router 16 can locally route the LSP to another parallel
  link to Router 17 _OR_ another disjoint path to 17. What you
  are trying to achieve here is link disjointness and not
  node disjointness.
   
-> W.r.to your questions, If Router 16, has indicated the ingress
-> and done the reroute (global repair), It will not indicate the
                                           ^^^^^
-> ingress to reroute again when the link between 16 and 17 comes
-> up.

  Router 16 MAY indicate the ingress LER when the link between
  Router 16 and 17 comes back up. There are no hard and fast rules...

--Venkata Naidu

---

From: Sachin Kalra <[email-masked]>
Date: Tue, 09 Oct 2001 13:17:06 -0400

Venkata:

Thanks for the email.

 >Router 16 and 17 comes back up. There are no hard and fast rules...

I agree with Mani in this case and suspect that "LSR 16 MAY indicate the 
ingress LER when the link between Router 16 and 17 comes back up."

Because
1> Why would LSR16 maintain information about the broken LSP (Which is not 
going through LSR16 any more, as may be the case that LSR14/15 or Ingress 
LER may have rerouted the LSP bypassing LSR16)

2> And if LSR16 does not maintain any state for broken LSP then it should 
not even know that it has to inform any LER (or other LSR) about the link 
recovery.

Please correct me if I am wrong.
Sachin

---

From: "S.Manikantan" <[email-masked]>
Date: Tue, 9 Oct 2001 10:33:49 -0700

Hello Venkata

#-> If you have a "local repair" support implemented, Router 16 will
#-> reroute the LSP from itself (Router16) to the destination. It is not
#-> required for the rerouting to be done from the Ingress or the head
#-> of the LSP - which is known as "Global repair".
#
#  Strictly speaking, there is no requirement that only the
#  affected router (Router 16 here) should do "local repair".
#  Any router/LSR which has sufficient information can do 
#  local repair (for example router 15 or 14 etc)

Yes. I agree that there other than Router 16, its upstream
LSRs/Routers too do the "local repair". 

I meant, if Router 16 has the capability to do the local
repair, it can reroute the LSP from its point itself.
In that case Router 15 or 14 need not do a re route. Am I right?

# 
#-> Secondly Router 16 can reroute avoiding Router 17, only when
#-> Router 17 is not an explicit Hop to be reached from Router 16 for
#-> the rerouted LSP
#
#  Not necessarily true. If one of the links between Router 16 
#  and Router 17 fails, the _only_ requirement is to avoid the
#  failed "link" and not the complete "node" (Router 17 here).
#
#  So Router 16 can locally route the LSP to another parallel
#  link to Router 17 _OR_ another disjoint path to 17. What you
#  are trying to achieve here is link disjointness and not
#  node disjointness.

I meant, suppose the LSP is initially established, and the LSP request
had Router 17 as a strict hop (ERO) to be reached from Router 16. In this
case the LSP cannot be rerouted right? Since Router 17 is the one
to be reached from Router 16. 

Let me know if I am missing something?

#   
#-> W.r.to your questions, If Router 16, has indicated the ingress
#-> and done the reroute (global repair), It will not indicate the
#                                           ^^^^^
#-> ingress to reroute again when the link between 16 and 17 comes
#-> up.
#
#  Router 16 MAY indicate the ingress LER when the link between
#  Router 16 and 17 comes back up. There are no hard and fast rules...

Is this more of an implementation related one? i.e. to indicate the ingress?

Correct me .. I may be wrong?

regards
mani

---

From: "Naidu, Venkata" <[email-masked]>
Date: Tue, 9 Oct 2001 13:48:31 -0400

-> -> Router 16 MAY indicate the ingress LER when the link between
-> -> Router 16 and 17 comes back up. There are no hard and fast rules...

-> I agree with Mani in this case and suspect that "LSR 16 MAY indicate the
ingress LER when the link -> between Router 16 and 17 comes back up."

-> Because
-> 1> Why would LSR16 maintain information about the broken LSP (Which is
not going through LSR16 any -> more, as may be the case that LSR14/15 or
Ingress LER may have rerouted the LSP bypassing LSR16)

-> 2> And if LSR16 does not maintain any state for broken LSP then it should
not even know that it -> -> has to inform any LER (or other LSR) about the
link recovery. 

  What I am trying to convey is: There is no requirement which 
  states not to maintain notification information.

  Please refer to section 3.8.3 Restoration and Notification 
  in draft-ietf-mpls-recovery-frmwrk-03.txt.

--Venkata Naidu

---

From: "Naidu, Venkata" <[email-masked]>
Date: Tue, 9 Oct 2001 13:54:55 -0400

-> #-> If you have a "local repair" support implemented, Router 16 will
-> #-> reroute the LSP from itself (Router16) to the 
-> destination. It is not
-> #-> required for the rerouting to be done from the Ingress 
-> or the head
-> #-> of the LSP - which is known as "Global repair".
-> #
-> #  Strictly speaking, there is no requirement that only the
-> #  affected router (Router 16 here) should do "local repair".
-> #  Any router/LSR which has sufficient information can do 
-> #  local repair (for example router 15 or 14 etc)
-> 
-> Yes. I agree that there other than Router 16, its upstream
-> LSRs/Routers too do the "local repair". 
-> 
-> I meant, if Router 16 has the capability to do the local
-> repair, it can reroute the LSP from its point itself.
-> In that case Router 15 or 14 need not do a re route. Am I right?

  Yes.
 
-> #-> Secondly Router 16 can reroute avoiding Router 17, only when
-> #-> Router 17 is not an explicit Hop to be reached from Router 16 for
-> #-> the rerouted LSP
-> #
-> #  Not necessarily true. If one of the links between Router 16 
-> #  and Router 17 fails, the _only_ requirement is to avoid the
-> #  failed "link" and not the complete "node" (Router 17 here).
-> #
-> #  So Router 16 can locally route the LSP to another parallel
-> #  link to Router 17 _OR_ another disjoint path to 17. What you
-> #  are trying to achieve here is link disjointness and not
-> #  node disjointness.
-> 
-> I meant, suppose the LSP is initially established, and the 
-> LSP request
-> had Router 17 as a strict hop (ERO) to be reached from 
-> Router 16. In this
-> case the LSP cannot be rerouted right? Since Router 17 is the one
-> to be reached from Router 16. 

  Yes, if Router 17's failed link is in strict/loose ERO.  

-> #-> W.r.to your questions, If Router 16, has indicated the ingress
-> #-> and done the reroute (global repair), It will not indicate the
-> #                                           ^^^^^
-> #-> ingress to reroute again when the link between 16 and 17 comes
-> #-> up.
-> #
-> #  Router 16 MAY indicate the ingress LER when the link between
-> #  Router 16 and 17 comes back up. There are no hard and 
-> fast rules...
-> 
-> Is this more of an implementation related one? i.e. to 
-> indicate the ingress?

  As Dave pointed out, Yes!

--Venkata Naidu

---

From: "David Allan" <[email-masked]>
Date: Tue, 9 Oct 2001 15:23:32 -0400

Hongwei:
 
You use the tools according to the requirements. Ingress router re-route on
failure will of course make the most optimal use of resources as the only
network resource committment is to the currently working "optimal" path.
However on failure you get a relatively long outage which is the sum of the
durations of the detection/propagation times for the initial failure, and
the set up time for the new optimal path with the failed resource removed
from the topology database. Any attempt to improve on this to meet other
performance criteria (e.g. to minimize packet loss) involves juggling how
you commit resources in the network and steady state operation may look less
optimal if you simply stick with any one approach.
 
As to your questions, won't claim expertise... but an explicit route (and I
assume you mean with constraints) involves pruning the topology database
according to the desired constraints and running the SPF algorithm on the
pruned set. How much computational load this spreads over the network (e.g.
done once at the LER or iteratively modified as the setup progresses across
the network) depends on whether you use a strict or loose route, have
routing hierarchy, rate of churn, etc. crankback being one answer to fix
imperfections in LER route determination.
 
later
Dave

-----Original Message-----
From: Hongwei [mailto:[email-masked]]
Sent: Tuesday, October 09, 2001 2:28 PM
To: Allan, David [CAR:NS00:EXCH]
Cc: mpls
Subject: RE: LSP Failure/Recovery

Dave,
 
If it is intended to implement traffic engineering with mpls, i think it
will be rational to let the ingress router deal with rerouting task because
it is the ingress router that computed the explicit route. if we allow LSR16
to do local rerouting, we may not achieve overall optimised network
performance, that is, the network load may not be balanced the best. 
 
If we have no concern about traffic engineering, i think all the three
methods you listed are usable, depending on the network administrator or
device vendors.
 
To be honest, I have also some other confusions about explicit routing:
1. how does the ingress routers compute the optimised explicit routes
through the network?
2. To compute an optimised route, a router need complete information of the
network. but every router including LERs and LSRs, has the complete
information about the whole network or the autonomous system, or just the
LERS have this whole information?
3. how do the routers get the information about the whole network? it should
be a headache because the load of the network, maybe also the topology of
the network, is in highly dynamic change.
 
Thanks for every answer in advance!!!
 
-Hongwei

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of David Allan
Sent: 09 October 2001 18:39
To: Sachin Kalra; Naidu, Venkata; [email-masked]'; [email-masked]
Subject: RE: LSP Failure/Recovery

Sachin/Venkata:
 
You're mixing protection switching, and re-route scenarios. There are
specific behaviors/state requirements depending on the recovery strategy,
    - LSR 16 may tell the ingress (revertive/non-revertive global repair), 
    - LSR 16 may tell no-one (local repair),  
    - LSR 16 may tell EVERYONE (simple re-route) when the link goes
down/comes back up.
 
later
Dave

---

From: "David Allan" <[email-masked]>
Date: Tue, 9 Oct 2001 16:40:01 -0400

Venkata/Mani:

-----Original Message-----
From: Naidu, Venkata [mailto:[email-masked]]
Sent: Tuesday, October 09, 2001 1:01 PM
To: [email-masked]'; 'Sachin Kalra'; [email-masked]

>  local repair (for example router 15 or 14 etc)

Technically the definition of local repair in the framework document is THE
router upstream of the failure taking action. Pragmatically, if the router
is not adjacent to the failure, then you need fault propagation, more
complex diversity algorithms, and endure longer outages on failure (due to
propagation delay).

>  are trying to achieve here is link disjointness and not

I'm hearing about 3 things here:

- the fact that a backup route that is diverse with the failed resource may
not exist.
- the requirement is for the backup path to avoid the failure (and you may
not be able to distinguish link and node failures in which case pre-planned
recovery paths need to go to the next-next-hop).
- a scenario where a failure can authoritratively be localized to one link
in a multi-link adjacency.

So my failure detection tells me what it can, and I do recovery accoringly
(including declaring real "hard" failure when an alternative does not
exist).

>  Router 16 and 17 comes back up. There are no hard and fast rules...

The rules depend on whether the network recovers and re-uses those LSP
resources that survive a failure or not. 

Dave