> 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]
