[Lsr] Re: draft-ietf-lsr-dynamic-flooding-algorithm-02 ietf last call Rtgdir review

[Tony Li <[e-mail]>]

Hi Adrian,

Thank you for your review.  My apologies for not being able to respond more quickly.


> The document is clear and readable, although I found that the outline in
> section 3 to be both too detailed to not be taken as a complete overview
> of the algorithm, and not detailed enough to capture all of the 
> important bits of the algorithm as defined in section 4.


I respect that opinion and would be happy to address it, but am unclear on how to do so. Can you offer any more specific guidance on both the unnecessary detail and the needed detail?  Obviously, the point is not to turn it into section 4.

> On the other hand, you might consider that this document is actually
> Informational disclosing the algorithm developed by Arista and HPE -
> that seems like a lot less effort.


The WG was unwilling to consider Informational status.


> I may be struggling with the term "biconnected". My graph theory is
> probably rusty, but I thought the term meant:
> - the graph is connected (i.e., you can navigate edges and nodes to
>  reach from any node to any other node)
> - removal of a node from the graph does not make what remains
>  disconnected


And:
- Removal of an edge from the graph does not make what remains disconnected.


> Given this, I am not sure that we have the same understanding of the
> term because I don't think that property 2 in Section 3 makes for a
> biconnected graph in my definition (a ring is biconnected, hub and
> spoke is not).


Could you please say more about your reasoning?


> Actually, the detailed description of the algorithm in section 4 seems
> to differ from that in section 3. The detail in section 4 *does* work
> with biconnected graphs even if the outline in section 3 does not.


Obviously, there is some detail in section 4 that was not mentioned in section 3.  Which one?


> I think it would be informative to include some implementation status
> even if that would be removed from the published RFC. Such information
> would explain to reviewers why it is worthwhile to publish the document.
> You can find guidance in RFC 7942.


As discussed, it is worthwhile publishing this because it is a practical algorithm that addresses the problem at hand. This is 100% independent of the implementation status. The status is wholly uninteresting: there is one implementation.


> Section 1 provides a useful summary of the desired behaviors of a
> flooding topology. It would be helpful to clarify that this a summary
> of the requirements set out in RFC 9667 (and not a new set of
> requirements created in this document).


Added.


> While there is no requirement to do so, it may be helpful to introduce 
> an Operational Considerations section to help understand how this
> algorithm would be deployed, configured, and diagnosed. For example,
> what are the assumptions for discovery or configuration of the nodes at
> each end of an edge?


I’m very unsure of how to add value here.  How do deploy it is straightforward: upgrade your routers. How to configure it: turn it on. Vendor specific knobs.  How to diagnose it: stare at the link state database for hours.  Does this help?

The assumption is that you’re running IS-IS and it has formed adjacencies where possible, and that nodes advertise their capabilities as per RFC 9667.


> Section 2 says...
>   We model the physical topology as an undirected graph.
> 
> No question about this being applicable to a physical topology. 
> Could it also be applied to a virtual topology?


Changed to ‘base topology’.


> Section 3 has...
>   V is the set of all reachable nodes in this area
> I think "reachable" has to be in the context of a "source" node because
> consider a partitioned network.


Removed ‘reachable’.


> Since you later say that one of the properties of the resultant subgraph
> is...
>   1.  It covers all nodes in the area.
> ... I think you might either:
> - change s/all reachable nodes/all nodes/
> or
> - s/covers all nodes in the area/covers all reachable nodes in the area/
> 
> Or, I suppose, "reachable" means that the intention is to cover all 
> nodes and edges that are supposed to be connected within the area, 
> notwithstanding any failed nodes and edges.


Anything that has failed is no longer part of the topology and is not referenced.


> When I get to section 4, I discover that there is an assumption that the
> base graph is connected, and with that assumption all is good. So 
> perhaps it is just that the outline in section 3 needs to call this out.


Qualifier added in section 2.


> Please don't make references from the Abstract as it needs to be
> available as stand-alone text.


Fixed.


> However, draft-ietf-lsr-dynamic-flooding is now RFC 9667 so, *if* you
> feel that it is necessary to point at another document, you can write
>   Dynamic flooding as described in RFC 9667, alleviates...


Fixed.


> The document is missing a mandatory IANA Considerations section.


Fixed


> Please expand LSP and LSPDU on first use.


That was already there in section 1.


> I'm pretty sure that you are using draft-ietf-lsr-dynamic-flooding 
> (i.e., RFC 9667) as a normative reference.


Fixed.

Cheers,
Tony