The MPLS-OPS Archive

Cell Relay Retreat>MPLS-OPS Archive>month:2003-May> msg00145



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Re: Fast reroute extensions to RSVP-TE for LSP Tunnels

  • From: Gary Carruthers <gary.carruthers@alcatel.com>
  • Date: Fri, 23 May 2003 11:45:15 -0400
  • CC: Vinaychandra A V S <vinaychandra.sham@wipro.com>, Rohit Mediratta <rohit_medi@yahoo.com>, mpls-ops@mplsrc.com
  • Organization: Alcatel Canada
  • Resent-Date: Fri, 23 May 2003 12:55:25 -0400
  • To: carlos <carlos@carlos.net>



carlos wrote:

> ----- Original Message -----
> From: "Vinaychandra A V S" <vinaychandra.sham@wipro.com>
> To: "Rohit Mediratta" <rohit_medi@yahoo.com>; <mpls-ops@mplsrc.com>
> Sent: Friday, May 23, 2003 2:29 AM
> Subject: RE: [MPLS-OPS]: Fast reroute extensions to RSVP-TE for LSP Tunnels
>
> > Rohit,
> >
> > The problem you have described will not occur, as addresses in ERO will
> > usually denote the outgoing interfaces.
>
> It really depends on each implemenation.Some vendor uses <out-if,in-if>
> pairs in ERO.

First, the modification of ERO is really only an issue for node protection
bypass tunnels (aka facility backup) since the signaling for the protected path
must travel through the tunnel. For detours the signaling is a separate
"fragment" with its own ERO.

In order to modify  the ERO to support facility backup, all hops on any node
between the PLR and MP must be removed. This would include the <out-if> of the
hop previous to the MP, if present. Interfaces on the MP could be converted to
loose hops but really don't need to be since the path message must be routed
through the tunnel to the correct MP node in any case. The MP will simply
observe that the address actually does refer to itself and remove it from the
ERO.

>
>
> > Even if there are more than 1 entries in the ERO, belonging to the same
> > node, the ERO processing rules laid out in RFC 3209 will take care of
> > ignoring the redundant ones.
>
> Yes, but it's depend on implementation again.Some implementation
> may be too 'conversative' to accept other vendor behavior :-)
>
> Carlos
>
> -------
> The MPLS-OPS Mailing List
> Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

Gary

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