Subject: fast-reroute merging

From: "Sundara Murugan" <[email-masked]>
Date: Mon, 12 Aug 2002 10:36:00 -0700

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: Shahram Davari <[email-masked]>
Date: Mon, 12 Aug 2002 10:57:28 -0700

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
> 
> ------
>

---

From: "Sundara Murugan" <[email-masked]>
Date: Mon, 12 Aug 2002 11:21:37 -0700

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,

Yours,
-Shahram

---

From: Shahram Davari <[email-masked]>
Date: Mon, 12 Aug 2002 11:44:57 -0700

Sundara,

I think the shortest ERO is only a suggested example. and not a standard rule.

                G----H----I--\
                |    |    |   \

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

> Sent: Monday, August 12, 2002 2:22 PM
> To: Shahram Davari; [email-masked]
> 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.
> 
> "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?"
> 
>

---

From: "Sundara Murugan" <[email-masked]>
Date: Mon, 12 Aug 2002 12:02:05 -0700

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,

                G----H----I--\
                |    |    |   \

-Shahram

---

From: Shahram Davari <[email-masked]>
Date: Mon, 12 Aug 2002 12:21:57 -0700

SE is for BW sharing. I could send 2 labels to H in SE mode.

-Shahram

> Sent: Monday, August 12, 2002 3:02 PM
> 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
> 
> for C to compute computes the path as being 
> C-H-I-D-J-K-M-N-... Clearly C's detour should

---

From: Alia Atlas <[email-masked]>
Date: Mon, 12 Aug 2002 16:23:37 -0400

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
>

---

From: Shahram Davari <[email-masked]>
Date: Mon, 12 Aug 2002 14:33:51 -0700

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

> From: Alia Atlas [mailto:[email-masked]]
> Sent: Monday, August 12, 2002 4:24 PM
> To: Sundara Murugan
> Cc: Shahram Davari; [email-masked]
> I to H can 
> >If we have rule changed to "for merging the path messages 
> should have the 
> >same ERO",

---

From: Alia Atlas <[email-masked]>
Date: Tue, 13 Aug 2002 10:14:12 -0400

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

---

From: Alia Atlas <[email-masked]>
Date: Tue, 13 Aug 2002 10:23:36 -0400

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
>
> > Sent: Tuesday, August 13, 2002 10:14 AM
> > To: Shahram Davari
> > Cc: Sundara Murugan; [email-masked]

---

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

Alia,

-Shahram

---

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

Ping,

1) It is not a matter of careful coding. Please refer to my, Alia's and Sundara's emails,
for the problems that can't be mended with careful coding.
2) Is this the new definition of Standardization process: "Implement whatever you want
and by just letting other's know what you have done, expect it to be standardized".

-Shahram

> From: Ping Pan [mailto:[email-masked]]
> Sent: Tuesday, August 13, 2002 4:10 PM
> To: Shahram Davari
> Cc: Der-Hwa Gan; [email-masked]
> Subject: Re: fast-reroute merging
> 
> 
> 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
> 
> Shahram Davari wrote:
> 
> > Alia,
> > 
> > Why should the WG standardize a broken implemented behavior?
> > Being implemented is important, but when it has problems ....
> > 
> > -Shahram
> > 
> > 
> 
>