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

[Pushpasis Sarkar <[e-mail]>]

Hi Uma,

Please find comments and responses inline.

Thanks
-Pushpasis

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

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:[e-mail]]
Sent: Wednesday, April 02, 2014 3:32 AM
To: Uma Chunduri; [e-mail]<mailto:[e-mail]>
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

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

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

"   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).
[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
    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.

[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

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

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