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

[Sriganesh Kini <[e-mail]>]

Inline @ [Sri]

- Sri
 

> -----Original Message-----
> From: Eric Osborne (eosborne) [mailto:[e-mail]] 
> Sent: Tuesday, July 27, 2010 2:18 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
> 
> Inline with EO#
> 
> > -----Original Message-----
> > From: Sriganesh Kini [mailto:[e-mail]]
> > Sent: Tuesday, July 27, 2010 10:52 AM
> > To: Eric Osborne (eosborne); Alexander Vainshtein
> > Cc: [e-mail]
> > Subject: RE: [mpls] Scalability of the "effective FRR" approach in
> draft-kini-
> > mpls-ring-frr-facility-backup-00.txt
> > 
> > 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.
> 
> EO#  Yes, I'm familiar with how that works and that's not my 
> point.  In FRR networks as currently deployed, the timeline 
> goes something like
> this:
> 
> i) failure happens
> ii) PLR kicks in protection.  Traffic is protected, but may (in some
> topologies) be routed in the manner you refer to as suboptimal
> iii) headend of the protected tunnel is notified of the 
> failure and reroutes to a new primary path
> 
> Elapsed time:
> (i) -> (ii)  <=50ms
> (ii)->(iii) ~= O(seconds)
> 
> The point I'm making is not that there are O(seconds) of loss, but
> O(seconds) of suboptimality.  And I'm questioning whether the 
> amount of work you're proposing is worth it in order to 
> minimize this O(seconds) of suboptimality.  If the 
> suboptimality lasted for a long time (minutes?
> hours?) I think it may be worth trying to optimize away, but 
> it doesn't and thus IMHO isn't.

[Sri] Sub-optimality can result in degraded service (see example in section 3). Preventing this in time periods close to MPLS-FRR is important.

> 
> There are also existing mechanisms to minimize the impact of 
> this suboptimality.  They include proper placement of primary 
> and backup paths, QoS for congestion control, and path 
> protection.  None of these are mandatory, but all of them are 
> useful.  To me, this further reduces the utility of the 
> mechanism you describe.  This is, of course, always going to 
> be a matter of opinion.

[Sri] It would be useful if you describe in detail how the 'existing mechanisms' solves a specific problem such as the one described in section 3.

> 
> And don't even get me started on "if you don't like how ring 
> networks behave, don't build ring networks".  That's a whole 

[Sri] Not sure what gave you that impression.

> different topic.
> 
> 
> 
> eric
> 
> > >
> > > 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.
> 
> OK, so your desire is that the PLR locally (suboptimally) 
> protect traffic until the u-PLR does its thing.
> 
> > 
> > >
> > > 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
> > > >
> > > >
> > >
> > >
>