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

From: Greg Mirsky <[email-masked]>
Date: Tue, 27 Jul 2010 09:06:02 -0700

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) <[email-masked]
> wrote:

>
>
> > -----Original Message-----
> > From: Sriganesh Kini [mailto:[email-masked]]
> > Sent: Tuesday, July 27, 2010 2:59 PM
> > To: Eric Osborne (eosborne); Alexander Vainshtein
> > Cc: [email-masked]
> > 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:[email-masked]]
> > > Sent: Tuesday, July 27, 2010 5:30 AM
> > > To: Sriganesh Kini; Alexander Vainshtein
> > > Cc: [email-masked]
> > > 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: [email-masked]
> > > [mailto:[email-masked]] On
> > > > > Behalf
> > > > > > > Of
> > > > > > > > Sriganesh Kini
> > > > > > > > Sent: Tuesday, July 27, 2010 9:28 AM
> > > > > > > > To: Alexander Vainshtein
> > > > > > > > Cc: [email-masked]
> > > > > > > > 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:[email-masked]]
> > > > > > > >   Sent: Monday, July 26, 2010 11:55 PM
> > > > > > > >   To: Sriganesh Kini
> > > > > > > >   Cc: [email-masked]
> > > > > > > >   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:[email-masked]]
> > > > > > > >   Sent: Monday, July 26, 2010 8:01 PM
> > > > > > > >   To: Alexander Vainshtein
> > > > > > > >   Cc: [email-masked]
> > > > > > > >   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: [email-masked] [mailto:mpls-
> > > > > > > [email-masked]] On
> > > > > > > > Behalf Of Alexander Vainshtein
> > > > > > > >           Sent: Monday, July 26, 2010 9:57 AM
> > > > > > > >           To: Sriganesh Kini
> > > > > > > >           Cc: [email-masked]
> > > > > > > >           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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 27 Jul 2010 12:23:17 -0400

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:[email-masked]]
Sent: Tuesday, July 27, 2010 9:06 AM
To: Eric Osborne (eosborne)
Cc: Sriganesh Kini; Alexander Vainshtein; [email-masked]
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) <[email-masked]<mailto:[email-masked]>> wrote:

> From: Sriganesh Kini [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: [email-masked]<mailto:[email-masked]>
draft-kini-
is NOT
facility
much

eric

trying to
> > From: Eric Osborne (eosborne) [mailto:[email-masked]<mailto:[email-masked]>]
> > Cc: [email-masked]<mailto:[email-masked]>
but
in
this
'existing
'optimize'.
you've
-
that
distinction
the
engineering,
and
the
protect
> > > > > > > From: [email-masked]<mailto:[email-masked]>
> > [mailto:[email-masked]<mailto:[email-masked]>] On
> > > > Behalf
> > > > > > Of
> > > > > > > Sriganesh Kini
> > > > > > > Cc: [email-masked]<mailto:[email-masked]>
backup
benefit
> > > > > > > [mailto:[email-masked]<mailto:[email-masked]>]
> > > > > > >   Cc: [email-masked]<mailto:[email-masked]>
original
> > > > [mailto:[email-masked]<mailto:[email-masked]>]
> > > > > > >   Cc: [email-masked]<mailto:[email-masked]>
can
the
> > > > > > >           From: [email-masked]<mailto:[email-masked]> [mailto:mpls-<mailto:mpls->
> > > > > > [email-masked]<mailto:[email-masked]>] On
> > > > > > >           Cc: [email-masked]<mailto:[email-masked]>
two
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls