> This means you'd need to tag EVERYTHING - and that may be operationally
> problematic for Internet routes.

When I wrote my note I envisioned that RS on inbound may tag routes with RTs (based on the very same communities you would filter without RTs) 

Then enabling RTC SAFI would be pretty easy. I think with IOS-XE RS and IOS-XE client this could even work today without much effort - but I will say honestly that I have not tried it. 

Of course native filtering based on communities itself may also be cool. 

Last drops of updated based on community policy is cheap so perhaps client can just  filter between ajd-rib to bgp-rib interesting routes locally without signalling. After all the only bigger churn is at original session up. Then subsequent BGP updates usually would be pretty painless. 

Best,
R.



On Fri, Aug 20, 2021 at 9:34 PM Jeffrey Haas <jhaas@pfrc.org> wrote:
On Fri, Aug 20, 2021 at 04:04:35PM -0300, Douglas Fischer wrote:
> About the cone definition (by AS-SET) of IXPs... This is an especially
> important thing.
> But, unless some external force come to push the IXPs to do it, I don't see
> that we will have that so soon.

The IXP would need to have a mechanism that fits nicely into their route
server and operational infrastructure.  The mechanism I was referring to
previously for having it in their IRR was how the RSng infrastructure Merit
operated years ago worked.  In those days, the route server was the ISI
software.

(Note that this is historical.)

> About the use of RT-Constrain as a "please give that" tool, Robert
> mentioned SAFI 1, but...
> I don't see how to use that on the actual BGP engines on the tradicional
> BGP sessions. Even considering semantic limitation you mentioned.

Code-wise, it's simple.

Operationally, it's an interesting mess.  Rt-Constrain is a filter that says
"if you have one of these Extended Communities, you can send it".  This
means you'd need to tag EVERYTHING - and that may be operationally
problematic for Internet routes.

Some of the related issues are tangentially covered in a proposal to do
Rt-Constrain on things other than just Extended Communities.

https://datatracker.ietf.org/doc/html/draft-zzhang-idr-bgp-rt-constrains-extension-01

> I was reading some drafts and this one caught my attention.
> https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/
>
> That idea of Wide Communities is a one-fit-all tool.
> Maybe using the feature that will come from this Draft on another way, it
> could do the "please give that" job.

While I'm clearly a fan of Wide communities, I'd suggest that running an
entire deployment via the -rpd mechanism still seems operationally
challenging.  I guess we'll see how that works out.

-- Jeff