Re: Operational feedback on policy redundancy

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*
[email protected] / +353 83 036 1875 (FaceTime & WhatsApp)


On Sat, 4 Apr 2026 at 19:46, Gary Sparkes via NANOG <[email protected]>
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 <[email protected]>
> Sent: Saturday, April 4, 2026 2:28 PM
> To: [email protected]
> Cc: [email protected]
> 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/[email protected]/message/4JDEGK25VXD74NSLJXJVVFDCEZFXLSK6/
> _______________________________________________
> NANOG mailing list
>
> https://lists.nanog.org/archives/list/[email protected]/message/HGOC44MU5R43FYL3HWHKGJZOH6ZLUIND/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/[email protected]/message/6TO3UN75ID4CLTUYMAGAKJ3OZESTK2UW/