Re: Operational feedback on policy redundancy
Saku Ytti via NANOG <[email protected]>
| Newsgroups | gmane.org.operators.nanog |
|---|---|
| Message-ID | <CAAeewD_o3vA2MCEoZoKQKy3dNK2_mgM04iCpk70+_ZtzFD8tKw@mail.gmail.com> |
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 <[email protected]> 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/[email protected]/message/3RJ45WJJ63KNKUCNT7A5BCVQXBVONJ3V/ -- ++ytti _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/XT52O5NJWPSTDXL6A7E2DLFBKJ5BR7GC/