Re: path protection in Cisco routers

From: Eric Osborne (eosborne@cisco.com)
Date: Fri Jun 22 2001 - 15:55:52 EDT


On Fri, Jun 22, 2001 at 10:04:58AM -0700, Krishna Doddapaneni wrote:
> Eric,
> Fast reroute or local protection may be used only be a temporary or
> short-term mechanism while a long term solution is to use path
> protection because the head node is the best router to decide end-to-end
> constraints (Please correct me if iam wrong).

I don't agree. *Any* form of protection should be viewed as
short-term. Long-term (30s or more), the headend should create a new
LSP that doesn't cross the failed link/node, and use make-before-break
to switch over to this new LSP.

One of the problems with path protection is that it takes
comparatively longer than link/node protection to engender a
switchover. Since the backup path should only be used until a new
primary path can be found, you're subtracting from the time you
actually get to use the protection.

You may argue that path protection lets you switch over to a path
which can then become primary, and this is sometimes valid. But what
if your backup path doesn't have the same resources reserved as the
primary path? Especially with path protection, you may not want to
protect a 1Gb tunnel with another 1Gb tunnel; perhaps all you have
room for is a 500Mb tunnel, in which case there's definetly a
difference between primary and backup paths, even in path protection.

> So i thought there should be some mechanism for fast notification to the
> head node instead of using the slow PathERR messages.Another aspect is
> reliability with which the PathErr message is dispatched to the ingress
> or head-node.Since rsvp messages may get lost,
> does cisco IOS provide the ack mechanism as given in the
> draft-ietf-rsvp-refresh-reduct.txt?

Like I said in my first email, we don't have an implementation of
anything you'd consider path protection; all we can do right now is
juggle routing metrics to make the switchover a little faster. I
suspect that when we get around to doing path protection, we'll do
something very close to draft-ietf-rsvp-refresh-reduct-05.txt, but I
don't know for sure.

Why do you want path protection? I'm curious; do you have a real need
for it, a problem that can't be solved by node protection?

eric



This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:43 EDT