[Idr] Re: IETF 124 - non-IDR presentations of interest

[Adrian Farrel <[e-mail]>]

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

 

A

 

From: Robert Raszuk <[e-mail]> 
Sent: 28 October 2025 20:32
To: Jeffrey Haas <[e-mail]>
Cc: Adrian Farrel <[e-mail]>; idr <[e-mail]>
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-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 PM Jeffrey Haas <[e-mail] <mailto:[e-mail]> > wrote:

Adrian,


> On Oct 28, 2025, at 2:31 PM, Adrian Farrel <[e-mail] <mailto:[e-mail]> > 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 mailing list -- [e-mail] <mailto:[e-mail]> 
To unsubscribe send an email to [e-mail] <mailto:[e-mail]>