Operational feedback on policy redundancy
Hello, I am a PhD student currently looking at the long-term management of network policies and intents. In studying a large-scale production dataset from a service provider, I found that over 95% of the operational intents were semantically redundant (meaning they were completely shadowed or subsumed by broader, older rules). I am trying to understand if this high level of policy bloat matches the actual experience of operators in the field: Redundancy: Is cleaning up shadowed or redundant rules a regular part of your workflow, or do they just tend to stay in the system for years once they're active? Conflicts: How often do you run into cases where multiple goals (which all seem fine on their own) accidentally create a conflict when they are enforced together over the same traffic? Resolutions: Is there a standard way you "relax" or prioritize these goals when you find they are fighting each other? Thank you for any operational insights you can share. Best regards, Mubashir Anwar University of Illinois Urbana-Champaign
I'm skeptical of the data. What do you exactly mean? This list largely deals with stateless IP routers, and I am assuming this context. What are the 'operational intents' you refer to? Are they ACL rules, BGP policies? Because in either context, I don't believe 95% to be redundant for a moment, so I must be confused and you're talking about something entirely different. You're not going to receive any input, because no one knows what you're asking. On Fri, 3 Apr 2026 at 22:48, manwar--- via NANOG <nanog@lists.nanog.org> wrote:
Hello,
I am a PhD student currently looking at the long-term management of network policies and intents. In studying a large-scale production dataset from a service provider, I found that over 95% of the operational intents were semantically redundant (meaning they were completely shadowed or subsumed by broader, older rules).
I am trying to understand if this high level of policy bloat matches the actual experience of operators in the field:
Redundancy: Is cleaning up shadowed or redundant rules a regular part of your workflow, or do they just tend to stay in the system for years once they're active? Conflicts: How often do you run into cases where multiple goals (which all seem fine on their own) accidentally create a conflict when they are enforced together over the same traffic? Resolutions: Is there a standard way you "relax" or prioritize these goals when you find they are fighting each other?
Thank you for any operational insights you can share.
Best regards, Mubashir Anwar University of Illinois Urbana-Champaign _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3RJ45WJJ...
-- ++ytti
I wonder about the nature of such inquiries these days, especially when there are so many folks compiling this data for use in LLMs and the like. Perhaps you might elaborate on the usage a bit more and how such a collection of data (once you refine what it is your looking for) would be of benefit to the audience your asking participation from, i.e. Publishing your findings for all to use afterwards. I agree with Saku, you're not likely to get much input without such. -Joe On Sat, Apr 4, 2026 at 4:27 AM Saku Ytti via NANOG <nanog@lists.nanog.org> wrote:
I'm skeptical of the data. What do you exactly mean?
This list largely deals with stateless IP routers, and I am assuming this context.
What are the 'operational intents' you refer to? Are they ACL rules, BGP policies? Because in either context, I don't believe 95% to be redundant for a moment, so I must be confused and you're talking about something entirely different.
You're not going to receive any input, because no one knows what you're asking.
On Fri, 3 Apr 2026 at 22:48, manwar--- via NANOG <nanog@lists.nanog.org> wrote:
Hello,
I am a PhD student currently looking at the long-term management of
network policies and intents. In studying a large-scale production dataset from a service provider, I found that over 95% of the operational intents were semantically redundant (meaning they were completely shadowed or subsumed by broader, older rules).
I am trying to understand if this high level of policy bloat matches the
actual experience of operators in the field:
Redundancy: Is cleaning up shadowed or redundant rules a regular part of
your workflow, or do they just tend to stay in the system for years once they're active?
Conflicts: How often do you run into cases where multiple goals (which all seem fine on their own) accidentally create a conflict when they are enforced together over the same traffic? Resolutions: Is there a standard way you "relax" or prioritize these goals when you find they are fighting each other?
Thank you for any operational insights you can share.
Best regards, Mubashir Anwar University of Illinois Urbana-Champaign _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3RJ45WJJ...
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/XT52O5NJ...
I found that over 95% of the operational intents were semantically redundant (meaning they were completely shadowed or subsumed by broader, older rules).
I also find it very difficult to believe that 95% of things were redundant or duplicative, be it ACLs / BGP policies , or really anything. There are absolutely cases, say with ACLs, that you apply less permissive filtering at different network layers; however, this is usually an intentional design choice, not a bug. Conflicts: How often do you run into cases where multiple goals (which all
seem fine on their own) accidentally create a conflict when they are enforced together over the same traffic? Resolutions: Is there a standard way you "relax" or prioritize these goals when you find they are fighting each other?
Again assuming you're talking about ACLs / protocol policies, these are pretty binary. Either they work or they don't. Conflicting ACLs would almost by definition only mean traffic is blocked where it shouldn't be. Conflicting protocol policies means routes don't show up where/how they should, so something isn't working right. Agree with the other comments, without more context I'm not sure you're going to get helpful feedback. On Fri, Apr 3, 2026 at 3:48 PM manwar--- via NANOG <nanog@lists.nanog.org> wrote:
Hello,
I am a PhD student currently looking at the long-term management of network policies and intents. In studying a large-scale production dataset from a service provider, I found that over 95% of the operational intents were semantically redundant (meaning they were completely shadowed or subsumed by broader, older rules).
I am trying to understand if this high level of policy bloat matches the actual experience of operators in the field:
Redundancy: Is cleaning up shadowed or redundant rules a regular part of your workflow, or do they just tend to stay in the system for years once they're active? Conflicts: How often do you run into cases where multiple goals (which all seem fine on their own) accidentally create a conflict when they are enforced together over the same traffic? Resolutions: Is there a standard way you "relax" or prioritize these goals when you find they are fighting each other?
Thank you for any operational insights you can share.
Best regards, Mubashir Anwar University of Illinois Urbana-Champaign _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3RJ45WJJ...
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
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...
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...
It strikes me that what you are describing is a management/governance problem, not a technical problem. If your employer's governance program produces conflicting, impossible to implement, or nonsensical KPIs, you can't fix that with technology. I suggest referring to Simon Travaglia's excellent series of writings on network operations for the correct solution to this governance problem. To wit: the elevator doesn't have to be there when the doors open and the governance team is looking at their phones instead of paying attention... Andrew On Sat, Apr 4, 2026 at 2:28 PM manwar--- via NANOG <nanog@lists.nanog.org> wrote:
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...
On Fri, Apr 3, 2026 at 11:49 AM manwar--- via NANOG <nanog@lists.nanog.org> wrote:
I am a PhD student currently looking at the long-term management of network policies and intents. In studying a large-scale production dataset from a service provider, I found that over 95% of the operational intents were semantically redundant (meaning they were completely shadowed or subsumed by broader, older rules).
Howdy, How have you determined that the redundancies are unintentional (i.e.bloat)? Networks are dynamic systems. You're looking at a snapshot or snapshots. Things break. This changes which rules apply at any given instant.
To clarify: the data comes from an intent-based enterprise network, where the intents are high-level requirements collected from a running production system.
Actually, I'm curious if anyone in the ISP world is using intent-based networking. I've read about the concept but it struck me as an easy way to dig yourself a very deep hole. Networking at the ISP level is heavily focused on managing how things break. Because things break. A lot. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
I think this is a VERY important point to make. One team might be responsible for VOIP, so they set their intent requirement, which ignores any other intent requirements coming from other teams. The duplication/conflict is VERY intentional. Shane On Sat, Apr 4, 2026 at 3:17 PM Pedro Prado via NANOG <nanog@lists.nanog.org> wrote:
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... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/6TO3UN75...
I can attest that a very large American ISP/Telco/Wireless Provider is using intent based systems all over the place. On Sat, Apr 4, 2026 at 4:16 PM William Herrin via NANOG < nanog@lists.nanog.org> wrote:
On Fri, Apr 3, 2026 at 11:49 AM manwar--- via NANOG <nanog@lists.nanog.org> wrote:
I am a PhD student currently looking at the long-term management of network policies and intents. In studying a large-scale production dataset from a service provider, I found that over 95% of the operational intents were semantically redundant (meaning they were completely shadowed or subsumed by broader, older rules).
Howdy,
How have you determined that the redundancies are unintentional (i.e.bloat)? Networks are dynamic systems. You're looking at a snapshot or snapshots.
Things break. This changes which rules apply at any given instant.
To clarify: the data comes from an intent-based enterprise network, where the intents are high-level requirements collected from a running production system.
Actually, I'm curious if anyone in the ISP world is using intent-based networking. I've read about the concept but it struck me as an easy way to dig yourself a very deep hole. Networking at the ISP level is heavily focused on managing how things break. Because things break. A lot.
Regards, Bill Herrin
-- For hire. https://bill.herrin.us/resume/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/6OJEUIUJ...
Intent Based Networking is the love child of a failed network engineer, and an MBA. On Sat, Apr 4, 2026 at 5:42 PM Shane Ronan via NANOG <nanog@lists.nanog.org> wrote:
I can attest that a very large American ISP/Telco/Wireless Provider is using intent based systems all over the place.
On Sat, Apr 4, 2026 at 4:16 PM William Herrin via NANOG < nanog@lists.nanog.org> wrote:
On Fri, Apr 3, 2026 at 11:49 AM manwar--- via NANOG <nanog@lists.nanog.org> wrote:
I am a PhD student currently looking at the long-term management of network policies and intents. In studying a large-scale production dataset from a service provider, I found that over 95% of the operational intents were semantically redundant (meaning they were completely shadowed or subsumed by broader, older rules).
Howdy,
How have you determined that the redundancies are unintentional (i.e.bloat)? Networks are dynamic systems. You're looking at a snapshot or snapshots.
Things break. This changes which rules apply at any given instant.
To clarify: the data comes from an intent-based enterprise network, where the intents are high-level requirements collected from a running production system.
Actually, I'm curious if anyone in the ISP world is using intent-based networking. I've read about the concept but it struck me as an easy way to dig yourself a very deep hole. Networking at the ISP level is heavily focused on managing how things break. Because things break. A lot.
Regards, Bill Herrin
-- For hire. https://bill.herrin.us/resume/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/6OJEUIUJ... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/DIQHWC5R...
Tom Beecher via NANOG wrote on 04/04/2026 23:12:
Intent Based Networking is the love child of a failed network engineer, and an MBA.
it's mostly relevant to small/medium enterprise networks, which will have different operational goals to service provider networks. As a general principle, if you try to optimise for a specific outcome on any system - e.g. improving latency/throughput to a specific destination - there's invariably a cost. In the case of intent-based networking, the cost will be complexity and routing consistency and long term maintenance. For a tiny network with simple edges, that might not be a problem. For larger networks, it probably will be. Worse still, undoing complex networking configuration is a complex operation in its own right and often leads to unexpected service loss. Any fool can build a complex network, but it takes skill to create a simple one. The fact that some larger networks use intent-based networking doesn't change this calculus. Nick
Hi Mubashir, Looks like it is a 10y old mantra "Intent-based QoS/QoE". You would better search for a feedback from some Enterprise/Business networking alias, not Telco. It does not makes sense for Telco, Telco is the "best effort". The best $$ from B2B segment (in Telco) that I have seen was 50%:50%, but even for that Telco, B2B traffic was still <5%. The rest was B2C (means "subscribers"). 5% of traffic could be easily prioritized (simple and hard policy), and that’s it - problem solved. No need for any fancy QoS - subscribers (95%) would never pay for it. The situation is different for Enterprises where QoS may be needed for >50% of traffic. Hence, search your customer there. There were hundreds of attempts for every big Telco to depart from "best effort" and sell 95% of traffic to subscriber or OTT (on the other end). All failed, Telco is a "dump pipe", like them or not. I could say even more - there are example of anti-QoS. Some Telco implemented advanced traffic engineering to equalize the load on all infrastructure. It is possible to improve ROI in the order of 30%. I have seen a situation when Enterprise customer was asking Telco: "how you did it? The ping from the neighboring desktops in the branch has a 10ms different latency to HQ inside the same MPLS VPN". It is because hash has put one ping into the short LSP tunnel, but the second one in a different LSP tunnel. You see: ROI is more important than QoS, QoS could be sacrificed on purpose. If you change your topic to "Intend-based OAM" (that is actually "closed loop automation" to predict and repair), then it make sense for both: Telco and Enterprise. But then "latency", "jitter" and all other QoS staff should not be mentioned. "Mean time to repair" is the KPI. Eduard
-----Original Message----- From: manwar--- via NANOG <nanog@lists.nanog.org> Sent: Saturday, April 4, 2026 21:28 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/4JDEGK2 5VXD74NSLJXJVVFDCEZFXLSK6/
participants (11)
-
Andrew Kirch -
Gary Sparkes -
Joe -
manwar＠illinois.edu -
Nick Hilliard -
Pedro Prado -
Saku Ytti -
Shane Ronan -
Tom Beecher -
Vasilenko Eduard -
William Herrin