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

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

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.

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.

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