For the purpose of this discussion can someone quote the definition of LAN ?
Why ? *1* In most modern data centers I do not see any LANs. Even compute nodes are L3 nodes connected over /31 or /30 to TORs. From fabric IGP this is passive interface. *2* In slightly older DCs there are redundant L3 access routers connecting in an L2 /24 fashion to TORs and towards computes there is VRRP/HSRP. Is this LAN we need to worry about ? *3* Then we have non routing aware devices on say /29 subnets acting as NFVs - is this a LAN flooding computation needs to worry about ? Or is LAN only when IGPs decide to compute DR/BDR ? Maybe before we move on here it would be actually useful to propose a one page lsr draft stating that implementations should automagically enable ospf/isis point to point behavior when there is /31 or /30 subnet configured on the interface ? Is there a reason why this is still a manual knob ? Thx, R. On Wed, Apr 3, 2019 at 12:34 AM Tony Przygienda <[email protected]> wrote: > 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) <[email protected]> wrote: > >> I agree as well. >> Thanks, >> Acee >> >> On 4/2/19, 1:26 PM, "Lsr on behalf of [email protected]" < >> [email protected] on behalf of [email protected]> 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) < >> [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 >> >> >> _______________________________________________ >> Lsr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr >> > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
