| Internet-Draft | rtgwg-not-a-dump-truck | October 2026 |
| Halpern, et al. | Expires 3 May 2027 | [Page] |
This document explores addressing the problem of using an IGP to carry arbitrary information, often referred to using the phrase "the IGP is not a dump truck". It describes the kinds of information carried in an IGP and proposes an approach to changing the system.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document takes place on the Routing Area Working Group Working Group mailing list (rtgwg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/rtgwg/.¶
Source for this draft and an issue tracker can be found at https://github.com/JoelHalpern/Offloading-Dumptruck.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 3 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
As the usage of protocols for IP routing within domains has evolved, a need has emerged to carry many more different kinds of information across the domain in support of the IP handling system. This has resulted in a syndrome informally referred to as treating the IGP (the routing system within many domains) as a dump truck.¶
This phenomenon results in multiple kinds of problems. The most obvious effect is that the sheer volume of information grows faster than the operational systems to support it. We have seen many cases where efforts to add further information to the set are met with "that is too much". This leaves the requestor with a need that is hard to meet. Further, as the IGP operations require (slow) refresh of information, we pay additional information propagation costs that are not well-matched to the problem. The net effect is a set of needs that are not well-met and which can interfere with effective operation of the IGP for its primary purpose.¶
This draft outlines an approach to changing the situation. It starts by describing the information carried in the IGP in terms of the dynamics relevant to separating the dump truck aspects. That section then describes what appears to be a tractable and useful separation.¶
An additional section then starts to describe the interface properties that a solution proposal can look at.¶
This is followed by a brief description of the infrastructure of a solution, while explicitly not picking a mechanism. There are a few properties that are anticipated to be needed by any infrastructure addressing this space.¶
Finally, and in many ways most importantly, there is a description of the deployability issues and properties that need to be recognized to make this undertaking effective.¶
One question that comes up when looking at the above is whether this is relevant for BGP. First and foremost, it is important to understand that this proposal is not intended to propose solutions for the BGP space.¶
Having said that, it is clear that BGP has similar issues, and that a well-designed solutioin may have applicability to BGP. THere is an important disnction to be drawn if one wishes to consider that. For BGP usage within an operator domain, and for information intended to be propagated only within that domain, a sultion that address the problems describe below is likely to have applicability. The privacy concerns and the ability to reach the relevant parties seem quite similar.¶
Alternatively, one could consider that within an operator domain BGP is a reasonable and effective dump truck, and with route reflectors and similar technology does not need any alternatives when it is being used. this could be based on capabilities such as Rotue Reflectors and separation of AFI/SAFI to different sessions. Analysis of this alternative would be part of the considerations in any solution evaluation.¶
In contrast, for information being propagated between operators, and even more for information to be propagated across significant swaths of the Interet, an approach that solves the problems described here is unlikely to be applicable. That problem likely requires separate evaluation and approaches if it is to be addressed. Constraints to meet that need are intended to be out of scope for this problem and its derived solutions.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
To discuss what information can be helpfully unloaded, this draft proposes three categories of information.¶
Highly dynamic information - This is information that changes faster than typical routing information. An example would be the current congestion state of a queue. This information is not the subject of this draft. How it is handled is left to other documents and practices.¶
Topological state and similar information - This is the core of the job of routing protocols. This draft does not propose to change this. Information in this category is critical for driving forwarding decisions, and changes at a moderate rate.¶
Long term stable information - This is information that while subject to change as device software or configuration changes, is not subject to rapid environmental effects or similar dynamics. Examples include node capability information, the set of VPNs a node is supporting, and similar. Link MTU is another example of information that can be handled by this system. Service SIDs are an example of information which while currently supported in other ways may benefit from this mechanism if it gains traction. Whether the supported set of information should include information such as link latency for non-radio links is for future discussion. The first important property is that this information does not need to be refreshed. So designs built around reliable delivery can be considered. It is also frequently information which is only of interest to a subset of nodes. So a distribution mechanism that does not burden uninterested nodes with effort or storage is worth evaluating.¶
From the point of view of standardization, the important part of this proposal is a mechanism to put information into the system, and get information out of the system¶
To participate in this system in either or both of the roles of information provider or information recipient, a node needs to discover an entry point to the system. It is assumed for purposes of discussion that this appears as a list of IP Address / Protocol / Port / Higher layer behavior tuples. The exact encoding is yet to be determined, but should leverage existing work in this area. The choice among explicit list, some form of URN/URI, or a different representation are considerations to be evaluated later in the process.¶
As is discussed in the infrastructure section, it is assumed that the system appears to be a distributed service. As such, a node may receive multiple identifier tuples.¶
It is for further study whether the provision of these identifiers to nodes is done via an advertisement in a routing protocol or is configured on each participating node.¶
The information to be handled by the system must have certain properties in order for this proposal to be effective.¶
Each piece of information needs to be uniquely identified so that the system can tell the difference among adding new information, updating information, or deleting information. It is likely that this will be achieved via a combination of domain-wide unique identifiers of system participants and local generation of identifiers for information.¶
Information in this offload system needs to be useable in relation to the underlying routing system. As such, advertisements in this system will need to use identifiers that correlate with node and link identification as understood by the IGP. To a first approximation, one can assume a single style of IGP, and use the identifiers exactly as it represents them. It is worth exploring whether this should be generalized.¶
To enable distribution of information only to interested parties, there also needs to be a standardized way to represent the semantic scope (e.g. provider edge devices, devices supporting specific VPNs, devices serving as head ends for a particular tunnel technology.)¶
Information has to have enough structure and content identification that it can be understood. This implies the use of standardized schema of some sort, standardized encoding, and well-defined extensibility so that new information can be introduced incrementally. Whether YANG is the right schema, or some other already defined candidate is to be used remains to be determined. It is not the goal of this proposal to introduce a new schema language.¶
Once a node has one or more identifiers for this offload service, it contacts the service. It is presumed that there is some sort of registration and authentication process, and that all communication with the service will have the capability at least for integrity protection. Whether confidentiality is needed is for further study and may well depend upon the specific operational environment.¶
Once properly registered, a node provides to the system its collection of suitably static information such as nodal capabilities. The properties of this information are described above. Encoding details such as whether lengths are used, etc. are for future study. A stable definition of this information structure is needed for interoperability. Equally, extensibility is critical as we cannot and should not restrict what information is handled by this system.¶
Providers of information will need to be able to withdraw information they have provided and update the content of specific items.¶
A node desiring to retrieve information from the system registers and authenticates as above. Following that, each node provides a series of requests for information. The common case will be a request for some scoped set of information from all contributors, with timely updates when content changes such as new information becoming available, information being withdrawn, or an update of content. In particular, this frequently occurs when a new node joins the operating environment. There is no rush about deleting out-of-date information, although explicit deletion does need to be propagated.¶
The obvious starting point for such a system is a set of servers offering the information handling service. This must be distributed and replicated so as to be resilient across failure of individual servers. It is assumed that the system can be delivered by a combination of services co-resident with routers and separate software instances, to be decided by the operator.¶
The infrastructure will need a mechanism so that when new servers join the system, such new participants can reliably fetch the data set. It is not expected that the system instances will have persistent storage, as, under a full restart, the supporting nodes will re-register and provide their information.¶
The exact mechanism for doing this may be a distributed database, a pub-sub service, or any number of techniques developed in the server world. Assuming we have a stable interface, it is not clear whether there is even a need to standardize one or more infrastructure handling systems.¶
This represents a significant change in the information handling paradigm of an operational environment. This leads to the question of whether it is practical to deploy this.¶
There are clearly a number of existing use cases for which this system would improve the overall behavior. However, it is hard to see how vendors and operators would justify the complications of changing already deployed, if awkward distribution mechanisms.¶
As such, the expected first step would be to define this, and define its use for new use cases which are currently emerging and seem to place an unfortunate strain on IGPs. Only once there is traction for this approach in operational environments would we then propose carrying some of the existing stable information cases in this and, if successful, gradually make more use of this approach.¶
The system described in this document introduces a distributed service through which nodes register, distribute, and consume routing-adjacent information. This creates a new trust surface that requires careful analysis in any solution effort. This section identifies the principal threat classes.¶
A node that gains unauthorized access to the service and registers false information --- incorrect capability flags, false VPN membership, incorrect link MTU --- can cause other nodes to make incorrect forwarding decisions. Authentication mechanisms must ensure that only authorized nodes can register information and that registered information is attributable to a specific node identity consistent with that node's identity in the IGP. Compromise of a single participant must not enable persistent corruption of information attributed to other nodes.¶
Integrity protection must apply to the full distribution path, not only the registration leg. A man-in-the-middle between a registering node and the service, or between the service and a collecting node, must not be able to modify advertisements undetected.¶
Confidentiality requirements vary by information type. VPN membership information (which nodes participate in a given VPN) is sensitive in multi-tenant environments; disclosure reveals customer topology to unauthorized parties. Node capability flags and link MTU values are generally not sensitive. Any solution must support per-information-type confidentiality policy rather than applying a uniform policy to all content.¶
The service is a new high-value target. Three distinct denial-of-srvice vectors must be considered:¶
Attacks against registration endpoints prevent nodes from publishing capabilities; consumers see absent or stale data and may make incorrect forwarding decisions.¶
Attacks against the discovery mechanism (see Section 4.1) can redirect nodes to a malicious service before a session is established; the bootstrap trust anchor must itself be authenticated.¶
Attacks against the distribution path prevent updates from reaching consumers, causing them to act on stale information for an extended period.¶
The replicated and distributed nature of the infrastructure partially mitigates availability attacks, but does not eliminate them.¶
When a node fails or is withdrawn without cleanly deregistering, its information persists until explicit deletion or expiry. Consumers acting on stale capability or membership data face correctness risk. This risk is amplified if an attacker can prevent a node from deregistering (for example by severing its management plane connectivity while its data plane remains reachable), causing consumers to continue acting on capabilities that are no longer valid.¶
IS-IS and OSPF both provide cryptographic authentication of protocol messages. The trust model for the offload service must be at least as strong as the IGP trust model it complements. A node trusted in the IGP must not be able to inject false information into the offload service through a weaker authentication path, nor must the offload service become a vector for attacking the IGP itself.¶
This document does not assign or modify any IANA code points.¶
This document does not yet have any acknowledgements.¶