Tony - From: Lsr <[email protected]> On Behalf Of [email protected] Sent: Thursday, March 07, 2019 9:16 AM To: Tony Li <[email protected]> Cc: [email protected]; Peter Psenak (ppsenak) <[email protected]> Subject: Re: [Lsr] Open issues with Dynamic Flooding
On Mar 5, 2019, at 1:31 PM, [email protected]<mailto:[email protected]> wrote: Let me propose that we add something to sections 6.7.5, 6.7.9, and 6.7.11 like: Addition of temporary flooding should be done with caution, as the addition of excessive connectivity to the flooding topology may trigger unwanted behavior. Routers SHOULD add temporary flooding in a rate limited manner, if not configured otherwise. [Les:] The first sentence is OK with me. The second one I think goes beyond anything on which we can claim consensus. Whether adding the first sentence alone is worth a new revision I think is questionable – but I certainly would not oppose it. Regarding LANs, the encoding for OSPF is more problematic – basically we need to identify the value as a router id or a network LSA id (or something like that). So, committing to this without consensus has a downside that we might live to regret. I am in agreement with Peter’s position. LANs introduce additional complexity and it is not clear that including that support is a real benefit in the topologies in which we expect the flooding optimizations to be used. I know you believe real deployments may need this support – but what I don’t know is whether we have hard evidence to support that position. I am also wondering whether the following serves us better: a)We keep LANs always enabled for flooding b)The algorithms consider this and are biased towards using LANs when possible as this is a cheaper way to enable flooding to multiple nodes than many P2P interfaces. IN this way we keep the simplicity of not having to define LAN behavior/encoding, yet reap benefits in topologies where LANs have a significant presence. Let me know what problems you see with this approach. Les Hi, I haven’t heard any feedback on this. Can we please adopt this? The draft cutoff is Monday, March 11. Could we please incorporate this change and the addition of the pseudonode identifier by then? Tony
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
