The MPLS WG Archive

[Anna Charny <acharny@cisco.com>]

Hi Shahram,

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

<snip>

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

We will clarify the text, thanks.



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

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.

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

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


> >
> > 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.
>
>May be, but again you are comparing and criticizing other methods for
>the very same reason.

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.


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

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>

> >
> > >
> > >9) Section 6.2.4: What happens if all NNHOPs are part of the SRLG?
> >
> > 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?

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.

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

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

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



>Yours,
>-Shahram
>
> >
> > Thanks,
> > Anna
> >
> > >Yours,
> > >Shahram
> >