A Policy Control Mechanism in IS-IS Using Administrative Tags
Extracted elements (17)
Both 32-bit and 64-bit tag widths are provided to support carrying BGP standard communities (32-bit) and BGP extended communities (64-bit), enabling direct mapping between BGP community values and IS-IS administrative tags.
The tag ordering semantics are intentionally implementation-dependent with no implied operational meaning, but ordering preservation is required when propagating between levels so that single-tag implementations have a consistent view — this allows multi-tag and single-tag implementations to coexist.
Implementations that support only a single tag and those that support multiple tags may coexist in the same IS-IS domain. An implementation supporting multiple tags SHOULD therefore assign any tag required to be interpreted by all systems as the first tag in any set of multiple tags.
A compliant IS-IS implementation MAY be able to assign more than one tag to any IP prefix and MAY be able to interpret second and subsequent tags where more than one tag is present in the sub-TLV.
A compliant IS-IS implementation MUST be able to assign one tag to any IP prefix in TLV 135, TLV 235, TLV 236, or TLV 237, and MUST be able to interpret a single tag or the first tag where multiple are present.
A tag value of zero is reserved and SHOULD be treated as 'no tag' for both 32-bit and 64-bit administrative tag sub-TLVs.
Each tag SHOULD be treated as an autonomous identifier that MAY be used in policy to perform a policy action; whether tag A precedes or succeeds tag B SHOULD NOT change the meaning of the tag set.
If an implementation needs to change tag values when propagating TLVs between levels at an area boundary, the TLV(s) SHOULD be copied to the newly generated Level-1 or Level-2 LSP, at which point sub-TLV contents MAY change as dictated by policy.
On receipt, an implementation MAY consider only one encoded tag; if so, the first encoded tag MUST be considered and any additional tags ignored. This applies to both 32-bit and 64-bit sub-TLVs.
The Administrative Tag SHALL be encoded as one or more 8-octet unsigned integers using Sub-TLV 2 in TLV 135, TLV 235, TLV 236, and TLV 237.
When propagating TLVs between levels, a compliant IS-IS implementation MAY be able to rewrite or remove one or more tags associated with a prefix in TLV 135, TLV 235, TLV 236, or TLV 237.
When propagating TLVs containing multiple tags between levels, an implementation SHOULD preserve the ordering such that the first tag remains the first tag, ensuring consistent view for implementations that only recognize a single tag.
Two new Administrative Tag sub-TLVs (sub-TLV 1 for 32-bit tags and sub-TLV 2 for 64-bit tags) are defined for use in TLV 135, TLV 235, TLV 236, and TLV 237 to carry administrative policy information about IP prefixes.
IANA has assigned type code 1 for the 32-bit Administrative Tag Sub-TLV and type code 2 for the 64-bit Administrative Tag Sub-TLV in the IS-IS Sub-TLV registry.
This document raises no new security issues for IS-IS, as administrative tag annotations to IP prefixes should not pass outside the administrative control of the network operator's IS-IS domain; allowing such leakage would violate the spirit of Interior Gateway Protocols.
The 32-bit Administrative Tag Sub-TLV 1 encodes as: 1 octet type (value 1), 1 octet length (multiple of 4), and one or more 4-octet unsigned integer tag values.
The 64-bit Administrative Tag Sub-TLV 2 encodes as: 1 octet type (value 2), 1 octet length (multiple of 8), and one or more 8-octet unsigned integer tag values.