We may have a philosophical difference of approach. While a working
group to select a solution will need to evaluate multiple alternatives,
I do not think this document is the place for a start on that. It seems
to me that we need to first determine if we agree that it is worth
solving this.
I also think that if we decompose the problem properly, we will be in a
good position to evaluate the alternatives for each component.
Yours,
Joel
On 10/12/2026 5:55 PM, Robert Raszuk wrote:
> I specifically did not try to pick the solution protocol in this draft.
That is good.
But it would not hurt if you study a few various architectural options
and add to the document a table comparison of pros and cons of each
approach.
And surely the two I listed are far from exhaustive list.
Regards,
R.
On Mon, Oct 12, 2026 at 11:41 PM Joel Halpern <[email protected]> wrote:
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]
