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

[Sriganesh Kini <[e-mail]>]

Greg,

Couple comments
1. FLA should be do-able in firmware, if hardware is inflexible.
2. Do you have any evidence to support your observation that deploying path and segment protection would run into lesser issues than the ones you are presuming.


- Sri



________________________________
From: Greg Mirsky [mailto:[e-mail]]
Sent: Tuesday, July 27, 2010 9:06 AM
To: Eric Osborne (eosborne)
Cc: Sriganesh Kini; Alexander Vainshtein; [e-mail]
Subject: Re: [mpls] Scalability of the "effective FRR" approach in draft-kini-mpls-ring-frr-facility-backup-00.txt

Dear Eric,
as a developer I share your concerns regarding advantages of proposed changes (I consider Fast LSA Alert and Efficient FRR in combination as latter depends on the former). It would be helpful to hear opinions of providers whether they would be ready to accept risks and possibly go through fork-lift upgrades of existing equipment (to support FLA) in order to improve FRR. To me there's not enough benefit to justify risks and troubles (note that heterogeneous environment might require extensions to IGP-TEs). I'd rather suggest deployment of Path and Segment protection schemes if inefficiency of FRR's backup is the major problem for an operator.

Regards,
Greg

On Tue, Jul 27, 2010 at 6:49 AM, Eric Osborne (eosborne) <[e-mail]<mailto:[e-mail]>> wrote:


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

It is obvious that O(sec) is worse than O(msec).  This is why FRR was
developed in the first place and is the factor that drives its continued
deployment.

But you are attacking a straw man.  We are not discussing whether FRR is
better than no FRR.  We are discussing whether draft-kini 'efficient
FRR' is better than straight-up rfc4090 FRR.

Actually, we're not even discussing that.  I'm happy to stipulate that
the method you have specified is, within its domain, likely to expose
you to less potential suboptimality than the FRR that exists today.  You
have O(sec) of congestion/delay exposure no matter what you do, but in
your case the time is lower.

You cannot claim that you will reduce or eliminate the O(msec) part of
FRR; that's laws of physics plus particulars of a given implementation.
All you can claim is that you will *reduce* the O(sec) time in some
cases.  And I agree that your draft is likely to do that.

My contention is, and always has been, that the difference here is not
worth the work (by vendor or by operator).




eric



>
> - 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]<mailto:[e-mail]>]
> > Sent: Tuesday, July 27, 2010 5:30 AM
> > To: Sriganesh Kini; Alexander Vainshtein
> > Cc: [e-mail]<mailto:[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]>
> > [mailto:[e-mail]<mailto:[e-mail]>] On
> > > > Behalf
> > > > > > Of
> > > > > > > Sriganesh Kini
> > > > > > > Sent: Tuesday, July 27, 2010 9:28 AM
> > > > > > > To: Alexander Vainshtein
> > > > > > > Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>]
> > > > > > >   Sent: Monday, July 26, 2010 11:55 PM
> > > > > > >   To: Sriganesh Kini
> > > > > > >   Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>]
> > > > > > >   Sent: Monday, July 26, 2010 8:01 PM
> > > > > > >   To: Alexander Vainshtein
> > > > > > >   Cc: [e-mail]<mailto:[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:[e-mail]> [mailto:mpls-<mailto:mpls->
> > > > > > [e-mail]<mailto:[e-mail]>] On
> > > > > > > Behalf Of Alexander Vainshtein
> > > > > > >           Sent: Monday, July 26, 2010 9:57 AM
> > > > > > >           To: Sriganesh Kini
> > > > > > >           Cc: [e-mail]<mailto:[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
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > >
> >
_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mpls