Subject: RE: Re: Between OSPF RSVP...

From: "Nair, Girish (Girish)" <[email-masked]>
Date: Wed, 12 Mar 2003 15:25:37 -0500

Giovanni,

I agree. Link down LSP rerouting can be done a little more efficiently
using the IGP. This has been done in some proprietary signaling
implementations
and works well. It involves tighter coupling between the IGP and signaling
though.

Girish

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 12, 2003 3:13 PM
To: mpls
Subject: Re:Re: Between OSPF RSVP...

Hi Curtis hi all,
essentially my considerations are: if i have two pre-calculated disjoint
backup paths and i use opaque LSA to flood the link failure information,
it could be a reasonable faster  way of proceeding instead of using RSVP if
i have an intelligence in the source routers (routers have to be able to
switch among the two LSPs if they receive that particular opaque LSA; note
that for a restoration of many LSPs RSVP will work in series, but OSPF will
work in parallel with its flooding mechanism).
So the basic question is: is it a reasonable way the use of OSPF  and opaque
LSA? Is there a reason to the use always RSVP for path protection, since, i
think, increasing the LSPs corrupted by one link failure (if there are many
active LSPs on the link that goes down) the OSPF mechanism of flooding is
more efficient than using many RSVP messages from node that detects the
failure towards the LSPs senders?

Thanks in advance for your kind answers and observations.

Giovanni Di Giacomo

In message <[email-masked]>,
"john151@libero
.it" writes:
> Hi all,
> I' m interesting in protection/restoration (P/R) mechanisms and after
having 
> read some works, i' d like to do some observations.
> In a TE path protection scenario, there are works dealing with the use of
RSV
> P-TE messages to signal, in  example, 
> a link failure.
> But could it have sense this other way of recovery?
> ...After a detection of a failure, OSPF ( OSPF-TE ) uses the flooding
mechani
> sm to advertise the all network that one link is broken
> ( ... using opaque LSA? ); then all nodes, receiving the LSA with this
inform
> ation, could compute an analysis of what LSPs ( LSP having source in that
nod
> e ) are interested by the failure. Then, in example, each node that wants
to 
> do restoration in a MPLS scenario could make a Label Switching if there is
a 
> Backup Path available. 
> This approach has some problem:
> -   a faster trigger on OSPF in detecting failure, since HELLO mechanism
is s
> low;
> -   the prioriting of the sequence ---flooding LSA---  and  then
---computing
>  SPF algorithm--- to do faster;
> -   the adding of intelligence in each node to do the Switching.
> 
> I know that these are only some observations containing ( i hope few )
errors
>  and that aren't complete, but since i haven' t found any P/R mechanisms
in a
>  TE scenario using OSPF ( or any optimized version of this ), i' d like to
ma
> ke you a question:
> is this a possible way of study ( as an alternative to RSVP signalling )
or i
> s completely wrong and out of all standards?
> 
> Thanks in advance for your kind answers and observations.
> 
> Giovanni Di Giacomo

OSPF/TE already uses the SONET framing detection to trigger fast
flooding of link down.  This is a FAQ.

Ingress then quickly find any affected LSPs (the quickly part is an
implementation detail, but reasonable implementations don't do a
search of all LSPs but rather have this information already available
as a data structure hung off the TE-LSDB entry for the link).

Presignaled disjoint backup LSPs from the ingress are known as
"standby" LSP and are implemented by most LSR as an alternate to FRR.
In practice, standby LSP provide anywhere from sub second to a few
second restoration AFAIK.  Otherwise the ingress must resignal the
affected LSPs on new paths.  This is supposed to take just a few
seconds but in practice if a lot of LSPs are affected most LSR seem to
fall back to IP forwarding and get the LSPs up in 10s of seconds.
Implementations are improving and getting this to consistently a few
seconds, even for large topologies and large numbers of affected LSPs
is being discussed elsewhere usually referred to as the "fast
convergence" problem.

LDP makes direct use of the OSPF derived next-hop.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 12 Mar 2003 16:21:18 -0500

In message <[email-masked]
> and works well. It involves tighter coupling between the IGP and signaling

There is nothing proprietary about this.  ***All*** IP routers that
implement OSPF/TE and/or ISIS/TE do this AFAIK and probably all LSR
that implement OSPF/TE and/or ISIS/TE (the remaining subset is mostly
ATM switches).

I welcome corrections from anyone that knows of an LSR that implements
OSPF/TE or ISIS/TE that doesn't use the flooded information as a hint
that some of the LSPs are down.

Curtis

---

From: Matthew Meyer <[email-masked]>
Date: Wed, 12 Mar 2003 16:19:24 -0700

Thus spake Curtis Villamizar ([email-masked]):

 |
 |I welcome corrections from anyone that knows of an LSR that implements
 |OSPF/TE or ISIS/TE that doesn't use the flooded information as a hint
 |that some of the LSPs are down.
 |

I know of one, though that may have been on old code.  Regardless,
for the sake of interoperability with less intelligent code, I'd
think folks would agree one would not want to skip sending the 
tears on link-down, at least by default.  

Another point to consider is that IGP convergence is a function of 
network size and IGP tuning. It wasn't too long ago that a number
vendors were less aggressive in their IGP tuning due to processor
constraints and other factors.  As a result it has been my 
observation that many networks have resisted the urge to 'jump in'
and retune their IGP (memories of meltdowns die hard).  Knowing 
that IGP arrival beats RSVP in a lab or on certain code + certain
vendor is one thing, assuming these features are deployed optimally
and on all platforms is quite another.

Because of the number of variables relating to customer and vendor 
implementation choices, a skip-sending-tear-on-link-down feature
would IMO get implemented (if at all) as a vendor specific knob.
Translate: this isn't standards material. :-/

Matthew

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 12 Mar 2003 19:35:40 -0500

> tears on link-down, at least by default.  

Absolutely.  Always send the tears becasue this does the resource
cleanup.  The IGP hint just makes convergence go faster.  The ingress
teardown can't replace the resv tears past the point of failure.  Also
multiple failures (due to SRLG) can create isolated middle segments of
the former path.  Getting the midpoints to clean up quickly frees
resources that may be needed.

> and on all platforms is quite another.

I'm quite sure you know this but for the benefit of others.

Two things changed.  One is that vendors used to start the SPF and
then flood.  Flooding was really slow and this issue was discussed as
operational experience at NANOG.  The other is that vendors decided
that the origination delay after quiescence should be zero.  Dave Katz
(Juniper) has argued for very fast reflood essentially eliminating any
protocol imposed flooding delay.

The result has been convergence has been getting faster for all of the
major routers who all seem to be paying attention to and participating
in this discussion at NANOG.  (Yes Scotty, there is intellegent life
at NANOG, and it seems friendly enough).

[Discussing operator experience as a means to improve protocols and
protocol implementations - what a concept!]

> Translate: this isn't standards material. :-/

The skip-sending-tear-on-link-down would be a real bad idea and I
don't think it should even be implemented as an option.

Sounds like you misinterpreted my suggestion or I missed something in
the suggestion that was originally posted.

The IGP and RSVP tears are both hints that the ingress can use to
determine that a link is down.  The former can be made more efficient
and faster but that doesn't mean the latter should be eliminated
because it still serves a purpose including among other things
interoperability.

> Matthew

In practice both arrive before all but a few CSPFs are redone so for
reroute its somewhat of a moot point.  For standby LSP the resoration
can be accomplished prior to processing a bombardment of PATH tears
and RESV tears that result from a failed link.  For subsecond standby
LSP resoration with lots of LSPs to restore this sort of optimization
is beneficial.

Curtis

ps - now back to out regularly scheduled arguments about
call/connection separation.  :(