Well, I did talk to a number of people in operations at ISPs to see if
there was itnerest. While I can't speak for them, I was encouraged by
what I heard.
As for alternatives I did not explore, without knowing what two you are
thinking of I can't comment on whether I missesd them or consider them
candidate solutions to be evalauted if the problem is to be addressed.
I specifically did not try to pick the solution protocol in this draft.
Yours,
Joel
On 10/12/2026 5:14 PM, Robert Raszuk wrote:
Joel,
I think the vast majority of the audience agree and understand that
routing protocols should not be overloaded with opaque information.
Just look at recent proposals for FSv2 iextensions n BGP and you will
likely fall off your chair.
But there is always the least effort path ... if TCP session is there
or if IGP flooding is there let's use it. And why is that ? Simply
because deploying a new transport requires significant effort. So much
more than anything a fair amount of cheerleading is required to make
it happen.
As to the content of your draft what seems to be clearly missing are
two approaches which has been well documented and one even is
available as an open source code. I think it would be good to include
those and perhaps even discuss them in your draft.
*Namely: *
Tony's DROID: https://datatracker.ietf.org/doc/html/draft-li-lsr-droid-00
Meta's OPENR: https://github.com/facebook/openr
Thx,
Robert
On Mon, Oct 12, 2026 at 11:03 PM Joel Halpern
<[email protected]> wrote:
The basic idea is that the alternative distribution protocol is
not the existing IGPs. As such and assuming there is community
interest in addressing the problem, I did not want to prejudge
whether the work would be in rtgwg, in lsr, or in a new working
group. Les is correct that once there is such a protocol, the
decision of what data uses which one seems appropriate to LSR.
And if the community decides that it is interested, and that the
work belongs in LSR, then I am happy to work on the offloading
protocol in LSR. But it is not for me to tell the routing
community which working group should own a piece of new protocol
work.
So, rephrasing the above, it seems to me that judging whether
there is interest, and deciding where the work belongs, under the
current structures, to be appropriate for rtgwg.
If the rtgwg and lsr chairs tell me I misjudged, I am happy to
discuss wherever it belongs.
Yours,
Joel
On 10/12/2026 4:57 PM, Robert Raszuk wrote:
My confusion comes from the point that draft talks about IGPs and
proper WG is LSR WG to discuss this.
I was asking since you apparently want to proceed with it in
RTGWG that more then IGPs will be covered. And that actually may
not be a bad idea as offloading some stuff from IGP and BGP may
land into pub-sub common message bus for distribution.
Thx,
r.
On Mon, Oct 12, 2026 at 10:54 PM Joel Halpern
<[email protected]> wrote:
I am making no comment about BGP by the title. I am drafting
some text to better explain the relationship with BGP.
Regarding the title, it is draft-halpern-rtgwg because
problem statement dispatch for routing, as I understand it,
is an RTGWG function. I didn't add -igp- to the filename
because I dislike creating long draft names. For me, the
draft filename never gives the whole story, so I didn't worry
about being completely precise in the filename.
Yorus,
Joel
On 10/12/2026 4:51 PM, Robert Raszuk wrote:
Hi Joel,
Can you explain why the title of the draft is not consistent
with its filename ?
Specifically you are talking about IGP ... but the title
says rtgwg ?
Are you trying to say that "The IGP is not a Dump Truck" but
BGP is ?
Thx,
R.
On Thu, Sep 24, 2026 at 4:06 PM Joel Halpern
<[email protected]> wrote:
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]
_______________________________________________
rtgwg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
