Summary

  • RFC 3318 let a policy role-combination begin with *, so one reusable rule could match interfaces that shared required roles while carrying any number of additional roles.
  • That compression did not define precedence. If several matching policies conflicted, the PDP had to resolve them; the PEP had to reject unresolved conflict rather than invent a local policy.

In a configuration system, repetition is visible and ambiguity is not. Thousands of nearly identical interface rules look expensive, so designers search for an abstraction that will say the common part once. RFC 3318 offered roles. It also recorded the price of that compression with unusual precision: the moment a wildcard made one interface eligible for more than one policy, someone still had to own the collision.

The document defined the Framework Policy Information Base used around COPS-PR. A Policy Decision Point, or PDP, selected provisioning information. A Policy Enforcement Point, or PEP, represented the device that would accept and enforce it. SPPI supplied the language of provisioning classes and instances. RFC 3318 added common vocabulary for roles, capability sets, state incarnations, limitations and errors.

A role was simply a string associated with an interface: finance, manager, Backbone_interface, or another description of function. One interface could carry several roles. A policy instance carried a role-combination, and applicability depended on matching that combination against the interface's set. This indirection was valuable because a central policy did not need to know that one vendor called a port Gi0/1 and another used a different local identity.

The representation was stricter than an ordinary tag list. Comparisons were case-sensitive. Roles in a combination were ordered lexicographically by their ASCII values. a+b was the valid rendering of one set; b+a did not name another set, but was an invalid rendering of the same one. An interface with no roles had the null combination. These details created a canonical form that two endpoints could compare without first negotiating how to print a set.

Then came the asterisk. In policy classes with install or install-notify access, a combination such as *+a+b matched an interface that included a and b plus zero or more other roles. The star could not itself be reported as an interface role, and it was not a substring wildcard inside a name. Its job was set inclusion. RFC 3318's example says *+b+e+g would match a+b+c+e+f+g.

This reduced policy volume. If three interfaces all carried roles A and B, but also carried R1, R2 and R3 respectively, one *+A+B policy could cover them. The PDP did not have to install three copies that differed only in the extra role. The abstraction saved configuration bytes and made intent easier to state.

But inclusion is not precedence. The RFC explicitly allowed an interface to match more than one wildcarded role combination. Two matches might be compatible, or they might both try to assign an incompatible treatment. The PDP was expected to resolve conflicts before sending the policies. If it sent multiple policies that conflicted—through a controller mistake or because of a device-specific constraint—the PEP had to reject the installation and return an error.

The finance-and-manager example located authority even more clearly. Initially, two interfaces might carry finance and another manager. When one finance user became a manager, that interface reported the new combination finance+manager. The PDP could decide that manager policy took precedence, or it could create a third policy, such as a distinct DSCP marking for finance managers. What it could not do was leave the PEP to manufacture the answer by merging the two older policies. RFC 3318 said the PEP was neither required nor allowed to construct policy for a new combination.

That sentence prevents a tempting but dangerous shortcut. A device close to the packet has all the inputs and might seem best placed to combine rules. Yet local synthesis would turn enforcement into decision-making. Different vendors could merge the same inputs differently, and the central controller could no longer explain which policy had authorized the result. Rejection preserved the boundary: a failed decision was visible; an improvised decision might look successful.

Role changes also had an order. The PEP reported role combinations and interface associations in full request state. A PDP could later send new associations in an unsolicited decision. If the PEP processed them, it first returned success, then sent updated full-state requests for open contexts. The PDP was not supposed to assume the new state before that success. During the transition, other decisions could still reflect the old roles.

So a renamed role was not proof that all dependent policy had changed at the same instant. There were separate facts: the intended role assignment, the device's acceptance of that assignment, the refreshed request state, the PDP's replacement decisions, and the PEP's reports. RFC 3084 provided the broader request, decision and report mechanism; RFC 3159 supplied the PIB modeling rules. The chain mattered because a role label was an input to policy, not a receipt for the resulting packet treatment.

Security protected the exchange but could not supply a missing precedence rule. RFC 3318 warned that configurable information could be disastrously misconfigured and pointed to protection between PDP and PEP. Authentication could show who sent two matching policies. Encryption could hide them in transit. Neither could decide whether finance or manager should win, or whether their combination was safe on a particular device.

The architecture later became historical in the formal sense as well. In 2016, the IESG moved RFC 3318, COPS-PR and SPPI to Historic, noting limited deployment and the shift of network-management work toward NETCONF and YANG. That record limits any claim that the role mechanism became common practice. It does not make the collision problem obsolete.

The durable point is not the syntax of *+a+b. It is the separation of compression from authority. A wildcard can reduce the number of rules, but it cannot decide what overlapping rules mean. RFC 3318 named the controller as the place for that decision and rejection as the device's safe answer when the decision was incomplete. That is a more useful historical receipt than a claim that the asterisk made policy simple.

Sources: RFC 3318, RFC 3084, RFC 3159, and the 2016 IESG status change.