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

[Sriganesh Kini <[e-mail]>]

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