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

[Sriganesh Kini <[e-mail]>]

Eric, pls see inline @ [Sri]

- Sri
 

> -----Original Message-----
> From: Eric Osborne (eosborne) [mailto:[e-mail]] 
> Sent: Tuesday, July 27, 2010 1:19 AM
> To: Sriganesh Kini; Alexander Vainshtein
> Cc: [e-mail]
> Subject: RE: [mpls] Scalability of the "effective FRR" 
> approach in draft-kini-mpls-ring-frr-facility-backup-00.txt
> 
> 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.

This solution aims for characteristics as close to MPLS-FRR when repair is done at an LSR adjacent to the failure. MPLS-FRR is used for networks requiring failure recovery with very low traffic loss (typically sub 50msec). If the network you are considering is tolerant to several seconds of traffic loss, plain old IGP convergence should be more than enough.

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

Typically a protection switch at PLR should result in lower overall loss than completely dropping traffic. If there are very specific conditions where completely dropping traffic is more advantageous, it may be an additional behavior.

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

The draft makes a statement about applicability to general topologies and as you correctly noted it works just as well. How much of overlap is there will vary from one network to another.

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