From: Sriganesh Kini <sriganesh.kini@ericsson.com>
To: "Eric Osborne (eosborne)" <eosborne@cisco.com>,
 Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Date: Tue, 27 Jul 2010 10:58:03 -0400
Thread-Topic: [mpls] Scalability of the "effective FRR" approach in
 draft-kini-mpls-ring-frr-facility-backup-00.txt
Thread-Index: Acss451Rwl5jkjLdTWWmLbBSEMenUAAAJKaAABzm8kAAAGaFoAAB6yoAAADgilAAAUKywAABic6QAASecBAAAb+9UAABmppQAAJf+zA=
Message-ID: <5A5E55DF96F73844AF7DFB0F48721F0F567DB80FED@EUSAACMS0703.eamcs.ericsson.se>
References: <D29E470202D67745B61059870F433B5402511686@XMB-RCD-202.cisco.com>
 <5A5E55DF96F73844AF7DFB0F48721F0F567DB80E8F@EUSAACMS0703.eamcs.ericsson.se>
 <D29E470202D67745B61059870F433B5402511689@XMB-RCD-202.cisco.com>
 <5A5E55DF96F73844AF7DFB0F48721F0F567DB80EA0@EUSAACMS0703.eamcs.ericsson.se>
 <D29E470202D67745B61059870F433B54025116C2@XMB-RCD-202.cisco.com>
 <5A5E55DF96F73844AF7DFB0F48721F0F567DB80EDC@EUSAACMS0703.eamcs.ericsson.se>
 <D29E470202D67745B61059870F433B540251173C@XMB-RCD-202.cisco.com>
In-Reply-To: <D29E470202D67745B61059870F433B540251173C@XMB-RCD-202.cisco.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] Scalability of the "effective FRR" approach in
 draft-kini-mpls-ring-frr-facility-backup-00.txt
Precedence: list

Eric, lets discuss this in person. Some comments inline @ [Sri]

- Sri


> -----Original Message-----
> From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com]
> Sent: Tuesday, July 27, 2010 6:49 AM
> To: Sriganesh Kini; Alexander Vainshtein
> Cc: mpls@ietf.org
> Subject: RE: [mpls] Scalability of the "effective FRR"
> approach in draft-kini-mpls-ring-frr-facility-backup-00.txt
>
>
>
> > -----Original Message-----
> > From: Sriganesh Kini [mailto:sriganesh.kini@ericsson.com]
> > Sent: Tuesday, July 27, 2010 2:59 PM
> > To: Eric Osborne (eosborne); Alexander Vainshtein
> > Cc: mpls@ietf.org
> > 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.

Correct. To be precise the proposal is to make RFC4090 FRR better when ther=
e is a U-turn.

>
> 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.

No claim is made that violates the laws of physics !

> 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.

Good. So let us treat this as a basis for agreement. I would also like to q=
ualify it further that in those cases the draft reduces the time to somethi=
ng that is comparable to that expected from RFC4090 FRR where PLR is adjace=
nt to failure (typically sub-50msec). Hope you agree on that too.

>
> My contention is, and always has been, that the difference
> here is not worth the work (by vendor or by operator).

If RFC4090 was worth the work so-far (by vendor and operator) it is importa=
nt to make it work in all topologies/scenarios. Rings are topologies of int=
erest in many deployments.

The work required by this draft are straightforward extensions to capabilit=
ies already present in implementations supporting RFC4090.
1. The alert mechanism builds on the alert mechanism already present in MPL=
S with a small change. A single new diagnostic code is defined for BFD.
2. The protection-switch at PLR-u closely mirrors the node protection mecha=
nism that should already exist in current FRR.
3. RSVP-TE signaling extensions uses already defined encoding of objects an=
d the association of protected to e-backup should be straightforward.

The work required by operator should also be straightforward
1. Path computation for e-backup should not need extra planning since it fo=
llows the path of the backup
2. Setup/maintenance of e-backup should be similar/same as whatever the ope=
rator uses.
3. There would be more tunnels, but the number is not a lot more for typica=
l topologies.

Recovering at head-end runs loses the nice scalability properties that back=
up tunnels provide.

>
>
>
>
> 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:eosborne@cisco.com]
> > > Sent: Tuesday, July 27, 2010 5:30 AM
> > > To: Sriganesh Kini; Alexander Vainshtein
> > > Cc: mpls@ietf.org
> > > 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: mpls-bounces@ietf.org
> > > [mailto:mpls-bounces@ietf.org] On
> > > > > Behalf
> > > > > > > Of
> > > > > > > > Sriganesh Kini
> > > > > > > > Sent: Tuesday, July 27, 2010 9:28 AM
> > > > > > > > To: Alexander Vainshtein
> > > > > > > > Cc: mpls@ietf.org
> > > > > > > > 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:Alexander.Vainshtein@ecitele.com]
> > > > > > > >         Sent: Monday, July 26, 2010 11:55 PM
> > > > > > > >         To: Sriganesh Kini
> > > > > > > >         Cc: mpls@ietf.org
> > > > > > > >         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:sriganesh.kini@ericsson.com]
> > > > > > > >         Sent: Monday, July 26, 2010 8:01 PM
> > > > > > > >         To: Alexander Vainshtein
> > > > > > > >         Cc: mpls@ietf.org
> > > > > > > >         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: mpls-bounces@ietf.org
> [mailto:mpls-
> > > > > > > bounces@ietf.org] On
> > > > > > > > Behalf Of Alexander Vainshtein
> > > > > > > >                 Sent: Monday, July 26, 2010 9:57 AM
> > > > > > > >                 To: Sriganesh Kini
> > > > > > > >                 Cc: mpls@ietf.org
> > > > > > > >                 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
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > >
>