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

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Tue, 27 Jul 2010 03:18:56 -0500

I'm afraid I don't quite see the severity of the u-turn.  Yes, it's
suboptimal.  But how long does the condition last?  All implementations
I'm familiar with will rebuild the new primary LSP (the L9->L6 LSP, in
your example) in O(seconds), so the suboptimal condition is pretty
transient.  Your solution seems like quite a lot of work (BFD, e-backup
tunnels) for a few seconds of gain.

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?  

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.

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

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 27 Jul 2010 04:51:35 -0400

Eric, pls see inline @ [Sri]

- Sri

> From: Eric Osborne (eosborne) [mailto:[email-masked]] 
> Sent: Tuesday, July 27, 2010 1:19 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
> 
> I'm afraid I don't quite see the severity of the u-turn.  
> Yes, it's suboptimal.  But how long does the condition last?  
> All implementations I'm familiar with will rebuild the new 
> primary LSP (the L9->L6 LSP, in your example) in O(seconds), 
> so the suboptimal condition is pretty transient.  Your 
> solution seems like quite a lot of work (BFD, e-backup

This solution aims for characteristics as close to MPLS-FRR when repair is done at an LSR adjacent to the failure. MPLS-FRR is used for networks requiring failure recovery with very low traffic loss (typically sub 50msec). If the network you are considering is tolerant to several seconds of traffic loss, plain old IGP convergence should be more than enough.

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

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

> > 	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
> > 	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-
> > 	If I understood correctly your concern is about the 
> number of number 
> > of e-backup tunnels?
> > 
> > 
> > 
> combinations 
> > for {ring-ingress, ring-egress}, for typical ring sizes,
> the number
> > 		If I understood you correctly, your proposal 
> requires a dedicated 
> > backup tunnel for all LSPs with the given {head-end,
> tail-end} pair

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Tue, 27 Jul 2010 04:18:16 -0500

Inline with EO#

> Sent: Tuesday, July 27, 2010 10:52 AM
> To: Eric Osborne (eosborne); Alexander Vainshtein
> Cc: [email-masked]
> Subject: RE: [mpls] Scalability of the "effective FRR" approach in
draft-kini-
> > All implementations I'm familiar with will rebuild the new primary
LSP
> > (the L9->L6 LSP, in your example) in O(seconds), so the suboptimal
> > condition is pretty transient.  Your solution seems like quite a lot
> > of work (BFD, e-backup
> This solution aims for characteristics as close to MPLS-FRR when
repair is
> done at an LSR adjacent to the failure. MPLS-FRR is used for networks
> requiring failure recovery with very low traffic loss (typically sub
50msec). If
> the network you are considering is tolerant to several seconds of
traffic loss,
> plain old IGP convergence should be more than enough.

EO#  Yes, I'm familiar with how that works and that's not my point.  In
FRR networks as currently deployed, the timeline goes something like
this:

i) failure happens
ii) PLR kicks in protection.  Traffic is protected, but may (in some
topologies) be routed in the manner you refer to as suboptimal
iii) headend of the protected tunnel is notified of the failure and
reroutes to a new primary path

Elapsed time:
(i) -> (ii)  <=50ms
(ii)->(iii) ~= O(seconds)

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.

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.

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

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

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 27 Jul 2010 07:47:35 -0400

Inline @ [Sri]

- Sri

> Sent: Tuesday, July 27, 2010 2:18 AM
> EO#  Yes, I'm familiar with how that works and that's not my 
> point.  In FRR networks as currently deployed, the timeline 
> goes something like
> this:
> 
> i) failure happens
> iii) headend of the protected tunnel is notified of the 
> failure and reroutes to a new primary path
> 
> Elapsed time:
> (i) -> (ii)  <=50ms
> 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.

> 
> 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.
> OK, so your desire is that the PLR locally (suboptimally) 
> protect traffic until the u-PLR does its thing.
> 
> > 
> > >

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Tue, 27 Jul 2010 07:30:00 -0500

Inline with EO#
...

> > 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.
> 
> >
> > 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
> 
> > > > > extra bandwidth consumed compared to [MPLS-FRR]. The benefit
is
> > > > > they are protecting. But the overall effect is exactly the
same
> > IMO.
> > > > > head-end'. An e-backup should be setup from each LSR on the
ring
> > to

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 27 Jul 2010 08:59:10 -0400

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?

- Sri

PS: The title of the draft says "Efficient FRR ..." so obviously it is trying to improve (optimize - if you prefer that term) FRR.

> Sent: Tuesday, July 27, 2010 5:30 AM
> 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, 
> > > > > > From: [email-masked] 
> [mailto:[email-masked]] On
> > > Behalf
> > > > > Of
> > > > > > Sriganesh Kini
> > > > > > ingress, ring-egress} LSRs. Consider a typical case 
> where in a
> > > ring,
> > > > > there is a

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Tue, 27 Jul 2010 08:49:12 -0500

> Sent: Tuesday, July 27, 2010 2:59 PM
draft-kini-
> 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.
> 
this
> > 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.
> >
> > 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?
> >
> > 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.
distinction
> > 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
> > All I'm contending is that these mechanisms (QoS, traffic
engineering,
> > 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
> >
> >
> >
> > >
> > > >
protect
> > > > > > > Bandwidth can be shared between the e-backup and the
backup
> > > > tunnel.
> > > > > > > of LSRs in the ring. (Regular facility FRR requires just
two
> > > > backup

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 27 Jul 2010 10:58:03 -0400

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

- Sri

> Sent: Tuesday, July 27, 2010 6:49 AM
> 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.

> > > > > paths, QoS for congestion control, and path
> protection.  None of
> > > these
> amount of
> during that
> (probably
> mechanism which
> > > > > > > > When the e-backup is routed along the backup,
> there should
> > > > > > > not be any
> > > > > > > > agree on the facts (proliferation of e-backup
> LSPs) but we
> > > > > > > differ in
> > > > > > > >         E-backup tunnels should be setup based
> on protected
> > > > > > > LSP's {ring-
> > > > > > > > 'ring-head-end' and LSPs are setup from other
> LSRs on the
> > > > > > > ring to the
> > > > > > > 'ring-
> > > > > > > > Behalf Of Alexander Vainshtein

---

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

[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:[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
> > -----Original Message-----

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