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

["Eric Osborne (eosborne)" <[e-mail]>]

I'm afraid I don't quite see the severity of the u-turn.  Yes, it's
suboptimal.  But how long does the condition last?  All implementations
I'm familiar with will rebuild the new primary LSP (the L9->L6 LSP, in
your example) in O(seconds), so the suboptimal condition is pretty
transient.  Your solution seems like quite a lot of work (BFD, e-backup
tunnels) for a few seconds of gain.

Also, it's not clear to me what happens in the time after the failure
but before fast-alert messages are processed at the u-PLR.  Does the PLR
drop traffic until then?  Does it do inefficient backup?  Is this an
implementations-specific decision?  

Thirdly, I'm not sure how generalizable this solution is to a mesh
topology.  While it will certainly work just as well there as in a ring,
it is entirely possible (and in my experience quite common) that the
backup tunnel does not overlap with many of the tunnels which it is
protecting, and thus you do not have a problem to solve.  As you are
solving a problem that is IMHO predominant only in ring topologies, this
mechanism is more of a specialized, ring-optimized tool than a
general-purpose thing.



eric


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
Of
> Sriganesh Kini
> Sent: Tuesday, July 27, 2010 9:28 AM
> 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, 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:mpls-
> [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
> 
>