[Idr] Re: IETF 124 - non-IDR presentations of interest
Jeffrey Haas <jhaas@pfrc.org> Tue, 28 October 2025 18:44 UTC
Return-Path: <jhaas@pfrc.org>
X-Original-To: idr@mail2.ietf.org
Delivered-To: idr@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id E4EEF7D984F0 for <idr@mail2.ietf.org>; Tue, 28 Oct 2025 11:44:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arT50-WNT6ah for <idr@mail2.ietf.org>; Tue, 28 Oct 2025 11:44:47 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by mail2.ietf.org (Postfix) with ESMTP id C82357D984EB for <idr@ietf.org>; Tue, 28 Oct 2025 11:44:47 -0700 (PDT)
Received: from smtpclient.apple (99-188-202-8.lightspeed.livnmi.sbcglobal.net [99.188.202.8]) by slice.pfrc.org (Postfix) with ESMTPSA id 398D11E24F; Tue, 28 Oct 2025 14:44:47 -0400 (EDT)
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\))
Content-Type: text/plain; charset="us-ascii"
From: Jeffrey Haas <jhaas@pfrc.org>
X-Priority: 3
In-Reply-To: <516805330.145119.1761676288544@www.getmymail.co.uk>
Date: Tue, 28 Oct 2025 14:44:46 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <6E66C6C7-405F-4868-8DD2-728210283F00@pfrc.org>
References: <5BDA83D4-D934-4253-A6FD-65C1FDE1ED37@pfrc.org> <516805330.145119.1761676288544@www.getmymail.co.uk>
To: Adrian Farrel <adrian@olddog.co.uk>
X-Mailer: Apple Mail (2.3696.120.41.1.10)
Message-ID-Hash: UJPNL6VEWKL6TN5SQAM4YAENJFGQKTZ6
X-Message-ID-Hash: UJPNL6VEWKL6TN5SQAM4YAENJFGQKTZ6
X-MailFrom: jhaas@pfrc.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: idr <idr@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Idr] Re: IETF 124 - non-IDR presentations of interest
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/0Ht7GVSI8P07AmSG0dIc4qEb51A>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Owner: <mailto:idr-owner@ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Subscribe: <mailto:idr-join@ietf.org>
List-Unsubscribe: <mailto:idr-leave@ietf.org>
Adrian, > On Oct 28, 2025, at 2:31 PM, Adrian Farrel <adrian@olddog.co.uk> wrote: > > Hi Jeff, > > > https://datatracker.ietf.org/meeting/124/materials/agenda-124-cats-01 > > > > - Distribution of Service Metadata in BGP FlowSpec. The material discusses blending flowspec, the metadata draft (which will have an update in cats as well), coloring mechanisms, and new path attributes. > > > >I didn't think cats was yet chartered to work on protocol extensions. > > It isn't, and seems unlikely ever to be unless: > - there is a need for a totally new protocol > - another WG wants to give away control of its protocol (which seems unlikely with IDR!) I agree that we'll not want to give away such control specifically for CATS use cases. Speaking for the usual joke, I suspect the DNS folk similarly wouldn't be interested. > But, as the CATS Framework approaches last call, and as clarity is emerging on what the CATS metrics are, we are taking some time out to hear abput proposals being floated in other WGs that may be applicable to CATS. > > As cochair of CATS I am conscious that a balance is needed. CATS may need to show interest for a protocol WG to invest time, but it is important that "I presented in CATS" is not used as a false justification. > > This comment applies to any and all protocol drafts and is not specific to this I-D. Thanks for the current status. My goal for highlighting the CATS agenda point was to draw early attention to this discussion. The existing work on the 5g metadata draft already highlighted a number of places where it was a "lumpy fit" for traditional BGP. Discussion on that document raised points about how it's a limited domain solution, had interesting security considerations in terms of confining the new path attribute to that domain, and its impacts on BGP route selection and forwarding consistency. Many of those points are likely to be general to the CATS work. If CATS has reached the point where "does this fit into existing protocols" is the conversation point, I'd suggest soliciting specific talks about how CATS requirements and the protocol under consideration's defined behaviors are likely to interact. In my opinion, it's much better to have those "lumpy fit" discussions more under the auspice of CATS requirements than seeing what can be pushed into the protocol of the day. -- Jeff
- [Idr] IETF 124 - non-IDR presentations of interest Jeffrey Haas
- [Idr] Re: IETF 124 - non-IDR presentations of int… Linda Dunbar
- [Idr] Re: IETF 124 - non-IDR presentations of int… Adrian Farrel
- [Idr] Re: IETF 124 - non-IDR presentations of int… Jeffrey Haas
- [Idr] Re: IETF 124 - non-IDR presentations of int… Robert Raszuk
- [Idr] Re: IETF 124 - non-IDR presentations of int… Adrian Farrel