Hi Reese, Thank you for your comments. Please see inline. > Introduction: > "However it is very clear that using an Exterior Gateway Protocol as an IGP is > sub-optimal, if only due to the configuration overhead." To me, the "very > clear" and the "if only due" sound like they're contradicting each other. If > it's very clear, I expect a very strong reason or multiple. Please consider > providing more reasons why an EGP is suboptimal or weakening the "very clear". Sure. > "The primary issue that is demonstrated when conventional mechanisms are > applied is the poor reaction of the network to topology changes." Please > consider clarifying what conventional mechanisms means specifically here. > Conventional IGPs? Link state protocol specifically? Are the two the same? All of our conventional IGPs are link state at this point, so yes. Reworded to ‘conventional IGPs’. > "This problem is not entirely surprising. Link state routing protocols were > conceived when links were very expensive and topologies were sparse. The fact > that those same designs are sub-optimal in a dense topology should not come as > a huge surprise. The fundamental premise that original designs addressed was an > environment of extreme cost and scarcity. Technology has progressed to the > point where links are cheap and common. This represents a complete reversal in > the economic fundamentals of network engineering" The text in and around this > part seems a bit redundant, please consider shortening it to say the surprise > part and the "link used to be costly" only once. Sure. > Section 3, Solution requirements: > "Changes to nodes outside of the dense subgraph are not acceptable. " > Please consider clarifying what "changes" means here - Is this to say that the > solution needs to be backwards-compatible and/or an extension to an existing > IGP? Reworded. I really meant any change. Even software upgrades are out of the question. Some production networks require 2 (or more) years to vet a new release. > Section 4, Dynamic flooding: > "New link state information that arrives from outside of the flooding topology > suggests that the sender has different or no flooding topology information and > that the link state update should be flooded on the flooding topology as well." > This part was not immediately obvious to me - "arrives from outside of the > flooding topology" means it arrives from outside the subgraph that supports > dynamic flooding and/or from a legacy device? Or does it mean that the > information arrives from within the flooding topology but over a link that is > not part of the flooding topology? Please consider clarifying this point. Reworded. > "When centralized mode is used and if, during a transient, there are multiple > flooding topologies being advertised […]" The word "transient" is used as a > noun multiple times during the draft, so I assume this is a standing term in > routing which I have never heard before. Please consider adding a brief > explanation of what a transient is. Added. > Section 4.1: > Does "legacy flooding" and "standard flooding" refer to the same thing? If so, > please consider unifying the terms here. Converged on ’standard’. > Section 4.3: > "If the leader chooses to include a multi-node broadcast LAN segment as part of > the flooding topology, all of the connectivity to that LAN segment should be > included as well." Please consider clarifying what "all the connectivity" means > here, as I think this is the first time LANs are discussed. Does it mean all > links that connect to the LAN segment? Are LANs with multiple links the same as > "multi-access LANs" referenced later in the document, in which case please > consider using a consistent term? Fixed. > Section 4.4: > Please consider adding figures to help the explanation here. I would be happy to, but my limited skills with ASCII art aren’t really up to the task. > Section 4.4.2: > "Adding one more leaf between the last and first spine will produce a cycle of > N spines and N leaves." Are these both intended to be N, or is one intended to > be M? It is correct as stated. > Does the algorithm make any assumptions of how many spines and leaves > there are in total? No. The only assumption is that there are more leaves than spines. This is implicit in the definition of the topology. > Section 4.5: > "Instead, we choose to encode the flooding topology as a set of intersecting > paths, where each path is a set of connected edges." I think this is the first > time the document mentions paths. Please consider briefly expanding on how a > path is defined, unless there is a clear consistent definition that is > well-known in the routing area in general. Path is a well known term in both graph theory and routing. A path from node A to node B is a connected list of edges starting at A and ending at B. Please see RFC 4655 as one of many examples about path computation. > Are edges the same as links, in > which case please consider using consistent terms? In general, edges and links are synonymous in graph theory and routing. However, in this document, we are making something of a subtle distinction that is described in section 4.6. The distinction is relevant when you consider parallel links between nodes. The flooding topology is computed on edges, which we are defining as a pair of nodes. This can be instantiated by flooding on a given link. In the case of PTP links, we do not care that the nodes choose the same link for the edge, as they are functionally equivalent. However, if broadcast LANs are involved, the distinction becomes relevant as other nodes will become part of the flooding topology. > Section 4.6: > "As the flooding topology is defined by edges (not by links)" > This sentence implies these are different things. Please consider clarifying > what the difference is and/or providing a brief reasoning on why it's edges > here and not links. Ok. > Section 5.1: > When referencing IS-IS, please consider referencing a relevant RFC or such. > Please consider expanding LSP on first use. The only definition of IS-IS is ISO 10589, which is what we’ve referenced. There is no relevant RFC. I’ve expanded LSP. > "A TLV to advertise the list of system IDs that compose the flooding topology > for the area." Are system IDs the same as nodes here, in which case please > consider saying so? A system ID is an identifier for a node. This is commonly known to those working with IS-IS. Notation added. > Section 5.1.1: > "Due to transients during database flooding, different nodes may not agree on > the Area Leader." Is this a problem? If not, why not? If so, what is the best > way to handle this problem? Please consider discussing these points briefly. This is not problematic, as subsequent flooding will cause the entire area to converge. > Does each system just pick its own priority? Is it configured? Or how is > priority determined? Please consider discussing these points briefly. Typically, the priority is configured by the network operator, however, this is not required and priority could be computed, set to a default value, or set by a management application. We typically do not specify the mechanisms, as it is not relevant. I’ve explicitly added that it’s out of scope. > Section 5.1.5: > Please consider expanding IIH PDU on first use. Done. > Section 5.2: > When referencing OSPFv2 and OSPFv3, please consider referencing a relevant RFC > or such. There are references to RFC 2328 and RFC 5340 in section 1. > Section 6.1: > Please consider expanding SPT on first use. > Please consider expanding OL on first use. Done > Section 6.6.2.1: > Please consider expanding CSNP and PSNP on first use. Done > "NOTE: If any node connected to the LAN requests the enablement of temporary > flooding, all nodes revert to the standard flooding behavior." Should this > sentence be rephrased as a MUST? Sure. > Section 6.7: > "If a node determines that adjacencies are to be added to the flooding > topology, it should add those and begin flooding on those adjacencies > immediately." Does this apply to both centralized and distributed mode? Is this > temporary flooding or does it change the flooding topology? Please consider > clarifying this point. Yes, this is mode independent. > > Section 6.8.1: > Please consider expanding SRM on first use. Done. > Section 6.8.9: > "Temporary flooding MUST be enabled towards a subset of the disconnected nodes > per the discussion in Section 6.8.12." Please consider referencing Section 6.7 > as well. Ok. Tony -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
