In reply to my own post, here is my opinion regarding including LANs in the Flooding Topology:
While I think it would be "nice" and simplifying to be able to ignore LANs, I think we are unable to do so because the possibility that LANs are actually in use as transit links in some topologies exists. NOTE: I am not persuaded by the argument that some operators have LANs that could be operated in point-to-point mode but they simply don't configure the links to do so. If a customer is serious about flooding reduction then they need to also do what they can to reduce unnecessary LSPs/LSAs from even being generated. Even if we treat LANs as always enabled for flooding , any algorithm to calculate the flooding topology would be sub-optimal if it did not consider the fact that flooding is occurring on the LANs. Bottom line, unless we are confident that LANs will not exist in the topologies where flooding optimizations will be used, not supporting LANs seems to be an undesirable restriction. Les > -----Original Message----- > From: Lsr <lsr-boun...@ietf.org> On Behalf Of Les Ginsberg (ginsberg) > Sent: Tuesday, April 02, 2019 8:31 AM > To: tony...@tony.li; lsr@ietf.org > Subject: [Lsr] Open issues with Dynamic Flooding: Including LANs in the > Flooding Topology > > (I have altered the subject so we can discuss the two issues in Tony's > previous post separately.) > > > There are several aspects to consider when discussing LAN support in the > context of flooding optimizations: > > 1)Flooding topology advertisement (centralized mode only) > > Support for encoding LANs when advertising the flooding topology requires > that > we include not only all routers in the set of "nodes" in the network but also > (to use IS-IS terminology) all “pseudo-nodes” as well. This means when > advertising the set of nodes and associated indeces used in calculating the > flooding topology there needs to be an indication as to whether a given > entry is a node or a pseudo-node. The encoding for this is straightforward > in IS-IS (include pseudo-node ID in the node identifier) but more complex > in OSPF. > > However, this is a problem with a straightforward solution and is therefore > not a significant consideration. > > 2)Enablement/disablement of flooding on a LAN > > Correct operation of flooding on a LAN requires all nodes connected to the > LAN perform their role when the LAN is enabled for flooding and conversely > all nodes suppress flooding via the LAN when flooding is disabled for > flooding. This applies to temporary enablement of flooding on a LAN in the > event of a partitioned flooding topology i.e., if any node connected to the > LAN > signals enablement of temporary flooding on the LAN all nodes connected to > the > LAN MUST honor that request. > > Selective enablement of flooding on a LAN based on whether it is part > of the calculated flooding topology therefore entails some additional > complexity. > > Note that this discussion assumes that flooding operation on a LAN > is not altered by the introduction of flooding optimizations. For example > there is no proposal to selectively enable transmission of LSPs/LSAs on > a LAN only by a subset of the nodes connected to the LAN. > > 3)Use of LANs in flooding topology algorithms > > When LANs are considered part of the flooding topology, any algorithm > used to compute the flooding topology has to consider how to use LANs. > For example, using a LAN might have an advantage in that by enabling > flooding on a single LAN multiple nodes are now connected to the flooding > topology. This might reduce the number of point-to-point edges required > in the flooding topology and/or decrease the diameter of the flooding > topology. > > But use of a LAN might either increase the diameter of the flooding topology > and thereby affect convergence or unnecessarily increase the degree of > connectivity of certain nodes to the flooding topology and thereby reduce > the optimization achieved. > > If LANs are always enabled for flooding but are not included in the set of > nodes considered as part of the flooding topology (see point #1 above) then > "false partitions" might occur during the calculation of the flooding > topology. > > Whether LANs are considered part of the flooding topology or not, the > presence > of a LAN introduces the possibility that there are "hidden nodes" to which > flooding is actually occurring but which are not explicitly mentioned in > the calculated flooding topology. > > 4)Deployment Limitations > > The significance of support for LANs depends upon their existence in a > deployment where the use of flooding optimizations is desired. > > If all links are point-to-point then the question is irrelevant. > > If all links are point-to-point but ethernet links have not been configured > to operate in point-to-point mode then lack of support for LANs would > compromise the value of flooding optimizations. A counter argument to this > case is that unnecessary operation in LAN mode itself increases the number > of > LSPs/LSAs that need to be flooded by as much as 50% and therefore is > something which SHOULD be addressed by altering configuration. There > should > then be motivation for network operators to enable point-to-point operation > where possible even if they have not done so before. > > If LANs with more than 2 connected nodes are present and are used for > transiting traffic then lack of support for LAN circuits for flooding > optimizations will lead to diminished effectiveness of flooding optimizations. > > Summary: > > When forming an opinion on whether to include LANs in the flooding > topology > it is prudent to consider the above points. > > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
