Thanks Les. From talking to operators, they don't seem to consider the
instance separation approach viable. The problem may be just that we
have not been sufficiently clear about what kinds of information can be
separated. My ypothesis, and I recognize that I may be mistaken, is
two-fold. One is that if there were a clear separate mechanism it might
actually address the problem. And the other is that the difference in
the properties of the information I am suggesting we offload are such
that a different mechanism (for example without timeouts and refreshes,
might be better suited.
To be very clear, I fully agree that even if we define a separate
mechanism, the decision about what information belongs in what mechanism
would belong to LSR.
Yours,
Joel
On 10/12/2026 4:05 PM, Les Ginsberg (ginsberg) wrote:
(Adding LSR WG)
Joel –
There are two topics associated with your draft:
1)What should/should not be advertised by the IGPs.
This discussion belongs in LSR.
This isn’t a new topic of course.
Been discussed off and on for years.
As alluded to, IGPs have defined alternate instance mechanisms
(https://datatracker.ietf.org/doc/rfc6823/ for IS-IS,
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/
for OSPF) to support this – but thus far neither has been used.
Why? I have to believe it is because folks do what is “easiest” – not
necessarily what is technically better/forward looking. And depending
on what new use case we are talking about, any individual may find
themselves on either side of this issue.
Note: As Bruno mentions BGP-LS as an alternate transport, it may well
be that IDR should be on this thread.
Certainly, I am seeing examples where BGP-LS is being “taken advantage
of” in a manner similar to IGP cases.
2)Do we want to define a new “protocol” to support advertising
information which should be kept out of the IGPs.
This discussion may well start in RTGWG, but probably ends up
somewhere else depending on the characteristics of the new protocol.
So, while your draft is useful in that it raises awareness of a
longstanding issue that we should probably take on – I think the draft
as it is constituted has a limited future.
Les
*From:*Joel Halpern <[email protected]>
*Sent:* Thursday, September 24, 2026 10:25 AM
*To:* [email protected]
*Cc:* 'RTGWG' <[email protected]>
*Subject:* [rtgwg] Re: Fwd: I-D Action:
draft-halpern-rtgwg-not-a-dump-truck-00.txt
Thanks Bruno. There are indeed two sets of things to move out of the
IGP. The quasi-stable information (MNA capabilities, link MTU, what
VPN is of interest to a node, ...) and the highly dynamic
information. I expect that the solutions to those two are different,
and I chose to solve the quasi-static use case because there are a lot
of existing tools we could use to address that problem. I don't know
what a good approach is to the highly dynamic information, although I
would be interested in exploring that on its own merits.
Yours,
Joel
On 9/24/2026 1:02 PM, [email protected] wrote:
Hi Joel, all
1. improving IGP robustness by moving quasi-stable information
not need for routing convergence out of the IGP
Interesting coincidence, as I had similar discussions about this
subject in Vienna.
Not sure what you mean by “quasi-stable information”.
Personally, I had a different starting point: keep in the IGP what
is needed for the SPF /distributed internal routing and move the
“decorative” stuff somewhere else. Of course this is on the
extreme side, and the frontier is likely a subject for discussion.
(if not a matter of personal opinion)
But I’d rather first remove from the IGP the dynamic information
(rather than the quasi-stable ones). Typically link load /
reserved bandwidth used for TE.
I agree that bootstrapping implementations and deployments will be
very difficult. Any new use case will ask for its IGP sub-TLV,
because this new proposal is not universally deployed hence not
usable. So it will likely be “for next time” forever.
May be including in scope the gathering of information from other
routing area/AS may help trigger more interest / deployment and
may possibly be easier to justify implementations (as a new IGP
sub-TLV would not be feasible). Since this is done today mostly
via BGP-LS, have you considered using BGP-LS for this proposal? If
so, what’s the outcome of your analysis? Personally, that was my
initial idea: move stuff from IGP to BGP-LS. Bootstrapping
implementation and deployment seemed easier since BGP-LS is
already implemented.
Yours,
--Bruno
*From:*Joel Halpern <[email protected]>
<mailto:[email protected]>
*Sent:* Thursday, September 24, 2026 4:06 PM
*To:* 'RTGWG' <[email protected]> <mailto:[email protected]>
*Subject:* [rtgwg] Fwd: I-D Action:
draft-halpern-rtgwg-not-a-dump-truck-00.txt
Calling your attention to a draft I just submitted, with some
co-authors.
It is a problem statement draft, outlining an approach to
improving IGP robustness by moving quasi-stable information not
need for routing convergence out of the IGP. The basic question
is whether the community is interesting in improving this
behavior. If so, we can decide whether it goes to LSR or gets a
new working group.
Thank you,
Joel
-------- Forwarded Message --------
*Subject: *
I-D Action: draft-halpern-rtgwg-not-a-dump-truck-00.txt
*Date: *
Thu, 24 Sep 2026 07:02:04 -0700
*From: *
[email protected]
*Reply-To: *
[email protected]
*To: *
[email protected]
Internet-Draft draft-halpern-rtgwg-not-a-dump-truck-00.txt is now
available.
Title: The IGP is not a Dump Truck
Authors: Joel Halpern
Andrew Alston
Name: draft-halpern-rtgwg-not-a-dump-truck-00.txt
Pages: 8
Dates: 2026-09-24
Abstract:
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.
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-halpern-rtgwg-not-a-dump-truck/
There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-halpern-rtgwg-not-a-dump-truck-00.html
Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts
_______________________________________________
I-D-Announce mailing list -- [email protected]
To unsubscribe send an email to [email protected]
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
