Subject: RE: fast-reroute merging

From: Shahram Davari <[email-masked]>
Date: Tue, 13 Aug 2002 07:44:13 -0700

Alia,

Why should the WG standardize a broken implemented behavior?
Being implemented is important, but when it has problems ....

-Shahram

> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]]
> Sent: Tuesday, August 13, 2002 10:24 AM
> To: Shahram Davari
> Cc: Sundara Murugan; [email-masked]
> Subject: RE: fast-reroute merging
> 
> 
> Shahram,
> 
> It has been implemented.  Certainly, I am not an advocate of this 
> method.  The draft was done to merge the existing methods 
> into something 
> which could inter-operate; this is one of those methods.  I 
> think it is 
> more critical to clean up the draft and clarify the behavior 
> than to, at 
> this point, try to remove options which have been implemented.
> 
> Alia
> 
> At 07:16 AM 8/13/2002 -0700, Shahram Davari wrote:
> >Alia,
> >
> >What do you mean by "is currently available" ?
> >Why can't the WG remove it from the draft?
> >
> >-Shahram
> >
> > > -----Original Message-----
> > > From: Alia Atlas [mailto:[email-masked]]
> > > Sent: Tuesday, August 13, 2002 10:14 AM
> > > To: Shahram Davari
> > > Cc: Sundara Murugan; [email-masked]
> > > Subject: RE: fast-reroute merging
> > >
> > >
> > > Shahram,
> > >
> > > I do not believe that the "path-specific method" is a good
> > > solution.  Unfortunately, it is one of the methods which 
> is currently
> > > available.
> > >
> > > Alia
> > >
> > > At 02:33 PM 8/12/2002 -0700, Shahram Davari wrote:
> > > >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:[email-masked]]
> > > > > Sent: Monday, August 12, 2002 4:24 PM
> > > > > To: Sundara Murugan
> > > > > Cc: Shahram Davari; [email-masked]
> > > > > 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:[email-masked]]
> > > > > >Sent: Monday, August 12, 2002 11:45 AM
> > > > > >To: Sundara Murugan; [email-masked]
> > > > > >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:[email-masked]]
> > > > > > > Sent: Monday, August 12, 2002 2:22 PM
> > > > > > > To: Shahram Davari; [email-masked]
> > > > > > > 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:[email-masked]]
> > > > > > > Sent: Monday, August 12, 2002 10:57 AM
> > > > > > > To: Sundara Murugan; [email-masked]
> > > > > > > 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:[email-masked]]
> > > > > > > Sent: Monday, August 12, 2002 1:36 PM
> > > > > > > To: [email-masked]
> > > > > > > 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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > >
> > > >
> >
> >

---

From: Ping Pan <[email-masked]>
Date: Tue, 13 Aug 2002 13:10:29 -0700

Shahram,

An approach that requires careful coding does not make it broken. The 
idea of standardization is to allow others to know what's going on, not 
a popularity contest.

- Ping