(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]<mailto:[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]<mailto:[email protected]> Reply-To: [email protected]<mailto:[email protected]> To: [email protected]<mailto:[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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[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]
