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

[Sriganesh Kini <[e-mail]>]

Eric, lets discuss this in person. Some comments inline @ [Sri]

- Sri


> -----Original Message-----
> From: Eric Osborne (eosborne) [mailto:[e-mail]]
> Sent: Tuesday, July 27, 2010 6:49 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
>
>
>
> > -----Original Message-----
> > From: Sriganesh Kini [mailto:[e-mail]]
> > Sent: Tuesday, July 27, 2010 2:59 PM
> > 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, 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 there 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 qualify it further that in those cases the draft reduces the time to something that is comparable to that expected from RFC4090 FRR where PLR is adjacent 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 important to make it work in all topologies/scenarios. Rings are topologies of interest in many deployments.

The work required by this draft are straightforward extensions to capabilities already present in implementations supporting RFC4090.
1. The alert mechanism builds on the alert mechanism already present in MPLS 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 mechanism that should already exist in current FRR.
3. RSVP-TE signaling extensions uses already defined encoding of objects and 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 follows the path of the backup
2. Setup/maintenance of e-backup should be similar/same as whatever the operator uses.
3. There would be more tunnels, but the number is not a lot more for typical topologies.

Recovering at head-end runs loses the nice scalability properties that backup 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:[e-mail]]
> > > Sent: Tuesday, July 27, 2010 5:30 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
> > >
> > > 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]] 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
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > >
>