The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <20030312192338.O98279@kummer.juniper.net>, Kireeti Kompella writes:
> Hi Curtis et al,
> 
> On Wed, 12 Mar 2003, Curtis Villamizar wrote:
> 
> > > >OK.  I know for a fact that Avici does this.  Anyone else?
> > >
> > > CISCO.
> >
> > 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.


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