The MPLS WG Archive

[Anna Charny <acharny@cisco.com>]

Hi Shahram,

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

At 10:48 AM 8/9/2002 -0700, Shahram Davari wrote:
>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?

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.

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

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

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

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

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

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.

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

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.

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

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.

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

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.

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

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?


>10) Section 7: Can't the L1 detect the L1 defects? In that case the node
>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?

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

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

>Yours,
>Shahram