Alia,
Sundara and I also presented a number of other problems with "path-specific
method".
Having so many problems, I am wondering why do we have it in the first place?
Why not have the Sender_template only?
-Shahram
> -----Original Message-----
> From: Alia Atlas [mailto:aatlas@xxxxxxxxx]
> Sent: Monday, August 12, 2002 4:24 PM
> To: Sundara Murugan
> Cc: Shahram Davari; mpls@xxxxxx
> Subject: RE: fast-reroute merging
>
>
> 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@xxxxxxxxxxxxxx]
> >Sent: Monday, August 12, 2002 11:45 AM
> >To: Sundara Murugan; mpls@xxxxxx
> >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@xxxxxxxxxxxxxxxxx]
> > > Sent: Monday, August 12, 2002 2:22 PM
> > > To: Shahram Davari; mpls@xxxxxx
> > > 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@xxxxxxxxxxxxxx]
> > > Sent: Monday, August 12, 2002 10:57 AM
> > > To: Sundara Murugan; mpls@xxxxxx
> > > 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@xxxxxxxxxxxxxxxxx]
> > > > Sent: Monday, August 12, 2002 1:36 PM
> > > > To: mpls@xxxxxx
> > > > 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
> > > >
> > > >
> > > >
> > >
>
>
|
