I am in complete agreement with both Les’s extensive analysis and opinion. ;-)
Tony > On Apr 2, 2019, at 8:37 AM, Les Ginsberg (ginsberg) <[email protected]> > wrote: > > 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 <[email protected]> On Behalf Of Les Ginsberg (ginsberg) >> Sent: Tuesday, April 02, 2019 8:31 AM >> To: [email protected]; [email protected] >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
