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

[Sriganesh Kini <[e-mail]>]

Eric, the important thing to consider is the time-scale. O(seconds) of suboptimality (leading to O-seconds of degraded-service/packet-loss) is NOT comparable to the expected packet-loss (typically sub-50msec) in the facility bypass method of [MPLS-FRR] where PLR is adjacent to failure. It is much higher. Do you agree?

- Sri

PS: The title of the draft says "Efficient FRR ..." so obviously it is trying to improve (optimize - if you prefer that term) FRR.

> -----Original Message-----
> From: Eric Osborne (eosborne) [mailto:[e-mail]] 
> Sent: Tuesday, July 27, 2010 5:30 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#
> ...
> 
> > > 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.
> 
> 
> EO#
> I think it's important to distinguish between 'solve' and 'optimize'.
> You cannot eliminate L9->L8->L9 packet forwarding unless L8 
> simply decides to drop packets when link L8-L7 goes down.  We 
> agreed on as much in an earlier email.  To me, this means you 
> cannot 'solve' the problem.
> You can only optimize it, insofar as you can minimize the 
> amount of time that packets go L9->L8->L9 before the network 
> makes this suboptimality go away - this is the whole point of 
> your draft.  
> 
> Also - the suboptimality you point out comprises two parts.  
> You have some time where you have additional delay, and 
> during that same amount of time you have the potential for 
> traffic loss due to congestion.  Do you agree?
> 
> I am not claiming that existing mechanisms *solve* the 
> problem you've pointed out.  But I hope that if you were to 
> take my distinction between solve and  optimize that you 
> would agree that the method in your draft does not solve this 
> problem either.  Given that it takes some finite amount of 
> time to react to a failure, all any mechanism can ever do is 
> minimize the time spent in this suboptimal condition - that 
> is, 'optimize'.
> 
> Do you agree?  If not, we have a fundamental disagreement 
> (probably one of terminology rather than of technology) and 
> we should sort that out first.
> 
> I assume henceforth that you agree with my solve/optimize 
> distinction and my view of the limitations of what can ever 
> be done here.
> 
> Assuming you do, then I think what you're asking is "how do 
> existing mechanisms minimize the impact of this 
> suboptimality?"  And I think the implicit question here is 
> also "...and why do you contend that these mechanisms reduce 
> the utility of the draft-kini mechanism?"
> 
> If that's true, then it should be pretty clear.  Any 
> mechanism which can be used to structure the network or the 
> behavior of the network such that the exposure to either the 
> congestion or delay piece of the suboptimality is minimized 
> optimizes things (by definition).  
> 
> All I'm contending is that these mechanisms (QoS, traffic 
> engineering, path protection), which are common operational 
> tools that are by and large not specific to MPLS-TE, optimize 
> enough of the suboptimality away that the additional 
> mechanisms you propose will not add much, and which will add 
> whatever they add at a significant cost.  This is, of course, 
> necessarily an opinion rather than a hard fact.  
> 
> 
> 
> 
> 
> eric
> 
> 
> 
> > 
> > >
> > > 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
> > > > > >
> > > > > >
> > > > >
> > > > >
> > >
>