[Lsr] Comments regarding convergence regarding draft-cc-lsr-flooding-reduction and draft-li-lsr-dynamic-flooding

["Van De Velde, Gunter (Nokia - BE/Antwerp)" <[e-mail]>]

[with corrected copy/paste in cc]

Dear LSR WG,

The LSR chairs informed that attempts to merge drafts draft-cc-lsr-flooding-reduction and draft-li-lsr-dynamic-flooding is exposing challenges, and hence asked me as independent unbiased WG contributor to have a look at both drafts and provide suggestions on how we may progress to deliver the highest quality WG technology deliverable. 

Please find following observations on both documents with my hat of "independent unbiased LSR contributor":

Both drafts have clearly written problem space description and in general a well written solution space. The problem space is real. Each draft approaches the problem space using different accents within the solution space. These accents are obvious when the solution-space is discussed in both drafts.

I found the solution space described in "draft-cc-lsr-flooding-reduction" centered around restoring flooding topology and making sure that during critical changes, flooding is still fast. The solution space provides mechanism to make sure that a reduced flooding topology has minimal impact upon convergence (it use backup paths, critical paths/node, ...). The compromise to achieve fast topology restoration is by introducing a complexity trade-off. For example, there are many moving parts from flooding mechanics, to avoid against flooding topology split. This raise to me some concern from implementor perspective.

The solution space discussed in "draft-li-lsr-dynamic-flooding" uses a generic vision based upon solution requirements and seems to focus around protocol efficiency/simplicity versus speed of topology convergence. From a documentation perspective I found the flow contained by "draft-li-lsr-dynamic-flooding" easier to understand. This understanding includes packet format descriptions and architectural decisions (for example known LSR technology properties/limitations). I found most of the information sufficiently well described with minimal complexity. 

In both drafts the distributed algorithm solution seems underspecified and that raise implementation concerns to me.

Conclusion:
Coming back to the original request of the LSR chairs asking feedback to progress for a quality WG deliverable. I have read both drafts and constructed an opinion. Items of interest to me were draft documentation flow, draft technological format/content and high level architectural decisions made within each proposal. Using those criteria, the balance scales towards "draft-li-lsr-dynamic-flooding" because it is using clear solution requirements, clear descriptions of encoding and their usage, clear behavioral specifications and has considered introducing minimal complexity. This means that from review perspective "draft-li-lsr-dynamic-flooding" seems best candidate to adopt with most potential for high quality WG deliverable. In addition, we could assign a shepherd to work within the WG. If needed I am happy to help shepherding the WG deliverable.

This work is important for industry. The solution must work and be causing less issues as the problem we are trying to fix. 
We need to progress the work on flooding reduction. We need to select the most optimal/pragmatic solution.
 
Obviously, additional reviews from WG contributors will help LSR WG to define and build the highest quality WG deliverable. 

Kind Regards,
Gunter Van de Velde