RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

[Uma Chunduri <[e-mail]>]

Dear Authors & Chris,
...
...


[Uma]:What is Topology-A and Topology-B represent? Are these 2 from the 14 SP topologies?
Else we don't know what are the main characteristics of the topology.
[CB]  You are correct that Topology-A and Topology-B are just 2 out of many topologies analyzed.

Ok, these are some arbitrary topologies with huge number of nodes and I don't think we can conclude results based on this to confirm 8-16 PQ nodes for fSPF would always yield best coverage.
But your results based on these are pointing towards that.


[CB]  ...In my opinion, the focus of the draft should be on the use of forward SPF rooted at a PQ-node as the means of determining if the path from PQ-to-dest is node protecting
I think this should be THE  goal of this document.

[CB]  ..and to collect other path properties.
IMO,  this should belong to LFA/RLFA manageability draft.


Summary:


1.       I feel this draft should focus on the original goal of rLFA NP as the way it's specified today i.e., NP extended P-space and fSPF from candidate PQ to destinations (just this, bit more cleaner).

2.       Also after further study as indicated in the draft, should define a default strategy for reducing the number of PQs which will maximize the NP coverage.

While doing this it should always consider:

a.       The total number of PQ nodes should be lesser; not for fSPF load reduction but also for minimizing the TLDP on the fly sessions. So preference for close to Source must also be a factor.

b.      Given the defined criteria for any topology for any vendor should yield the same PQ node (predictability for operations and planning)

3.       Manageability considerations as defined in this draft should be completely removed  (I see the same already in http://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-03#section-5.2.4)

FWIW,  I feel an update is needed before it proceeds further. I also have more particular comments and will post in a separate e-mail.

--
Uma C.