Subject: RE: Comments on draft-psarkar-rtgwg-rlfa-node-protection-03

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 2 Apr 2014 10:31:58 +0000

Hi Uma,

First off, sorry for the late response. Second, thanks a lot for taking your time to review this draft so closely. Please find some comments and resolution inline. Hoping I am able to address all your comments.

Thanks
-Pushpasis

From: Uma Chunduri [mailto:[email-masked]]
Sent: Friday, March 28, 2014 11:21 PM
To: [email-masked]
Subject: Comments on draft-psarkar-rtgwg-rlfa-node-protection-03

Dear Authors,

These are some specific comments -

=============

1. Abstract -
   "The
   document also shows how the same procedure can be utilised for
   collection of complete characteristics for alternate paths.
   Knowledge about the characteristics of all alternate path is
   precursory to apply operator defined policy for eliminating paths not
   fitting constraints."

   Why we need this for NP only?
   ...
[Pushpasis] This is not needed for NP. But the proposed solution for NP(i.e. FSPF rooted on the PQ-node) is also necessary when we need to support LFA-manageability, even when NP is not required. That is why we originally chose the title of this draft as "Remote-LFA Node Protection and Manageability"

2. Introduction

   "  Also, the LFA Manageability [I-D.ietf-rtgwg-lfa-manageability]
   document, requires a computing router to find all possible (including
   all possible Remote-LFA) alternate nexthops, collect the complete set
   of path characteristics for each alternate path, run a alternate-
   selection policy (configured by the operator), and find the best
   alternate path.  This will require the Remote-LFA implementation to
   gather all the required path characteristics along each link on the
   entire Remote-LFA alternate path."

Why do we need to collect path characteristics of all alternatives before alternate policy ? This is not what is represented in I-D.ietf-rtgwg-lfa-manageability (it's prune then run alternate

selection policy)
[Pushpasis] As far as I understand the draft talks about what all characteristics to collect and evaluate while evaluating a alternate-selecting policy. Obviously for that we need to collect all those characteristics before doing the actual policy run. Much like how all the route-parameters of  a route are learnt and collected before running a route-policy on it. Policy cannot be expected to give the correct selection if appropriate characteristics of the route(or alternate path) is provided to the policy. Right? In some implementation the policy engine may take the responsibility of collecting all path characteristics itself. But atleast the path characteristics need to be evaluated before policy evaluation.
Now looking at the path characteristics of RLFA path they are basically all the characteristics in the LFA manageability for the each link and node on the alternate path from PLR to PQ-node as well as from PQ-node to destination. We will be able to typically walk the links and node from PLR to PQ-node since we would already run a Djikstra(FSPF) rooted at 1-hop neighbor on the path from PLR to PQ-node(standard RFC5286 implementation). However we will not walk the nodes and links from PQ-node to destination, unless we run a Djikstra(FSPF) rooted at PQ-node.

3. Section 2.1
   " A closer look at Table 1 shows that, while the PQ-node R2 provides
   link-protection for all the destinations, it does not provide node-
   protection for destinations E and F."

   There is no node F in the diagram. You mean to say D1 here?
[Pushpasis] Yes. Typo. Will correct it while uploading next version.

4. Section 2.1 - Table 2
    D2          | S->E->D1     | R3      | S=>N=>E=>R3->D2

    The above should be S->E-R3-D2
[Pushpasis] No the shortest path from N (assuming link-protection like base RLFA draft does) is still N->E->R3->D2. After adding the link between N and E, there are two PQ-nodes R2 and R3. This particular row is w.r.t R3 as the PQ-node. The shortest path from S to R3 that does not take S-E link is S->N->E->R3 (still traverses primary nexthop E).

We are trying to point the issue with the assumption (i.e protect against S-E link failure, not node-failure of E) taken by the PQ-node solution logic in the base RLFA draft here.

5. Section 2.1
    "Again a closer look at Table 2 shows that, unlike Table 1, where the
   single PQ-node R2 provided node-protection, for destinations R3 and
   G, if we choose R3 as the R-LFA nexthop, it does not provide node-
   protection for R3 and D1 anymore."

   There is no node G in the diagram
[Pushpasis] Typo again :) Thanks for pointing out. Will correct it while uploading next version.

6. Section 2.2.1

    D_opt(Ni,Y) < D_opt(Ni,S) + D_opt(S,E) + D_opt(E,Y)

   Need to be changed (even in the main draft, per agreement earlier) to
     D_opt(Ni,Y) < D_opt(Ni,S) + D_opt(S,Y)

[Pushpasis] Sure. Will change it.

7.Section 2.2.2
  "It must be noted that a node Y satisfying the condition in Figure 4
   above only guarantees that the R-LFA alternate path segment from S
   via direct neighbor Ni to the PQ-node Y is not affected in the event
   of a node failure of E. It does not yet guarantee that the path
   segment from PQ-node Y to the destination is also unaffected by the
   same failure event."

   I don't think Y is yet a PQ node as description says. Probably it needs to be corrected as "potential PQ-node"
[Pushpasis] Y is a candidate being evaluated for being in the node-protecting Ext-P space. . Will correct it while uploading next version.

8. Section 2.3.1 (even title itself is incorrect, this is all about NP ext-P space)

   "Implementations should run the inequality in Section 2.2.2 Figure 4
   for all direct neighbor, other than primary nexthop node E, to
   determine whether a PQ-node Y is also a candidate node-protecting PQ-
   node."
   for all direct neighbor ==> should be replaced to indicate all eligible neighbors where back is provisioned.
[Pushpasis] This in my opinion is very implementation specific. So I will prefer to keep the eligibility part outside
this draft. But I agree that in case a neighbor has been configured as 'ineligible' for providing backup by
user configuration, it should be skipped over.

9. Section 2.3.1

   " Implementations should run the inequality in Section 2.2.2 Figure 4
   for all direct neighbor, other than primary nexthop node E, to
   determine whether a PQ-node Y is also a candidate node-protecting PQ-
   node."

   Y is not PQ-node here. "PQ-node" should be replaced with node protecting extended-p space node.
[Pushpasis] Well in reality a node-protecting PQ-node will also be a link-protecting PQ-node. But I will still modify the text in next version to remove the linkage.

10. Section 2.3.1
     In the similar grounds as above
     Table 3 & table 4 first column should not be "PQ-node (y)"
[Pushpasis] Ok. Will correct it in next version.

11. Section 2.3.1
    Though this section is trying to justify how and why the PQ nodes selected are link protecting and node protecting.
    But the way it's written is incorrect  with references to section 2.2.2

    For e.g.

    "So S may re-use the list of
   links and nodes collected from the same SPF computations, to decide
   whether a PQ-node Y is a candidate node-protecting PQ-node or not.  A
   PQ-node Y shall be considered as a node-protecting, if and only if,
   there is atleast one direct neighbor of S, other than the primary
   nexthop E, for which, the primary nexthop node E does not exist on
   the list of nodes traversed on any of the shortest path(s) from the
   direct neighbor to the PQ-node."

   Here the usage of PQ node is incorrect as it is referring to section 2.2.2.
   The more correct term here is the candidate NP extended-P space.
[Pushpasis] Sure. Will correct it in next version.

12. Section 2.3.1

    "
   As seen in the above Table 4 while R2 is candidate node-protecting
   Remote-LFA nexthop for R3 and G, it is not so for E and F, since the
   primary nexthop E is in the shortest path from R2 to E and F."

   There are no nodes G and F anywhere in the diagrams
[Pushpasis] Typo again :). Will correct it in next version.

13. Section 2.3.2

    "After
   running the forward SPF on a PQ-node (from the node-protecting PQ-
   space) the computing router shall run the inequality in Figure 6
   below.  PQ-nodes that does not qualify the condition for a given
   destination, does not gaurantee node-protection for the path segment
   from the PQ-node to the given destination."

   Here the PQ nodes are candidate NP PQ nodes - this section should be cognizant
   of this while loosely using PQ nodes term.
[Pushpasis] Will correct it in next version.

    Also it's not "After running the forward SPF..", it should be "While running the forward SPF.."

[Pushpasis] This is too implementation specific. Depends on wether you run Djikstra first and then compute backup path from its results, or do everything along with the main djikstra. So I will replace it like this ... "On running the forward SPF on a candidate node-protecting PQ-node ... "

14. Section 2.3.3

    " Implementations MUST choose
   a default value for this limit and may provide user with a
   configuration knob to override the default limit.  Implementations
   MUST also evaluate some default preference criteria while considering
   a PQ-node in this subset."

   Here the point is for interoperability and deterministically getting the same PQ node from all vendors one default criteria should be used.
[Pushpasis] RemoteLFA like all other LFA mechanism is entirely a local decision on the PLR. PQ-nodes chosen by two PLRs will never be same. So it should not matter.

   But if "some default" preference is used you won't fulfill the objective of same PQ node. If this is really a goal then this document must
   define indeed a default heuristic and this must be implemented by all.

   The below paragraph indicates a suggested default criteria and also points out further study is required to confirm this is indeed the "default".
    I think this need to be worked out.

   "A suggested default criteria for PQ-node selection will be to put a
   score on each PQ-node, proportional to the number of primary
   interfaces and remote destination routers being protected by it, and
   then pick PQ-nodes based on this score.  A more appropriate
   heuristsics can be devised, based on in-depth study of coverage
   provided by R-LFA, in the networks where they are mostly deployed.
   The same can then be used for PQ-node selection."

[Pushpasis] This is a just a suggestion, and not a MUST. Individual implementations are free to use their own heuristics.

15. Section 3

    "For such
   policy-based alternate selection to run, all the relevant path
   characteristics for each the alternate paths (one through each of the
   PQ-nodes), needs to be collected."

   This is very vague - what path characteristics you are seeking must be clearly spelled out.

   And also this whole thing doesn't belong here and should be in
   http://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-03

   And I already see the same in Section 5.2.4.2 of the same.

[Pushpasis] This is added to the LFA-manageability draft only after it was proposed in this draft earlier. We have kept it short and simple in here. And decided any further developments in this will be added in LFA-manageability draft. So all future heuristics that are being worked on will be added in the LFA-manageability draft.

--
Uma C.

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 8 Apr 2014 23:21:11 +0000

Thought to reply for this  earlier but missed it. Most of the things are fine but I have few comments as described below -

--
Uma C.

From: Pushpasis Sarkar [mailto:[email-masked]]
Sent: Wednesday, April 02, 2014 3:32 AM
To: Uma Chunduri; [email-masked]
Cc: LITKOWSKI Stephane DTF/DERX
Subject: RE: Comments on draft-psarkar-rtgwg-rlfa-node-protection-03

Hi Uma,

First off, sorry for the late response.
[Uma]: :), I think I matched your response!

   ...

2. Introduction

selection policy)

[Uma]: The main issue  I observed in the above paragraph is  - you are asking to collect all possible path characteristics (which can be as many as 500+ FSPFs depending on the topology) then run the alternate policy..

"   all possible Remote-LFA) alternate nexthops, collect the complete set
   of path characteristics for each alternate path, run a alternate-
   selection policy"

I think you need to clarify here that after heuristics (default or whatever) the pruned version of candidate NP PQs are considered as input for the policy for the best alternate path.
You can see; it's quite possible, after the heuristics and the  operator policy you may not  get any NP PQ at the end (so be it).

...

4. Section 2.1 - Table 2

[Uma]:     D2          | S->E->D1     ==> be S->E->R3->D2 (:))

14. Section 2.3.3

[Uma]:.  Of course, it will not be same. I was not talking about PQ-nodes for 2 PLRs
             I was rather talking about, same and predictable PQ node from the SAME PLR for different vendors  (for manageability purposes, that's what you got to aim for at minimum). Please read through my original comment again!

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 9 Apr 2014 11:40:09 +0000

Hi Uma,

Please find comments and responses inline.

Thanks
-Pushpasis

From: Uma Chunduri [mailto:[email-masked]]
Sent: Wednesday, April 09, 2014 4:51 AM
To: Pushpasis Sarkar; [email-masked]
Cc: LITKOWSKI Stephane DTF/DERX
Subject: RE: Comments on draft-psarkar-rtgwg-rlfa-node-protection-03

--
Uma C.

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

Hi Uma,

   ...

2. Introduction

selection policy)

[Uma]: The main issue  I observed in the above paragraph is  - you are asking to collect all possible path characteristics (which can be as many as 500+ FSPFs depending on the topology) then run the alternate policy..
[Pushpasis] No, this paragraph is not asking to do so, it just clarifying what is required if we need to support LFA-manageability for RLFA. Ideally we should be running FSPF on all possible PQ-nodes and evaluate all possible RLFA alternate paths. In section 2.3.2 of this draft we mentioned that while finding all possible RLFA paths will be ideal it will not be feasible and hence we recommend to limit the search with upto 16 PQ-nodes.

I think you need to clarify here that after heuristics (default or whatever) the pruned version of candidate NP PQs are considered as input for the policy for the best alternate path.
You can see; it's quite possible, after the heuristics and the  operator policy you may not  get any NP PQ at the end (so be it).
[Pushpasis] Yes its quite possible. And that applies to the LFA-manageability draft as well. With the operator's choice of alternate policy certain destinations may end up with ZERO protection though there were feasible alternate paths. Point is whenever any policy is being used, while it provides a powerful tool to achieve a lot, the same can be misused or used without adequate awareness of its consequences leading to undesired behavior. IMO, a draft should be listing out what all could be achieved with this solution and not listing out extensively what all cannot be achieved. But if the group members still insist I will add some text in next version.

...

4. Section 2.1 - Table 2

[Uma]:     D2          | S->E->D1     ==> be S->E->R3->D2 (:))
[Pushpasis] Ack. One more typo :( I should have waited some more time for your response.

14. Section 2.3.3

[Uma]:.  Of course, it will not be same. I was not talking about PQ-nodes for 2 PLRs
             I was rather talking about, same and predictable PQ node from the SAME PLR for different vendors  (for manageability purposes, that's what you got to aim for at minimum). Please read through my original comment again!
[Pushpasis] Uma do you foresee one single node running multiple vendor implementations? If not this is not a concern in my opinion. If you are replacing PLR from one vendor implementation to another it will either use the same heuristics or the operator is fine with the new different heuristics. Again the point is we don't want any vendor implementation to not implement a better heuristics if they have found one because this draft has made it mandatory.