Hi Eric,
You are right about the scalability issue of providing a backup tunnel
with equal reservation.One way of using backup LSP with lower
reservation may be sending only packets with certain prority(may be
using E-LSP)into the back tunnel.I agree that this case may be rare.And
i was thinking of pathprotection not on an application perspective but
on an implementation perspective.
Thanks a lot for the discussion,
krishna
Eric Osborne wrote:
>
> 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