Subject: Comments on Backup-Computation draft

From: Shahram Davari <[email-masked]>
Date: Fri, 9 Aug 2002 10:48:51 -0700

Hi,

I have a few comments regarding this draft:

1) Section 3, does not seem to indicate that it is possible to request local protection and BW protection by only using the Session_Attribute. Why is that?

2) Many parts of the draft says PLR SHOULD send path_Error to the ingress LSR.
While the fast-reroute draft says MAY. Which one is correct?

3) The term "backup tunnel" is used in this draft to mean "Bypass tunnel".
Please follow the terms as defined in the fast-reroute draft. 

4) Section 5.1 says:

"Note also that the single failure assumption needed for such bandwidth 
sharing is a pre-requisite to any protection approach which uses pre-
computed backup tunnels -"

Do you mean it is pre-requisite for this draft? Otherwise it can't be pre-requisite for any protection approach.

5) Section 5.1 says:

"However, achieving such sharing using explicit bandwidth reservations 
for the backup tunnels requires extensive signaling and routing 
extensions: 
        - routing extensions  propagating the set of backup LSPs as  
        well as their bandwidth and the element(s) they protect [BP- 
        PLACEMENT]. In [lakshman]it was proposed to substantially 
        reduce the amount of state that needs to be propagated in the  
        routing updates at the price of sacrificing the amount of  
        achievable sharing.  "

This is not accurate. If you use the configuration method advised in this
draft or use the extension you propose to IGP in this draft, there is
no need for any more extensions to routing.

Also Fast_reroute draft already proposes extensions to the signaling. So
extension to signaling should not be an issue. And I even think the same
extensions could be used here by the head-end for signaling.

6) Appendix A gives an example which is easily solvable using the text from
other parts of this draft. The solution is using 2 Bypass tunnel for the R2-R3
link as following:

R2-R6-R7-R4 = 5M
R2-R8-R9-R4 = 5M

So it is possible to use independent CSPF at PLRs.

7) Section 6.1.1 criticizes that if a PLR is computing the Backup tunnel, then
it needs signaling to enable an LSR distinguish between primary and Backup LSP.
But the Fast_Reroute draft ha already defined these extensions and making use of them. So there is no need for any extra signaling. 

8) Section 6.2.1 suggests finding the backup pool, by subtracting the global reservable BW from the link BW. How does a node know the link BW to do this computation?
 
9) Section 6.2.4: What happens if all NNHOPs are part of the SRLG?

10) Section 7: Can't the L1 detect the L1 defects? In that case the node
and link failures could be distinguished.

11) Finally, let me provide you with an alternative, simpler proposal:

Let only the Ingress LSRs (head-end) do the TE and Bypass tunnel computation. Here is how:

If a Bypass tunnel is required at a PLR node, the ingress LSR can check the RRO object in the RESV message to see whether, the node or link that it wants has bypass tunnel or not. If a Bypass tunnel exists, fine, otherwise it will compute a bypass tunnel ( or more) and indicate that, in its PATH message. The appropriate PLR will then use the received PATH message to generate the Bypass tunnel(s). 

The advantage of this method is that it is distributed, and doesn't need
intermediate LSRs to do CSPF. Also as I  mentioned the issue of Appendix A
is easily solvable using more than 1 Bypass tunnels.

Yours,
Shahram

---

From: Anna Charny <[email-masked]>
Date: Thu, 15 Aug 2002 17:35:04 -0400

Hi Shahram,

First, thanks for all your comments!  Please see in-line:

At 10:48 AM 8/9/2002 -0700, Shahram Davari wrote:
>1) Section 3, does not seem to indicate that it is possible to request 
>local protection and BW protection by only using the Session_Attribute. 
>Why is that?

We did not mean to say that it is not possible to do so.  Both modes (using 
the SESSIONJ-ATTRIBUTE object or the FAST REROUTE object) are supported in 
the FRR draft. We will try to clarify the text to make sure it is clear.

>While the fast-reroute draft says MAY. Which one is correct?

You are right,  we will change the SHOULD to MAY to be compliant with the 
fast-reroute draft

>Please follow the terms as defined in the fast-reroute draft.

Yes, you are quite right - we will make sure we use the proper term. Thanks.

>Do you mean it is pre-requisite for this draft? Otherwise it can't be 
>pre-requisite for any protection approach.

What we meant to say really is something very simple. If you want to 
protect, say, against *any* N failures with N>1, then pre-computed backup 
paths simply cannot do the job (in the worst case at least), as you can 
always have one failure in the primary and another failure in the backup 
even if they are completely link and node disjoint.  We will try to modify 
the text to make it more clear.

>no need for any more extensions to routing.

We did not mean a general statement here - we were just pointing out the 
properties of the two *other* schemes currently proposed for bandwidth sharing.
You are right that our draft does not need any more routing extensions than 
we defined (and that was one of the reasons we thought it may be useful), 
and those extensions are needed just for a distributed case.

>extensions could be used here by the head-end for signaling.

we were talking about signaling extensions in the first of the references 
in our text that you quote. These are extensions that are necessary to 
convey the information pertaining specifically to bandwidth sharing. Such 
extensions are not defined in the fast-reroute draft.

>So it is possible to use independent CSPF at PLRs.

First let me point out that the issue of independent CSPF computation, 
although we believe correct, is really a secondary point in the draft, the 
primary point being the ability to provide bandwidth sharing between backup 
tunnels protecting against independent failures.

Regarding the independent CSPF issue,  you are right that if you allow 
load-balancing, then this particular example can be solved.  However, in 
the context of facility backup (which is the context of our draft), it will 
be undesirable to have a large number of such load-balanced tunnels 
protecting a single facility. We were assuming that in practice one would 
want to limit the number of such "splits" of a single backup tunnel into 
several smaller ones would be limited by some fixed number.  In fact, if 
you upper bound the number of splits by some N, then for each N it is 
possible to give an example when independent CSPF will not find a solution, 
when the solution actually exists.
We gave an example for N=1. Of course examples for larger N will be more 
complicated.

But again, this really is not the key issue in our draft.  I guess one can 
view the ability to find better solutions than in the case of independent 
CSPF as a pleasant side benefit of our approach rather that its motivation.

>But the Fast_Reroute draft ha already defined these extensions and making 
>use of them. So there is no need for any extra signaling.

I was under the impression that fast-reroute defines such extensions for 
the detour case but not for the bypass case (which is the one our draft 
discusses). For the BYPASS case, one cannot make the distinction between a 
primary and a bypass LSP that's why signalling non 0 bw bypass tunnel would 
require some additions in signalling. Also the CAC should be modified.

>8) Section 6.2.1 suggests finding the backup pool, by subtracting the 
>global reservable BW from the link BW. How does a node know the link BW to 
>do this computation?

Here is an example with OSPF (link TLV of the TE opaque LSA):

Sub-TLV 6 - Maximum Bandwidth

    The Maximum Bandwidth sub-TLV specifies the maximum bandwidth that
    can be used on this link in this direction (from the system
    originating the LSA to its neighbor), in IEEE floating point format.
    This is the true link capacity.

Sub-TLV 7 - Maximum Reservable Bandwidth

    The Maximum Reservable Bandwidth sub-TLV specifies the maximum
    bandwidth that may be reserved on this link in this direction, in
    IEEE floating point format

Maximum bandwidth - Maximum Reservable Bandwidth = Backup bandwidth pool.

>9) Section 6.2.4: What happens if all NNHOPs are part of the SRLG?

Could you please clarify your example and your question?

>and link failures could be distinguished.

I do not see how L1 can tell whether it is just the link that failed, or 
whether it was really the node on the other end that failed AND brought the 
link down with it?

>If a Bypass tunnel is required at a PLR node, the ingress LSR can check 
>the RRO object in the RESV message to see whether, the node or link that 
>it wants has bypass tunnel or not. If a Bypass tunnel exists, fine, 
>otherwise it will compute a bypass tunnel ( or more) and indicate that, in 
>its PATH message. The appropriate PLR will then use the received PATH 
>message to generate the Bypass tunnel(s).
>

It seems to me that you describe a method to off-load the bypass tunnel 
path computation on the HE. But I do not understand how this proposal 
addresses the key goal of our draft - namely the ability to share the 
bandwidth between backup tunnels protecting independent failures.  Can you 
please clarify?

Thanks,
Anna

---

From: Shahram Davari <[email-masked]>
Date: Fri, 23 Aug 2002 11:08:08 -0700

Hi Anna,

Sorry for delay in response. Please see my comments in-line.

-Shahram

> -----Original Message-----
> From: Anna Charny [mailto:[email-masked]]
> Sent: Thursday, August 15, 2002 5:35 PM
> To: Shahram Davari
> Cc: [email-masked]'
> Subject: Re: Comments on Backup-Computation draft
> 
> 
> Hi Shahram,
> 

OK.

> You are right,  we will change the SHOULD to MAY to be 

OK.

> Yes, you are quite right - we will make sure we use the 

OK.

> the text to make it more clear.

OK.

> and those extensions are needed just for a distributed case.

So I suggest changing the first sentence to:

However, achieving such sharing using explicit bandwidth 
reservations as defined in draft X and draft Y for the backup tunnels 
requires extensive signaling and routing extensions.

> extensions are not defined in the fast-reroute draft.

My point was that you are criticizing the other methods because
you say they requires extensions to signaling for admission
control, but yet you are introducing similar extensions in
your draft.

> We gave an example for N=1. Of course examples for larger N 

1) N=2 or 3 is very practical and in fact will probably cover
most cases.
2) Even in your proposal (in which you limit N=1) it is possible
 not to find a solution, even if one exists.

So I don't think 100% possibility of finding a solution should be
a criteria, since no method exists to do that.

> CSPF as a pleasant side benefit of our approach rather that 

May be, but again you are comparing and criticizing other methods for 
the very same reason.

> >it needs signaling to enable an LSR distinguish between 
> primary and Backup 
> >LSP.

Since you used the term backup tunnel instead of bypass tunnel, I thought
you are talking about backup tunnels. The FRR draft only distinguishes between
backup and primary, but not bypass and primary.

But another question is, if zero BW signaling is done, then how can the ingress LSRs
know how much BW is used for bypass tunnel in those links so that they don't use
it for any primary LSPs? By a fixed backup pool? 

> Maximum bandwidth - Maximum Reservable Bandwidth = Backup 

OK.

> Could you please clarify your example and your question?

  A-----B-----C-----D-----E
  |     |     |     |
   -----F-----G-----H

Assume B wants to compute bypass tunnel for itself and the A-B link. It will compute:

AFB for AB link faliure and AFGC for itself's failure. But what if C is part of the same SRLG as B? Seems that B can't compute for example AFGHD in that case. Right?

> whether it was really the node on the other end that failed 

If you loose the light, it means the link has failed. 

> bandwidth between backup tunnels protecting independent 

Let's assume a HE wants to have a backup tunnel to protect some link or node.
and assume no bypass tunnel exist at that point. It can compute that based on the BW pool
assigned to bypass tunnel and signal that backup tunnel in its PATH message. The PLR node will use that info to create a bypass tunnel (and backup tunnel). The PLR can signal zero BW for creation of bypass/backup tunnels.

Yours,
-Shahram

---

From: Anna Charny <[email-masked]>
Date: Tue, 27 Aug 2002 22:00:35 -0400

Hi Shahram,

cutting out some text irrelevant to the remaining issues under the discussion:

<snip>

>requires extensive signaling and routing extensions.

We will clarify the text, thanks.

>control, but yet you are introducing similar extensions in

Well,  maybe we did not make it clear enough, so let me try to explain.
draft-leroux-mpls-bypass-placement-00.txt that achieves complete bandwidth 
sharing introduces MANY more routing extensions than we do.
On the other hand, draft-kini-restoration-shared-backup-01.txt does indeed 
offer much fewer extensions (comparable to what our drafts suggests), but 
it does not result in complete sharing.  What we propose therefore differs 
from the former in the amount of extensions, and it differs from the latter 
in the ability to share all sharable bandwidth.

>a criteria, since no method exists to do that.

You are quite right - since the problem of is NP complete noone can claim 
the ability to find solutions in 100% of all cases. But it is the matter of 
relative success of different approaches. All we are saying is that since 
there is more information available in our approach, it is capable of 
finding a solution in many more cases. Note that we do not discuss any 
particular algorithm for the computation - clearly the relative success of 
finding a solution depends on exactly what algorithm is used. But again,
this is a secondary point in our draft...

>May be, but again you are comparing and criticizing other methods for

well, strictly speaking all we are saying is that in our approach you can 
find a solution more frequently than with distributed CSPF. And that is a 
fact that our example intended to demonstrate.

>it for any primary LSPs? By a fixed backup pool?

Well, in our approach the ingress LSR does not need to know about bandwidth 
requirements of any bypass tunnels other than those for which it itself is 
responsible or for which it is the headend.  All the intelligence about the 
bandwidth usage and requirements is concentrated locally on each LSR that 
is responsible for the computation of the backup tunnels for itself and/or 
a set of links. To give an example for node protection only,  each LSR 
knows how much bandwidth that goes *through itself* it needs to protect, 
and it also has a global view of the fixed backup bandwidth pool  on all 
links to know how much bandwidth is available to place the bypass tunnels 
protecting against its own failure.    Does this answer your question?

<snip>

>AFB for AB link faliure and AFGC for itself's failure. But what if C is 
>part of the same SRLG as B? Seems that B can't compute for example AFGHD 
>in that case. Right?

Right. In the current version of the draft we only consider nhop and nnhop 
tunnels.  We also were assuming that SRLGs contain links but not nodes.
In principle,  our approach can be generalized to deal with these issues, 
but we have not done it yet.

>If you loose the light, it means the link has failed.

No, I do not think that is right. If you do not see light on the link, you 
surely know that the link failed, but what you do not know is whether the 
node on the other end has ALSO failed.  And we do need to know whether that 
node is alive or not.

>assigned to bypass tunnel and signal that backup tunnel in its PATH 
>message. The PLR node will use that info to create a bypass tunnel (and 
>backup tunnel). The PLR can signal zero BW for creation of bypass/backup 
>tunnels.

You have explained how a bypass tunnel of zero bandwidth can be 
created.  But I do not think you have explained how the bandwidth of the 
bypass tunnel created this way can be shared with other bypass tunnels 
traversing the same links but protecting against failures of other 
elements, while simultaneously ensuring a bandwidth guarantee in the case 
of any single failure.  Could you please elaborate on exactly how bandwidth 
sharing with bandwidth guarantees are achieved in your approach?

Thanks,
Anna