Joel, > I also think that if we decompose the problem properly, > we will be in a good position to evaluate the alternatives for each component.
That's interesting. I think there is resistance to develop, deploy and support one new way to carry opaque routing information around network elements. /* Leave alone that soon you will have a bunch of mgmt folks telling you most of this is already solved by some form of telemetry out of network elements or in the form of cfg into them */. If we now multiply this by N (one per above "component") I would not hold my breath waiting for anything real to come out of it. But good luck ! R. On Tue, Oct 13, 2026 at 12:02 AM Joel Halpern <[email protected]> wrote: > 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]
