MIME-Version: 1.0
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: <6E66C6C7-405F-4868-8DD2-728210283F00@pfrc.org>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 28 Oct 2025 21:32:11 +0100
Message-ID: 
 <CAOj+MMHNmTpu-3+e87tusTWnAHPNw9AB-YxeBBhmw+EC-bUb3Q@mail.gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Content-Type: multipart/alternative; boundary="000000000000c53e2e06423de956"
Message-ID-Hash: OLXME475MDZT3IPP5B3LTJISVSRYDDHD
CC: idr <idr@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BIdr=5D_Re=3A_IETF_124_-_non-IDR_presentations_of_interest?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/idr/TUNazlNghu7cvKqq5OFxtKKjLME>

--000000000000c53e2e06423de956
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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-decision-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/agenda-124-cats-01
> > >
> > > - Distribution of Service Metadata in BGP FlowSpec. The material
> discusses blending flowspec, the metadata draft (which will have an updat=
e
> 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 hea=
r
> 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 importa=
nt
> 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 o=
f
> places where it was a "lumpy fit" for traditional BGP.  Discussion on tha=
t
> 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 tal=
ks
> about how CATS requirements and the protocol under consideration's define=
d
> behaviors are likely to interact.  In my opinion, it's much better to hav=
e
> 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
>

--000000000000c53e2e06423de956
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div>It looks to me like the term &quot;=
giving away control of the protocol&quot; is at best exaggeration.=C2=A0</d=
iv><div><br></div><div>Is there any reason CATS could not leverage=C2=A0BGP=
 Cost Community as specified in=C2=A0<a href=3D"https://datatracker.ietf.or=
g/doc/html/draft-ietf-idr-custom-decision-08">https://datatracker.ietf.org/=
doc/html/draft-ietf-idr-custom-decision-08</a> ?=C2=A0</div><div><br></div>=
<div>Some vendors already have shipping implementations of this feature.=C2=
=A0</div><div><br></div><div>Not that I am fully subscribed to CATS charter=
 and requirements, however looking from BGP side I am not sure anything els=
e 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.=
=C2=A0</div><div><br></div><div>Thx,</div><div>R.</div><div><br></div></div=
><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" clas=
s=3D"gmail_attr">On Tue, Oct 28, 2025 at 7:45=E2=80=AFPM Jeffrey Haas &lt;<=
a href=3D"mailto:jhaas@pfrc.org">jhaas@pfrc.org</a>&gt; wrote:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex">Adrian,<br>
<br>
<br>
&gt; On Oct 28, 2025, at 2:31 PM, Adrian Farrel &lt;<a href=3D"mailto:adria=
n@olddog.co.uk" target=3D"_blank">adrian@olddog.co.uk</a>&gt; wrote:<br>
&gt; <br>
&gt; Hi Jeff,<br>
&gt;=C2=A0 <br>
&gt; &gt; <a href=3D"https://datatracker.ietf.org/meeting/124/materials/age=
nda-124-cats-01" rel=3D"noreferrer" target=3D"_blank">https://datatracker.i=
etf.org/meeting/124/materials/agenda-124-cats-01</a><br>
&gt; &gt;<br>
&gt; &gt; - 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.<br>
&gt; &gt;<br>
&gt; &gt;I didn&#39;t think cats was yet chartered to work on protocol exte=
nsions.<br>
&gt;=C2=A0 <br>
&gt; It isn&#39;t, and seems unlikely ever to be unless:<br>
&gt; - there is a need for a totally new protocol<br>
&gt; - another WG wants to give away control of its protocol (which seems u=
nlikely with IDR!)<br>
<br>
I agree that we&#39;ll not want to give away such control specifically for =
CATS use cases.=C2=A0 Speaking for the usual joke, I suspect the DNS folk s=
imilarly wouldn&#39;t be interested.=C2=A0 <br>
<br>
&gt; But, as the CATS Framework approaches last call, and as clarity is eme=
rging on what the CATS metrics are, we are taking some time out to hear abp=
ut proposals being floated in other WGs that may be applicable to CATS.<br>
&gt;=C2=A0 <br>
&gt; As cochair of CATS I am conscious that a balance is needed. CATS may n=
eed to show interest for a protocol WG to invest time, but it is important =
that &quot;I presented in CATS&quot; is not used as a false justification.<=
br>
&gt;=C2=A0 <br>
&gt; This comment applies to any and all protocol drafts and is not specifi=
c to this I-D.<br>
<br>
Thanks for the current status.=C2=A0 My goal for highlighting the CATS agen=
da point was to draw early attention to this discussion.<br>
<br>
The existing work on the 5g metadata draft already highlighted a number of =
places where it was a &quot;lumpy fit&quot; for traditional BGP.=C2=A0 Disc=
ussion on that document raised points about how it&#39;s a limited domain s=
olution, had interesting security considerations in terms of confining the =
new path attribute to that domain, and its impacts on BGP route selection a=
nd forwarding consistency.=C2=A0 <br>
<br>
Many of those points are likely to be general to the CATS work.<br>
<br>
If CATS has reached the point where &quot;does this fit into existing proto=
cols&quot; is the conversation point, I&#39;d suggest soliciting specific t=
alks about how CATS requirements and the protocol under consideration&#39;s=
 defined behaviors are likely to interact.=C2=A0 In my opinion, it&#39;s mu=
ch better to have those &quot;lumpy fit&quot; discussions more under the au=
spice of CATS requirements than seeing what can be pushed into the protocol=
 of the day. <br>
<br>
-- Jeff<br>
<br>
_______________________________________________<br>
Idr mailing list -- <a href=3D"mailto:idr@ietf.org" target=3D"_blank">idr@i=
etf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:idr-leave@ietf.org" targe=
t=3D"_blank">idr-leave@ietf.org</a><br>
</blockquote></div>

--000000000000c53e2e06423de956--