Summary

  • Revision 03 of the GROW routing-operations terminology draft explicitly presents itself as a descriptive, non-authoritative snapshot in which the same term may carry different meanings by context.
  • Peer can describe a route-exchange relationship between ASes or merely a BGP neighbour session. A workflow that stores the word without its sense, subjects, policy and evidence can apply the wrong export rule while every participant believes the record is clear.

The ticket said only: “add the new peer.” The commercial team meant an AS relationship in which each side would advertise its own and downstream routes. The router automation team read “peer” as an established BGP neighbour and copied the default external-session template. Both interpretations appear in real routing language. Only one matched the intended policy.

That ambiguity is not an embarrassing edge case hidden from the standards process. It is made visible by revision 03 of Currently Used Terminology in Global Routing Operations, submitted by Tobias Fiebig and Wolfgang Tremmel on 2 October 2026. In its neighbour-relation section, a peer is a pair of directly connected ASes that exchange only routes they originate or learn from downstreams. In its routing section, “peer” may simply mean a BGP neighbour: two speakers exchanging NLRI.

The document is unusually disciplined about its own authority. Its abstract says it does not serve as an authoritative source of correct terminology. Its scope says it is descriptive, records observed usage at a point in time, and is subject to change. Terms can occur in several sections with different descriptions. That is not a flaw to correct by choosing one universal definition. It is the central operational fact.

Datatracker records revision 03 as an active GROW working-group Internet-Draft in the IETF stream. It has no responsible Area Director, document shepherd, RFC number, telechat or completed standards-process outcome. The text says intended status Informational and expires on 5 April 2027. It requests no IANA action. Its Security Considerations says that, because it describes terminology and makes no recommendations, it has no security considerations.

That last statement is properly read as a claim about the document, not every system that may ingest its words. A glossary can make no protocol recommendation while an inventory, policy engine or autonomous agent creates a security consequence by treating a context-dependent label as an executable fact. The danger lies in the consumer's semantic compression.

A word can coordinate without identifying a predicate

When an operator says “peer,” listeners infer a cluster of properties. They may infer symmetry, no transit, a certain export filter, a commercial arrangement, a physical interconnection, an established session or simply the other endpoint in a troubleshooting exchange. The word is efficient precisely because experienced people restore missing context.

Machines do not restore the same context unless designers encode it. A field named relationship: peer may drive export policy. A field named peer_state may report session establishment. A log line saying peer down may describe transport or BGP finite-state-machine state. A contract database may use “peer” for economic classification. Moving one string among these systems silently changes the proposition.

The correct response is not to ban the word. It is to attach a sense. A record should identify the vocabulary and version, the term identifier, the declared context, both subjects, directionality, observation point, time and evidence. bgp-neighbor-session and as-route-exchange-relationship can still render as “peer” to a human, but they should not be the same machine value.

Even the relationship sense needs evidence. RFC 9234 defines BGP Roles exchanged in OPEN messages to help prevent route leaks. A negotiated role is stronger than guessing from route patterns, but it still depends on configuration and policy enforcement. A signed commercial agreement, an operator declaration, a role negotiation and observed exports answer different questions. No one receipt should impersonate the others.

Revision 03 improves terms without making them universal

The change from revision 02 to 03 is not merely a date rollover. The new text expands the acronym list, adds and refines definitions and references, and corrects several formulations. BFD, for example, is now described as checking whether a configured neighbour is reachable and signalling lost reachability to protocols such as BGP, rather than proving that the neighbour is “alive.” That is a meaningful reality-layer correction.

The path-attribute descriptions are also tightened. Optional transitive attributes that an implementation does not understand are expected to be propagated; optional non-transitive attributes are discarded and not propagated. General entries for BGP, EGP, IGP, EIGRP, IS-IS, OSPF and RIR are added or clarified. These edits make the snapshot more useful.

They do not convert it into a conformance profile. The draft still says its summaries are subject to change and not authoritative. Its definitions aid people reading contemporary drafts. An application importing them must preserve that provenance and version rather than flatten the newest wording into timeless truth.

Versioning matters because a term's operational perimeter can move. An older inventory may have encoded one sense, while a newer glossary distinguishes two. Reprocessing historical tickets under the latest vocabulary can create false consistency. A record should retain the sense in force when a decision was made, plus any later mapping used for analysis.

“Neighbour” proves less than “relationship”

The draft defines a neighbour as an AS to which an established BGP session exists, and a BGP neighbour as two speakers exchanging NLRI. Those are observable control-plane facts. A session can be authenticated with TCP-AO under RFC 5925, remain established, exchange updates and still be configured with the wrong relationship policy.

Conversely, a commercial or administrative relationship can exist while a session is down. Maintenance, a transport failure or an intentional shutdown does not necessarily terminate the broader relationship. If a customer portal reads session state as contract state, it will oscillate institutional truth with every BGP reset.

The separation suggests four records. Relationship evidence says how the organisations intend to exchange routes. Session configuration says what two speakers were told to do. Session observation says what protocol state and messages were seen. Export and forwarding observations say what routes and packets actually crossed. Each record can disagree with another, and that disagreement is valuable evidence.

RFC 4271's decision process is local. A speaker can select a route according to configured policy. That does not prove the neighbour selected the reciprocal policy or that traffic followed an expected commercial path. The word “peer” must not bridge those layers without evidence.

Other terms expose the same type error

Network edge appears in the relationship discussion as the last routers under an operator's control that connect to other networks. In the routing discussion it is the last routers under the operator's control. Provider Edge usually adds an MPLS role. An asset database that equates every device tagged edge with a PE router can deploy the wrong template to the wrong boundary.

Cone can mean a recursively defined set of downstream ASes and, depending on context, the joint set of prefixes they originate. Those are different set types. A containment check over AS numbers cannot be run against prefixes without a mapping and a time-bound observation. If a policy engine accepts both under one untyped field, a syntactically successful query can compute the wrong perimeter.

Blackholing generally describes packets being silently dropped. In the security section it describes announcing prefixes with a particular community to cause observers to drop traffic. One is an observed symptom; the other is a deliberate control action. Turning a loss alarm into a blackhole command because both use the same word is a category error with direct availability consequences.

Operator may be an individual, group or organisational unit responsible for BGP speakers, policy and administrative change. A ticket that says “operator approved” has not necessarily identified the human principal, scope or approval record. The organisational role helps route work; it does not satisfy accountability by itself.

Depeering is removal of sessions with a neighbouring AS. It does not prove all forwarding through that organisation stopped. Traffic may move to another interconnection, transit path, default route or cached forwarding state. If an incident closes when session deletion succeeds, the workflow confuses configuration with outcome.

A full table is full only under stated coordinates

The draft defines a full table as containing a route to all prefixes in the Global Routing Table and no default route. In practice, “all” needs coordinates: address family, collector or speaker, time, import policy and the working definition of the GRT. Two vantage points can differ without either being corrupt.

A table can also be control-plane complete while forwarding installation is partial. Resource limits, policy, recursion failure or programming delay can keep selected routes out of the forwarding plane. Saying “the full table arrived” is therefore not a delivery receipt for traffic.

The same discipline applies to convergence. The draft describes a BGP speaker learning and evaluating routes and finding a preferred route for each destination. One speaker can finish that process while updates continue elsewhere, forwarding entries lag, or data-plane paths remain inconsistent. “Converged” needs a named scope and observable stopping condition.

BFD sharpens the point. RFC 5880 and the revised draft entry support rapid detection of a forwarding-path failure under a configured session. A BFD Up state is not an application-service receipt, and Down is not proof of the root cause. Reachability, BGP state, route selection, forwarding and user delivery remain separate observations.

Security labels do not establish intent

The draft says a BGP or route hijack occurs when an AS announces a route it is not authorised to announce and notes that the event may result from accidental misconfiguration or malicious action. The technical classification therefore does not settle intent. A dashboard that labels an event “hijack” should not automatically assign a malicious actor or trigger sanctions.

RFC 7908 similarly classifies route leaks as propagation beyond intended scope in violation of policy. To determine which policy was intended, an investigator needs relationship and configuration evidence. The observed path can demonstrate propagation; it does not alone reconstruct the approval chain or root cause.

RPKI supplies narrower evidence. RFC 6480 describes the resource-certification architecture, and RFC 9582 specifies ROAs through which a holder authorises an AS to originate routes for prefixes within scope. A valid origin under a ROA does not prove the path respected relationship policy, that the route was globally reachable, or that packets arrived. A ROA_VALID label should not be expanded into “safe route.”

The same caution runs the other way. RPKI invalid or not-found states are inputs to local policy, not self-executing universal verdicts. A validator exposes its view; a router consumes data at a time; configured policy decides; forwarding produces an outcome. A glossary can name each component while only operational evidence can join them.

The minimum typed envelope

A consuming system needs at least nine fields. First, the exact term. Second, its vocabulary and version. Third, a machine-stable sense identifier. Fourth, declared context. Fifth, subject identities and direction. Sixth, observation point and time. Seventh, evidence or source. Eighth, the requested action and authorised principal. Ninth, uncertainty or conflicting interpretations.

This envelope should not pretend to solve every routing ontology. Its purpose is to prevent a high-impact type error. A human interface may continue to show familiar words. The API beneath it should reject a relationship-only action when given session-only evidence, reject a prefix-set operation on an AS set, and preserve unknown when the sense is absent.

Compatibility needs explicit treatment. Legacy records containing only peer should not be silently upgraded. They can be marked ambiguous and routed to a resolver, or mapped using documented contextual evidence with provenance. Filling the field with the most likely modern sense creates precision that never existed.

Monitoring should count ambiguous inputs, cross-context mappings, policy actions launched from descriptive terms, conflicts between relationship and session evidence, full-table claims without coordinates, local convergence claims without forwarding checks and incident labels promoted into intent. These are not merely data-quality metrics; they identify where language is controlling infrastructure.

What the glossary can and cannot earn

Revision 03 earns value by refusing false authority. It gathers contemporary language, records multiple meanings and improves definitions without claiming to settle usage forever. Operators and implementers can use it to notice assumptions they had stopped seeing.

The next step belongs to each consuming workflow. A ticketing system needs typed fields. An inventory needs versioned semantics. A policy engine needs explicit predicates. An autonomous agent needs capability and action boundaries. An incident process needs evidence for observation, causation and intent. None should ask a descriptive glossary to make those decisions on its behalf.

This is Heng Lu's reality-layer problem in a practical form. A term is symbolic coordination data. A relationship or policy is an institutional and control-plane object. A session and configuration are executable state. Route propagation and packet delivery are observed reality. Clarity feels demanding because it prevents one convenient word from moving power across all four layers.

Minimum Initial Specification points to the small typed envelope rather than a universal ontology. Running-Code Primacy requires incompatible-sense tests: feed a session-only peer record into a relationship-policy action and prove it is rejected; remove a BGP session and observe whether traffic persists; mark one speaker converged while updates continue elsewhere and keep the wider state unknown.

The opening ticket therefore failed before the router changed. It failed when a human relationship term crossed into automation without its sense. Both teams used a legitimate word. Neither supplied a sufficient action contract. The remedy is not a vocabulary police force. It is a system that preserves context long enough to know what proposition it has, what evidence supports it and what action that evidence can safely authorise.

Sources