Subject: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 14 Mar 2014 05:01:44 +0000

Hi!

During the meeting in London the authors asked for the WG to adopt this draft.

This message officially starts the call for adoption for draft-psarkar-rtgwg-rlfa-node-protection.  Please indicate your position about adopting it by end-of-day on March 28, 2014.

http://tools.ietf.org/html/draft-psarkar-rtgwg-rlfa-node-protection

Thanks!

Alvaro.

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Fri, 14 Mar 2014 05:11:46 +0000

support

From: "Alvaro Retana (aretana)" <[email-masked]<mailto:[email-masked]>>
Date: Friday 14 March 2014 06:01
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Hi!

Thanks!

Alvaro.

---

From: Pushpasis Sarkar <[email-masked]>
Date: Fri, 14 Mar 2014 09:20:10 +0000

Support as a author.

From: Alvaro Retana (aretana) [mailto:[email-masked]]
Sent: Friday, March 14, 2014 10:32 AM
To: [email-masked]
Cc: [email-masked]
Subject: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Hi!

Thanks!

Alvaro.

---

From: <[email-masked]>
Date: Fri, 14 Mar 2014 11:27:41 +0100

Support as co-author.

De : rtgwg [mailto:[email-masked]] De la part de Alvaro Retana (aretana)
Envoyé : vendredi 14 mars 2014 06:02
À : [email-masked]
Cc : [email-masked]
Objet : WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Hi!

Thanks!

Alvaro.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Alia Atlas <[email-masked]>
Date: Fri, 14 Mar 2014 10:00:38 -0400

support - it's good to have a draft describing the options around rLFA
node-protection.

Alia

On Fri, Mar 14, 2014 at 1:01 AM, Alvaro Retana (aretana)
<[email-masked]>wrote:

>  This message officially starts the call for adoption
> for draft-psarkar-rtgwg-rlfa-node-protection.  Please indicate your
> position about adopting it by end-of-day on March 28, 2014.
>
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg
>
>

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 14 Mar 2014 19:01:40 +0000

Support in principle..

Will post detailed  comments  later. But ..

1.       Would like to definitely see IPR claims on this

2.       It's important to note, this is adding additional complexity into the system  on OTO rLFA and it's not yielding any/very-minimal gain

for 60-70% of topologies and remaining 30% it's giving around ~10-12% coverage gain.

--
Uma C.

From: rtgwg [mailto:[email-masked]] On Behalf Of Alvaro Retana (aretana)
Sent: Thursday, March 13, 2014 10:02 PM
To: [email-masked]
Cc: [email-masked]
Subject: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Hi!

Thanks!

Alvaro.

---

From: <[email-masked]>
Date: Sat, 15 Mar 2014 09:39:24 +0100

Hi Uma,

Why do you say that the gain is very minimal ?
The gain is major, and it's not just a question of numbers ...
With basic rLFA specification you cannot guarantee node protection. Even if based on statistics, node protection exists with basic spec, and NP coverage may be quite good depending of topology, it's not guaranteed. For a service provider requiring NP, it's really important to guarantee the NP without relying on statistics or defacto node protection.

Would be also interested in why do you think the solution is complex ?

Thanks !

Stephane

De : Uma Chunduri [mailto:[email-masked]]
Envoyé : vendredi 14 mars 2014 20:02
À : Alvaro Retana (aretana); [email-masked]
Cc : [email-masked]
Objet : RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Support in principle..

--
Uma C.

From: rtgwg [mailto:[email-masked]] On Behalf Of Alvaro Retana (aretana)
Sent: Thursday, March 13, 2014 10:02 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Hi!

Thanks!

Alvaro.

---

From: Alia Atlas <[email-masked]>
Date: Sat, 15 Mar 2014 08:56:43 -0400

Stephane,

A solution that requires or desires different heuristics depending upon the
network topology is complex and somewhat fragile.

I also feel that we are in the realm of attempted partial solutions, each
more complex than the previous one.  SPRING has the hope of making the rLFA
approach simpler and without a concern for the computational load during
convergence time (or alternately for the time that is unprotected),

That said, I know this is the path that you are all going down and that you
see the trade-offs as acceptable.

Regards,
Alia

On Sat, Mar 15, 2014 at 4:39 AM, <[email-masked]> wrote:

> With basic rLFA specification you cannot guarantee node protection. Even
> if based on statistics, node protection exists with basic spec, and NP
> coverage may be quite good depending of topology, it's not guaranteed. For
> a service provider requiring NP, it's really important to guarantee the NP
> without relying on statistics or defacto node protection.
>
>
>
> *De :* Uma Chunduri [mailto:[email-masked]]
> *Envoyé :* vendredi 14 mars 2014 20:02
> *À :* Alvaro Retana (aretana); [email-masked]
> *Cc :* [email-masked]
> *Objet :* RE: WG Adoption Call for
> draft-psarkar-rtgwg-rlfa-node-protection
>
>
>
> Support in principle..
>
>
>
> *1.       **Would like to definitely see IPR claims on this*
>
> 2.       It's important to note, this is adding additional complexity
> into the system  on OTO rLFA and it's not yielding any/very-minimal gain
>
> *From:* rtgwg [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Alvaro Retana (aretana)
> *Sent:* Thursday, March 13, 2014 10:02 PM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection
>
>
>
> Hi!
>
>
>

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 17 Mar 2014 06:50:09 +0000

Hi Stephane,

You asked the right questions. But I don't think I can give better/precise answers than the reply we already got.

Any ways, let me try -

> Why do you say that the gain is very minimal ?

(..per base draft, in real SP topologies) 9 out of 14 topologies showed very minimal gain with rLFA NP
and the remaining 5 topologies with limited improved coverage. Given the PQ explosion in certain topologies
to as many as more than half the number of nodes in the network, I don't think this gain is, in any way matching the
complexity of the proposal/performance impact at times in the network ..

>The gain is major, and it's not just a question of numbers ...

I don't think so. I think you have to explain why and how you think it's a major gain.

>.. NP coverage may be quite good depending of topology, it's not guaranteed

It's always good to be optimistic but number are speaking the other way.

> Would be also interested in why do you think the solution is complex ?

It's pumping complexity in the code base not only in terms of maintainability with
competing and interfering solution space  on the table from MRT to other technologies but
also due to the the heuristics proposed (are indeed fragile as indicated). Secondly, IMO,
though it's not mandatory to collect path characteristics (you also expect not only PQs but also
all the nodes to upgrade and advertise node admin tags to get these ?)  from PQ to destination,
overall it is bit of over engineering . This got to be simplified at minimum.
Probably this can be discussed later.
--
Uma C.

From: Alia Atlas [mailto:[email-masked]]
Sent: Saturday, March 15, 2014 5:57 AM
To: Stephane Litkowski
Cc: Uma Chunduri; Alvaro Retana (aretana); [email-masked]; [email-masked]
Subject: Re: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Stephane,

A solution that requires or desires different heuristics depending upon the network topology is complex and somewhat fragile.

I also feel that we are in the realm of attempted partial solutions, each more complex than the previous one.  SPRING has the hope of making the rLFA approach simpler and without a concern for the computational load during convergence time (or alternately for the time that is unprotected),

That said, I know this is the path that you are all going down and that you see the trade-offs as acceptable.

Regards,
Alia

---

From: Pushpasis Sarkar <[email-masked]>
Date: Mon, 17 Mar 2014 07:21:32 +0000

Hi Uma,

Juniper has filed one in Sep 2013. The IPR disclosure submission is under progress by Juniper legal team and will be completed by end of this week.

Thanks
-Pushpasis

From: Uma Chunduri [mailto:[email-masked]]
Sent: Saturday, March 15, 2014 12:32 AM
To: Alvaro Retana (aretana); [email-masked]
Cc: [email-masked]
Subject: RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Support in principle..

--
Uma C.

Hi!

Thanks!

Alvaro.

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 17 Mar 2014 07:24:45 +0000

Support as co-author.

Hi!

Thanks!

Alvaro.

---

From: Pushpasis Sarkar <[email-masked]>
Date: Mon, 17 Mar 2014 07:51:43 +0000

Hi Uma,

From: Uma Chunduri [mailto:[email-masked]]
Sent: Monday, March 17, 2014 12:20 PM
To: Alia Atlas; Stephane Litkowski
Cc: [email-masked]; [email-masked]
Subject: RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Hi Stephane,

Any ways, let me try -
[Pushpasis] The real motivation behind node-protection has been to protect traffic against node-failures of the 1-hop immediate neighbors. IMO, this can be achieved in two ways only.

1.       Deploy node-protection on PLR, Or

2.       Deploy NSR/GR on all 1-hop neighbors.
Both methods will add computational complexity and it is matter of choice which one will the operator go for. Again IMO, NSR is far more complex than node-protection and adds considerably much more to overall CPU and other resource consumptions than node-protection. For networks where NSR is already deployed, node-protection may not be that critical. But for networks that did not deploy NSR (for whatever reasons, I don't want to speculate), it is quite critical, once again in my opinion.
I don't think so. I think you have to explain why and how you think it's a major gain.
[Pushpasis] Again, for networks that did not deploy NSR, it is quite critical.
It's always good to be optimistic but number are speaking the other way.
[Pushpasis] I agree that it does not guarantee 100% protection. However, we have seen ~96-98% coverage even when we restricted the number of PQ-nodes between 8 and 16, and that too with a very simple heuristic as suggested in the draft.
[Pushpasis] Yes LFA manageability is optional, but if you donot need it then you also donot need to collect the path characteristics. So you save time on that. Without that, all you need is a basic Forward SPF on the PQ-node. On a router with the kind of high performance CPUs used today, a SPF with 1000 node topology, a single SPF runs well under 1ms. How much performance overhead are we really adding then?

I don't get your comment in pumping code-complexity. The only extra things we need to do is
- Run a Forward SPF on a PQ-node. The same code that was written for LFA can be re-used. Just run it on a PQ-node instead of a 1 hop neighbor.
- Alos the existing code for checking inequalities can then be easily re-used/extended to run on the results procured from the above SPF.

--
Uma C.

From: Alia Atlas [mailto:[email-masked]]
Sent: Saturday, March 15, 2014 5:57 AM
To: Stephane Litkowski
Cc: Uma Chunduri; Alvaro Retana (aretana); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Stephane,

Regards,
Alia

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 17 Mar 2014 09:23:58 +0100

support as co-author;

On Fri, Mar 14, 2014 at 05:01:44AM +0000, Alvaro Retana (aretana) wrote:
|    Hi!
|    During the meeting in London the authors asked for the WG to adopt this
|    draft.
|    This message officially starts the call for adoption
|    for draft-psarkar-rtgwg-rlfa-node-protection.  Please indicate your
|    position about adopting it by end-of-day on March 28, 2014.
|    http://tools.ietf.org/html/draft-psarkar-rtgwg-rlfa-node-protection
|    Thanks!
|    Alvaro.

| _______________________________________________
| rtgwg mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/rtgwg

---

From: <[email-masked]>
Date: Mon, 17 Mar 2014 09:25:46 +0100

Hi Alia,

Pls find comments inline.

De : Alia Atlas [mailto:[email-masked]]
Envoyé : samedi 15 mars 2014 13:57
À : LITKOWSKI Stephane DTF/DERX
Cc : Uma Chunduri; Alvaro Retana (aretana); [email-masked]; [email-masked]
Objet : Re: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Stephane,

A solution that requires or desires different heuristics depending upon the network topology is complex and somewhat fragile.
[SLI] Agree, that why simulation results are interresting.

[SLI] Right, SPRING would make things simpler. But SPRING is SPRING, no more IP routed networks :) We already know, that some legacy platforms may never support SPRING (not ony for technical reason) but LFA/rLFA can be enhanced for such equipments that may be kept in networks for years.
I don't really agree about adding complexity there, what we require here is just running few fSPFs, and as Pushpasis mentioned,it's peanut in term of computation load even on old platforms. Compare the complexity with some routers having 100's of RSVP-TE tunnels with CSPF ...

Now, you pointed a very good question. As SPRING would be there, do we still need to work on IP FRR enhancements ?  IMHO, both can be kept in parallel. Maybe some people may not want to deploy SPRING.
Moreover, I think that it may be good to finish the work on LFA/rLFA with node protection addings. Good way to close the work on the subject.

[SLI] Current IP FRR mechanism are all subjects to tradeoff ... LFA/rLFA, even MRT ...

Regards,
Alia

On Sat, Mar 15, 2014 at 4:39 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Uma,

Thanks !

Stephane

De : Uma Chunduri [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : vendredi 14 mars 2014 20:02
À : Alvaro Retana (aretana); [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>
Objet : RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Support in principle..

--
Uma C.

Hi!

Thanks!

Alvaro.

Thank you.

_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtgwg

---

From: <[email-masked]>
Date: Mon, 17 Mar 2014 09:47:24 +0100

Agree with Pushpasis.

IMHO, there is no added complexity because we are just reusing LFA piece of code : new fSPF to compute (as if the router has new neighbors), and node protection equations to check (as in base LFA spec) : computation load added is just as your router would have extra neighbors ... how many ISIS neighbors do you support on your boxes ? (I hope hundreds ... if yes, your box already scale to hundreds of fSPF to compute LFA).

Pushpasis pointed a good point while talking about NSR/GR.

>From SP point of view, NSR/GR in the core may not implemented because  nodes are often doubled (two per site)  and moreover NSR/GR is really adding a major complexity in equipments : complexifying testings on a lot of features in service provider lab and Service Providers want to keep their core as simple and stable as possible.

That's why guaranteed node protection is a requirement and we think there is major gain in this solution rather than relying on statistical or defacto NP.

As Pushpasis mentioned, yes, there is no 100% node protection, and there is a need of tradeoff as for all IPFRR solutions today ...

The solution we propose here is simple as LFA is.

Best Regards,

Stephane

De : Pushpasis Sarkar [mailto:[email-masked]]
Envoyé : lundi 17 mars 2014 08:52
À : Uma Chunduri; Alia Atlas; LITKOWSKI Stephane DTF/DERX
Cc : [email-masked]; [email-masked]; Chris Bowers
Objet : RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Hi Uma,

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Stephane,

Any ways, let me try -

--
Uma C.

Stephane,

Regards,
Alia

---

From: <[email-masked]>
Date: Mon, 17 Mar 2014 10:09:53 +0100

Uma,

What simulation numbers are your refering to ? Is it Section 8 of draft-ietf-rtgwg-remote-lfa ?
If yes, the number displayed are not applicable to our solution.

NP coverage in Section 8 of draft-ietf-rtgwg-remote-lfa are using the default rLFA tiebreaker : closest PQ and single PQ election per interface.

We don't have the topology that CISCO was using in the draft, so we cannot provide numbers with our solution with the same set of topologies. But I think, we could add in the draft, some simulation results showing the improvement of guaranteed NP using our solution compared to basic rLFA spec.

Stephane

De : Uma Chunduri [mailto:[email-masked]]
Envoyé : lundi 17 mars 2014 07:50
À : Alia Atlas; LITKOWSKI Stephane DTF/DERX
Cc : Alvaro Retana (aretana); [email-masked]; [email-masked]
Objet : RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Hi Stephane,

Any ways, let me try -

Stephane,

Regards,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Mon, 17 Mar 2014 09:47:16 -0400

Stephane,

I absolutely agree - that current IP FRR mechanisms are all subject to
trade-offs, that not all networks will be SPRING, that IP/LDP FRR will be
needed for quite some time and it makes sense to finish these off.

Sadly, none of this stops this solution from being incremental with each
piece adding more complexity.  Engineering is about trade-offs and that can
be different for each network and person.

Regards,
Alia

On Mon, Mar 17, 2014 at 4:25 AM, <[email-masked]> wrote:

> *De :* Alia Atlas [mailto:[email-masked]]
> *Envoyé :* samedi 15 mars 2014 13:57
> *À :* LITKOWSKI Stephane DTF/DERX
>
> *Cc :* Uma Chunduri; Alvaro Retana (aretana); [email-masked];
> [email-masked]
> *Objet :* Re: WG Adoption Call for
> A solution that requires or desires different heuristics depending upon
> the network topology is complex and somewhat fragile.
>
> [SLI] Right, SPRING would make things simpler. But SPRING is SPRING, no
> more IP routed networks J We already know, that some legacy platforms may
> never support SPRING (not ony for technical reason) but LFA/rLFA can be
> enhanced for such equipments that may be kept in networks for years.
>
> I don't really agree about adding complexity there, what we require here
> is just running few fSPFs, and as Pushpasis mentioned,it's peanut in term
> of computation load even on old platforms. Compare the complexity with some
> routers having 100's of RSVP-TE tunnels with CSPF ...
>
>
>
> Now, you pointed a very good question. As SPRING would be there, do we
> still need to work on IP FRR enhancements ?  IMHO, both can be kept in
> parallel. Maybe some people may not want to deploy SPRING.
>
> Moreover, I think that it may be good to finish the work on LFA/rLFA with
> node protection addings. Good way to close the work on the subject.
>
>
>
> *1.*       *Would like to definitely see IPR claims on this*
>

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 17 Mar 2014 17:54:07 +0000

Stephane,

Comments in-line [Uma]

--
Uma C.

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, March 17, 2014 1:47 AM
To: Pushpasis Sarkar; Uma Chunduri; Alia Atlas
Cc: [email-masked]; [email-masked]; Chris Bowers
Subject: RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Agree with Pushpasis.
[Pushpasis] On a router with the kind of high performance CPUs used today, a SPF with 1000 node topology, a single SPF runs well under 1ms. How much performance overhead are we really adding then?

[Uma]:I think we all know and this and we already took advantage of the modern CPUs Pushpasis mentioning and we added  a bunch of additional computations in layers till now.

..how many ISIS neighbors do you support on your boxes ? (I hope hundreds ... if yes, your box already scale to hundreds of fSPF to compute LFA).

[Uma]: So we do few hundreds of fSPF from each neighbor for base LFA then few hundreds for Q space rSPFs and few more hundreds for rSPFs from PQ nodes depending on the network/heuristics for each primary SPF right. Did you see your 1msec is multiplied few multiple hundred times here.

If really don't care about this additional fSPFs from candidate PQs, why do you bother to reduce the same through heuristics proposed?
Did you see your contradiction already?

[Uma]: As I said it's good to document this.

>From SP point of view, NSR/GR in the core may not implemented because  nodes are often doubled (two per site)  and moreover NSR/GR is really adding a major complexity in equipments : complexifying t…

[Uma]: Stephane, I think this is the real contradiction you are talking!
GR/NSR is not new to lot of vendors/customers and it's there from long back for lot of vendors. If you say deploying the same with one command is complex, tuning, simulating rLFA NP configuration as per topology is orders of magnitude complex.
Trust me am  just debugging an issue on of the (tier 1)  customer node and AFAICT much more simpler things are still not handled well and what we are talking here is way far off than the practical reality on the ground.

[Uma]: I agree.

As I said earlier I support this, but some discussion ought to happen on this topic and heuristics as well as the path characteristics mentioned in the draft.

You said above - "a lot of features in service provider lab and Service Providers want to keep their core as simple and stable as possible."
I think for this sake at least we  need to simplify solutions where ever possible at least. I will share detailed comments later.

Good luck!

--
Uma C.

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 17 Mar 2014 17:54:39 +0000

Pushpasis,

You said -

2.       Deploy NSR/GR on all 1-hop neighbors.
..For networks where NSR is already deployed, node-protection may not be that critical.
[Pushpasis] Yes LFA manageability is optional, but if you donot need it then you also donot need to collect the path characteristics

It's good we agree upon these 2 points in he discussion.
I think for the benefit of future readers you ought to capture these 2 points in the draft.
--
Uma C.

---

From: Pushpasis Sarkar <[email-masked]>
Date: Mon, 17 Mar 2014 18:14:10 +0000

[Uma]: So we do few hundreds of fSPF from each neighbor for base LFA then few hundreds for Q space rSPFs and few more hundreds for rSPFs from PQ nodes depending on the network/heuristics for each primary SPF right. Did you see your 1msec is multiplied few multiple hundred times here.
[Pushpasis] Few hundreds fSPFS for PQnodes are not necessary. 8-16 PQ nodes selected using the default heuristic in this draft provide quite a good amount of coverage.

From: Uma Chunduri [mailto:[email-masked]]
Sent: Monday, March 17, 2014 11:24 PM
To: [email-masked]; Pushpasis Sarkar; Alia Atlas
Cc: [email-masked]; [email-masked]; Chris Bowers
Subject: RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Stephane,

Comments in-line [Uma]

--
Uma C.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Monday, March 17, 2014 1:47 AM
To: Pushpasis Sarkar; Uma Chunduri; Alia Atlas
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Chris Bowers
Subject: RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Agree with Pushpasis.

Good luck!

--
Uma C.

---

From: Pushpasis Sarkar <[email-masked]>
Date: Mon, 17 Mar 2014 18:16:36 +0000

Sure.

Thanks
-Pushpasis

From: Uma Chunduri [mailto:[email-masked]]
Sent: Monday, March 17, 2014 11:25 PM
To: Pushpasis Sarkar; Alia Atlas; Stephane Litkowski
Cc: [email-masked]; [email-masked]; Chris Bowers
Subject: RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Pushpasis,

You said -

---

From: <[email-masked]>
Date: Mon, 17 Mar 2014 19:46:48 +0100

More inline :)

De : Uma Chunduri [mailto:[email-masked]]
Envoyé : lundi 17 mars 2014 18:54
À : LITKOWSKI Stephane DTF/DERX; Pushpasis Sarkar; Alia Atlas
Cc : [email-masked]; [email-masked]; Chris Bowers
Objet : RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Stephane,

Comments in-line [Uma]

--
Uma C.

Agree with Pushpasis.

[SLI] I'm not saying that we don't care about additional fSPFs at all ... we clearly said during the WG meeting that running fSPF for each candidate PQ is too much computation ... I completely agree on that. But with only few additional fSPFs (~10), we are able to provide a pretty good coverage for guaranteed NP.

[SLI] Some bricks of NSR/GR are there from years ... but there are always pieces missing depending on the vendor ... (we always need support for all of our fancy protocols/features ...)
Doing simulation/tuning in network is not new , and it's part of network planning. It's not "complex" (it may ...), I would say it's more expensive in time ...
I agree that if we can save some time in this area, it would be better, but it's a more an "IP FRR" issue rather than a new issue brought by the node protection rLFA proposal (basic LFA requires simulation , MRT also ... ).
I completely agree that we need to keep thing simple in both implementations (simple code, so less buggy code) and operations. But here I think, that what we are adding there is not too much : maybe it depends of your existing code structure, and if yes, we can discuss it offline, in order to better understand your constraints.
What would be your proposal to make this more simple ? or do you think we need to give up guaranteed NP for rLFA and use SPRING ?

[SLI] Completely inline with the approach, but from now, I don't see how to simplify it more ... but clearly open to any ideas.

Good luck!

--
Uma C.

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 18 Mar 2014 06:18:35 +0000

In-line [Uma1]:

--
Uma C.

From: Pushpasis Sarkar [mailto:[email-masked]]
Sent: Monday, March 17, 2014 11:14 AM
To: Uma Chunduri; [email-masked]; Alia Atlas
Cc: [email-masked]; [email-masked]; Chris Bowers
Subject: RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

[Uma1]:
                "8-16 PQ nodes/ quite a good amount of coverage/ few additional fSPFs (~10)"
                Well, we all know the above qualifications are purely subjective and completely depends on the topology, number of total nodes, number of total interfaces etc..
                If the total number of candidate PQ nodes are in the order of multiple hundreds and with  LFA manageability considerations like per prefix options are enabled
                limiting to a marginal value to 8-16 PQ nodes may not give the gains we are seeking to start with.
                I  think we are back to heuristics.
                However,  I know with some tricky heuristics we can limit the fSPFs and total number of candidate PQs.

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 18 Mar 2014 06:20:28 +0000

>[SLI] Some bricks of NSR/GR are there from years ... but there are always pieces missing depending on the vendor ... (we always need support for all of our fancy protocols/features ...)

[Uma1]: Seriously - If that is the case, then rest assured, you won't be any better here and the bricks would  be much more smaller and different shapes from different vendors for
                   rLFA NP with default and extended heuristics.

                 Shall discuss more on this with manageability considerations in place and see why  exactly we are embracing more and more complexity even in deployments in a  multi-vendor SP environments.

--
Uma C.

---

From: <[email-masked]>
Date: Tue, 18 Mar 2014 16:37:15 +0000

Hi authors,

This is an interesting work, thanks for the draft and the rtgwg presentation.

1)      Regarding node protection, have you considered/evaluated the use of the algorithm proposed in TI-LFA (draft-francois-segment-routing-ti-lfa)?
Namely: computing the backup path with a (C)SPF (without the protected node), and enforcing this explicit path using multiple segments/labels?
Clearly, using TI-LFA in the absence of Segment Routing (more precisely the absence of adjacency segments/labels), 100% coverage is not possible. But this is also not possible with draft-psarkar. It's a priori not clear to me if the coverage would be increased or decreased. On the pro side, the use of multiple segments increases the coverage by allowing reaching more Q nodes. On the con side, the additional constraints added during the computation (namely enforcing the post convergence path (only)) decreases the coverage as this specific path may require an adjacency segment to cross a high metric link.
Evaluating this option would probably be interesting (in term of coverage, control plane computation, label stack depth, routing optimality, number of T-LDP sessions).

2)      On a related note, a possible heuristic for draft-psarkar to pick a node protecting PQ, would be to pick the PQ on the post convergence SPF (as per above/TI-LFA). That's simple, computationally not expensive (one SPF), and reduce the set of Candidate Node-Protecting PQ to a single element at most (not considering ECMP, to simply). If the set has one node, a node protecting PQ node has been found (on the optimal path, as a free property). If the set is empty, you may choose to fall back on draft-psarkar (picking a subset of PQ using heuristic and running SPF on those PQ).

Thanks,
Regards,
Bruno

From: rtgwg [mailto:[email-masked]] On Behalf Of Alvaro Retana (aretana)
Sent: Friday, March 14, 2014 6:02 AM
To: [email-masked]
Cc: [email-masked]
Subject: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Hi!

Thanks!

Alvaro.

---

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 18 Mar 2014 17:11:41 +0000

Hi Bruno,

Many many thanks for your thoughts. Please find some comments inline with [Pushpasis]

Thanks
-Pushpasis

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 18, 2014 10:07 PM
To: [email-masked]
Cc: [email-masked]; Alvaro Retana (aretana)
Subject: RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Hi authors,

1)      Regarding node protection, have you considered/evaluated the use of the algorithm proposed in TI-LFA (draft-francois-segment-routing-ti-lfa)?
Namely: computing the backup path with a (C)SPF (without the protected node), and enforcing this explicit path using multiple segments/labels?
[Pushpasis] We have gone through the TI-LFA and draft, and to the best of my understanding this requires a CSPF for each destination node in the network with the primary link as well as primary-nexthop node as exclude constraints for finding a backup path(if feasible) all the way to the destination. This will need far more computation than 1 forward SPF per PQ-nodes. Obviously it has the advantage of finding 100% of all possible node-protecting backup paths. With 16 PQ-nodes selected on the basis of the default heuristic suggested in this draft it was seen to find ~96-97% of all possible node-protecting backup paths on some of the common SP topologies we have run a simulation on. Adding so much of extra computation to achieve rest 3% of feasible node-protecting backup paths seemed insignificant and not worth exploring.

Clearly, using TI-LFA in the absence of Segment Routing (more precisely the absence of adjacency segments/labels), 100% coverage is not possible.
[Pushpasis] My understanding is that since with TI-LFA we are going to run CSPF for each destination, we will find 100% of all the feasible node-protecting paths to each destination. There may be destinations for which there are no feasible/possible node-protecting backup paths at all. Those destinations cannot be covered because there is no possible node-protecting backup paths for them.

But this is also not possible with draft-psarkar.
[Pushpasis] True. Like Stephane mentioned already, it is a tradeoff :)

It's a priori not clear to me if the coverage would be increased or decreased.
[Pushpasis] Obviously with TI-LFA will provide more coverage, like I explained above. But that will come at the cost of lot of extra computational overhead of running a lot of CSPFs.
On the pro side, the use of multiple segments increases the coverage by allowing reaching more Q nodes. On the con side, the additional constraints added during the computation (namely enforcing the post convergence path (only)) decreases the coverage as this specific path may require an adjacency segment to cross a high metric link.
Evaluating this option would probably be interesting (in term of coverage, control plane computation, label stack depth, routing optimality, number of T-LDP sessions).
[Pushpasis]Looks like you are referring to protection of MPLS traffic. I hope you remember that this draft also applies to IP-FRR.

2)      On a related note, a possible heuristic for draft-psarkar to pick a node protecting PQ, would be to pick the PQ on the post convergence SPF (as per above/TI-LFA). That's simple, computationally not expensive (one SPF), and reduce the set of Candidate Node-Protecting PQ to a single element at most (not considering ECMP, to simply). If the set has one node, a node protecting PQ node has been found (on the optimal path, as a free property). If the set is empty, you may choose to fall back on draft-psarkar (picking a subset of PQ using heuristic and running SPF on those PQ).
[Pushpasis] Not sure if I got what you are trying to say here. But, I think it will be best to not bring in TI-LFA in this. This draft was intended to cover the lack of node-protection in the original RLFA draft and address the need of some of the network deployments which still need node-protection to be guaranteed. The intention of using a heuristic is to choose a subset of all PQ-nodes found in the network and restrict the number of FSPFs to a maximum number, and still achieve a hight percentage of coverage with the same subset of PQ-nodes.

Thanks,
Regards,
Bruno

Hi!

Thanks!

Alvaro.

Thank you.

---

From: <[email-masked]>
Date: Tue, 18 Mar 2014 18:46:44 +0100

Here are primarly fresh results on 10 topologies with postconvergence path enforcement using only LFA/rLFA or LFA/rLFA+dLFA (1hop adj) :

LFA+rLFA

LFA+rLFA+dLFA

87,07961

95,77624278

88,68371

93,94736589

88,98679

90,51039143

81,66041

87,89868668

83,05648

95,43189369

88,27434

95,13274336

94,60468

100

99,66204

100

99,54467

99,6987133

99,55152

100

The table present % of TI-LFA repair list.

For example for topology 1 (first line), 87% of repair_list could be encoded on postconvergence path using only LFA and rLFA , we can extend this to 95% by adding dLFA (just one Adjacency segment).

De : Pushpasis Sarkar [mailto:[email-masked]]
Envoyé : mardi 18 mars 2014 18:12
À : DECRAENE Bruno IMT/OLN; [email-masked]
Cc : [email-masked]; Alvaro Retana (aretana)
Objet : RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Hi Bruno,

Thanks
-Pushpasis

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, March 18, 2014 10:07 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana)
Subject: RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Hi authors,

Thanks,
Regards,
Bruno

Hi!

Thanks!

Alvaro.

Thank you.

---

From: <[email-masked]>
Date: Tue, 18 Mar 2014 18:58:37 +0100

The TI-LFA draft is not really clear today about the Mathematics :)
At least it requires one SPF rooted at PLR per neighbor considering the neighbor has failed.

Hi Bruno,

Thanks
-Pushpasis

Hi authors,

Thanks,
Regards,
Bruno

Hi!

Thanks!

Alvaro.

Thank you.

---

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 18 Mar 2014 18:31:53 +0000

Yes. To be precisely an CSPF each rooted on PLR for each destination with the primary link and neighbor as exclude-constraints.

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 18, 2014 11:29 PM
To: Pushpasis Sarkar; DECRAENE Bruno IMT/OLN; [email-masked]
Cc: [email-masked]; Alvaro Retana (aretana)
Subject: RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

De : Pushpasis Sarkar [mailto:[email-masked]]
Envoyé : mardi 18 mars 2014 18:12
À : DECRAENE Bruno IMT/OLN; [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana)
Objet : RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Hi Bruno,

Thanks
-Pushpasis

Hi authors,

Thanks,
Regards,
Bruno

Hi!

Thanks!

Alvaro.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Tue, 18 Mar 2014 20:47:13 +0000

Hi Pushpasis,

Please find some comments inline with [Bruno]

Thanks,
Bruno

From: Pushpasis Sarkar [mailto:[email-masked]]
Sent: Tuesday, March 18, 2014 6:12 PM
To: DECRAENE Bruno IMT/OLN; [email-masked]
Cc: [email-masked]; Alvaro Retana (aretana)
Subject: RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Hi Bruno,

Thanks
-Pushpasis

Hi authors,

1)      Regarding node protection, have you considered/evaluated the use of the algorithm proposed in TI-LFA (draft-francois-segment-routing-ti-lfa)?
Namely: computing the backup path with a (C)SPF (without the protected node), and enforcing this explicit path using multiple segments/labels?
[Pushpasis] We have gone through the TI-LFA and draft, and to the best of my understanding this requires a CSPF for each destination node in the network with the primary link as well as primary-nexthop node as exclude constraints for finding a backup path(if feasible) all the way to the destination.
[Bruno] TI-LFA has a 2 steps process:
- find the Post Convergence Path (assuming the protected element (node or link) has failed). This requires  1 CSPF rooted on the PLR, excluding the failed element. This single CSPF gives you the path for all destination (just like the regular IGP one)
- then we need to find how to enforce an explicit route toward each destinations. There are different ways to do this,  which may depend on your existing (r)LFA implementation. But as an example, you can compute the (regular) extended P space. Cost (so far...) is one SPF per neighbor  (just like for LFA). Then you explore your post convergence graph and "intersect" it with your extended P space and you get all the destinations, along the post convergence path, which are reachable with no additional encapsulation (à la LFA).
So far so good. To go further, you can use the RLFA trick: send the packet to a remote destination using encapsulation (IP or MPLS or whatever.) Those destinations are all farest Q nodes, along the post convergence path. Number of those nodes is topology dependent. According to Stéphane simulations, this is very manageable. Then you run a CSPF on those P nodes, so see what you destinations, along the post convergence path, you can reach via this P nodes. You can install those in you FIB, using the encapsulation required to reach the P (a la RLFA). According the Stéphane simultations (just sent) at this step you can expect 81%- 99% coverage, with guaranteed node protection and a single layer of encapsulation (label)
Then you can apply the same RLFA trick recursively, adding a layer of encapsulation each time (to get to the first P, then from the first P to the second...), until you have explored you complete CSPF/post convergence graph. Here, we see that MPLS is a better encapsulation as the header is shorter (4 octets) compared to an IPv4 or IPv6 encapsulation.
Without segment routing, when following your post convergence graph, there are high metrics links, that you will not be able to cross. (e.g. links with "infinity" metrics).

This will need far more computation than 1 forward SPF per PQ-nodes.
[Bruno] The number of CSPF is topology dependant so we will need simulation to compare. If your are limited by SPF computation, but may also prune some path along your post convergence SPF, at the cost of reduced coverage. (e.g. limiting the depth of the number of P nodes required to reach the destination, or pruning the sub-tree that the depth / destinations is too high.
Obviously it has the advantage of finding 100% of all possible node-protecting backup paths. With 16 PQ-nodes selected on the basis of the default heuristic suggested in this draft it was seen to find ~96-97% of all possible node-protecting backup paths on some of the common SP topologies we have run a simulation on. Adding so much of extra computation to achieve rest 3% of feasible node-protecting backup paths seemed insignificant and not worth exploring.
[Bruno] indeed, 16 CSPF is low, but Stéphane could probably get some result on its simulations. Or you could also evaluate yourself the TI-LFA algo on your topologies. Based on simulations I got, this seems manageable, but the more simulations, the better.
Note also the TI-LFA also provide the optimal backup path that RLFA/draft-psarkar does not provides.

Clearly, using TI-LFA in the absence of Segment Routing (more precisely the absence of adjacency segments/labels), 100% coverage is not possible.
[Pushpasis] My understanding is that since with TI-LFA we are going to run CSPF for each destination, we will find 100% of all the feasible node-protecting paths to each destination.
[Bruno] A single CSPF is enough to get all the path. Now we need to compute the list of P nodes on the path to each destinations and this requires more SPF. Should be much lower than one for all destinations.
Then we can't have 100% coverage since high metric links can't be crossed using regular IGP routing.
There may be destinations for which there are no feasible/possible node-protecting backup paths at all. Those destinations cannot be covered because there is no possible node-protecting backup paths for them.

2)      On a related note, a possible heuristic for draft-psarkar to pick a node protecting PQ, would be to pick the PQ on the post convergence SPF (as per above/TI-LFA). That's simple, computationally not expensive (one SPF), and reduce the set of Candidate Node-Protecting PQ to a single element at most (not considering ECMP, to simply). If the set has one node, a node protecting PQ node has been found (on the optimal path, as a free property). If the set is empty, you may choose to fall back on draft-psarkar (picking a subset of PQ using heuristic and running SPF on those PQ).
[Pushpasis] Not sure if I got what you are trying to say here. But, I think it will be best to not bring in TI-LFA in this.
[Bruno] IMO, it would be good to have simulations to compare both approach. But as it's would require you/Stéphane to do the simulation work, it really is up to you.
This draft was intended to cover the lack of node-protection in the original RLFA draft and address the need of some of the network deployments which still need node-protection to be guaranteed. The intention of using a heuristic is to choose a subset of all PQ-nodes found in the network and restrict the number of FSPFs to a maximum number, and still achieve a hight percentage of coverage with the same subset of PQ-nodes.
[Bruno] indeed. But in the end, the performance of the solutions (in term of control plane CPU, coverage, path optimality, number of T-LDP sessions for LDP networks) is topology dependent hence seems difficult to compare without simulations. Hence my original question to see if you had explore this option.

Many thanks,
Bruno

Thanks,
Regards,
Bruno

Hi!

Thanks!

Alvaro.

Thank you.

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 19 Mar 2014 17:15:24 -0700

Hi Pushpasis,
you've written:
"
*[Pushpasis] The real motivation behind node-protection has been to protect
traffic against node-failures of the 1-hop immediate neighbors."*
I wonder how one can reliably detect that it is immediate neighbor node
failure, not link failure. I'd argue that such distinction can not be made
dynamically and thus choice of using link protection or node protection is
matter of pre-defined interpretation like one done in RSVP FRR (RFC 4090).

Regards,
Greg

On Mon, Mar 17, 2014 at 12:51 AM, Pushpasis Sarkar <[email-masked]>wrote:

>  Hi Uma,
>
>
>
> *From:* Uma Chunduri [mailto:[email-masked]]
> *Sent:* Monday, March 17, 2014 12:20 PM
> *To:* Alia Atlas; Stephane Litkowski
> *Cc:* [email-masked];
> [email-masked]
> *Subject:* RE: WG Adoption Call for
> to as many as more than half the number of nodes in the network, I don't
> think this gain is, in any way matching the
>
> *[Pushpasis] The real motivation behind node-protection has been to
> protect traffic against node-failures of the 1-hop immediate neighbors.
> IMO, this can be achieved in two ways only.*
>
> *1.       **Deploy node-protection on PLR, Or*
>
> *2.       **Deploy NSR/GR on all 1-hop neighbors.*
>
> *Both methods will add computational complexity and it is matter of choice
> which one will the operator go for. Again IMO, NSR is far more complex than
> node-protection and adds considerably much more to overall CPU and other
> resource consumptions than node-protection. For networks where NSR is
> already deployed, node-protection may not be that critical. But for
> networks that did not deploy NSR (for whatever reasons, I don't want to
> speculate), it is quite critical, once again in my opinion. *
>
> I don't think so. I think you have to explain why and how you think it's a
> *major* gain.
>
> *[Pushpasis] Again, for networks that did not deploy NSR, it is quite
> critical.*
>
> *[Pushpasis] I agree that it does not guarantee 100% protection. However,
> we have seen ~96-98% coverage even when we restricted the number of
> PQ-nodes between 8 and 16, and that too with a very simple heuristic as
> suggested in the draft. *
>
> *[Pushpasis] Yes LFA manageability is optional, but if you donot need it
> then you also donot need to collect the path characteristics. So you save
> time on that. Without that, all you need is a basic Forward SPF on the
> PQ-node. On a router with the kind of high performance CPUs used today, a
> SPF with 1000 node topology, a single SPF runs well under 1ms. How much
> performance overhead are we really adding then? *
>
>
>
> *I don't get your comment in pumping code-complexity. The only extra
> things we need to do is*
>
> *- Run a Forward SPF on a PQ-node. The same code that was written for LFA
> can be re-used. Just run it on a PQ-node instead of a 1 hop neighbor.*
>
> *- Alos the existing code for checking inequalities can then be easily
> re-used/extended to run on the results procured from the above SPF.*
>
>
>
> --
>
> Uma C.
>
>
>
> *From:* Alia Atlas [mailto:[email-masked] <[email-masked]>]
> *Sent:* Saturday, March 15, 2014 5:57 AM
> *To:* Stephane Litkowski
> *Cc:* Uma Chunduri; Alvaro Retana (aretana); [email-masked];
> *Subject:* Re: WG Adoption Call for

---

From: Chris Bowers <[email-masked]>
Date: Thu, 20 Mar 2014 03:06:43 +0000

Uma,

At the London meeting we presented a sample of results from modeling different PQ-selection heuristics in real network topologies.  They are in slides 7-14 of this link.

http://www.ietf.org/proceedings/89/slides/slides-89-rtgwg-4.pdf
The comparison of per-PLR coverage for different heuristics for selecting a subset of PQ-nodes is shown for two topologies on p.11-14.  Not shown in these slides are the results when one considers all possible PQ-nodes, but this was also computed.  The exhaustive PQ-node results show that for some topologies, there is potential to improve coverage with more PQ-nodes or a better choice of PQ-nodes, especially with respect to node-protecting coverage.  However, for these two topologies, even with a simple heuristic for selecting 16 PQ nodes, RLFA offers a significant improvement in coverage compared to local LFA (as shown on p.9-10 ), so some service providers may find it useful.

As has been pointed out by others, having to deal with the constraint imposed by limiting possible repair tunnels to those that can be created with a single LDP label (extended P-space) is generally going to be problematic.  Using explicitly routed repair tunnels (created using RSVP or segment routing) or using an alternate topology (as with MRT) may be more productive approaches to improving coverage and backup path quality.

Chris

From: Uma Chunduri [mailto:[email-masked]]
Sent: Tuesday, March 18, 2014 1:19 AM
To: Pushpasis Sarkar; [email-masked]; Alia Atlas
Cc: [email-masked]; [email-masked]; Chris Bowers
Subject: RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

In-line [Uma1]:

--
Uma C.

To: Uma Chunduri; [email-masked]<mailto:[email-masked]>; Alia Atlas

[Uma1]:

---

From: Pushpasis Sarkar <[email-masked]>
Date: Thu, 20 Mar 2014 06:09:29 +0000

Hi Greg,

As far as my understanding on the topic, when a user configures 'node-protection' on a link, he is expecting the LFA software to assume the worst on detecting a link-down event (i.e the reason for the link down is that the neighbor node itself has gone down). And then it expects the backup traffic to be sent on a path that does not traverse the fated link and the remote node. 'node-protection' does not mean we take this backup path only after detecting the neighbor has actually gone down.

Thanks
-Pushpasis

From: Greg Mirsky [mailto:[email-masked]]
Sent: Thursday, March 20, 2014 5:45 AM
To: Pushpasis Sarkar
Cc: Uma Chunduri; Alia Atlas; Stephane Litkowski; [email-masked]; [email-masked]
Subject: Re: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Hi Pushpasis,
you've written:
"[Pushpasis] The real motivation behind node-protection has been to protect traffic against node-failures of the 1-hop immediate neighbors."
I wonder how one can reliably detect that it is immediate neighbor node failure, not link failure. I'd argue that such distinction can not be made dynamically and thus choice of using link protection or node protection is matter of pre-defined interpretation like one done in RSVP FRR (RFC 4090).
Regards,
Greg

On Mon, Mar 17, 2014 at 12:51 AM, Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>> wrote:
Hi Uma,

From: Uma Chunduri [mailto:[email-masked]<mailto:[email-masked]>]

Hi Stephane,

Any ways, let me try -

--
Uma C.

Stephane,

Regards,
Alia

---

From: Gábor Sándor Enyedi <[email-masked]>
Date: Thu, 20 Mar 2014 10:12:06 +0000

Hi Stephane,

When there is bidirectional traffic (which is the common case), it is possible that you can correct a failure only in one direction. Did you take that into consideration?
BR,

Gabor

From: rtgwg [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, March 18, 2014 6:47 PM
To: Pushpasis Sarkar; DECRAENE Bruno IMT/OLN; [email-masked]
Cc: [email-masked]
Subject: RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

LFA+rLFA

LFA+rLFA+dLFA

87,07961

95,77624278

88,68371

93,94736589

88,98679

90,51039143

81,66041

87,89868668

83,05648

95,43189369

88,27434

95,13274336

94,60468

100

99,66204

100

99,54467

99,6987133

99,55152

100

Hi Bruno,

Thanks
-Pushpasis

Hi authors,

Thanks,
Regards,
Bruno

Hi!

Thanks!

Alvaro.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Thu, 20 Mar 2014 11:38:51 +0100

You are right, as for every « LFA » based technique, you may have coverage in one direction only.

De : Gábor Sándor Enyedi [mailto:[email-masked]]
Envoyé : jeudi 20 mars 2014 11:12
À : LITKOWSKI Stephane DTF/DERX; Pushpasis Sarkar; DECRAENE Bruno IMT/OLN; [email-masked]
Cc : [email-masked]
Objet : RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Hi Stephane,

Gabor

From: rtgwg [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, March 18, 2014 6:47 PM
To: Pushpasis Sarkar; DECRAENE Bruno IMT/OLN; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

LFA+rLFA

LFA+rLFA+dLFA

87,07961

95,77624278

88,68371

93,94736589

88,98679

90,51039143

81,66041

87,89868668

83,05648

95,43189369

88,27434

95,13274336

94,60468

100

99,66204

100

99,54467

99,6987133

99,55152

100

Hi Bruno,

Thanks
-Pushpasis

Hi authors,

Thanks,
Regards,
Bruno

Hi!

Thanks!

Alvaro.

Thank you.

Thank you.

---

From: Gábor Sándor Enyedi <[email-masked]>
Date: Thu, 20 Mar 2014 10:54:56 +0000

Is it possible to tweak the simulation code you have to get the bidirectional coverage as well? I would be much more interested in those numbers.

Gabor

P.s.: Just out of curiosity, is there any real application with unicast unidirectional traffic?

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 20, 2014 11:39 AM
To: Gábor Sándor Enyedi; Pushpasis Sarkar; DECRAENE Bruno IMT/OLN; [email-masked]
Cc: [email-masked]
Subject: RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

De : Gábor Sándor Enyedi [mailto:[email-masked]]
Envoyé : jeudi 20 mars 2014 11:12
À : LITKOWSKI Stephane DTF/DERX; Pushpasis Sarkar; DECRAENE Bruno IMT/OLN; [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>
Objet : RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Hi Stephane,

Gabor

LFA+rLFA

LFA+rLFA+dLFA

87,07961

95,77624278

88,68371

93,94736589

88,98679

90,51039143

81,66041

87,89868668

83,05648

95,43189369

88,27434

95,13274336

94,60468

100

99,66204

100

99,54467

99,6987133

99,55152

100

Hi Bruno,

Thanks
-Pushpasis

Hi authors,

Thanks,
Regards,
Bruno

Hi!

Thanks!

Alvaro.

Thank you.

Thank you.

Thank you.

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 20 Mar 2014 11:24:04 +0000

Asymmetric routing.
Hot potato.

--
Jakob Heitz.

On Mar 20, 2014, at 3:55 AM, "Gábor Sándor Enyedi" <[email-masked]<mailto:[email-masked]>> wrote:

Gabor

To: Gábor Sándor Enyedi; Pushpasis Sarkar; DECRAENE Bruno IMT/OLN; [email-masked]<mailto:[email-masked]>

Hi Stephane,

Gabor

LFA+rLFA

LFA+rLFA+dLFA

87,07961

95,77624278

88,68371

93,94736589

88,98679

90,51039143

81,66041

87,89868668

83,05648

95,43189369

88,27434

95,13274336

94,60468

100

99,66204

100

99,54467

99,6987133

99,55152

100

Hi Bruno,

Thanks
-Pushpasis

Hi authors,

It’s a priori not clear to me if the coverage would be increased or decreased.

2)      On a related note, a possible heuristic for draft-psarkar to pick a node protecting PQ, would be to pick the PQ on the post convergence SPF (as per above/TI-LFA). That’s simple, computationally not expensive (one SPF), and reduce the set of Candidate Node-Protecting PQ to a single element at most (not considering ECMP, to simply). If the set has one node, a node protecting PQ node has been found (on the optimal path, as a free property). If the set is empty, you may choose to fall back on draft-psarkar (picking a subset of PQ using heuristic and running SPF on those PQ).
[Pushpasis] Not sure if I got what you are trying to say here. But, I think it will be best to not bring in TI-LFA in this. This draft was intended to cover the lack of node-protection in the original RLFA draft and address the need of some of the network deployments which still need node-protection to be guaranteed. The intention of using a heuristic is to choose a subset of all PQ-nodes found in the network and restrict the number of FSPFs to a maximum number, and still achieve a hight percentage of coverage with the same subset of PQ-nodes.

Thanks,
Regards,
Bruno

Hi!

Thanks!

Alvaro.

Thank you.

Thank you.

Thank you.

---

From: Gábor Sándor Enyedi <[email-masked]>
Date: Thu, 20 Mar 2014 13:08:08 +0000

Asymmetric routing is not unidirectional, it just sends traffic back on a different path, but there is traffic coming back (e.g. if there  is TCP flow, at least some ACK will come back). The same is true for hot potato. Probably if the paths are so asymmetric that even the AS paths are different...

Gabor

From: Jakob Heitz
Sent: Thursday, March 20, 2014 12:24 PM
To: Gábor Sándor Enyedi
Cc: [email-masked]; Pushpasis Sarkar; DECRAENE Bruno IMT/OLN; [email-masked]; [email-masked]
Subject: Re: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Asymmetric routing.
Hot potato.

--
Jakob Heitz.

Gabor

Hi Stephane,

Gabor

LFA+rLFA

LFA+rLFA+dLFA

87,07961

95,77624278

88,68371

93,94736589

88,98679

90,51039143

81,66041

87,89868668

83,05648

95,43189369

88,27434

95,13274336

94,60468

100

99,66204

100

99,54467

99,6987133

99,55152

100

Hi Bruno,

Thanks
-Pushpasis

Hi authors,

Thanks,
Regards,
Bruno

Hi!

Thanks!

Alvaro.

Thank you.

Thank you.

Thank you.

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 20 Mar 2014 18:42:36 +0000

Chris,

In-line [Uma]:
--
Uma C.

From: Chris Bowers [mailto:[email-masked]]
Sent: Wednesday, March 19, 2014 8:07 PM
To: Uma Chunduri; Pushpasis Sarkar; [email-masked]; Alia Atlas
Cc: [email-masked]; [email-masked]
Subject: RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Uma,

[Uma]:What is Topology-A and Topology-B represent? Are these 2 from the 14 SP topologies?
Else we don't know what are the main characteristics of the topology.
X-axis is not marked in the graph to get an idea of the total number of nodes in each topology; however I see anywhere between 500 - 1100 PQ nodes for
most PLRs (I am sure this is also function of number of  no of links per PLR apart from other factors).

[Uma]: I also see the coverage varies on PLT to PLR.  Though this result is giving some idea, probably it's still difficult to  conceive default heuristic is indeed is the best bet for all/majority the topologies. On the other hand, if the results are varying for each type of heuristic viz., AVOID_THEN_DIST/ DIST_THEN_AVOID/ RR_ AVOID_THEN_DIST/ SOME _BEST_PROP _XX_HEURISTIC  and we strive for best coverage, then how can we assure you get the same pre-computed PQ node irrespective of the vendor ? And also this predictability seems to be the premise of the standardization of the solution...

As has been pointed out by others, having to deal with the constraint imposed by limiting possible repair tunnels to those that can be created with a single LDP label (extended P-space) is generally going to be problematic.
[Uma]: Though it's problematic, probably this is operationally simple.
Using explicitly routed repair tunnels (created using RSVP or segment routing) or using an alternate topology (as with MRT) may be more productive approaches to improving coverage and backup path quality.
[Uma]: Agree.

Chris

---

From: Chris Bowers <[email-masked]>
Date: Fri, 21 Mar 2014 16:19:43 +0000

Uma
,
Thanks for your responses.
See my responses inline [CB].

Chris

From: Uma Chunduri [mailto:[email-masked]]
Sent: Thursday, March 20, 2014 1:43 PM
To: Chris Bowers; Pushpasis Sarkar; [email-masked]; Alia Atlas
Cc: [email-masked]; [email-masked]
Subject: RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Chris,

In-line [Uma]:
--
Uma C.

To: Uma Chunduri; Pushpasis Sarkar; [email-masked]<mailto:[email-masked]>; Alia Atlas

Uma,

[CB]  You are correct that Topology-A and Topology-B are just 2 out of many topologies analyzed.  I decided to present only two to keep the presentation brief and also to be able to present the coverage seen by each PLR.  The two topologies presented were fairly typical.  The only exception being that they are both fairly large in terms of number of nodes.  Topology A has more 500 nodes and topology B has more than 1000 nodes.  I chose large networks to make the point that if one wants to quickly calculate forward SPFs from PQ-nodes in order to determine the path characteristics from PQ-node to destination, then some heuristic to select a smaller subset of PQ-nodes is needed, because the PQ-condition can still results in hundreds of PQ-nodes.  Other than that, the topologies were not consciously chosen to make any particular point.

[CB]  In my opinion, this draft shouldn't try to standardize a particular PQ-selection heuristic, because there is no way to agree on what "best" coverage or backup path quality means and certainly no way to agree on best heuristic.  The meaning of best heuristic will certainly vary from network to network, and as you point out, it can even vary from PLR to PLR in the same network.  In my opinion, the focus of the draft should be on the use of forward SPF rooted at a PQ-node as the means of determining if the path from PQ-to-dest is node protecting and to collect other path properties.

[CB] When this idea was originally presented to the WG in Berlin, concerns were raised that computing forward SPFs from all PQ-nodes was computationally problematic.  To address that concern, section 2.3.3  was added to the draft.  It requires choosing a subset of PQ-nodes from which to perform forward SPFs.  The modeling results presented in London were intended to illustrate that when one imposes a limit on the subset of PQ-nodes from which to perform forward SPFs and uses a fairly simple heuristic, one can still get quite useful improvements in coverage by augmenting local LFA with RLFA.  It wasn't intended to imply that any particular heuristic should be standardized.  I hope that clarifies our reasons for presenting some results from analyzing PQ-selection heuristics.

Chris

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 28 Mar 2014 17:44:52 +0000

Dear Authors & Chris,
...
...

[Uma]:What is Topology-A and Topology-B represent? Are these 2 from the 14 SP topologies?
Else we don't know what are the main characteristics of the topology.
[CB]  You are correct that Topology-A and Topology-B are just 2 out of many topologies analyzed.

Ok, these are some arbitrary topologies with huge number of nodes and I don't think we can conclude results based on this to confirm 8-16 PQ nodes for fSPF would always yield best coverage.
But your results based on these are pointing towards that.

[CB]  ...In my opinion, the focus of the draft should be on the use of forward SPF rooted at a PQ-node as the means of determining if the path from PQ-to-dest is node protecting
I think this should be THE  goal of this document.

[CB]  ..and to collect other path properties.
IMO,  this should belong to LFA/RLFA manageability draft.

Summary:

1.       I feel this draft should focus on the original goal of rLFA NP as the way it's specified today i.e., NP extended P-space and fSPF from candidate PQ to destinations (just this, bit more cleaner).

2.       Also after further study as indicated in the draft, should define a default strategy for reducing the number of PQs which will maximize the NP coverage.

While doing this it should always consider:

a.       The total number of PQ nodes should be lesser; not for fSPF load reduction but also for minimizing the TLDP on the fly sessions. So preference for close to Source must also be a factor.

b.      Given the defined criteria for any topology for any vendor should yield the same PQ node (predictability for operations and planning)

3.       Manageability considerations as defined in this draft should be completely removed  (I see the same already in http://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-03#section-5.2.4)

FWIW,  I feel an update is needed before it proceeds further. I also have more particular comments and will post in a separate e-mail.

--
Uma C.