Tony – This is not what I was trying to say.
It is true that I still “kind of wish” we could just say “LANs always enabled for flooding” and be done with it. But as there are (or could be) cases where LANs are part of the deployment, I think it is more robust if we define the protocol extension in a way that supports LANs. This means – at a minimum – that the defined encoding needs to allow pseudo-nodes to be assigned an index. It is then up to the algorithm(s) to decide how to make use of LANs. One option would be to treat LANs as always on and always include them in the advertised flooding topology (centralized mode). It would then be legitimate for one vendor to offer algorithm(s) which always use all LANs for flooding. Benefits of this might be simplicity. Drawbacks may be sub-optimal flooding reduction in some topologies. Another vendor may offer an algorithm that is more sophisticated in its use of LANs for flooding and tout the benefits while reassuring customers regarding the risk associated with complexity. But if we don’t allow for support of LANs then we restrict the topologies in which it is possible to reap significant benefits. I think there is enough evidence to suggest that we might encounter LANs in some target topologies – so I am opting to agree with what Tony L has been advocating for quite a while now – let’s define extensions that leave open optimal support in a larger set of topologies. Hope this is clear. Les From: Tony Przygienda <tonysi...@gmail.com> Sent: Tuesday, April 02, 2019 3:34 PM To: Acee Lindem (acee) <a...@cisco.com> Cc: tony...@tony.li; Les Ginsberg (ginsberg) <ginsb...@cisco.com>; lsr@ietf.org Subject: Re: [Lsr] Open issues with Dynamic Flooding: Including LANs in the Flooding Topology 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<mailto:a...@cisco.com>> wrote: I agree as well. Thanks, Acee On 4/2/19, 1:26 PM, "Lsr on behalf of tony...@tony.li<mailto:tony...@tony.li>" <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> on behalf of tony...@tony.li<mailto: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<mailto: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<mailto:lsr-boun...@ietf.org>> On Behalf Of Les Ginsberg (ginsberg) >> Sent: Tuesday, April 02, 2019 8:31 AM >> To: tony...@tony.li<mailto:tony...@tony.li>; lsr@ietf.org<mailto: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<mailto:Lsr@ietf.org> >> https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
