The MPLS-OPS Archive

[Jean Philippe Vasseur <jvasseur@cisco.com>]

Hi Carlos,

Just noticed that I hadn't replied to your email ....

See in line.

At 16:57 02/05/2003 -0700, carlos@carlos.net wrote:

>-------Original Message-------
>From: Jean Philippe Vasseur <jvasseur@cisco.com>
>Sent: 05/02/03 06:53 AM
>To: carlos@carlos.net
>Subject: Re: Re: [MPLS-OPS]: Fast Reroute Interface
>Support
>
> >
> > At 13:27 01/05/2003 -0700, carlos@carlos.net wrote:
>
> >-------Original Message-------
> >From: David Lapsley <dlapsley@haystack.mit.edu>
> >Sent: 05/01/03 07:42 AM
> >To: Vinay Bannai <bannai@pacbell.net>
> >Subject: Re: [MPLS-OPS]: Fast Reroute Interface Support
> >
> > >
> > > Hi Vinay,
> >
> >Good point. I know that there is equipment that is
> >capable of doing
> >local repair in the milliseconds and I believe that is
> >what most
> >people are quoting when they give their fast re-route
> >times.
> >=============
> >any traffic generator can be used to calculate
> >fast-reroute time.
> >
> >
> >
> >Can anybody comment on the mechanism that is used to
> >determine when to re-route when the failure is not
> >local?
> >==============
> >depends on scenario.
>
>FRR will be configured in such a way that the reroute
>can be local. In
>other words, every LSR will be a PLR
>===========================================
>
>I got your point,but it's also possible that main
>transit lsr doesn't support fast-reroute OR if it does
>support Fast-Reroute,it doesn't have the path to create
>a detour lsp.In this scenario PathError will help the
>upstream PLR(if any) for FRR notification.

just have a fall back option relaxing some constraint to make sure that you 
will always find a path to set up your backup tunnel (bypass or detour)


> >If the problem lies on let say outgoing interface of
> >transit router,path error can be used to signal FRR on
> >PLR.It should be pretty fast.
>
>But then, this is not longer a local protection scheme.
>Indeed, an
>upstream
>PLR could make use of Path Error or IGP update
>(requires tuning to be
>fast)
>as reroute triggers but then on top of the failure
>detection time you add
>some delays for the Fault Indication Signal propagation
>(propagation
>delay,
>queueing, ...)
>================
>Right,it's not "Fast"-Reroute,but still switching of
>detour lsp

or bypass

>will start from that PLR and will be used to
>forward the traffic forever until the main path comes
>alive(In case main lsp doesn't have any backup lsps and
>path is strict ERO or a very "strict" colour).

same comment as before but for the primary LSP: have last resort option 
relaxing constraints.


> >If the problem is due to node reboot or crash,rsvp
> >hello can help.
>
>Node reboot can be handled w/o making use of RSVP
>hellos.
>=================
>Right,but waiting for refresh msg to expired is too
>long,instead hello in any implementation can be
>configured in seconds.

I'm not suggesting to use RSVP Refresh for that purpose .. just saying that 
node reboot can be quickly detected by Head-end LSR that would reroute in a 
non disruptive manner.

JP.

>Carlos
>
>-------
>The MPLS-OPS Mailing List
>Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
>Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml