Return-Path: 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 4C76D7ED5674 for ; Thu, 30 Oct 2025 04:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.795 X-Spam-Level: X-Spam-Status: No, score=-2.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=olddog.co.uk 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 k2fO0Z4HnR4F for ; Thu, 30 Oct 2025 04:43:59 -0700 (PDT) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 9CA167ED566D for ; Thu, 30 Oct 2025 04:43:59 -0700 (PDT) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta6.iomartmail.com (8.14.7/8.14.7) with ESMTP id 59UBhwEK020650; Thu, 30 Oct 2025 11:43:58 GMT Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4408E46050; Thu, 30 Oct 2025 11:43:58 +0000 (GMT) Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 41BC74604F; Thu, 30 Oct 2025 11:43:58 +0000 (GMT) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs3.iomartmail.com (Postfix) with ESMTPS; Thu, 30 Oct 2025 11:43:58 +0000 (GMT) Received: from LAPTOPK7AS653V (82-69-109-75.dsl.in-addr.zen.co.uk [82.69.109.75]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.7/8.14.7) with ESMTP id 59UBhvow016643 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Oct 2025 11:43:57 GMT From: "Adrian Farrel" To: "'Robert Raszuk'" , "'Jeffrey Haas'" References: <5BDA83D4-D934-4253-A6FD-65C1FDE1ED37@pfrc.org> <516805330.145119.1761676288544@www.getmymail.co.uk> <6E66C6C7-405F-4868-8DD2-728210283F00@pfrc.org> In-Reply-To: Date: Thu, 30 Oct 2025 11:43:57 -0000 Organization: Old Dog Consulting Message-ID: <01ec01dc4992$7a2f10f0$6e8d32d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01ED_01DC4992.7A2FD440" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFZukAWLe1ALvg1M7X3LCHCvNr1NQG/dtpBAKHrgfYCSKFp87W6YA6Q Content-Language: en-gb X-Originating-IP: 82.69.109.75 X-Thinkmail-Auth: adrian@olddog.co.uk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=olddog.co.uk; h=reply-to :from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type; s=20221128; bh=lh1/n5dZYJRvA5QLDJWq5 kEUJDupwp5LnZQ5HXkjhIQ=; b=o5Opp7eNffT82aV5uAEgHT4iIKrGpJxdcQuH7 CroDl8s2mtJAPgaRNbf6lfvuVGSr8xrHZrfJdrok2NwTv1RHBtH6EX0TMaFDdxqJ DDo/p7Ngh7UAd19QzsnSoGPWYNlDKu6OacmpPS8iS3+nXpNlfqvfi2qu0yeJ14Wk 5mg37AiK/siPlU5F9hlG24iB7IyS+5rlKRmS8nohi6fCNIrGoma5TVxZOl2hU5a1 J9EvJZJkX3SQIY6eH5gLYg4xZvP96o4mARP9qRwKTYSiFj86l7PSMRuYNx9kqv0V jC+HNsQnCtEfpfRSe3T2b75Wx8sOUMyXIWsIem+Y1GcWmzeiw== X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1006-29464.005 X-TM-AS-Result: No--26.344-10.0-31-10 X-imss-scan-details: No--26.344-10.0-31-10 X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1006-29464.005 X-TMASE-Result: 10--26.343800-10.000000 X-TMASE-MatchedRID: iKTMlETJ4ps0QDP3j4T8uU8HitdqBBn7/sUSFaCjTLz95dwSoVJjf7V5 fSMRD1zq4DZDPY0VWlpi/vwRQpvR0/wSjEH7SOGpL/fdNahJQfoapIb9znReAxrqgrduJYasWks nQww9YXSOJmpFkiF2wxv6Pqm1jBTSeJs832DqeTzgS1I0HMWkYAw85kvZfX2K6KjY+CtcuzhWjS WvFszxqz6hVXnKDh9XTGXWkP5ReZsyVLVOuOqJlsNad1tMJT8XCtzGvPCy/m5tGams9PgywtbZh geyVPQjMBblt7zglMGyaJXoZYzXDyW2+RmsbSZm6bCLcknlxLUFxov+3JYvY8sF0raalpiWvHGw ZVw7NKlqjHcG0rAjrs+RkJP4f+7wEW+VzYyvOpqHVKyaEO3R+JUOQGWwlBfF4Fxe8GG/1pGZ6U7 QhkqRnnHJdVMZw6tLzYuwhWSUgabOcsP2AvLoZ81YNkuvGNxv8MPuu+RzTf7Q2dRRUyVMpg6QlB HhBZuwPflfI/fXxv/gARwLy4ncYqG9sYwsyCRqRjWJzJpJeXu4V0/u9pqUzUl3rVD3hKjhth6Qv eQfsqOf7y5OBAioaDba6gSbbjl+iONMOkcrBiaHO/kG/PtN6fx0ykrbAxjCv3d9ewcMHQcWzPTb xO7R+vdIm8S+G8+gLsvndq11AZKbVVXilP6Qq/CDFvXZFmYyYeSLiGsUzvlU4sxFq6igEVCd7VO gbE3oc0v9j9D2Tcn8AbXLZcf8kVPSAWHDBcndWpIdEoPquH/iTsyDsnGzT/xeH3fk9hIOWUtm6A JIkCDUGhtzq3pqRYA+zZbAFdrSd2VXGyctB+5j1vXr7GCgWkbgTmf4sxQ0mkCGwliFomubKItl6 1J/yZUdXE/WGn0FSlnU38LCY8t5/8Ulwj9hQD8+sMVfTph8sOzOncrmCoOFR9Hau8GO7gP90fJP 9eHt X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0 Message-ID-Hash: EKNUZWYYGCHAQW3YIB7PM54HDARR6V4W X-Message-ID-Hash: EKNUZWYYGCHAQW3YIB7PM54HDARR6V4W X-MailFrom: adrian@olddog.co.uk 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' X-Mailman-Version: 3.3.9rc6 Precedence: list Reply-To: adrian@olddog.co.uk Subject: =?utf-8?q?=5BIdr=5D_Re=3A_IETF_124_-_non-IDR_presentations_of_interest?= List-Id: Inter-Domain Routing Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is a multipart message in MIME format. ------=_NextPart_000_01ED_01DC4992.7A2FD440 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Which is why doing/discussing the protocol work inside IDR makes sense = to me. =20 A =20 From: Robert Raszuk =20 Sent: 28 October 2025 20:32 To: Jeffrey Haas Cc: Adrian Farrel ; idr Subject: Re: [Idr] Re: IETF 124 - non-IDR presentations of interest =20 Hi, =20 It looks to me like the term "giving away control of the protocol" is at = best exaggeration.=20 =20 Is there any reason CATS could not leverage BGP Cost Community as = specified in = https://datatracker.ietf.org/doc/html/draft-ietf-idr-custom-decision-08 = ?=20 =20 Some vendors already have shipping implementations of this feature.=20 =20 Not that I am fully subscribed to CATS charter and requirements, however = looking from BGP side I am not sure anything else would be needed to = influence routing decisions in a non standard way (at least within = domain). Inter-domain is a completely different can of worms.=20 =20 Thx, R. =20 =20 On Tue, Oct 28, 2025 at 7:45=E2=80=AFPM Jeffrey Haas > wrote: Adrian, > On Oct 28, 2025, at 2:31 PM, Adrian Farrel > wrote: >=20 > Hi Jeff, > =20 > > = 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. > =20 > 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. =20 > 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. > =20 > 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. > =20 > 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. =20 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.=20 -- Jeff _______________________________________________ Idr mailing list -- idr@ietf.org =20 To unsubscribe send an email to idr-leave@ietf.org = =20 ------=_NextPart_000_01ED_01DC4992.7A2FD440 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Which is why doing/discussing the protocol work inside IDR = makes sense to me.

 

A

 

From:<= /b> Robert = Raszuk <robert@raszuk.net>
Sent: 28 October 2025 = 20:32
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: = Adrian Farrel <adrian@olddog.co.uk>; idr = <idr@ietf.org>
Subject: Re: [Idr] Re: IETF 124 - non-IDR = presentations of interest

 

Hi,

 

It looks to me like the term "giving away control = of the protocol" is at best = exaggeration. 

 

Is there any reason CATS could not leverage BGP = Cost Community as specified in https://datatracker.ietf.org/doc/html/draft-ietf-idr-custom-decis= ion-08 ? 

 

Some vendors already have shipping implementations of = this feature. 

 

Not that I am fully subscribed to CATS charter and = requirements, however looking from BGP side I am not sure anything else = would be needed to influence routing decisions in a non standard way (at = least within domain). Inter-domain is a completely different can of = worms. 

 

Thx,

R.

 

 

On = Tue, Oct 28, 2025 at 7:45=E2=80=AFPM Jeffrey Haas = <jhaas@pfrc.org> = wrote:

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/agen= da-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 = mailing list -- idr@ietf.org
To unsubscribe send an email to idr-leave@ietf.org

------=_NextPart_000_01ED_01DC4992.7A2FD440--