The MPLS WG Archive

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

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