The MPLS WG Archive

[Alia Atlas <aatlas@avici.com>]

The idea of merging detour Path messages with different EROs but the same 
egress interface is based upon the "path-specific method".  With that 
method, it is required because there is no way to determine from the RESV 
which of the two (or more) detour Path messages the RESV belonged to.  This 
is because both detour Path messages have the same SENDER_TEMPLATE; the 
Path messages can be distinguished by the Detour object and the EROs.

However, doing such merging has very bad consequences.  First, there are 
cases where a detour LSP which was up is temporarily unavailable.  Second, 
it is not possible to guarantee protection against an SRLG failure.

The solution is to use the "sender-template-specific" method, where the 
sender address in the SENDER_TEMPLATE is set to an address belonging to the 
PLR instead of being left as an address belonging to the ingress.

I presented about the problems of merging Path messages with different EROs 
in Salt Lake City.  The draft I did then, 
draft-atlas-rsvp-local-protect-interop-02.txt, describes the issues in 
detail; it has expired, because the solution was incorporated into the 
merged fast-reroute draft.

Alia


At 12:02 PM 8/12/2002 -0700, Sundara Murugan wrote:
>Shahram,
>
>Let us assume that detours from B and C don't merge at H. But these two 
>LSPs share the same link between H-I. The at I there will be 2 detour LSP 
>(B to D and another from C to E).
>
>If the detour LSPs use SE filter, then the RESV message from I to H can 
>specify only one filter (Session + sender of all the detours will be the 
>same) and only one Label. Which label does I select?
>
>-sundara
>
>-----Original Message-----
>From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
>Sent: Monday, August 12, 2002 11:45 AM
>To: Sundara Murugan; mpls@UU.net
>Subject: RE: fast-reroute merging
>
>
>Sundara,
>
>I think the shortest ERO is only a suggested example. and not a standard rule.
>
>
>
>                 G----H----I--\
>                 |    |    |   \
>            A----B----C----D----E---F
>
>
>I think no merging should happen in the G, H and I LSRs. The reason is that
>may be B has calculated the route B-G-H-I-D-E-F assuming some BW 
>restrictions, etc.
>We don't want H to change that to B-G-H-I-E-F.
>
>Also since each PLR does an independent ERO calculation, it is quite possible
>for C to compute computes the path as being C-H-I-D-J-K-M-N-... Clearly 
>C's detour should
>not be merged with B's detour here.
>
>If we have rule changed to "for merging the path messages should have the 
>same ERO",
>then we won't have such a problem.
>
>
>-Shahram
>
> > -----Original Message-----
> > From: Sundara Murugan [mailto:smurugan@riverstonenet.com]
> > Sent: Monday, August 12, 2002 2:22 PM
> > To: Shahram Davari; mpls@UU.net
> > Subject: RE: fast-reroute merging
> >
> >
> > Shahram,
> >
> > Section 5.3.1 says that the MP selects the shorter ERO path
> > length. This may not be correct.
> >
> > If there are other routers between I and E, then the ERO
> > lenght of the detour from C could be more than the ERO lenght
> > of the detour from B. If you go by the rule, then H will
> > merge the detours from B & C and establish a detour to D.
> > Then the detour from C will not avoid its next-hop D. So
> > there won't be a detour from C.
> >
> > So the MP has to select the detour which merges with the main
> > LSP that is closer to the egress router.
> >
> > -sundara
> >
> >
> > -----Original Message-----
> > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> > Sent: Monday, August 12, 2002 10:57 AM
> > To: Sundara Murugan; mpls@UU.net
> > Subject: RE: fast-reroute merging
> >
> >
> > Sundara,
> >
> > This is exactly the same question that I asked in another email:
> >
> > "Since as stated in section 7, each PLR has option to apply
> > its own constraints, then each PLR  may reach to a different
> > backup-path ERO for the same flow. Assuming that the EROs
> > have a single link (the downstream link of an MP LSP) in
> > common, isn't it wrong for an MP LSR to merge those Path messages?"
> >
> >
> > I think the solution is to require the same ERO for merging.
> >
> > Yours,
> > -Shahram
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Sundara Murugan [mailto:smurugan@riverstonenet.com]
> > > Sent: Monday, August 12, 2002 1:36 PM
> > > To: mpls@UU.net
> > > Subject: fast-reroute merging
> > >
> > >
> > > Section 5.3.1 in draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt
> > > explains merging procedure. In the fig below if there is a
> > > link between I and F then D will have a detour D-I-F. In this
> > > case how router I (the MP) handles detour LSPs from B, C and D?
> > >
> > > -sundara
> > >
> > > ------
> > >
> > > 5.3.1. An Example on Path Message Merging
> > >
> > > Consider the following example:
> > >
> > >
> > >                 G----H----I--\
> > >                 |    |    |   \
> > >            A----B----C----D----E---F
> > >
> > >
> > >    The protected LSP is A-B-C-D-E-F. After running CSPF, let
> > > the detour
> > >    ERO from B be B-G-H-I-D-E-F, and the detour ERO from C be
> > > C-H-I-E-F.
> > >
> > >    H will receive Path messages that have the same SESSION and
> > >
> > >
> > >
> >