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

[Sriganesh Kini <[e-mail]>]

[Re-send due to mail size issues]

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

[Sri ] [---- deleted mail --------]