My 2c... Your examples sound like decisions made in different contexts - perhaps of time, or focus. The VoIP requirement was probably set first since this is fundamental for it, and at a later time the overall latency requirement was set, but at a broader level. Or perhaps it is known that the general latency requirement isn't that "set in stone" and it's safer to keep a <25ms requirement at the service level for VoIP should the general requirement change. The same can be applied to ACLs: you might apply a protection that in principle should never be needed to an element because the other "protector" might still fail, be mishandled, etc. Probably even more so if it's an intent-based system - both the intent and the translation of the intent to the actual device's configuration might have issues that one might want to avoid being a victim of, in certain cases. In general, though... if everything is intent-based, in a very solid system intent redundancy and intent conflicts should be easily detectable and avoidable. If desired and justifiable since that does not come free... *Pedro Martins Prado* pedro.prado@gmail.com / +353 83 036 1875 (FaceTime & WhatsApp) On Sat, 4 Apr 2026 at 19:46, Gary Sparkes via NANOG <nanog@lists.nanog.org> wrote:
In my view, one or the other can be overridden, while the other can't.
For example, that 'general' latency requirement, while ridiculous, could theoretically be waived for services that are located off-site or in a different geographic region. While the VOIP requirement is hard for service delivery.
Firewall rule interaction can also be a tricky space because behavior may not appear evident from what the rules say 'in plain language' but how they technically interact.
You can have traffic traverse a firewall and just pass on without processing, as well.
Some also make some technical/functional sense too - IE: On BGP, have an overarching announce of our entire /32 space, but also announce more specific prefixes at the locations they're required. The more specific prefix 'wins' in BGP, so it may appear redundant or confusing at first.
Prioritization is definitely key, but as you see with the 20 vs 25ms above, while the general policy might be waved, you might still have specific sub requirements for specific things that would need to be waived as well, or adhered to without *further* waivers/exceptions.
-----Original Message----- From: manwar--- via NANOG <nanog@lists.nanog.org> Sent: Saturday, April 4, 2026 2:28 PM To: nanog@lists.nanog.org Cc: manwar@illinois.edu Subject: Re: Operational feedback on policy redundancy
Hi all,
Thanks for the feedback, and apologies if this isn’t the right forum for this kind of question.
To clarify: the data comes from an intent-based enterprise network, where the intents are high-level requirements collected from a running production system.
By redundancy, I mean cases like: - A general requirement (e.g., “latency < 20ms for all services”) alongside a weaker, service-specific one (e.g., “VoIP latency < 25ms”), where the latter is effectively subsumed.
By conflicts, I mean situations like: - One intent requiring all traffic to traverse a firewall, while another requires no middleboxes for performance-sensitive services.
In this dataset, such cases often appeared without explicit documentation of how they were resolved. My assumption is that, in practice, these get handled via implicit prioritization or later clarification.
So my main question is: At the high-level goal / intent layer (before translation into ACLs, BGP policy, etc.): - Do redundant or overlapping requirements tend to exist in practice? - Is it common for conflicts to be resolved through undocumented clarifications or implicit prioritization?
I do intend to publish the results of this work once the project is complete, with the goal of making it useful for operators as well.
Appreciate any insights.
Best regards, Mubashir _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/4JDEGK25... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/HGOC44MU...