Summary

  • RFC 9104 gives Extended Administrative Groups a BGP-LS representation in Link Attribute TLV 1173. A legal length and an intact bit field prove that information was carried; they do not prove that a consumer applied the operator’s intended colour dictionary or selected a path.
  • The useful evidence chain continues after receipt: source IGP state, BGP-LS encoding, AG/EAG consistency, consumer vocabulary, policy version, computation result, installation receipt and packet observation must remain distinguishable.

A valid field reaches an undecided machine

Imagine a BGP-LS consumer receiving a Link NLRI with a Link Attribute containing TLV 1173. The value is eight bytes long. The session is established, the attribute parses, and the consumer records two 32-bit words. Nothing in this hypothetical opening is malformed.

The tempting operational sentence is: “the controller now knows the link colours”. That sentence quietly combines several different events. The producer carried a bit field. The consumer accepted a data structure. A local catalogue may map each set bit to an operational meaning. A policy may include or exclude links bearing those meanings. A path engine may compute candidates. A southbound system may install one result. Packets may—or may not—follow it.

RFC 9104 standardises the first boundary. Published as a Standards Track RFC in August 2021, it defines how BGP Link-State carries the Extended Administrative Group, or EAG, associated with a link. It assigns Link Attribute TLV type 1173 and says that its value consists of one or more 32-bit bitmasks. The Length is the number of bytes in the value and must be a multiple of four.

That format is deliberately spare. It is enough to preserve the bit field. It is not a policy language, a dictionary of colour meanings, a path computation request or a forwarding receipt.

Why the field had to grow

The older Administrative Group is a fixed 32-bit mask. Network operators commonly call the individual bits colours, but “colour” is a convenience, not a universal vocabulary. A bit that one network treats as low latency may mean maintenance avoidance, jurisdictional restriction or nothing at all in another.

RFC 7308 introduced the Extended Administrative Group so deployments were not confined to 32 such attributes. EAG remains a sequence of 32-bit words; its practical size is still bounded by the protocol and medium carrying it. RFC 9104 then provides the BGP-LS projection for that extensible IGP link attribute.

The extension does not replace the original field. RFC 9104 says the legacy Administrative Group TLV 1088 and EAG TLV 1173 can coexist. RFC 7308 defines how a receiver handles that overlap: when both are advertised for the same link, the first 32 EAG bits must be identical to the Administrative Group. The receiver uses the legacy Administrative Group for bits 0 through 31 and EAG for bits 32 and above. A mismatch should be reported to the operator.

This is a useful compatibility rule and a useful diagnostic. It is not proof that either bit set has the right business meaning. Two copies can agree perfectly and still be interpreted against the wrong local catalogue.

Syntax has a hard edge; meaning has a local owner

RFC 9104 draws one of its most important boundaries in error handling. If TLV 1173 is syntactically malformed—for example, its length is not a multiple of four—the BGP-LS Attribute is discarded under the applicable malformed-attribute rules. That is a transport and encoding consequence with a defined edge.

Semantic and content checking are different. Whether the value makes sense, whether the TLV is associated with an appropriate NLRI or attribute, and what an application should do with the information are left to the BGP-LS consumer. The RFC expressly places consumer behaviour outside its scope.

That separation prevents a parser from pretending to be a policy authority. A parser can establish that 64 bits arrived. It cannot infer that bit 42 still means “avoid during maintenance”, that a policy using that meaning is active, or that an unknown bit should be ignored rather than treated conservatively.

RFC 9552, which later replaced the base BGP-LS specification RFC 7752, makes the broader distribution model clearer: BGP-LS obtains topology and traffic-engineering information from an LSDB or TED and sends it to external consumers. Individual TLVs can define permissible values and semantics for validation, while application-specific error handling remains an application responsibility. That 2023 text helps describe today’s architecture; it is not retroactive evidence that a particular consumer behaved correctly when RFC 9104 appeared in 2021.

The colour dictionary does not travel inside TLV 1173

The absence is visible in the wire format. TLV 1173 contains a length and the set of bitmasks. It does not contain a label saying that a bit means “encrypted transport”, “submarine cable”, “low delay”, “restricted geography” or “do not use after 18:00”. It does not carry a dictionary version, policy precedence, approval identity, candidate path, selected path or installation status.

This is an inference from the defined field, not a quotation from the RFC. It matters because a valid bit field may cross organisational and software boundaries while its vocabulary does not. A producer may export the latest IGP state to a consumer still using yesterday’s mapping. Two controllers may receive the same EAG and make different decisions because their unknown-bit rules or policy priorities differ. A migration may activate a bit before every consumer receives the new catalogue.

Even the treatment of bits not advertised by a system is partly local. RFC 7308 generally describes those bits as zero, while allowing a local system to apply its own strategy. That is another reason to record consumer behaviour rather than infer it from the advertisement alone.

A receipt for every boundary

A defensible operational claim can be assembled as a chain of separate receipts.

Source receipt. Identify the IGP instance, protocol, link, originating LSA or LSP, EAG value and observation time. Without link identity and topology epoch, a bitmask can be syntactically exact but attached to stale or ambiguous state.

Projection receipt. Record the BGP-LS producer, Link NLRI descriptors, Protocol-ID, peer/session, Link Attribute, TLV 1173 length and raw value. If TLV 1088 is also present, record the first-32-bit comparison and any mismatch report.

Consumer receipt. Record parse outcome, semantic validation, link association, colour dictionary version and unknown-bit policy. “Received” should not stand in for “understood”.

Policy receipt. Name the policy version, the bits it includes or excludes, priority and conflict rules, approver and rollback authority. “Understood” should not stand in for “used”.

Computation receipt. Bind the input topology epoch and policy version to the candidate set, rejected links, selected path and computation time. “Used” should not stand in for “won”.

Execution receipt. Record the southbound transaction and resulting RIB, FIB or label state. “Computed” should not stand in for “installed”.

Service receipt. Observe packet path, traffic and relevant performance or service outcome. “Installed” should not stand in for “delivered”.

Keeping these rows separate is more than audit hygiene. It makes failures diagnosable. A missing route can be traced to a malformed attribute, a stale dictionary, an inactive policy, an infeasible candidate or an installation failure without rewriting the meaning of the earlier evidence.

What RFC 9104 does not secure

RFC 9104 does not change the BGP security model. It assumes that the IGP instances generating the source attributes use the appropriate OSPF or IS-IS security mechanisms. The existence of TLV 1173 therefore does not authenticate the source IGP by itself, authorise the consumer, validate the local policy or guarantee a safe path.

Nor does carriage establish freshness. A BGP-LS update may be current at one boundary and obsolete at the moment of computation. A consumer can receive authentic information and combine it with a different topology epoch. A correct policy can produce an unexpected result if the available paths have changed. These are operational conditions to measure, not defects that the TLV claims to solve.

The article’s mechanism must also remain separate from adjacent standards. RFC 9917 defines how reverse Administrative Group constraints participate in Flex-Algorithm calculations, with measurement and pruning rules specific to that problem. RFC 9825 deals with ordered OSPF administrative-tag lists and the possibility of capacity truncation. EAG in RFC 9104 is a bitmask projected into BGP-LS. It should not inherit the proof obligations of either a reverse constraint or an ordered tag list.

Carriage is a precise and valuable claim

Restricting the claim does not diminish the standard. Before TLV 1173, an extensible IGP link attribute lacked this defined BGP-LS representation. A stable code point, a reproducible encoding and explicit malformed handling make multi-component systems easier to build and inspect.

The restraint is in what follows. Lu Heng’s Running-Code Primacy offers a useful editorial lens: a coordination artefact is not the same thing as an implemented, validated and used result. His Minimum Initial Specification argument points toward a small common layer that preserves essential interoperability while leaving future local decisions local. Neither essay proves an RFC author’s intent or a deployment outcome, but both help keep the evidence boundary visible.

For TLV 1173, that boundary is unusually clean. The common layer can prove that a named link attribute was represented and carried. The consumer’s dictionary, policy selection, calculation, installation and service outcome need their own running evidence. A good status report therefore ends its first sentence at “the EAG arrived intact” and begins a second sentence before claiming what the network did.

Sources