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

[Uma Chunduri <[e-mail]>]

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

"   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
    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 (:))

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!