The MPLS WG Archive

[Shahram Davari <Shahram_Davari@pmc-sierra.com>]

Hi Anna,

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

-Shahram

> -----Original Message-----
> From: Anna Charny [mailto:acharny@cisco.com]
> Sent: Thursday, August 15, 2002 5:35 PM
> To: Shahram Davari
> Cc: 'mpls@UU.net'
> Subject: Re: Comments on Backup-Computation draft
> 
> 
> 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.

OK.

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

OK.

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


OK.

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

OK.

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



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

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

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

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

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

OK.

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

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

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

Yours,
-Shahram

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