Re: Outbound Route Filtering (ORF) vendor support

[Douglas Fischer <fischerdouglas () gmail com>]

Thanks Jeffrey!

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.

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.

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.

Or (I know someone will try to kill-me fo that) a new address family for
ORF based on Wide Communities could germinate.


Em qui., 19 de ago. de 2021 às 09:16, Jeffrey Haas <jhaas () pfrc org>
escreveu:

> > On Aug 19, 2021, at 12:18 AM, Douglas Fischer <fischerdouglas () gmail com>
> wrote:
> > I agree that without combining prefix-list and as-path, the
> effectiveness of ORF, considering its initial purpose, the pros and cons
> does not pay themselves.
> > But (there is always a but), I was imagining a different use for
> ext-community-orf !
> > Considering scenarios like:
> >  -  Route-Servers of big IXPs, now days with almost 200K routes.
> >  - Transit providers sending its own point of view of DFZ with almos
> 900K routes.
> > On both cases, informative communities are an excelente way to decide
> "what is good for my ASN, and what is not".
> > Yes, I know that is possible to filter based on that after receiving
> those routes.
> > But it takes computational effort on both sides to do that.
> > And I imagine that comparing to AS-Path Regex, the needed computational
> effort and the complexity of the logics to do filtering based on
> community-list are much smaller.
> > So, if I could say:
> >      "Hey Mr. Route-Server... how are you?
> >      Could you please not send-me the routes that are tagged with the
> community <RS-ASN:xyz>?
> >      And after that, send-me just the routes that are tagged with the
> community <RS-ASN:abc>?"
> > In a Route-Server context, beyond reduce the number of BGP Messages that
> would be great for the CPU/Memory consumption both, RS and RS-Client.
> > Or, in a Transit context...
> > 1 - Customer opens a ticket with support team to set the export filter
> to send only default-route.
> > 2 - Customer, 5 days later, opens a ticket with support team re-adjust
> the export filter, now sending full-routing.
> > 3 - Customer, on next month, opens another ticket with support team to
> send only the cone at right of the ASN of ITP.
> > With a good and public informative communities policy and
> ext-community-orf, the transit customer could change what his router will
> receive from the BGP transit Peer, depending only on himself.
> > Well... I don't really know how complex is to deal with that again on a
> WG.
> > But I would like to see that.
>
> Once upon a time, people would register their filtering intent with a
> local IRR and the route server would simply construct the necessary view
> for them.  It seems like IXPs have gotten out of that habit.
>
> As Robert notes elsewhere, RT-Constrain is something that might work fine
> if implementations support filtering vs. non-VPN famlies with it.  However,
> that's still somewhat problematic for the type of scenario you're
> discussing.
>
> Rt-Constrain is intended to be a pull protocol for positive state.
> Basically, "send me things that have X route-target extended community in
> it".  While it's possible that IXP process might map well to that semantic
> with some careful planning, much of the time the desire is for filtering
> out of stuff - the opposite semantic.  So, this becomes an awkward fit for
> Rt-Constrain.  Even for the previously discussed ORFs, this is awkward and
> that's part of the discussion about the RD-ORF proposal.
>
> An example of something that would fit modestly well for Rt-Constrain is
> routes are tagged by the IXP with a route-target that has the AS of the IXP
> participant.  You then send in a Rt-Constrain route for each of the ASes
> you want to pull from the RS.  But as noted, this means applying
> Rt-Constrain to non-VPN families which not all implementations do.  (I keep
> intending to do the work in Juniper's implementation, but the round-tuit
> vs. fighting our process get in the way...)
>
> -- Jeff

-- 
Douglas Fernando Fischer
Engº de Controle e Automação