Re: [mpls] Scalability of the "effective FRR" approach in draft-kini-mpls-ring-frr-facility-backup-00.txt

[Sriganesh Kini <[e-mail]>]

Sasha, you are welcome.

It should be noted that path computation for e-backup is trivial when routed along the backup. That should not impact operational experience. Setup/maintenance of e-backup should be fairly straightforward. It would be helpful if you can quantify a 'proliferation'.

Bandwidth can be shared between the e-backup and the backup tunnel. When the e-backup is routed along the backup, there should not be any extra bandwidth consumed compared to [MPLS-FRR]. The benefit is that the problematic U-turn goes away.

Thanks

- Sri



________________________________
From: Alexander Vainshtein [mailto:[e-mail]]
Sent: Monday, July 26, 2010 11:55 PM
To: Sriganesh Kini
Cc: [e-mail]
Subject: RE: [mpls] Scalability of the "effective FRR" approach in draft-kini-mpls-ring-frr-facility-backup-00.txt

Sri,
Lots of thanks for a prompt response. It seems that we more or less agree on the facts (proliferation of e-backup LSPs) but we differ in interpreting  the impact  of these facts  on the actual operational experience.

However, I'd like to notice that "BW effectiveness" of e-backup LSPs is also somewhat problematic IMO.
Please note that both the regular backup and e-backup bypass tunnels cross multiple links that are not involved with the original set of LSPs they are protecting. And they both consume BW on these links. The only difference is that they are competing for BW with other LSPs, not with ones they are protecting. But the overall effect is exactly the same IMO.

My 2c,
     Sasha

From: Sriganesh Kini [mailto:[e-mail]]
Sent: Monday, July 26, 2010 8:01 PM
To: Alexander Vainshtein
Cc: [e-mail]
Subject: RE: [mpls] Scalability of the "effective FRR" approach in draft-kini-mpls-ring-frr-facility-backup-00.txt

Sasha,

As you noted the e-backup tunnel protects all LSPs that have a common {head-end, tail-end} pair. More precisely, the e-backup can be shared to protect all LSPs that have a common {ring-ingress-LSR, ring-egress-LSR} pair (that is path is disjoint with the e-backup).

If I understood correctly your concern is about the number of number of e-backup tunnels?

E-backup tunnels should be setup based on protected LSP's {ring-ingress, ring-egress} LSRs. Consider a typical case where in a ring, there is a 'ring-head-end' and LSPs are setup from other LSRs on the ring to the 'ring-head-end'. An e-backup should be setup from each LSR on the ring to the 'ring-head-end'. This is order(n).

Even for cases where protected LSPs have many possible combinations for {ring-ingress, ring-egress}, for typical ring sizes, the number of tunnels required should not be a concern for today's implementations.

Also, in many topologies an LSR that is purely a transit for protected LSPs, does not have to originate any e-backup.

Thanks

- Sri
PS: Regular facility FRR requires more that two backup tunnels, depending on what is being protected.

________________________________
From: [e-mail] [mailto:[e-mail]] On Behalf Of Alexander Vainshtein
Sent: Monday, July 26, 2010 9:57 AM
To: Sriganesh Kini
Cc: [e-mail]
Subject: [mpls] Scalability of the "effective FRR" approach in draft-kini-mpls-ring-frr-facility-backup-00.txt
Sriganesh and all,
If I understood you correctly, your proposal requires a dedicated backup tunnel for all LSPs with the given {head-end, tail-end} pair of LSRs in the ring. (Regular facility FRR requires just two backup tunnels).
If this understanding is correct, this looks to like a serious scalability issue with your approach.

Regards,
     Sasha