Routing Configuration Guide for Cisco 8000 Series Routers, Cisco IOS XR Release

PDF

Routing policy language structures

Want to summarize with AI?

Log in

Describes the structure of RPL objects and sets, including named and inline forms, matching constructs, policy statements, conditional logic, apply behavior, parameterization, and supported set types used to build routing policies.


A routing policy language structure is a set of rules and syntax that

  • organizes how routing policies and sets are defined and named

  • specifies the valid elements and formats for sets such as as-path-sets, community-sets, extcommunity-sets, prefix-sets, and rd-sets, and

  • enables you to create, match, and manage routing policies effectively.

Routing policy language structures allow persistent, named objects to be created for both policies and sets. These sets serve as containers for matching various attributes, such as AS paths or communities, in policy conditions. Both inline and named forms are supported, providing flexibility for different configuration needs.


Policy objects in RPL

A policy object is a persistent, named configuration item in the Routing Policy Language (RPL) that can be defined as a set or a policy and is identified by a unique name.

To define a policy named test, use this structure.

route-policy test
[ . . . policy statements . . . ]
end-policy

Policy names can include uppercase and lowercase letters, numerals (0-9), period (.), hyphen (-), and underscore (_), and must begin with a letter or number.


Sets in RPL

A set is an unordered collection of unique elements in RPL that

  • is used as a container for groups of values for matching in conditional expressions

  • allows both named and inline forms, and

  • separates elements with commas, allowing null (empty) sets except where prohibited.

  • Named set: Defined and referenced by name.

  • Inline set: Defined inline within a policy for quick comparisons.

Inline sets

In this context, the term set is used in its mathematical sense to refer to an unordered collection of unique elements. In the routing policy language, sets serve as containers for grouped values that are used in matching operations within conditional expressions.

Elements in a set are separated by commas, and empty (null) sets are permitted.

When comparisons involve only a small number of elements, such as two or three community values, the values can be listed directly within the policy. These are referred to as inline sets.

Inline sets are functionally equivalent to named sets but allow simple comparisons without defining a separate set. This approach avoids maintaining a standalone set when only a small number of values are required.

In general, the syntax for an inline set is a comma-separated list enclosed in parentheses, where each entry corresponds to the required data type, for example, a prefix or community value.

route-policy sample-inline
  if community matches-any ([10..15]:100) then
    set local-preference 100
  endif
end-policy
community-set test-communities
  10:100,
  11:100,
  12:100,
  13:100,
  14:100,
  15:100
end-set

route-policy sample
  if community matches-any test-communities then
    set local-preference 100
  endif
end-policy

Both policies produce the same result. The inline form eliminates the need to configure a separate set when only a limited number of values are being compared. Either approach can be used depending on the configuration context.

Subsequent sections provide examples of both named and inline set usage where appropriate.

Consider this example:

prefix-set backup-routes
  # currently no backup routes are defined
end-set

If this set is referenced in a condition, if destination in backup-routes then, the condition evaluates to FALSE for every route because the set contains no matching entries.


AS path sets

An AS path set is a collection of match criteria for Autonomous System (AS) path attributes that

  • supports matching using regular expressions,

  • can be defined as a named set or an inline set, and

  • is used to match AS path attributes in route policies.

Named AS path set

The named AS path set form uses the ios-regex keyword to specify the regular expression type. Enclose each regular expression in single quotation marks.

as-path-set aset1
  ios-regex '_42$',
  ios-regex '_127$'
end-set

This AS path set contains two elements. In a matching operation, the system matches any route whose AS path ends with autonomous system (AS) number 42 or 127.

To remove this named AS path set, use the no as-path-set aset1 command.

An inline AS path set is defined as a list enclosed in parentheses and separated by commas.

(ios-regex '_42$', ios-regex '_127$')

This inline set matches the same AS paths as the named set, aset1, but does not require you to create a separate named set. It can be used directly within a policy where needed.

Regular expression matching requires significant CPU resources. You can improve policy performance by:

  • collapsing multiple regular expression patterns to reduce the total number of regular expression evaluations, or

  • using equivalent native AS path match operations such as as-path neighbor-is , as-path originates-from , or as-path passes-through .


Community sets

A community set is a named or inline set in RPL that

  • holds BGP community values for matching against the community attribute

  • requires community values as two unsigned decimal integers (0 to 65535) separated by a colon, and

  • supports parameterization and wildcards.

Named community set

A named community set is a user-defined collection of community values. It is configured with a unique name and referenced within routing policies to match the BGP community attribute.

Example:

community-set cset1
  12:34,
  12:56,
  12:78,
  internet
end-set

Define an inline community set as a list enclosed in parentheses and separated by commas. Use this list directly within a policy when needed.

The inline form also supports parameterization. Each 16-bit portion of the community value can be parameterized.

Example:

(12:34, 12:56, 12:78)
($as:34, $as:$tag1, 12:78, internet)

RPL provides symbolic names for standard well-known community values:

  • internet represents 0:0

  • no-export represents 65535:65281

  • no-advertise represents 65535:65282, and

  • local-as represents 65535:65283.

Community specifications may include wildcards. Define a wildcard by replacing one of the 16-bit portions of the community value with an asterisk. The wildcard matches any value for that portion.

Example:

community-set cset3
  123:*
end-set

This set matches all communities in which the autonomous system portion is 123.

Every community set must contain at least one community value. If a community set is empty, the system rejects it as invalid.


Extended community sets

An extended community set is a collection of extended-community values used in routing policies that

  • supports both named and inline forms, including parameterization within parameterized policies

  • permits matching using wildcards and regular expressions, and

  • contains at least one extended community value.

Extended community rt set

An extended community set is similar to a community set, but it contains extended community values instead of regular community values. Extended community sets support both named and inline forms.

As with community sets, the inline form supports parameterization within parameterized policies. Either portion of the extended community value can be parameterized.

Community specifications may include wildcards. Define a wildcard by replacing one of the 16-bit portions of the community value with an asterisk. The wildcard matches any value for that portion.

Every extended community set must contain at least one community value. If a community set is empty, the system rejects it as invalid.

There are three types of extended community sets:

  • cost

  • soo

  • rt

An rt set is an extended community set used to store BGP Route Target (RT) extended community type communities.

Example: Named form for extended community rt set

extcommunity-set rt a_rt_set
  203.0.113.4:666
  1234:666,
  203.0.113.4:777,
  4567:777
end-set

Example: Inline set form for extended community rt set

(203.0.113.4:666, 1234:666, 203.0.113.4:777, 4567:777)
($ipadrr:666, 1234:$tag, 1.2.3.4:777, $tag2:777)

A soo set is an extended community set used to store BGP site-of-origin (soo) extended community type communities.

Example: Named form for extended community soo set

extcommunity-set soo a_soo_set
  192.0.2.1:100,
  100:200
end-set

This table lists the options you can define under extcommunity-set .

Table 1. Supported options under extcommuniety-set rt and extcommunity-set soo

Option

Description

#-remark Remark beginning with '#'
* Wildcard (any community or part thereof)
<1-4294967295> 32-bit decimal number
<1-65535> 16-bit decimal number
A.B.C.D/M:N Extended community - IPv4 prefix format
A.B.C.D:N Extended community - IPv4 format
ASN:N Extended community - ASPLAIN format
X.Y:N Extended community - ASDOT format
abort Discard RPL definition and return to top level config
dfa-regex DFA style regular expression
end-set End of set definition
exit Exit from this submode
ios-regex Traditional IOS style regular expression
show Show partial RPL configuration

Prefix sets

A prefix set is a set in RPL that

  • holds IPv4 or IPv6 prefix match specifications

  • allows specification of address, mask length, minimum and maximum matching length, and

  • uses a comma-separated list of prefix specifications.

A prefix set contains IPv4 or IPv6 prefix match specifications. Each specification consists of four components:

  • address

  • mask length

  • minimum matching length, and

  • maximum matching length.

The address is mandatory. The remaining components are optional.

Prefix match specification format

Table 2. Prefix match specification components and defaults
Component Description IPv4 Range / Default IPv6 Range / Default
Address Expressed as a standard dotted-decimal IPv4 address or colon-separated hexadecimal IPv6 address. Standard IPv4 format Standard IPv6 format
Mask length
  • Optional

  • Follows the address, separated by a slash (/)

  • Must be a nonnegative decimal integer

  • Range: 0–32

  • Default (if not specified): 32

  • Range: 0–128

  • Default (if not specified): 128

Minimum matching length (ge)
  • Optional.

  • Specified using the ge keyword (greater than or equal to) followed by a nonnegative decimal integer.

  • Range: 0–32

  • Default: mask length

  • Range: 0–128

  • Default: mask length

Maximum matching length (le)
  • Optional.

  • Specified using the le keyword (less than or equal to) followed by a nonnegative decimal integer.

  • Range: 0–32

  • Default rules:

    • If ge is specified and le is not: 32

    • If neither ge nor le is specified: mask length

  • Range: 0–128

  • Default rules:

    • If ge is specified and le is not: 128

    • If neither ge nor le is specified: mask length

Exact match (eq)

Syntactic shortcut to specify an exact prefix length for matching.

Matches only the specified prefix length

Matches only the specified prefix length

Prefix set structure and examples

A prefix set is defined as a comma-separated list of prefix match specifications.

IPv4 examples

prefix-set legal-ipv4-prefix-examples
  192.0.2.1,
  192.0.2.2/24,
  192.0.2.3/24 ge 28,
  192.0.2.4/24 le 28,
  192.0.2.5/24 ge 26 le 30,
  192.0.2.6/24 eq 28,
  192.0.2.7/32 ge 16 le 24,
  192.0.2.8/26 ge 8 le 16
end-set

Explanation of IPv4 examples:

  • 192.0.2.1 matches only 192.0.2.1/32.

  • 192.0.2.2/24 matches only 192.0.2.2/24.

  • 192.0.2.3/24 ge 28 matches prefixes from 192.0.2.3/28 to 192.0.2.255/32.

  • 192.0.2.4/24 le 28 matches prefixes from 192.0.2.4/24 to 192.0.2.240/28.

  • 192.0.2.5/24 ge 26 le 30 matches prefixes from 192.0.2.5/26 to 192.0.2.252/30.

  • 192.0.2.6/24 eq 28 matches prefixes of length 28 from 192.0.2.0/28 through 192.0.2.240/28.

  • 192.0.2.7/32 ge 16 le 24 matches prefixes of length 32 in the range 192.0.[0..255].7/32 (from 192.0.0.7/32 to 192.0.255.7/32).

  • 192.0.2.8/26 ge 8 le 16 matches prefixes of length 26 in the range 192.[0..255].2.8/26 (from 192.0.2.8/26 to 192.255.2.8/26).

IPv6 examples

prefix-set legal-ipv6-prefix-examples
  2001:DB8:1::/64,
  2001:DB8:2::/64 ge 96,
  2001:DB8:2::/64 ge 96 le 100,
  2001:DB8:2::/64 eq 100
end-set

Explanation of IPv6 examples:

  • 2001:DB8:1::/64 matches only the single prefix 2001:DB8:1::/64.

  • 2001:DB8:2::/64 ge 96 matches prefixes derived from 2001:DB8:2::/64 with lengths from /96 through /128.

  • 2001:DB8:2::/64 ge 96 le 100 matches prefixes derived from 2001:DB8:2::/64 with lengths from /96 through /100.

  • 2001:DB8:2::/64 eq 100 matches only prefixes of length /100 derived from 2001:DB8:2::/64.

Validation Rules

  • Neither minimum length nor maximum length is valid without a mask length.

  • For IPv4, the minimum length must be less than 32.

  • For IPv6, the minimum length must be less than 128.

  • The maximum length must be equal to or greater than the minimum length.

Invalid prefix set examples

Table 3. Invalid prefix set examples and validation errors
Invalid example Validation rule error
192.0.2.1 ge 16 Minimum length (ge) specified without a mask length.
192.0.2.2 le 16 Maximum length (le) specified without a mask length.
192.0.2.3/24 le 23 Maximum length must be equal to or greater than the mask length; 23 is less than /24.
192.0.2.0/24 ge 33 For IPv4, the minimum length must be less than 32; 33 exceeds the valid range (0–32).
192.0.2.0/25 ge 29 le 28 Maximum length must be equal to or greater than the minimum length; 28 is less than 29.

ACL support in RPL prefix sets

Access Control List (ACL) type prefix set entries hold IPv4 or IPv6 prefix match specifications. Each specification includes an address and a wildcard mask. The address and wildcard mask use standard dotted-decimal IPv4 or colon-separated hexadecimal IPv6 notation.

The wildcard mask, also called an inverted mask, indicates which bits must match:

  • binary 0 indicates a mandatory match, that is, bits set to 0 must match exactly, and

  • binary 1 indicates a do not match condition, that is, bits set to 1 are ignored.

This format allows the prefix set to specify both contiguous and non-contiguous sets of bits that must be matched in a route.


Route distinguisher sets

A route distinguisher set (rd-set) is a set in RPL that

  • contains route distinguisher elements for BGP VPNs, and

  • allows specification in IPv4 or ASN formats, with support for wildcards and subnet masks.

A route distinguisher (RD) is a 64-bit value that is prepended to an IPv4 address to create a globally unique Border Gateway Protocol (BGP) VPN IPv4 address.

Supported route distinguisher formats

RD values can be defined using these formats.

Table 4. Supported RD formats
Format Description Example
a.b.c.d:m:* BGP VPN RD in IPv4 format with a wildcard character. 10.0.0.2:255.255.0.0:*
a.b.c.d/m:n BGP VPN RD in IPv4 format with a subnet mask. 10.0.0.2:255.255.0.0:666
a.b.c.d:** BGP VPN RD in IPv4 format with a wildcard character. 10.0.0.2:255.255.0.0
a.b.c.d:n BGP VPN RD in IPv4 format. 10.0.0.2:666
asn:* BGP VPN RD in ASN format with a wildcard character. 10002:255.255.0.0
asn:n BGP VPN RD in ASN format. 10002:666
rd-set rdset1
  10.0.0.0/8:*,
  10.0.0.0/8:777,
  10.0.0.0:*,
  10.0.0.0:777,
  65000:*,
  65000:777
end-set

Policy definitions

A policy definition is a route policy that

  • defines a named sequence of policy statements,

  • starts with the route-policy keyword and a policy name, and

  • ends with the end-policy keyword.

Policy definition syntax

Use this syntax to define a policy:

route-policy <name>
    <policy statements>
end-policy

This example shows a policy that drops any route it encounters:

route-policy drop-everything
    drop
end-policy

Policy statements in the body determine how routes are evaluated and modified.

To remove a policy definition, use the no route-policy <name> command.

A policy name is an identifier that you use to bind a policy definition to a protocol attach point.

Example bind point in BGP configuration:

router bgp 2
  neighbor 10.1.1.1
    remote-as 65535
    address-family ipv4 unicast
      route-policy param-example(10, prefix_set1)
      route-policy param-example(20, prefix_set2)

When you attach a policy at an attach point, the system applies the policy for routes at that location.


Policy statements

A policy statement is a route policy instruction that

  • defines how the policy evaluates, modifies, accepts, or rejects routes

  • runs in sequence as it appears in the policy, and

  • can include remarks, dispositions, actions, conditional logic, and policy calls.

Policy statement types

A route policy can include these policy statement types:

  • Remark

  • Disposition (drop, pass, done)

  • Action, such as, set operations

  • If (conditional logic)

  • Apply (run another policy from the current policy)


Remarks

A remark is a comment line in a policy that

  • starts with # at the beginning of each line

  • documents the policy, and

  • is ignored by the policy language parser.

RPL remark usage and persistence

You typically place remarks between complete statements or between elements of a set. You cannot place remarks in the middle of statements or within an inline set definition.

Unlike comments preceded by an exclamation mark in the CLI, RPL remarks persist through device reboots and when you save and reload configurations.

# This is a simple one-line remark.
# This
# is a remark
# comprising multiple
# lines.

Dispositions

A disposition statement is a policy statement that decides whether the policy accepts or rejects a route.

If the policy modifies a route, the route is accepted by default. If the policy does not modify a route, the route is dropped by default.

drop

The drop statement explicitly discards the route. When a drop is executed:

  • Policy execution stops immediately.

  • No further statements are evaluated.

route-policy DROP-EXAMPLE
  pass
  drop
  pass
end-policy

In this example, the first pass is overridden by the drop . The second pass is never executed. The route is dropped.

An explicit drop overrides any previously executed pass statement or attribute modification.

pass

Use the pass statement to prevent a route from being dropped when no modifications have occurred. This statement lets your route continue through policy execution.

When policy execution completes, a modified route or a route with a pass disposition passes the policy.

route-policy PASS-ALL
  pass
end-policy

This policy also passes all routes because it modifies a route attribute.

route-policy SET-LPREF
  set local-preference 200
end-policy

done

Use the done statement to stop the policy execution and accept the route. When the system encounters done statement:

  • The route passes through the policy.

  • The policy does not evaluate any remaining statements.

  • The policy preserves any modifications made before done statement.


Actions

An action is a sequence of operations that modifies route attributes. Many actions use the set keyword.

In a route policy, actions can be grouped together. In this example, the route policy named actions-example comprises three actions: two set actions, and one delete action.

route-policy actions-example
  set med 217
  set community (12:34) additive
  delete community in (12:56)
end-policy

If statements

An if statement is a conditional control structure in a route policy that

  • evaluates a Boolean condition

  • runs actions or dispositions when the condition is true, and

  • can include an optional else clause to run alternative actions when the condition is false.

Basic example

if as-path in as-path-set-1 then
  drop
endif
if origin is igp then
  set med 42
  prepend as-path 73.5 5
endif
Note

The CLI also supports exit as an alternative to endif .

Nested if behavior explanation

Table 5. Conditional variations in RPL
Construct Purpose Syntax Pattern Example Behavior
if Executes statements when the condition is true. if <condition> then ... endif
if as-path in as-path-set-1 then
  drop
endif
The system runs the statements only when the condition evaluates to true.
if–else Executes alternate statements when the condition is false. if <condition> then ... else ... endif
if med eq 8 then
  set community (12:34) additive
  else
  set community (12:56) additive
  endif
The then block runs if the condition is true; otherwise, the else block runs.
if–elseif–else Evaluates multiple conditions sequentially. if ... elseif ... else ... endif
if med eq 150 then
  set local-preference 10
  elseif med eq 200 then
  set local-preference 60
  elseif med eq 250 then
  set local-preference 110
  else
  set local-preference 0
  endif
The system tests conditions in order. It executes the first condition that is true. If no condition matches, the else block runs.
Nested if Allows conditional logic inside another conditional block. if ... then if ... then ... endif ... endif
if community matches-any (12:34,56:78) then
  if med eq 150 then
  drop
  endif
  set local-preference 100
  endif
The system evaluates the inner condition only if the outer condition is true.

In the nested example:

if community matches-any (12:34,56:78) then
  if med eq 150 then
    drop
  endif
  set local-preference 100
endif
  • Routes matching community 12:34 or 56:78 receive local preference 100 .

  • Routes that also have MED 150 are dropped.

  • The inner if statement executes only when the outer condition is satisfied.


Boolean conditions

A Boolean condition is an expression that evaluates to true or false and is used in an if statement.

Supported boolean operators

  • not (negation)

  • and (conjunction)

  • or (disjunction)

Operator precedence

  1. not

  2. and

  3. or

Table 6. Boolean condition examples in RPL
Condition type Expression Description
Simple condition med eq 42 True only if the MED value is 42.
Negation not next-hop in (198.51.100.2) Evaluates to true if the next-hop is not 198.51.100.2.
Compound condition (and) med eq 42 and next-hop in (198.51.100.2) True only if both conditions are true.
Compound condition (or) origin is igp or origin is incomplete True if either condition is true.
Grouped condition (med eq 42 and next-hop in (198.51.100.2)) Parentheses group conditions to control their evaluation.
Operator precedence example
med eq 10 or not destination in (198.51.100.0/24) and community matches-any ([12..34]:[56..78])
Evaluated using operator precedence: not, then and, then or.
Parentheses override precedence
med eq 10 or ((not destination in (198.51.100.0/24)) and community matches-any ([12..34]:[56..78]))
Parentheses show the order in which conditions are evaluated.
Grouped disjunction and conjunction example
(origin is igp or origin is incomplete or not med eq 42) and next-hop in (198.51.100.2)
Combines grouped disjunction with conjunction.

Apply statements

An apply statement is a route policy statement that

  • runs another policy from within the current policy

  • can run a parameterized or unparameterized policy, and

  • returns execution to the calling policy unless the applied policy drops the route.

How the apply statement works

When a route policy uses an apply statement, the applied policy is evaluated inline, exactly as if its statements were written at that location in the calling policy.

Key points:

  • The applied policy executes first, at the point where apply appears.

  • Drop and pass semantics are preserved:

    • If the applied policy drops the route, execution stops immediately.

    • If the applied policy does not drop the route, control returns to the calling policy and evaluation continues.

  • The final outcome is identical to manually expanding the applied policy in place.

The combination of main-policy and filter-destination policies functions the same as the expanded policy called main-policy-expanded .

Calling policy:

route-policy main-policy
  apply filter-destination
  if as-path neighbor-is '123' then
    pass
  endif
end-policy

Applied policy:

route-policy filter-destination
  if destination in (10.0.0.0/16 le 32) then
    drop
  endif
end-policy

Equivalent expanded policy:

route-policy main-policy-expanded
  if destination in (10.0.0.0/16 le 32) then
    drop
  endif
  if as-path neighbor-is '123' then
    pass
  endif
end-policy

Using the apply statement provides a structural convenience. It promotes reuse and readability without changing policy behavior. The router evaluates the logic as though the applied policy is written inline at the point of invocation.


Hierarchical policies using apply

A hierarchical policy is a route policy that

  • references another policy by using the apply statement

  • reuses common policy logic across multiple policies, and

  • behaves as if the referenced policy content is inserted where you call apply.

Example policy that applies another policy:

route-policy check-as-1234
  if as-path passes-through '1234.5' then
    apply drop-everything
  else
    pass
  endif
end-policy

If the route passed through autonomous system 1234.5 before the system receives it, the policy applies the drop-everything policy and drops the route. If the route did not pass through autonomous system 1234.5 before the system receives it, the policy accepts the route without modification.

Equivalent policy with the applied content inline:

route-policy check-as-1234-prime
  if as-path passes-through '1234.5' then
    drop
  else
    pass
  endif
end-policy
Note

Avoid creating too many hierarchy levels to keep your policies easy to manage and understand.


Parameterization

Parameterization is a route policy capability that

  • lets you define a policy that accepts one or more parameters

  • uses parameters that start with $ and contain only alphanumeric characters, and

  • allows you to substitute parameters into any attribute that accepts a parameter.

Policy parameterization

In addition to reusing policies through the apply statement, you can define policies to accept parameters. Substitute these parameters into attributes within the policy as needed.

Example 1:

route-policy param-example ($mytag)
  set community (1234:$mytag) additive
end-policy

In this example, the policy param-example takes one parameter, $mytag , which is used as part of a 16-bit community tag.

Example 2:

In this example, the policy takes two parameters, $mymed and $prefixset .

route-policy param-example ($mymed, $prefixset)
  if destination in $prefixset then
    set med $mymed
  endif
end-policy

In this case, a MED value and a prefix-set name are passed as parameters and substituted into the policy statements.

Reuse using apply with parameters

You can reuse a parameterized policy with different values by supplying arguments in the apply statement.

Example:

route-policy origin-10
  if as-path originates-from '10.5' then
    apply param-example(10.5)
  else
    pass
  endif
end-policy
route-policy origin-20
  if as-path originates-from '20.5' then
    apply param-example(20.5)
  else
    pass
  endif
end-policy

When you provide values in the apply statement, the policy param-example uses those values. If you change the definition of param-example , origin-10 and origin-20 automatically change their behavior.

The origin-10 policy adds the community 1234:10 to routes that originate from autonomous system 10. Similarly, origin-20 adds the community 1234:20 to routes originating from autonomous system 20.

Parameterization at attach points

The system also supports parameterization at attach points. You can supply parameters at attach points when you bind the policy to a protocol configuration.

Example:

router bgp 2
  neighbor 192.0.2.1
    remote-as 3
    address-family ipv4 unicast
      route-policy param-example(10, prefix_set1)
      route-policy param-example(20, prefix_set2)

In this case, the parameterized policy param-example is expanded using the values provided in the route-policy configuration at the attach point.

Global parameterization

RPL supports systemwide global parameters that you can reference in policy definitions.

To define global parameters, use this format:

policy-global
  glbpathtype 'ebgp'
  glbtag '100'
end-global

Use these values in a policy definition the same way you use local parameters.

Example:

route-policy globalparam
  if path-type is $glbpathtype then
    set tag $glbtag
  endif
end-policy

Local and global parameter precedence

  • If you define a parameter in your policy with the same name as a global parameter, the local parameter takes precedence and hides the global parameter.

  • You cannot delete a global parameter that any policy references.