<div dir="ltr"><br><div>> This means you'd need to tag EVERYTHING - and that may be operationally</div><div>> problematic for Internet routes.<br></div><div><br></div><div>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) </div><div><br></div><div>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. </div><div><br></div><div>Of course native filtering based on communities itself may also be cool. </div><div><br></div><div>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. </div><div><br></div><div>Best,<br>R.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 20, 2021 at 9:34 PM Jeffrey Haas <<a href="mailto:jhaas@pfrc.org">jhaas@pfrc.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Aug 20, 2021 at 04:04:35PM -0300, Douglas Fischer wrote:<br>
> About the cone definition (by AS-SET) of IXPs... This is an especially<br>
> important thing.<br>
> But, unless some external force come to push the IXPs to do it, I don't see<br>
> that we will have that so soon.<br>
<br>
The IXP would need to have a mechanism that fits nicely into their route<br>
server and operational infrastructure.  The mechanism I was referring to<br>
previously for having it in their IRR was how the RSng infrastructure Merit<br>
operated years ago worked.  In those days, the route server was the ISI<br>
software.<br>
<br>
(Note that this is historical.)<br>
<br>
> About the use of RT-Constrain as a "please give that" tool, Robert<br>
> mentioned SAFI 1, but...<br>
> I don't see how to use that on the actual BGP engines on the tradicional<br>
> BGP sessions. Even considering semantic limitation you mentioned.<br>
<br>
Code-wise, it's simple.<br>
<br>
Operationally, it's an interesting mess.  Rt-Constrain is a filter that says<br>
"if you have one of these Extended Communities, you can send it".  This<br>
means you'd need to tag EVERYTHING - and that may be operationally<br>
problematic for Internet routes.<br>
<br>
Some of the related issues are tangentially covered in a proposal to do<br>
Rt-Constrain on things other than just Extended Communities.<br>
<br>
<a href="https://datatracker.ietf.org/doc/html/draft-zzhang-idr-bgp-rt-constrains-extension-01" rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/html/draft-zzhang-idr-bgp-rt-constrains-extension-01</a><br>
<br>
> I was reading some drafts and this one caught my attention.<br>
> <a href="https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/" rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/</a><br>
> <br>
> That idea of Wide Communities is a one-fit-all tool.<br>
> Maybe using the feature that will come from this Draft on another way, it<br>
> could do the "please give that" job.<br>
<br>
While I'm clearly a fan of Wide communities, I'd suggest that running an<br>
entire deployment via the -rpd mechanism still seems operationally<br>
challenging.  I guess we'll see how that works out.<br>
<br>
-- Jeff<br>
</blockquote></div>