Read it through (fairly slowly even ;-) and seems Les is for simply always including LAN in the flood reduction topology. I would concur with that. figuring whether a LAN is transit is basically calculation whether it's a minimal cut. solving that is polynomial of course. When we have multiple LANs to decide what is the maximum subset of LANs that can be cut without paritioning the graph (i.e. how many LANs can we omit while still having the graph connected) smells to me NP complet'ish but I don't think I ever dealt with the problem. At worst it's combination of LANs * polynomial computaton so about sum_1_k (n over k) * polynomial which looks tad chewy to me ... then, LAN floods efficiently in terms of fanout compared to p2p replication in IGPs so there's this unknown optimization constant that affects overall solution ...
Obvioulsy, someone could implement a very clever algorithm how to avoid LANs or account for their efficiency and so on so IMO the draft doesn't even need to say anything normative if no algorithm is given as intended AFAIR --- tony On Tue, Apr 2, 2019 at 10:32 AM Acee Lindem (acee) <a...@cisco.com> wrote: > I agree as well. > Thanks, > Acee > > On 4/2/19, 1:26 PM, "Lsr on behalf of tony...@tony.li" < > lsr-boun...@ietf.org on behalf of tony...@tony.li> wrote: > > > 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) < > ginsb...@cisco.com> 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 <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 > > > _______________________________________________ > 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
