Subject: RE: Between OSPF RSVP...

From: "Muthukrishnan, Karthik (Karthik)" <[email-masked]>
Date: Wed, 12 Mar 2003 17:46:28 -0500

Curtis:

For the ignorant, does AFAIK stand for "As Far As I Know" ?

And ".. probably.. " imply these LSRs may or may not be capable of matching
IGP info with waiting-to-be-notified-of-failure LSPs ?

Maybe a good question to ask is "which IP routers that implement
OSPF/TE or ISIS/TE and use the flooded IGP information as a hint
that some of the LSPs are down?". We could then take lack of an answer
seriously.

John: to answer your question, pre-standard [proprietary] implementations
such as VNN have supported this for the last decade. For more details,
please feel free to unicast your questions to me.

-Karthik

-----Original Message-----
From: Curtis Villamizar [mailto:[email-masked]]
Sent: Wednesday, March 12, 2003 4:21 PM
To: Nair, Girish (Girish)
Cc: [email-masked]'; mpls
Subject: Re: Between OSPF RSVP... 

In message
<[email-masked]
.com>, "Nair, Girish (Girish)" writes:
> 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

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: Curtis Villamizar <[email-masked]>
Date: Wed, 12 Mar 2003 18:28:23 -0500

In message <[email-masked]
> For the ignorant, does AFAIK stand for "As Far As I Know" ?

It has since USENET in the 1980s.

> IGP info with waiting-to-be-notified-of-failure LSPs ?

No.  "Probably" just meant that I have less confidence in the ATM
switch vendors in this area.

> that some of the LSPs are down?". We could then take lack of an answer

OK.  I know for a fact that Avici does this.  Anyone else?

Since we've never explicitly tested for this, just assumed this
behaviour, it is possible that some other routers don't do this, but
this topic on the MPLS list dates back at least 5 years.

Both positive and negative responses welcome.

> please feel free to unicast your questions to me.

Note that deployed LSRs are carrying over 1,000 MPLS/TE LSP per
direction on an interface (someone can chime in with a bigger number
if they like) so on failure, one OSPF LSA or ISIS LSPDU fragment needs
to be advertised and over 1,000 path tears on the ingress side, plus
resv tears since the same interface is the egress side of other LSPs.
Its more efficient to flood the one IGP packet upstream to the
multiple ingress that are affected than 2,000 other messages.

There is nothing magic about using the link state information to
deduce that a path is no longer feasible.  A good implementatio,
having chosen a path can add an LSP to the linked list of LSPs
dependent on each link.  When the link goes down, figuring out which
LSPs are affected amounts to walking a linked list.  Adds about 16
bytes of overhead per link in the path, but saves time on failure when
saving time matters.

Curtis

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Wed, 12 Mar 2003 19:33:26 -0500

Hi,

At 18:28 12/03/2003 -0500, Curtis Villamizar wrote:

>In message 
><[email-masked]

CISCO.

>multiple ingress that are affected than 2,000 other messages.

As previously mentioned both failures indication are detected by the HE 
(PERR and IGP). IGP LSA/LSP might (or not) get received after the PERR 
(depending on the IGP tuning) but as you also mentioned, that does not 
really matter.

We mentioned IGP update reporting a link failure. Same reasoning applies to 
ISIS LP w/ overload bit set, OSPF LSA Maxage, ...

JP.

---

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

In message <[email-masked]>, Jean Philippe V
> >OK.  I know for a fact that Avici does this.  Anyone else?

Thank you.  I think we'll get a third affirmative shortly.

Curtis

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 12 Mar 2003 19:31:58 -0800 (PST)

Hi Curtis et al,

> Thank you.  I think we'll get a third affirmative shortly.

Am I on cue? :-)

On the matter of OSPF vs. RSVP, in our experience, RSVP almost always
wins.  With Notifies instead of PathErrs (no hop-by-hop processing),
RSVP should always win (unless messages get lost).

Kireeti.

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 13 Mar 2003 00:13:55 -0500

> RSVP should always win (unless messages get lost).

Kireeti,

Thanks for chiming in.

Regarding notifies.  They'd win unless you intentionally cheat and
give OSPF a head start because you want OSPF to win.  Even then
notfies could get there first.  I actually like path-err since they
clean up along the way and we find they don't beat OSPF often.

Absent any such cheating, internally prioritizing noticing TE-LSDB
changes and walking the linked list as soon as you hit a link down
shortcuts a lot of processing before restoration via standby.
Processing tha path-tear after restoration is then just state cleanup.

btw - Am I missing something or is there a direct notify to the
ingress that has been implimented in current MPLS code?  I know it has
been discussed in the GMPLS context.

When you say path-err almost always wins and notify should always win,
have you measured one OSPF LSA and say 1,000 path-err and 1,000
resv-err eminating from the same node and fanning out, and see if the
OSPF LSA gets there before some/most of the RSVP stuff.

A lot of things change when you go from a few LSPs in the lab to a few
hundred and even more so at a few thousand.  Needless to say we have
limited Juniper and Cisco gear in our lab and mostly for
interoperability testing and haven't noticed this with your stuff.

Curtis

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Thu, 13 Mar 2003 09:05:44 -0500

Hi Kireeti,

>RSVP should always win (unless messages get lost).

With appropriate RSVP message handling PERR is also pretty fast and allows 
states cleans up (see also Path Error State Removal).

Cheers.

JP.

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 13 Mar 2003 09:43:57 -0800 (PST)

> > Thank you.  I think we'll get a third affirmative shortly.

There are some who want me to spell it out, so here goes: if an
LSP goes over some link that subsequently fails, and the head end
learns this via OSPF/ISIS, the head end will switch to a backup,
or reroute the LSP.  The mechanism is pretty much what Curtis has
been describing.

No smoke, no mirrors :-)

Kireeti.