Subject: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt

From: Jeff Tantsura <[email-masked]>
Date: Tue, 1 Oct 2013 18:07:42 +0000

Hi,

Question to the authors of the draft about their intentions, obviously the
basic node protection equation(D_opt(Npq, Dst) < D_opt(Npq, Np) +
Distance_opt(Np, Dst)) is correct, however the rest is more or less
implementation details.
So if the authors would like to share the details about their
implementation should not the Intended Status be Informational?

Cheers,
Jeff

>>
>>>Folks,
>>>
>>>Does anyone know whether the draft deal will be treated in the IETF 88?
>>>
>>>Regards,
>>>
>>>Rogerio Mariano
>>>
>>>
>>>
>>>
>>>--
>>>View this message in context:
>>>http://ietf.10.n7.nabble.com/Request-for-review-draft-psarkar-rtgwg-rlfa
>>>-
>>>n
>>>ode-protection-01-txt-tp375714p386321.html
>>>Sent from the IETF - Rtgwg mailing list archive at Nabble.com.
>>>_______________________________________________
>>>rtgwg mailing list
>>>[email-masked]
>>>https://www.ietf.org/mailman/listinfo/rtgwg
>>
>

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 2 Oct 2013 10:51:55 +0200

hi jeff,

the single biggest problem with draft-ietf-rtgwg-remote-lfa
is that it leaves a lot of ambiguity how to implement certain
functionality - node-protection, manageability among them.

'the right thing'(™)  would be to fix the rlfa spec,
which somehow seems not possible, so it remains
in the state which it is now … what i call 'underspecified'.

draft-psarkar-rtgwg-rlfa-node-protection is a contribution
coming from a dev-team which had to implement this for
OSPF and IS-IS and make it work altogether.

we got the impression that customers want to use both
node-protection *and* manageability together and as such
you need to do things a certain way which is described in
the draft. IMO thats a bit more than just
'implementation details' but rather a guidance
how to get this right. therefore the intended status is
'proposed standard'.

/hannes

---

From: Alia Atlas <[email-masked]>
Date: Wed, 2 Oct 2013 08:26:18 -0400

It would be excellent to see progress on the Remote LFA draft and on
merging at least the two drafts that describe how to do node-protection for
Remote LFA before the Vancouver IETF.

Alia

---

From: John E Drake <[email-masked]>
Date: Wed, 2 Oct 2013 12:52:50 +0000

What a concept

Yours Irrespectively,

John

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Wednesday, October 02, 2013 5:26 AM
To: Hannes Gredler
Cc: [email-masked]
Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt

It would be excellent to see progress on the Remote LFA draft and on merging at least the two drafts that describe how to do node-protection for Remote LFA before the Vancouver IETF.

Alia

On Wed, Oct 2, 2013 at 4:51 AM, Hannes Gredler <[email-masked]<mailto:[email-masked]>> wrote:
hi jeff,

'the right thing'((tm))  would be to fix the rlfa spec,
which somehow seems not possible, so it remains
in the state which it is now ... what i call 'underspecified'.

/hannes

On Oct 1, 2013, at 8:07 PM, Jeff Tantsura wrote:

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

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

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 7 Oct 2013 06:29:35 +0000

Hi Alia/Hannes,

I support very much Alia's position here and would like to see node protection as part of base rlfa spec rather than dev-team HLD pushed as standard track document.
Would be great to see input from all vendors to ensure interoperability.

Thanks!

Cheers,
Jeff

From: Alia Atlas <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 2, 2013 5:26 AM
To: Hannes Gredler <[email-masked]<mailto:[email-masked]>>
Cc: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt

Alia

/hannes

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 7 Oct 2013 06:35:54 +0000

Hi Alia/Hannes,

Thanks!

Cheers,
Jeff

Alia

/hannes

---

From: <[email-masked]>
Date: Mon, 7 Oct 2013 09:10:30 +0200

Agree with the approach of having a single doc.

Stephane Litkowski
FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE
Operational Engineering & Support IPTAC for RAEI network
Orange Expert Network of Future
tél. +33 2 23 28 49 83
mob. +33 6 37 86 97 52
[email-masked]<mailto:[email-masked]>
De : [email-masked] [mailto:[email-masked]] De la part de Jeff Tantsura
Envoyé : lundi 7 octobre 2013 08:36
À : Alia Atlas; Hannes Gredler
Cc : [email-masked]
Objet : Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt

Hi Alia/Hannes,

Thanks!

Cheers,
Jeff

Alia

/hannes

_________________________________________________________________________________________________________________________

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: Hannes Gredler <[email-masked]>
Date: Mon, 7 Oct 2013 14:30:10 +0200

jeff,

i am happy to do this [rlfa single-spec for link and node-protection]
unfortunately the current editor of the rlfa base spec is a bit <cough, cough>
reluctant to incorporate changes for some reason.

IMO there are three roads to fix the problem:

1. keep rlfa, node protection seperate drafts

2. ask the current editor once more to incoporate the node-protection text
   as well as other comments from stephane (e.g. how to signal T-LDP
   preferred transport addresses)

3. ask WG-chairs to assign a new editor to the draft

/hannes

On Mon, Oct 07, 2013 at 06:35:54AM +0000, Jeff Tantsura wrote:
| Hi Alia/Hannes,
| 
| I support very much Alia's position here and would like to see node protection
| as part of base rlfa spec rather than dev-team HLD pushed as standard track
| document.
| Would be great to see input from all vendors to ensure interoperability.
|
| From: Alia Atlas <[email-masked]>
| Date: Wednesday, October 2, 2013 5:26 AM
| To: Hannes Gredler <[email-masked]>
| Cc: Jeff Tantsura <[email-masked]>, &quot;[email-masked]&quot;
| <[email-masked]>
| Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-
| 01.txt
| 
|      It would be excellent to see progress on the Remote LFA draft and on
|      merging at least the two drafts that describe how to do node-
|      protection for Remote LFA before the Vancouver IETF.
| 
|      Alia
| 
| 
|      On Wed, Oct 2, 2013 at 4:51 AM, Hannes Gredler  <[email-masked]>
|      wrote:
|           hi jeff,
| 
|           the single biggest problem with draft-ietf-rtgwg-remote-lfa
|           is that it leaves a lot of ambiguity how to implement
|           certain
|           functionality - node-protection, manageability among them.
| 
|           'the right thing'(™)  would be to fix the rlfa spec,
|           which somehow seems not possible, so it remains
|           in the state which it is now … what i call
|           'underspecified'.
| 
|           draft-psarkar-rtgwg-rlfa-node-protection is a contribution
|           coming from a dev-team which had to implement this for
|           OSPF and IS-IS and make it work altogether.
| 
|           we got the impression that customers want to use both
|           node-protection *and* manageability together and as such
|           you need to do things a certain way which is described in
|           the draft. IMO thats a bit more than just
|           'implementation details' but rather a guidance
|           how to get this right. therefore the intended status is
|           'proposed standard'.
| 
|           /hannes
| 
|           On Oct 1, 2013, at 8:07 PM, Jeff Tantsura wrote:
| 
|           > Hi,
|           >
|           > Question to the authors of the draft about their
|           intentions, obviously the
|           > basic node protection equation(D_opt(Npq, Dst) < D_opt
|           (Npq, Np) +
|           > Distance_opt(Np, Dst)) is correct, however the rest is
|           more or less
|           > implementation details.
|           > So if the authors would like to share the details about
|           their
|           > implementation should not the Intended Status be
|           Informational?
|           >
|           > Cheers,
|           > Jeff
|           >
|           >
|           >>>
|           >>>> Folks,
|           >>>>
|           >>>> Does anyone know whether the draft deal will be
|           treated in the IETF 88?
|           >>>>
|           >>>> Regards,
|           >>>>
|           >>>> Rogerio Mariano
|           >>>>
|           >>>>
|           >>>>
|           >>>>
|           >>>> --
|           >>>> View this message in context:
|           >>>> http://ietf.10.n7.nabble.com/Request-for-review-draft-
|           psarkar-rtgwg-rlfa
|           >>>> -
|           >>>> n
|           >>>> ode-protection-01-txt-tp375714p386321.html
|           >>>> Sent from the IETF - Rtgwg mailing list archive at
|           Nabble.com.
|           >>>> _______________________________________________
|           >>>> rtgwg mailing list
|           >>>> [email-masked]
|           >>>> https://www.ietf.org/mailman/listinfo/rtgwg
|           >>>
|           >>
|           >
|           > _______________________________________________
|           > rtgwg mailing list
|           > [email-masked]
|           > https://www.ietf.org/mailman/listinfo/rtgwg
|           >
|           >
| 
| 
|           _______________________________________________
|           rtgwg mailing list
|           [email-masked]
|           https://www.ietf.org/mailman/listinfo/rtgwg
|

---

From: <[email-masked]>
Date: Tue, 8 Oct 2013 13:33:47 +0200

Hi,

IMHO, it would make sense to wait maybe until IETF89 to decide about merging node protect with basic rLFA spec.
I think we could progress quite fast on node protection and two IETF meetings (88, 89) would be fine to have a good view and where we are on node protection maturity. Then we may decide if merge is possible or not. These two meetings would also permit to stabilize the rLFA base spec details and have consensus on the required level of details that are missing today.

I think now it's a bit early to decide ...

Feedbacks ? especially from chairs ?

---
Stephane

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Hannes Gredler
Envoyé : lundi 7 octobre 2013 14:30
À : Jeff Tantsura
Cc : [email-masked]
Objet : Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt

jeff,

i am happy to do this [rlfa single-spec for link and node-protection] unfortunately the current editor of the rlfa base spec is a bit <cough, cough> reluctant to incorporate changes for some reason.

/hannes

| I support very much Alia's position here and would like to see node 
| protection as part of base rlfa spec rather than dev-team HLD pushed 
| as standard track document.
| Cc: Jeff Tantsura <[email-masked]>, 
| &quot;[email-masked]&quot; <[email-masked]>
| Subject: Re: Request for review - 
| draft-psarkar-rtgwg-rlfa-node-protection-

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 8 Oct 2013 15:00:59 +0000

On 10/8/13 7:33 AM, "[email-masked]"
<[email-masked]> wrote:

>IMHO, it would make sense to wait maybe until IETF89 to decide about
>merging node protect with basic rLFA spec.
>I think we could progress quite fast on node protection and two IETF
>meetings (88, 89) would be fine to have a good view and where we are on
>node protection maturity. Then we may decide if merge is possible or not.
>These two meetings would also permit to stabilize the rLFA base spec
>details and have consensus on the required level of details that are
>missing today.
>

Hi!

I agree that we need to first work on the node protection topic *before*
thinking about whether that should be merged onto the "basic rLFA spec".
There's not much point in arguing on where the text should go if we
haven't agreed on that first.

Also, we need to be conscious of the balance of progressing work vs
waiting for additional topics to be included in a draft.  This is not a
statement one way or another, but the estimated timeline above really puts
us a year from now.  OTOH, the discussions on the "basic spec" are still
ongoing (as to this morning) as well.

Alvaro.

---

From: Levente Csikor <[email-masked]>
Date: Wed, 09 Oct 2013 10:30:09 +0200

Dear All,
I also support to work more on the node protection draft first, before 
merging it with "basic rLFA spec", because of various reasons:

First, I think it would be almost a good approach to show how 
node-protecting remote LFA works on the same, or almost the same sample 
network topology used in the basic rLFA spec., but for easier and more 
comprehensive understanding, a bit more complex but still simple example 
should be given. IMHO, in the basic rLFA spec. it is a bit confusing 
that node E is considered as a destination and this node is the next-hop 
as well, since the important parts of the different roles are not 
dissevering enough. Because of this, the similar example in node prot 
spec. is also not straightforward:

"In the event of the node-failure on primary nexthop E, the alternate 
path from Remote-LFA nexthop C to E and F also becomes unavailable."

According to the well-known last-hop problem, it is obvious that if the 
destination (in the first case: node E) goes down, then it cannot be 
protected. Moreover, since the example network topologyis not
2-node-connected, it is obvious again that the node F, which can be 
accessed only via node E, then the failure of node E infers that the 
node F can be never reached.
To (re)solve this issue, I suggest to use another network (in the basic 
rLFA spec. as well), which could be the following (all link costs are 
unit costs):

A----------B---------C
|          |       / |
|          |      /  |
|          |     /   |
F          G    /    H
|          |   /     |
|          |  /      |
|          | /       |
D----------E---------S

In this case, assuming that source node S wants to send a packet to node 
D, the next-hop of S is node E.
  - Link protecting case: If link(s,e) fails, then P-space of node S 
regarding to the failed link, would consist of node H,C,B and A, whilst 
the Q-space of D would consist all nodes except S and H. In this case, 
the PQ-nodes, as the possible repair tunnel endpoints, are node A,B and C.
  - Node protecting case: However, if node E itself fails, then the 
P-space of S would not alter, but the Q-space of D would only contain 
node F and A resulting that only node A is present in the set of PQ-nodes.
I think that this network also shows the different between the node 
protection and link protection, but in a more comprehensive manner. And 
it also demonstrates the fact mentioned in Figure 2 that for 
node-protecting rLFA, only the Q-spaces should be checked with those 
distance functions.

Moreover, if we assume that in the example network above, there is a 
link (A,E) and node E itself failed again, than PQ-space would be and 
empty set meaning that this case cannot be protected.

Second, it would be better in the draft if the questions about "how 
difficult or impossible to obtain those distances" would be clearly 
stated in a bullet point list:
For example:
  - Q-space can be obtained by rSPF calculated at destination node D
  - P-space can be obtained through SPF calculation at source node S and 
its 1-hop neighbor.
  - SPF at a PQ-node is impossible or if not what extensions should be 
implemented (actually, IMHO, this is the one, which is not clear enough)

Third, according to the Targeted-LDP discussion, which is about the fact 
that if some node do not support TLDP, then how can be the inner MPLS 
label obtained from the PQ-node; I think that if we want remote LFA 
protection then the nodes MUST implement/support this feature, because 
without this the protection cannot be guaranteed. For me, it is similar 
to a hypothetic case for example of Not-via, where if the router do not 
support Not-via, then it cannot be used. Or isn't it so simple?

Please comment my observations, in order to help me and may others as 
well to understand every aspects and little pieces of remote LFA 
specifications.

Best Regards,
Levente Csikor

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 9 Oct 2013 10:49:35 +0000

Hi Levente,

Please find few comments inline...

Thanks

-Pushpasis

-----Original Message-----
From: Levente Csikor [mailto:[email-masked]]
Sent: Wednesday, October 09, 2013 2:00 PM
To: [email-masked]
Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt

Dear All,

I also support to work more on the node protection draft first, before merging it with "basic rLFA spec", because of various reasons:

First, I think it would be almost a good approach to show how node-protecting remote LFA works on the same, or almost the same sample network topology used in the basic rLFA spec., but for easier and more comprehensive understanding, a bit more complex but still simple example should be given. IMHO, in the basic rLFA spec. it is a bit confusing that node E is considered as a destination and this node is the next-hop as well, since the important parts of the different roles are not dissevering enough. Because of this, the similar example in node prot spec. is also not straightforward:

[Pushpasis] If you see Table 1,2, and 3 in draft-psarkar-rtgwg-rlfa-node-protection-01 we have specified the destinations E, F (and their corresponding RLFA backup paths explicitly), that will be affected by node-failure of E. Also the destination G has been included which will still be reachable in the case of node-failure of E. Perhaps basic RLFA spec can also include such kind of illustrations

"In the event of the node-failure on primary nexthop E, the alternate path from Remote-LFA nexthop C to E and F also becomes unavailable."

[Pushpasis] That is exactly we are also saying in this draft(I mean draft-psarkar-rtgwg-rlfa-node-protection-01).. If any destination takes the shortest-path segment C...E that will not have node-protection using C as the PQ node, because C is going to forward the traffic to E anyhow. In Table 2 we see that the path segment C->D->E is included in the shortest path from C to E and F. That is why in case of node-failure of E, E and F cannot provide node-protection

According to the well-known last-hop problem, it is obvious that if the destination (in the first case: node E) goes down, then it cannot be protected. Moreover, since the example network topologyis not 2-node-connected, it is obvious again that the node F, which can be accessed only via node E, then the failure of node E infers that the node F can be never reached.

To (re)solve this issue, I suggest to use another network (in the basic rLFA spec. as well), which could be the following (all link costs are unit costs):

A----------B---------C

|          |       / |

|          |      /  |

|          |     /   |

F          G    /    H

|          |   /     |

|          |  /      |

|          | /       |

D----------E---------S

In this case, assuming that source node S wants to send a packet to node D, the next-hop of S is node E.

  - Link protecting case: If link(s,e) fails, then P-space of node S regarding to the failed link, would consist of node H,C,B and A, whilst the Q-space of D would consist all nodes except S and H. In this case, the PQ-nodes, as the possible repair tunnel endpoints, are node A,B and C.

  - Node protecting case: However, if node E itself fails, then the P-space of S would not alter, but the Q-space of D would only contain node F and A resulting that only node A is present in the set of PQ-nodes.

[Pushpasis] Can you elaborate on the method you used for deriving the PQ-nodes A and F here... Seems to me like you are doing a RSPF rooted on destination D and then pruning all links originating from E... I think Chris Bowers has already pointed on a different thread that while best way to guarantee node-protection is to run a RSPF rooted on each destination, we cannot afford to do so in reality... It will be much more feasible to run FSPF on fewer PQ-nodes as specified in our draft..

Also, the method specified by our draft also finds A as the node-protecting PQ-node, becoz the draft suggest to find the shortest-path from the PQ-nodes (C, B, and A) to destination D. Only the SPF path from A does not go through E, so only A will provide node-protection for D.

I think that this network also shows the different between the node protection and link protection, but in a more comprehensive manner. And it also demonstrates the fact mentioned in Figure 2 that for node-protecting rLFA, only the Q-spaces should be checked with those distance functions.

Moreover, if we assume that in the example network above, there is a link (A,E) and node E itself failed again, than PQ-space would be and empty set meaning that this case cannot be protected.

[Pushpasis] True. Our draft will also pick A->E->D as the SPF from A to D in that case and disqualify A as node-protecting PQ-node. In reality too there is no feasible path in this case till A re-converges after learning E's node-failure

Second, it would be better in the draft if the questions about "how difficult or impossible to obtain those distances" would be clearly stated in a bullet point list:

For example:

  - P-space can be obtained through SPF calculation at source node S and its 1-hop neighbor.

  - SPF at a PQ-node is impossible or if not what extensions should be implemented (actually, IMHO, this is the one, which is not clear enough)

[Pushpasis] The first two should really be addressed in the original RLFA draft. Chris has already written to the authors on this mailing list with suggesting text for the draft. The third one is no different than standard SPF we need for RFC5286 implementation.. only difference being that it is rooted on PQ-nodes  in case of RLFA... It is up to individual implementations to come up with ways to constraint those to a limit.

Third, according to the Targeted-LDP discussion, which is about the fact that if some node do not support TLDP, then how can be the inner MPLS label obtained from the PQ-node; I think that if we want remote LFA protection then the nodes MUST implement/support this feature, because without this the protection cannot be guaranteed. For me, it is similar to a hypothetic case for example of Not-via, where if the router do not support Not-via, then it cannot be used. Or isn't it so simple?

[Pushpasis] Again this is more related to original RLFA draft. I will prefer the corresponding authors to address this point :)

Please comment my observations, in order to help me and may others as well to understand every aspects and little pieces of remote LFA specifications.

Best Regards,

Levente Csikor

---

From: Levente Csikor <[email-masked]>
Date: Wed, 09 Oct 2013 13:46:36 +0200

Dear Pushpasis,
thanks for your comments.
For reactions see mine inline:

On 10/09/2013 12:49 PM, Pushpasis Sarkar wrote:
> Subject: Re: Request for review - 
> draft-psarkar-rtgwg-rlfa-node-protection-01.txt
>
> Dear All,
>
> node-protecting remote LFA works on the same, or almost the same 
> sample network topology used in the basic rLFA spec., but for easier 
> and more comprehensive understanding, a bit more complex but still 
> simple example should be given. IMHO, in the basic rLFA spec. it is a 
> bit confusing that node E is considered as a destination and this node 
> is the next-hop as well, since the important parts of the different 
> roles are not dissevering enough. Because of this, the similar example 
> in node prot spec. is also not straightforward:
>
> *[Pushpasis] If you see Table 1,2, and 3 in 
> draft-psarkar-rtgwg-rlfa-node-protection-01 we have specified the 
> destinations E, F (and their corresponding RLFA backup paths 
> explicitly), that will be affected by node-failure of E. Also the 
> destination G has been included which will still be reachable in the 
> case of node-failure of E. Perhaps basic RLFA spec can also include 
> such kind of illustrations*
>
**Yeah, I know and there is also the entry in the back-up path column 
for G, but here, I wanted to emphasized that the connectedness of the 
network does not remain any other opportunities to be considered.
In other words, if there were an additional node between F and G, say H, 
and nodes E-D-G-H-F would also form a 5-cycle, then all your claims will 
remain valid, since C's shortest path to F won't avoid the failed node 
E, but the graph-topological requirements would be not so confusing 
(maybe only for me :) , but when I analyze a network to calculate the 
rLFA protection coverage, then I always assume this basic graph 
topological property to easily derive the level of protection (in 
percent, for example) of the possible attainable 100%).
> **
> *[Pushpasis] That is exactly we are also saying in this draft(I mean 
> draft-psarkar-rtgwg-rlfa-node-protection-01).. If any destination 
> takes the shortest-path segment C...E that will not have 
> node-protection using C as the PQ node, because C is going to forward 
> the traffic to E anyhow. In Table 2 we see that the path segment 
> C->D->E is included in the shortest path from C to E and F. That is 
> why in case of node-failure of E, E and F cannot provide node-protection*
>
**It was a quote from the draft, so it is really the fact that you are 
saying :)
>
> According to the well-known last-hop problem, it is obvious that if 
> the destination (in the first case: node E) goes down, then it cannot 
> be protected. Moreover, since the example network topologyis not 
> To (re)solve this issue, I suggest to use another network (in the 
> basic rLFA spec. as well), which could be the following (all link 
> costs are unit costs):
>
> A----------B---------C
>
> |          |       / |
>
> |          |      /  |
>
> |          |     /   |
>
> F          G    /    H
>
> |          |   /     |
>
> |          |  /      |
>
> |          | /       |
>
> D----------E---------S
>
> regarding to the failed link, would consist of node H,C,B and A, 
> whilst the Q-space of D would consist all nodes except S and H. In 
> this case, the PQ-nodes, as the possible repair tunnel endpoints, are 
> node A,B and C.
>
> *[Pushpasis] Can you elaborate on the method you used for deriving the 
> PQ-nodes A and F here... Seems to me like you are doing a RSPF rooted 
> on destination D and then pruning all links originating from E... I 
> think Chris Bowers has already pointed on a different thread that 
> while best way to guarantee node-protection is to run a RSPF rooted on 
> each destination, we cannot afford to do so in reality... It will be 
> much more feasible to run FSPF on fewer PQ-nodes as specified in our 
> draft..*
>
**I did not consider any possible way of determining PQ-nodes, only used 
the description of P and Q spaces from the original draft, and from my 
research on this topic, where every kind of spaces were defined in cost 
terms to easily analyze the network theoretically.
>
> **
>
> **
>
> *Also, the method specified by our draft also finds A as the 
> node-protecting PQ-node, becoz the draft suggest to find the 
> shortest-path from the PQ-nodes (C, B, and A) to destination D. Only 
> the SPF path from A does not go through E, so only A will provide 
> node-protection for D.*
>
> protection and link protection, but in a more comprehensive manner. 
> And it also demonstrates the fact mentioned in Figure 2 that for 
> *[Pushpasis] True. Our draft will also pick A->E->D as the SPF from A 
> to D in that case and disqualify A as node-protecting PQ-node. In 
> reality too there is no feasible path in this case till A re-converges 
> after learning E's node-failure*
>
**I know that it is true, I just wanted to say that by this network, the 
case of absence of node protection could be demonstrated easily assuming 
that the main example was the network described above.
> *[Pushpasis] The first two should really be addressed in the original 
> RLFA draft. Chris has already written to the authors on this mailing 
> list with suggesting text for the draft. The third one is no different 
> than standard SPF we need for RFC5286 implementation.. only difference 
> being that it is rooted on PQ-nodes  in case of RLFA... It is up to 
> individual implementations to come up with ways to constraint those to 
> a limit. *
>
**Thanks
>
> Third, according to the Targeted-LDP discussion, which is about the 
> fact that if some node do not support TLDP, then how can be the inner 
> MPLS label obtained from the PQ-node; I think that if we want remote 
> LFA protection then the nodes MUST implement/support this feature, 
> because without this the protection cannot be guaranteed. For me, it 
> is similar to a hypothetic case for example of Not-via, where if the 
> router do not support Not-via, then it cannot be used. Or isn't it so 
> simple?
>
> *[Pushpasis] Again this is more related to original RLFA draft. I will 
> prefer the corresponding authors to address this point **J*
>
**Thanks
> **

Thanks,

Levente Csikor

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 9 Oct 2013 14:28:48 +0000

Hi Levente,

"I did not consider any possible way of determining PQ-nodes, only used the description of P and Q spaces from the original draft, and from my research on this topic, where every kind of spaces were defined in cost terms to easily analyze the network theoretically."

The original Q-space definition is...
"the set of routers which can reach the primary neighbor E can without traversing the link (S-E) being protected"

What will the definition for Q-space definition in this case? Do you mean...
" the set of routers than can reach the primary neighbor E without traversing any links originating from E"? That will leave no routers in the set.. Right?

What makes sense is "the set of routers that can reach destination without traversing any links originating/attached to E".... For doing that we will have two options

1.       RSPF rooted on the destination (will be very expensive if we have to do that for every destination node in the network)..  OR

2.       FSPF rooted on the PQ-node and check if primary neighbor E is on the SPF path from PQ-node to destination.. This is what is specified in our draft.. Assuming number of PQ-nodes are far less than number of nodes in the network this approach looked more feasible. Also now we are able to collect full path attributes for RLFA backup paths for LFA-manageability. Also RLFA does not attempt to provide 100% coverage. So like already said, implementations can decide to only consider upto a certain number of PQ-nodes to be considered in the whole network to limit the number of extra FSPFs to be computed.

Thanks
-Pushpasis

From: Levente Csikor [mailto:[email-masked]]
Sent: Wednesday, October 09, 2013 5:17 PM
To: Pushpasis Sarkar
Cc: [email-masked]; Chris Bowers
Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt

Dear Pushpasis,

Hi Levente,

Thanks

-Pushpasis

-----Original Message-----
From: Levente Csikor [mailto:[email-masked]]
Sent: Wednesday, October 09, 2013 2:00 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt

Dear All,

[Pushpasis] If you see Table 1,2, and 3 in draft-psarkar-rtgwg-rlfa-node-protection-01 we have specified the destinations E, F (and their corresponding RLFA backup paths explicitly), that will be affected by node-failure of E. Also the destination G has been included which will still be reachable in the case of node-failure of E. Perhaps basic RLFA spec can also include such kind of illustrations
    Yeah, I know and there is also the entry in the back-up path column for G, but here, I wanted to emphasized that the connectedness of the network does not remain any other opportunities to be considered.
In other words, if there were an additional node between F and G, say H, and nodes E-D-G-H-F would also form a 5-cycle, then all your claims will remain valid, since C's shortest path to F won't avoid the failed node E, but the graph-topological requirements would be not so confusing (maybe only for me :) , but when I analyze a network to calculate the rLFA protection coverage, then I always assume this basic graph topological property to easily derive the level of protection (in percent, for example) of the possible attainable 100%).

[Pushpasis] That is exactly we are also saying in this draft(I mean draft-psarkar-rtgwg-rlfa-node-protection-01).. If any destination takes the shortest-path segment C...E that will not have node-protection using C as the PQ node, because C is going to forward the traffic to E anyhow. In Table 2 we see that the path segment C->D->E is included in the shortest path from C to E and F. That is why in case of node-failure of E, E and F cannot provide node-protection
    It was a quote from the draft, so it is really the fact that you are saying :)

A----------B---------C

|          |       / |

|          |      /  |

|          |     /   |

F          G    /    H

|          |   /     |

|          |  /      |

|          | /       |

D----------E---------S

[Pushpasis] Can you elaborate on the method you used for deriving the PQ-nodes A and F here... Seems to me like you are doing a RSPF rooted on destination D and then pruning all links originating from E... I think Chris Bowers has already pointed on a different thread that while best way to guarantee node-protection is to run a RSPF rooted on each destination, we cannot afford to do so in reality... It will be much more feasible to run FSPF on fewer PQ-nodes as specified in our draft..
    I did not consider any possible way of determining PQ-nodes, only used the description of P and Q spaces from the original draft, and from my research on this topic, where every kind of spaces were defined in cost terms to easily analyze the network theoretically.

[Pushpasis] True. Our draft will also pick A->E->D as the SPF from A to D in that case and disqualify A as node-protecting PQ-node. In reality too there is no feasible path in this case till A re-converges after learning E's node-failure
    I know that it is true, I just wanted to say that by this network, the case of absence of node protection could be demonstrated easily assuming that the main example was the network described above.

For example:

Best Regards,

Levente Csikor

Thanks,

Levente Csikor

---

From: Levente Csikor <[email-masked]>
Date: Wed, 09 Oct 2013 16:51:11 +0200

To calculate, which nodes are in the Q-space I've just looked fornodes 
for which your distance function in Fig.2. applies.
 From an industrial/implementationpoint of view, I have no exact claim 
how the calculations should be made.

Furthermore, assumingthatonly link failures are consideredin a unit cost 
network (where every link has the same unit cost), then rLFA provides 
100% failure coverage. Note that in this case the minimal graph 
topological requirement is 2-edge-connectivity. That's why I said that 
theoretical investigation of the rLFA node-protecting failure coverage 
needs 2-node-connected networks to suppose that may 100% node-protection 
can be reached.

On 10/09/2013 04:28 PM, Pushpasis Sarkar wrote:
>
> Hi Levente,
>
> "I did not consider any possible way of determining PQ-nodes, only 
> used the description of P and Q spaces from the original draft, and 
> from my research on this topic, where every kind of spaces were 
> defined in cost terms to easily analyze the network theoretically."
>
> "the set of routers which can reach the primary neighbor E can without 
> traversing the link (S-E) being protected"
>
> " the set of routers than can reach the primary neighbor E without 
> traversing any links originating from E"? That will leave no routers 
> in the set.. Right?
>
> What makes sense is "the set of routers that can reach destination 
> without traversing any links originating/attached to E".... For doing 
> that we will have two options
>
> 1.RSPF rooted on the destination (will be very expensive if we have to 
> do that for every destination node in the network)..  OR
>
> 2.FSPF rooted on the PQ-node and check if primary neighbor E is on the 
> SPF path from PQ-node to destination.. This is what is specified in 
> our draft.. Assuming number of PQ-nodes are far less than number of 
> nodes in the network this approach looked more feasible. Also now we 
> are able to collect full path attributes for RLFA backup paths for 
> LFA-manageability. Also RLFA does not attempt to provide 100% 
> coverage. So like already said, implementations can decide to only 
> consider upto a certain number of PQ-nodes to be considered in the 
> whole network to limit the number of extra FSPFs to be computed.
>
> Thanks
>
> -Pushpasis
>
> *From:*Levente Csikor [mailto:[email-masked]]
> *Sent:* Wednesday, October 09, 2013 5:17 PM
> *To:* Pushpasis Sarkar
> *Cc:* [email-masked]; Chris Bowers
> *Subject:* Re: Request for review - 
>     To: [email-masked] <mailto:[email-masked]>
>     I also support to work more on the node protection draft first,
>     before merging it with "basic rLFA spec", because of various reasons:
>
>     sample network topology used in the basic rLFA spec., but for
>     easier and more comprehensive understanding, a bit more complex
>     but still simple example should be given. IMHO, in the basic rLFA
>     spec. it is a bit confusing that node E is considered as a
>     destination and this node is the next-hop as well, since the
>     important parts of the different roles are not dissevering enough.
>     Because of this, the similar example in node prot spec. is also
>     not straightforward:
>
>     destination G has been included which will still be reachable in
>     the case of node-failure of E. Perhaps basic RLFA spec can also
>     include such kind of illustrations*
>
> In other words, if there were an additional node between F and G, say 
> H, and nodes E-D-G-H-F would also form a 5-cycle, then all your claims 
> will remain valid, since C's shortest path to F won't avoid the failed 
> node E, but the graph-topological requirements would be not so 
> confusing (maybe only for me :) , but when I analyze a network to 
> calculate the rLFA protection coverage, then I always assume this 
> basic graph topological property to easily derive the level of 
> protection (in percent, for example) of the possible attainable 100%).
>
>     "In the event of the node-failure on primary nexthop E, the
>     alternate path from Remote-LFA nexthop C to E and F also becomes
>     unavailable."
>
>     *[Pushpasis] That is exactly we are also saying in this draft(I
>     mean draft-psarkar-rtgwg-rlfa-node-protection-01).. If any
>     destination takes the shortest-path segment C...E that will not
>     have node-protection using C as the PQ node, because C is going to
>     forward the traffic to E anyhow. In Table 2 we see that the path
>     segment C->D->E is included in the shortest path from C to E and
>     F. That is why in case of node-failure of E, E and F cannot
>     provide node-protection*
>
>     According to the well-known last-hop problem, it is obvious that
>     if the destination (in the first case: node E) goes down, then it
>     cannot be protected. Moreover, since the example network
>     topologyis not 2-node-connected, it is obvious again that the node
>     F, which can be accessed only via node E, then the failure of node
>     E infers that the node F can be never reached.
>
>       - Link protecting case: If link(s,e) fails, then P-space of node
>     S regarding to the failed link, would consist of node H,C,B and A,
>     this case, the PQ-nodes, as the possible repair tunnel endpoints,
>     are node A,B and C.
>
>       - Node protecting case: However, if node E itself fails, then
>     the P-space of S would not alter, but the Q-space of D would only
>     contain node F and A resulting that only node A is present in the
>     set of PQ-nodes.
>
>     *[Pushpasis] Can you elaborate on the method you used for deriving
>     the PQ-nodes A and F here... Seems to me like you are doing a RSPF
>     rooted on destination D and then pruning all links originating
>     from E... I think Chris Bowers has already pointed on a different
>     thread that while best way to guarantee node-protection is to run
>     a RSPF rooted on each destination, we cannot afford to do so in
>     reality... It will be much more feasible to run FSPF on fewer
>     PQ-nodes as specified in our draft..*
>
> **I did not consider any possible way of determining PQ-nodes, only 
> used the description of P and Q spaces from the original draft, and 
> from my research on this topic, where every kind of spaces were 
> defined in cost terms to easily analyze the network theoretically.
>
>     **
>
>     shortest-path from the PQ-nodes (C, B, and A) to destination D.
>     Only the SPF path from A does not go through E, so only A will
>     provide node-protection for D.*
>
>     I think that this network also shows the different between the
>     node protection and link protection, but in a more comprehensive
>     manner. And it also demonstrates the fact mentioned in Figure 2
>     that for node-protecting rLFA, only the Q-spaces should be checked
>     with those distance functions.
>
>     Moreover, if we assume that in the example network above, there is
>     a link (A,E) and node E itself failed again, than PQ-space would
>     be and empty set meaning that this case cannot be protected.
>
>     *[Pushpasis] True. Our draft will also pick A->E->D as the SPF
>     from A to D in that case and disqualify A as node-protecting
>     PQ-node. In reality too there is no feasible path in this case
>     till A re-converges after learning E's node-failure*
>
> **I know that it is true, I just wanted to say that by this network, 
> the case of absence of node protection could be demonstrated easily 
> assuming that the main example was the network described above.
>
>     Second, it would be better in the draft if the questions about
>     "how difficult or impossible to obtain those distances" would be
>     clearly stated in a bullet point list:
>
>     For example:
>
>       - SPF at a PQ-node is impossible or if not what extensions
>     should be implemented (actually, IMHO, this is the one, which is
>     not clear enough)
>
>     *[Pushpasis] The first two should really be addressed in the
>     original RLFA draft. Chris has already written to the authors on
>     this mailing list with suggesting text for the draft. The third
>     one is no different than standard SPF we need for RFC5286
>     implementation.. only difference being that it is rooted on
>     PQ-nodes  in case of RLFA... It is up to individual
>     implementations to come up with ways to constraint those to a limit. *
>
> **Thanks
>
>     Third, according to the Targeted-LDP discussion, which is about
>     the fact that if some node do not support TLDP, then how can be
>     the inner MPLS label obtained from the PQ-node; I think that if we
>     want remote LFA protection then the nodes MUST implement/support
>     this feature, because without this the protection cannot be
>     guaranteed. For me, it is similar to a hypothetic case for example
>     of Not-via, where if the router do not support Not-via, then it
>     cannot be used. Or isn't it so simple?
>
>     *[Pushpasis] Again this is more related to original RLFA draft. I
>     will prefer the corresponding authors to address this point **J*
>
> **Thanks
>
>     Please comment my observations, in order to help me and may others
>     as well to understand every aspects and little pieces of remote
>     LFA specifications.
>
>     Best Regards,
>
>     Levente Csikor
>
> Thanks,
>
> Levente Csikor
>

---

From: Gábor Sándor Enyedi <[email-masked]>
Date: Wed, 9 Oct 2013 15:05:35 +0000

Hi,

"That's why I said that theoretical investigation of the rLFA node-protecting failure coverage needs 2-node-connected networks to suppose that may 100% node-protection can be reached."

What if we say that 100% node-protection means that 100% of those node failures can be protected, which do not split the network?
BR,

Gabor

From: [email-masked] [mailto:[email-masked]] On Behalf Of Levente Csikor
Sent: Wednesday, October 09, 2013 4:51 PM
To: Pushpasis Sarkar
Cc: [email-masked]
Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt

To calculate, which nodes are in the Q-space I've just looked for nodes for which your distance function in Fig.2. applies.
>From an industrial/implementation point of view, I have no exact claim how the calculations should be made.

Furthermore, assuming that only link failures are considered in a unit cost network (where every link has the same unit cost), then rLFA provides 100% failure coverage. Note that in this case the minimal graph topological requirement is 2-edge-connectivity. That's why I said that theoretical investigation of the rLFA node-protecting failure coverage needs 2-node-connected networks to suppose that may 100% node-protection can be reached.
On 10/09/2013 04:28 PM, Pushpasis Sarkar wrote:
Hi Levente,

Thanks
-Pushpasis

From: Levente Csikor [mailto:[email-masked]]
Sent: Wednesday, October 09, 2013 5:17 PM
To: Pushpasis Sarkar
Cc: [email-masked]<mailto:[email-masked]>; Chris Bowers
Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt

Dear Pushpasis,

Hi Levente,

Thanks

-Pushpasis

-----Original Message-----
From: Levente Csikor [mailto:[email-masked]]
Sent: Wednesday, October 09, 2013 2:00 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt

Dear All,

A----------B---------C

|          |       / |

|          |      /  |

|          |     /   |

F          G    /    H

|          |   /     |

|          |  /      |

|          | /       |

D----------E---------S

For example:

Best Regards,

Levente Csikor

Thanks,

Levente Csikor

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 9 Oct 2013 15:46:13 +0000

Hi Levente,

As far as I understand.. 100% protection coverage means as long as there is a single feasible alternate path in the network, the protecting router shall use it to provide traffic protection.. irrespective of whether it is all unit cost link or not.. irrespective of whether the single feasible path is on the shortest path from any of my neighbor or not. There has to be just another path with any cost other than the primary path.

Thanks
-Pushpasis

From: Levente Csikor [mailto:[email-masked]]
Sent: Wednesday, October 09, 2013 8:21 PM
To: Pushpasis Sarkar
Cc: [email-masked]; Chris Bowers
Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt

Thanks
-Pushpasis

Dear Pushpasis,

Hi Levente,

Thanks

-Pushpasis

-----Original Message-----
From: Levente Csikor [mailto:[email-masked]]
Sent: Wednesday, October 09, 2013 2:00 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt

Dear All,

A----------B---------C

|          |       / |

|          |      /  |

|          |     /   |

F          G    /    H

|          |   /     |

|          |  /      |

|          | /       |

D----------E---------S

For example:

Best Regards,

Levente Csikor

Thanks,

Levente Csikor

---

From: Levente Csikor <[email-masked]>
Date: Wed, 09 Oct 2013 17:52:04 +0200

On 10/09/2013 05:46 PM, Pushpasis Sarkar wrote:
>
> Hi Levente,
>
> As far as I understand.. 100% protection coverage means as long as 
> there is a single feasible alternate path in the network, the 
> protecting router shall use it to provide traffic protection.. 
> irrespective of whether it is all unit cost link or not.. irrespective 
> of whether the single feasible path is on the shortest path from any 
> of my neighbor or not. There has to be just another path with any cost 
> other than the primary path.
>
Yes

> *Sent:* Wednesday, October 09, 2013 8:21 PM
> *To:* Pushpasis Sarkar
> To calculate, which nodes are in the Q-space I've just looked for 
> nodes for which your distance function in Fig.2. applies.
> Furthermore, assuming that only link failures are considered in a unit 
> cost network (where every link has the same unit cost), then rLFA 
> provides 100% failure coverage. Note that in this case the minimal 
> graph topological requirement is 2-edge-connectivity. That's why I 
> said that theoretical investigation of the rLFA node-protecting 
> failure coverage needs 2-node-connected networks to suppose that may 
> 100% node-protection can be reached.
>
>     used the description of P and Q spaces from the original draft,
>     and from my research on this topic, where every kind of spaces
>     were defined in cost terms to easily analyze the network
>     theoretically."
>
>     "the set of routers which can reach the primary neighbor E can
>     without traversing the link (S-E) being protected"
>
>     traversing any links originating from E"? That will leave no
>     routers in the set.. Right?
>
>     without traversing any links originating/attached to E".... For
>     doing that we will have two options
>
>     1.RSPF rooted on the destination (will be very expensive if we
>     have to do that for every destination node in the network)..  OR
>
>     2.FSPF rooted on the PQ-node and check if primary neighbor E is on
>     the SPF path from PQ-node to destination.. This is what is
>     specified in our draft.. Assuming number of PQ-nodes are far less
>     than number of nodes in the network this approach looked more
>     feasible. Also now we are able to collect full path attributes for
>     RLFA backup paths for LFA-manageability. Also RLFA does not
>     attempt to provide 100% coverage. So like already said,
>     implementations can decide to only consider upto a certain number
>     of PQ-nodes to be considered in the whole network to limit the
>     number of extra FSPFs to be computed.
>
>     Thanks
>
>     -Pushpasis
>
>     *Cc:* [email-masked] <mailto:[email-masked]>; Chris Bowers
>         I also support to work more on the node protection draft
>         first, before merging it with "basic rLFA spec", because of
>         various reasons:
>
>         node-protecting remote LFA works on the same, or almost the
>         same sample network topology used in the basic rLFA spec., but
>         for easier and more comprehensive understanding, a bit more
>         complex but still simple example should be given. IMHO, in the
>         basic rLFA spec. it is a bit confusing that node E is
>         considered as a destination and this node is the next-hop as
>         well, since the important parts of the different roles are not
>         dissevering enough. Because of this, the similar example in
>         node prot spec. is also not straightforward:
>
>         draft-psarkar-rtgwg-rlfa-node-protection-01 we have specified
>         the destinations E, F (and their corresponding RLFA backup
>         paths explicitly), that will be affected by node-failure of E.
>         Also the destination G has been included which will still be
>         reachable in the case of node-failure of E. Perhaps basic RLFA
>         spec can also include such kind of illustrations*
>
>     **Yeah, I know and there is also the entry in the back-up path
>     column for G, but here, I wanted to emphasized that the
>     connectedness of the network does not remain any other
>     opportunities to be considered.
>     In other words, if there were an additional node between F and G,
>     say H, and nodes E-D-G-H-F would also form a 5-cycle, then all
>     your claims will remain valid, since C's shortest path to F won't
>     avoid the failed node E, but the graph-topological requirements
>     would be not so confusing (maybe only for me :) , but when I
>     analyze a network to calculate the rLFA protection coverage, then
>     I always assume this basic graph topological property to easily
>     derive the level of protection (in percent, for example) of the
>     possible attainable 100%).
>
>
>         alternate path from Remote-LFA nexthop C to E and F also
>         becomes unavailable."
>
>         *[Pushpasis] That is exactly we are also saying in this
>         draft(I mean draft-psarkar-rtgwg-rlfa-node-protection-01).. If
>         any destination takes the shortest-path segment C...E that
>         will not have node-protection using C as the PQ node, because
>         C is going to forward the traffic to E anyhow. In Table 2 we
>         see that the path segment C->D->E is included in the shortest
>         path from C to E and F. That is why in case of node-failure of
>         E, E and F cannot provide node-protection*
>
>     **It was a quote from the draft, so it is really the fact that you
>     are saying :)
>
>
>         According to the well-known last-hop problem, it is obvious
>         that if the destination (in the first case: node E) goes down,
>         then it cannot be protected. Moreover, since the example
>         network topologyis not 2-node-connected, it is obvious again
>         that the node F, which can be accessed only via node E, then
>         the failure of node E infers that the node F can be never reached.
>
>         To (re)solve this issue, I suggest to use another network (in
>         the basic rLFA spec. as well), which could be the following
>         (all link costs are unit costs):
>
>         A----------B---------C
>
>         |          |       / |
>
>         |          |      /  |
>
>         |          |     /   |
>
>         F          G    /    H
>
>         |          |   /     |
>
>         |          |  /      |
>
>         |          | /       |
>
>         D----------E---------S
>
>         In this case, assuming that source node S wants to send a
>         packet to node D, the next-hop of S is node E.
>
>           - Link protecting case: If link(s,e) fails, then P-space of
>         node S regarding to the failed link, would consist of node
>         H,C,B and A, whilst the Q-space of D would consist all nodes
>         except S and H. In this case, the PQ-nodes, as the possible
>         repair tunnel endpoints, are node A,B and C.
>
>           - Node protecting case: However, if node E itself fails,
>         then the P-space of S would not alter, but the Q-space of D
>         would only contain node F and A resulting that only node A is
>         present in the set of PQ-nodes.
>
>         *[Pushpasis] Can you elaborate on the method you used for
>         deriving the PQ-nodes A and F here... Seems to me like you are
>         doing a RSPF rooted on destination D and then pruning all
>         links originating from E... I think Chris Bowers has already
>         pointed on a different thread that while best way to guarantee
>         node-protection is to run a RSPF rooted on each destination,
>         we cannot afford to do so in reality... It will be much more
>         feasible to run FSPF on fewer PQ-nodes as specified in our
>         draft..*
>
>     **I did not consider any possible way of determining PQ-nodes,
>     only used the description of P and Q spaces from the original
>     draft, and from my research on this topic, where every kind of
>     spaces were defined in cost terms to easily analyze the network
>     theoretically.
>
>
>         **
>
>         shortest-path from the PQ-nodes (C, B, and A) to destination
>         D. Only the SPF path from A does not go through E, so only A
>         will provide node-protection for D.*
>
>         node protection and link protection, but in a more
>         comprehensive manner. And it also demonstrates the fact
>         mentioned in Figure 2 that for node-protecting rLFA, only the
>         Q-spaces should be checked with those distance functions.
>
>         Moreover, if we assume that in the example network above,
>         there is a link (A,E) and node E itself failed again, than
>         PQ-space would be and empty set meaning that this case cannot
>         be protected.
>
>     **I know that it is true, I just wanted to say that by this
>     network, the case of absence of node protection could be
>     demonstrated easily assuming that the main example was the network
>     described above.
>
>
>         "how difficult or impossible to obtain those distances" would
>         be clearly stated in a bullet point list:
>
>         For example:
>
>         should be implemented (actually, IMHO, this is the one, which
>         is not clear enough)
>
>         original RLFA draft. Chris has already written to the authors
>         on this mailing list with suggesting text for the draft. The
>         third one is no different than standard SPF we need for
>         RFC5286 implementation.. only difference being that it is
>         rooted on PQ-nodes  in case of RLFA... It is up to individual
>         Third, according to the Targeted-LDP discussion, which is
>         about the fact that if some node do not support TLDP, then how
>         can be the inner MPLS label obtained from the PQ-node; I think
>         that if we want remote LFA protection then the nodes MUST
>         implement/support this feature, because without this the
>         protection cannot be guaranteed. For me, it is similar to a
>         hypothetic case for example of Not-via, where if the router do
>         not support Not-via, then it cannot be used. Or isn't it so
>         simple?
>
>         *[Pushpasis] Again this is more related to original RLFA
>         draft. I will prefer the corresponding authors to address this
>         point **J*
>
>     **Thanks
>
>
>         Please comment my observations, in order to help me and may
>         others as well to understand every aspects and little pieces
>         of remote LFA specifications.
>
>         Best Regards,
>
>         Levente Csikor
>
>     Thanks,
>
>     Levente Csikor
>

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 10 Oct 2013 16:14:11 +0100

Without doing a whole load of investigation, we should assume
that the IPR disclosures that apply to rlfa apply to this draft.
I will therefore set in place the process to extend the
disclosure.

Stewart

-- 
For corporate legal information go to:

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

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 10 Oct 2013 17:23:07 +0200

one more reason for making it part of the base spec ;-) - /hannes

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 10 Oct 2013 18:02:42 +0100

I really would like to get the base done - it's been a long time.

Stewart