Subject: draft-ietf-rtgwg-remote-lfa - ready for WGLC?

From: Stewart Bryant <[email-masked]>
Date: Thu, 20 Jun 2013 14:59:13 +0100

I write this email as duty editor of draft-ietf-rtgwg-remote-lfa

I recently updated this draft and think that it is ready for WGLC.

When the WG adopted the draft Alia made a number of comments which
I address below:

AA> First, if the intent is to restrict this mechanism to ONLY link
AA> protection, that belongs at a minimum prominently in the abstract and
AA> introduction.  It is currently first mentioned only in Section 3.

This has been addressed.

AA> Second, the algorithm description Sec 4.2.1 and Sec 4.2.2 needs
AA> significant expansion into a more formal algorithm description, such
AA> as is in the LFA spec, RFC 5286.  A brief description of the
AA> computational complexity would be useful, but the critical part is
AA> having it specified clearly.

Mike and I have included some cost metric explanations which I think
is adequate for ensuring the expected behavior. I am not convinced
that the level of formalism in RFC5286 is required. The requirement
is that an implementation will function correctly, neither breaking
the network, nor surprising the operator.

AA> Third, in Sec 4.2.3, there is no preferred or even specified method
AA> for selecting among the different PQ options that might be available.
AA> Such a method should be specified; as the draft says, there is an
AA> advantage from the network management perspective to consistency.   It
AA> is also required to have agreement on the output of analysis to
AA> compare/contrast methods.

We have added some text

AA> Fourth, one issue described in RFC 5286 is what happens when a worse
AA> failure occurs than the LFA was computed to handle - i.e. if a node
AA> failure happens instead of a link failure.  In that case, traffic
AA> looping can occur.  With Remote LFA, I believe that the same issue can
AA> exist - but made even worse because there is no effort to look for
AA> node-protecting Remote LFAs.   This concern needs some description in
AA> the draft.  Additionally, the equivalent of the Downstream Paths
AA> condition should be specified, if possible, that allows such traffic
AA> looping to be avoided.  Finally, since the argument for Remote LFA is
AA> the improved coverage over LFAs, I would like to see the coverage
AA> analysis based on simulation to show the coverage when the Downstream
AA> Paths equivalent requirement is met vs. when it is relaxed (as
AA> currently in the draft).

We added some test to section 6 to cover the worse than expected case.

AA> Fifth, for a better understanding of realistic behavior, I would like
AA> to see the analysis extended to show the min, average, and max
AA> coverage for the 11 specified topologies after each single failure has
AA> occurred in the topology.  (Of course, the computation should
AA> recognize that protecting cut-links isn't feasible and not include
AA> those failures.)

I don't think that this draft is the place to provide a greater analysis
of coverage. However I do think such a draft needs to be written.

I understand that Mike has plans to publish a draft before Berlin
to address this.

AA> While I recognize that link failures are significantly more common
AA> than node failures, I believe that fast-reroute techniques should be
AA> able to cover node failures as well.  Technically, I think that Remote
AA> LFA can, of course, be extended to provide node coverage - at the cost
AA> of computing a reverse-SPF from each next-next-hop of the computing
AA> router.

There are drafts covering the node case that are being proposed
by members of the WG.

AA> As I said early, at a minimum, the abstract and introduction
AA> need to clearly specify that Remote LFA only provides link protection
AA> and the traffic looping concerns need to be addressed.

Done

- Stewart

---

From: Acee Lindem <[email-masked]>
Date: Tue, 25 Jun 2013 16:53:50 +0000

Hi Stewart, 

See inline. 

>the network, nor surprising the operator.

I have to say that I agree with Alia here. I've read the document several
times and what you have in sections 4.2.1-4.2.3 is a heuristic for
determining a single remote LFA for a specific failure (S-E failure in
figure 1) rather than any kind of general case algorithm.

Thanks,
Acee 

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

---

From: Levente Csikor <[email-masked]>
Date: Wed, 26 Jun 2013 15:13:57 +0200

Dear All,
we've been analyzing and dealing with Remote LFA (rLFA for short) more 
than 1 year ago. As a first approach, we analyzed only unit costs 
networks with single link failures, and our results are summarized in 
[1]. Furthermore, we extended our work with node failures, which can be 
found in [2]. Since, in the first version of the rLFA Draft, it was not 
clearly explained that whether the usage of extended P-space involves 
additional complexity or not, we divided our analyses into two cases. In 
the first case, /only P-space/ is available for finding possible 
PQ-nodes (link-protecting remote LFA), while in the second case, 
/extended P-space/ was also considered (extended link-protecting remote 
LFA). Since we found that /remote LFA with extended P-spaces provides 
100% failure case coverage in all unit cost network against single link 
failures/, our separated analyses were also helpful. (However, we proved 
that if node protection is also considered, then unit cost networks are 
not fully protected.)

As Alia commented recently on the algorithm description in Sec. 4.2.1 
and Sec. 4.2.2. before, we also think that  a more formal algorithm 
description is necessary, especially, when P-spaces and Q-space are 
defined with cost functions similarly as defined in LFA FRR. From a 
routing point of view, I think, it would be easier to understand and 
calculate these /spaces/ (P,ext.P,Q) if they were defined with distance 
functions.

Fortunately, the authors of Remote LFA Draft do not have to resolve 
these issues on their own, since we already defined them in our relevant 
papers.
In order to not to read our full papers and searching the answers, I 
copied here the relevant parts:
*Link-protecting rLFA condition:*
For source /s/, destination /d/, and next-hop /e/, some node /n/ /!= 
s,d/ is a link-protecting remote LFA for the /s-d/ pair  if and only if
/dist(s, n) < dist(s, e) + dist(e, n)/  (1)
/dist(n, d) < dist(n, s) + dist(s, d)/  (2)
In these equations, one can easily see, that (1) defines the P-space, 
while (2) is the condition of Q-space. Furthermore, with these 
formalized conditions, one can easily observe, that (2) is actually the 
basic loop-free criterion of pure LFA.

*Link-protecting rLFA condition with extended P-space:*
For source /s///, destination /d///, and next-hop /e///, some node /n != 
s,d/ is an extended link-protecting remote LFA for the /s-d/ pair if and 
only if
/?v ? neigh(s) : dist(v, n) < dist(v, s) + dist(s, e) + dist(e, n)///
/dist(n, d) < dist(n, s) + dist(s, d) . /

*Node-protecting rLFA condition:*
For source /s///, destination /d///, and next-hop /e///, some /n != s,d/ 
is a node-protecting remote LFA for the /s-d/ pair if and only if
/dist(s,n) < dist(s,e) + dist(e,n)///     (3)
/dist(n,d) < dist(n,e) + dist(e,d) /    (4)
As it was in the case of link protection, here, (3) defines the P-space, 
while (4) characterize the Q-space.
Here, two important observations can be made, which are the followings:
  - P-space does not depend on the protection scheme (i.e., link or node 
protection)
  - (4) again is the basic node-protecting loop-free criterion of pure LFA.

*Node-protecting rLFA condition with extended P-space:*
For source /s///, destination /d///, and next-hop /e///, some node /n != 
s,d/ is an extended node-protecting remote LFA for the /s-d/ pair if and 
only if
/?v ? neigh(s) : dist(v, n) < dist(v, e) + dist(e, n)/
/dist(n, d) < dist(n, e) + dist(e, d) ./

Despite the fact that we only considered unit cost networks, the formal 
definitions above are *true for any arbitrary weighted network.*

I have to emphasize and thank the authors that in the second version of 
the rLFA draft, it became more clear how MPLS LDP label stack can 
provide the necessary "tunneling" for reaching remote LFA staging 
points, which answered me a lot of questions.
However, there is something in which I still not sure. As far as I 
know(, from the draft), reaching PQ-nodes in MPLS/LDP enabled network, 
two labels are necessary for the source node to avoid the failed 
component. An outer label, which is the label of S's neighbor for 
sending traffic to the PQ-node, while the inner label is the PQ node's 
label for reaching the destination. However, in this MPLS/LDP point of 
view, is there any difference between the label stacks used to reach a 
PQ-node in the case of simple P-space or extended P-space, or the are 
the same?

On the other hand, according to the MPLS LDP specification (RFC 5036), 
the targeted LDP capability may be disabled at the routers, which 
indicates that the simple label stacks cannot be always used to destine 
packets to a PQ-node, therefore IP tunneling (e.g., IP-in-IP, GRE) 
should be used to reach the same end. Is it an issue nowadays, or these 
are already addressed?

Additionally, for Sec. 9.3., we also have measured coverages of rLFA in 
real-world topologies inferred from Rocketfuel dataset, SNDLib and 
Topology-zoo, and we compared them to pure LFA coverages as well. These 
results can be found in our papers, which may be used in this draft.

We think that our results could be a crystallization for some aspects of 
remote LFA and may be used in the draft.
We also believe that the above mentioned more formal descriptions of P- 
and Q-spaces and their connectivities to pure LFA can definitely ease 
the understanding of how remote LFA works, especially for those who has 
experience in simple LFA.

If you decide to use our results, please mention our works somehow in 
the document (e.g., references, acknowledgements)

Best regards,
Levente Csikor
Ph.D. Student
MTA-BME Future Internet Research Group
High Speed Networks Laboratory
Dept. of Telecommunications and Media Informatics
Budapest University of Technology and Economics,
Hungary.

[1] L. Csikor, G. Retvari, "IP Fast Reroute with Remote Loop-Free 
Alternates: the Unit Link Cost Case", In: Proceeding of RNDM 2012 4th 
International Workshop on Reliable Networks Design and Modeling, 
pp:16-22. 2012.
[2] L. Csikor, G. Retvari, "On Providing Fast Protection with Remote 
Loop-Free Alternates: Analyzing and Optimizing Unit Cost Networks", 
submitted to Telecommunications Systems Journal, 2012.

P.S.: I already tried to contact one of the authors directly (by email), 
but no answers were received. That's why I send this message to the 
list. I have never post any message to these mailing lists and I hope I 
did not spamming it.

---

From: Alia Atlas <[email-masked]>
Date: Wed, 26 Jun 2013 10:15:03 -0400

Hi Levente,

Welcome!  Your email is certainly on-topic and generally appropriate.
I think it also serves as a useful reminder that many who read our drafts
benefit from
clearly specified conditions and algorithms.

Alia (WG chair hat on)

On Wed, Jun 26, 2013 at 9:13 AM, Levente Csikor <[email-masked]> wrote:

> but no answers were received. That's why I send this message to the list. I
> have never post any message to these mailing lists and I hope I did not
> spamming it.
>

---

From: Acee Lindem <[email-masked]>
Date: Wed, 26 Jun 2013 16:19:35 +0000

Hi Levente,
Thanks for your formal specification of the Remote-LFA constraints - I think the draft could benefit from this level of specification. See a couple questions inline.

On Jun 26, 2013, at 9:13 AM, Levente Csikor wrote:

Dear All,
we've been analyzing and dealing with Remote LFA (rLFA for short) more than 1 year ago. As a first approach, we analyzed only unit costs networks with single link failures, and our results are summarized in [1]. Furthermore, we extended our work with node failures, which can be found in [2]. Since, in the first version of the rLFA Draft, it was not clearly explained that whether the usage of extended P-space involves additional complexity or not, we divided our analyses into two cases. In the first case, only P-space is available for finding possible PQ-nodes (link-protecting remote LFA), while in the second case, extended P-space was also considered (extended link-protecting remote LFA). Since we found that remote LFA with extended P-spaces provides 100% failure case coverage in all unit cost network against single link failures, our separated analyses were also helpful. (However, we proved that if node protection is also considered, then unit cost networks are not fully protected.)

As Alia commented recently on the algorithm description in Sec. 4.2.1 and Sec. 4.2.2. before, we also think that  a more formal algorithm description is necessary, especially, when P-spaces and Q-space are defined with cost functions similarly as defined in LFA FRR. From a routing point of view, I think, it would be easier to understand and calculate these spaces (P,ext.P,Q) if they were defined with distance functions.

Fortunately, the authors of Remote LFA Draft do not have to resolve these issues on their own, since we already defined them in our relevant papers.
In order to not to read our full papers and searching the answers, I copied here the relevant parts:
Link-protecting rLFA condition:
For source s, destination d, and next-hop e, some node n != s,d is a link-protecting remote LFA for the s-d pair  if and only if
  dist(s, n) < dist(s, e) + dist(e, n)  (1)
  dist(n, d) < dist(n, s) + dist(s, d)  (2)
In these equations, one can easily see, that (1) defines the P-space, while (2) is the condition of Q-space. Furthermore, with these formalized conditions, one can easily observe, that (2) is actually the basic loop-free criterion of pure LFA.

Link-protecting rLFA condition with extended P-space:
For source s, destination d, and next-hop e, some node n != s,d is an extended link-protecting remote LFA for the s-d pair if and only if
∃v ∈ neigh(s) : dist(v, n) < dist(v, s) + dist(s, e) + dist(e, n)

I guess in this equation , v is the neighbor satisfying the condition - correct? One thing that is confusing is using n for the remote-LFA candidate while in RFC 5286, N is always the neighbor.

dist(n, d) < dist(n, s) + dist(s, d) .

Node-protecting rLFA condition:
For source s, destination d, and next-hop e, some n != s,d is a node-protecting remote LFA for the s-d pair if and only if
dist(s,n) < dist(s,e) + dist(e,n)      (3)
dist(n,d) < dist(n,e) + dist(e,d)     (4)
As it was in the case of link protection, here, (3) defines the P-space, while (4) characterize the Q-space.
Here, two important observations can be made, which are the followings:
 - P-space does not depend on the protection scheme (i.e., link or node protection)
 - (4) again is the basic node-protecting loop-free criterion of pure LFA.

Node-protecting rLFA condition with extended P-space:
For source s, destination d, and next-hop e, some node n != s,d is an extended node-protecting remote LFA for the s-d pair if and only if
∃v ∈ neigh(s) : dist(v, n) < dist(v, e) + dist(e, n)

Isn't the condition above sufficient? The condition below is not easy to obtain since one normally doesn't have the dist(n, e) when n is being considered as a candidate remote LFA.

dist(n, d) < dist(n, e) + dist(e, d) .

Despite the fact that we only considered unit cost networks, the formal definitions above are true for any arbitrary weighted network.

I have to emphasize and thank the authors that in the second version of the rLFA draft, it became more clear how MPLS LDP label stack can provide the necessary "tunneling" for reaching remote LFA staging points, which answered me a lot of questions.
However, there is something in which I still not sure. As far as I know(, from the draft), reaching PQ-nodes in MPLS/LDP enabled network, two labels are necessary for the source node to avoid the failed component. An outer label, which is the label of S's neighbor for sending traffic to the PQ-node, while the inner label is the PQ node's label for reaching the destination. However, in this MPLS/LDP point of view, is there any difference between the label stacks used to reach a PQ-node in the case of simple P-space or extended P-space, or the are the same?

Yes. The missing piece is that one must assume that LDP is following the LFA repair for the extended P-space to be used in conjunction with LDP remote LFA tunneling.

Thanks,
Acee

On the other hand, according to the MPLS LDP specification (RFC 5036), the targeted LDP capability may be disabled at the routers, which indicates that the simple label stacks cannot be always used to destine packets to a PQ-node, therefore IP tunneling (e.g., IP-in-IP, GRE) should be used to reach the same end. Is it an issue nowadays, or these are already addressed?

Additionally, for Sec. 9.3., we also have measured coverages of rLFA in real-world topologies inferred from Rocketfuel dataset, SNDLib and Topology-zoo, and we compared them to pure LFA coverages as well. These results can be found in our papers, which may be used in this draft.

We think that our results could be a crystallization for some aspects of remote LFA and may be used in the draft.
We also believe that the above mentioned more formal descriptions of P- and Q-spaces and their connectivities to pure LFA can definitely ease the understanding of how remote LFA works, especially for those who has experience in simple LFA.

If you decide to use our results, please mention our works somehow in the document (e.g., references, acknowledgements)

Best regards,
Levente Csikor
Ph.D. Student

[1] L. Csikor, G. Retvari, "IP Fast Reroute with Remote Loop-Free Alternates: the Unit Link Cost Case", In: Proceeding of RNDM 2012 4th International Workshop on Reliable Networks Design and Modeling, pp:16-22. 2012.
[2] L. Csikor, G. Retvari, "On Providing Fast Protection with Remote Loop-Free Alternates: Analyzing and Optimizing Unit Cost Networks", submitted to Telecommunications Systems Journal, 2012.

P.S.: I already tried to contact one of the authors directly (by email), but no answers were received. That's why I send this message to the list. I have never post any message to these mailing lists and I hope I did not spamming it.

Hi Stewart,

See inline.

On 6/20/13 6:59 AM, "Stewart Bryant" <[email-masked]><mailto:[email-masked]> wrote:

This has been addressed.

Thanks,
Acee

We have added some text

Done

- Stewart

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

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

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 26 Jun 2013 19:01:04 +0100

On 26/06/2013 14:13, Levente Csikor wrote:
> [1]. Furthermore, we extended our work with node failures, which can 
> be found in [2]. Since, in the first version of the rLFA Draft, it was 
> not clearly explained that whether the usage of extended P-space 
> involves additional complexity or not, we divided our analyses into 
> two cases. In the first case, /only P-space/ is available for finding 
> possible PQ-nodes (link-protecting remote LFA), while in the second 
> case, /extended P-space/ was also considered (extended link-protecting 
> remote LFA). Since we found that /remote LFA with extended P-spaces 
> provides 100% failure case coverage in all unit cost network against 
> single link failures/, our separated analyses were also helpful. 
> (However, we proved that if node protection is also considered, then 
> unit cost networks are not fully protected.)
Yes, I think that this was all in the earlier draft 
(draft-bryant-ipfrr-tunnels), or at least I assumed it was, we certainly 
thought about it a lot at the time. The real difficulty in the original 
case with nodes occurred because of an effect that we called 
interference. Now that we have the SR approaches, the best way forward 
seems to attempt a directed forward rlfa and if that does not work then 
use SR to get round the node or the high cost link.

> calculate these /spaces/ (P,ext.P,Q) if they were defined with 
> distance functions.
I think the issue is that we think about the problem in rather different 
ways.

I never think about this in terms of costs but rather in terms of the 
two abstract spaces (P and Q) which pop out of a a pair of black box SPF 
calculation which we explain in the draft. So whilst what you say below 
is true and is one way of doing the calculation, it is not the only way 
to do it, and the method of doing the calculation is surely up to the 
implementer since there are no interoperability issues. The loop free 
property of any path in P and in Q space is intrinsic to their definition.

Let me work though the math below with the other authors and see what we 
come up with.

> these issues on their own, since we already defined them in our 
> relevant papers.
> formalized conditions, one can easily observe, that (2) is actually 
> the basic loop-free criterion of pure LFA.
>
> For source /s/, destination /d/, and next-hop /e/, some node /n != 
> s,d/ is an extended link-protecting remote LFA for the /s-d/ pair if 
> and only if
> For source /s/, destination /d/, and next-hop /e/, some /n != s,d/ is 
> a node-protecting remote LFA for the /s-d/ pair if and only if
> As it was in the case of link protection, here, (3) defines the 
> P-space, while (4) characterize the Q-space.
> For source /s/, destination /d/, and next-hop /e/, some node /n != 
> s,d/ is an extended node-protecting remote LFA for the /s-d/ pair if 
> and only if
> Despite the fact that we only considered unit cost networks, the 
> formal definitions above are *true for any arbitrary weighted network.*
>
>
> I have to emphasize and thank the authors that in the second version 
> of the rLFA draft, it became more clear how MPLS LDP label stack can 
> label for reaching the destination. 
Correct.
> However, in this MPLS/LDP point of view, is there any difference 
> between the label stacks used to reach a PQ-node in the case of simple 
> P-space or extended P-space, or the are the same?
They are the same. The repairing router can always force the first hop 
since it gets to choose the output interface.
> indicates that the simple label stacks cannot be always used to 
> destine packets to a PQ-node, therefore IP tunneling (e.g., IP-in-IP, 
> GRE) should be used to reach the same end. Is it an issue nowadays, or 
> these are already addressed?
It is our assumption that IP tunneling of MPLS is not needed, and that 
if you want to use RLFA you need to enable MPLS on the whole path. That 
is quite a normal way to set networks up.
>
>
> Additionally, for Sec. 9.3., we also have measured coverages of rLFA 
> in real-world topologies inferred from Rocketfuel dataset, SNDLib and 
> Topology-zoo, and we compared them to pure LFA coverages as well. 
> These results can be found in our papers, which may be used in this draft.
>
>
Thanks - can I get a copy of the papers please.
>
>
> We think that our results could be a crystallization for some aspects 
> of remote LFA and may be used in the draft.
> We also believe that the above mentioned more formal descriptions of 
> P- and Q-spaces and their connectivities to pure LFA can definitely 
> ease the understanding of how remote LFA works, especially for those 
> who has experience in simple LFA.
Let me work though it with the other authors. As I note above I have 
always used a completely different mental model for this, and I would be 
interested in the thoughts of the WG.

> the document (e.g., references, acknowledgements)
Yes of course we will.

Stewart

> P.S.: I already tried to contact one of the authors directly (by 
> email), but no answers were received. That's why I send this message 
> to the list. I have never post any message to these mailing lists and 
> I hope I did not spamming it.
>
>
>> On 6/20/13 6:59 AM, "Stewart Bryant"<[email-masked]>  wrote:
>>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Levente Csikor <[email-masked]>
Date: Thu, 27 Jun 2013 09:51:16 +0200

Dear Acee,
see my answers inline:

>> /∃v ∈ neigh(s) : dist(v, n) < dist(v, s) + dist(s, e) + dist(e, n)///
>
> I guess in this equation , v is the neighbor satisfying the condition 
> - correct? One thing that is confusing is using n for the remote-LFA 
> candidate while in RFC 5286, N is always the neighbor.
Yes, you have right about /v/. I forgot to emphasize that /neigh(s)/ 
means the set of nodes, which are the neighbors of /s/.
We also thought that /n/ might be confusing, but in LFA /n/ was not only 
a neighbor, since it could be an LFA. This comes from the fact that in 
LFA only neighbors could be used to reroute the traffic to a detour. 
That's why we used /n/ for these direct or non-direct(remote) neighbors, 
which may be possible rLFA candidate, and what is more, using /n /in the 
distance functions corresponds to the distance functions used in LFA RFC 
5286.

>> /∃v ∈ neigh(s) : dist(v, n) < dist(v, e) + dist(e, n)/
>
> Isn't the condition above sufficient? The condition below is not easy 
> to obtain since one normally doesn't have the dist(n, e) when n is 
> being considered as a candidate remote LFA.
>
These conditions are sufficient and necessary.

>> know(, from the draft), reaching PQ-nodes in MPLS/LDP enabled 
>> network, two labels are necessary for the source node to avoid the 
>> failed component. An outer label, which is the label of S's neighbor 
>> for sending traffic to the PQ-node, while the inner label is the PQ 
>> node's label for reaching the destination. However, in this MPLS/LDP 
>> point of view, is there any difference between the label stacks used 
>> to reach a PQ-node in the case of simple P-space or extended P-space, 
>> or the are the same?
>
> Yes. The missing piece is that one must assume that LDP is following 
> the LFA repair for the extended P-space to be used in conjunction with 
> LDP remote LFA tunneling.
>
> Thanks,
> Acee
>
>
>
>>
>>
>> On the other hand, according to the MPLS LDP specification (RFC 
>> 5036), the targeted LDP capability may be disabled at the routers, 
>> which indicates that the simple label stacks cannot be always used to 
>> GRE) should be used to reach the same end. Is it an issue nowadays, 
>> or these are already addressed?
>>
>>

---

From: Levente Csikor <[email-masked]>
Date: Thu, 27 Jun 2013 09:59:03 +0200

Dear Stewart,
My previous email may not arrive, since I attached our papers, which 
involved a big message body.
I uploaded these papers to here:
http://csikor.tmit.bme.hu/remoteLFA/

Since,[2] (remote_lfa_telsys.pdf) is an extended journal version of 
[1](remoteLFA.pdf), everything, which was mentioned in [1] is also 
repeated in [2].

Regards,
Levente

On 06/26/2013 08:01 PM, Stewart Bryant wrote:
>> we've been analyzing and dealing with Remote LFA (rLFA for short) 
>> more than 1 year ago. As a first approach, we analyzed only unit 
>> costs networks with single link failures, and our results are 
>> summarized in [1]. Furthermore, we extended our work with node 
>> failures, which can be found in [2]. Since, in the first version of 
>> the rLFA Draft, it was not clearly explained that whether the usage 
>> of extended P-space involves additional complexity or not, we divided 
>> our analyses into two cases. In the first case, /only P-space/ is 
>> available for finding possible PQ-nodes (link-protecting remote LFA), 
>> while in the second case, /extended P-space/ was also considered 
>> (extended link-protecting remote LFA). Since we found that /remote 
>> LFA with extended P-spaces provides 100% failure case coverage in all 
>> unit cost network against single link failures/, our separated 
>> analyses were also helpful. (However, we proved that if node 
>> protection is also considered, then unit cost networks are not fully 
>> protected.)
> (draft-bryant-ipfrr-tunnels), or at least I assumed it was, we 
> certainly thought about it a lot at the time. The real difficulty in 
> the original case with nodes occurred because of an effect that we 
> called interference. Now that we have the SR approaches, the best way 
> forward seems to attempt a directed forward rlfa and if that does not 
> work then use SR to get round the node or the high cost link.
>
>>
> I think the issue is that we think about the problem in rather 
> different ways.
>
> two abstract spaces (P and Q) which pop out of a a pair of black box 
> SPF calculation which we explain in the draft. So whilst what you say 
> below is true and is one way of doing the calculation, it is not the 
> only way to do it, and the method of doing the calculation is surely 
> up to the implementer since there are no interoperability issues. The 
> loop free property of any path in P and in Q space is intrinsic to 
> their definition.
>
> Let me work though the math below with the other authors and see what 
> we come up with.
>
>>
>> node's label for reaching the destination. 
> Correct.
>> between the label stacks used to reach a PQ-node in the case of 
>> simple P-space or extended P-space, or the are the same?
> if you want to use RLFA you need to enable MPLS on the whole path. 
> That is quite a normal way to set networks up.
>>
>>
> always used a completely different mental model for this, and I would 
> be interested in the thoughts of the WG.
>
>>

---

From: Levente Csikor <[email-masked]>
Date: Thu, 27 Jun 2013 09:54:09 +0200

Dear Stewart,
yes, I indeed forgot to attach our papers:)

Regards,
Levente