Outbound Route Filtering (ORF) vendor support

Robert Raszuk robert at raszuk.net
Thu Aug 19 09:08:57 UTC 2021

Hi Doug,

But what you need you can do today in any shipping decent implementation of
BGP using RTC.


While originally designed for L3VPNs long ago the use of RTC has been
extended for other address families including SAFI 1.

As a matter of fact because this mechanism is already in place few of the
ORF extensions did not move forward.

Many thx,

On Thu, Aug 19, 2021 at 6:19 AM Douglas Fischer <fischerdouglas at gmail.com>

> Thanks Jeffrey!
> Well, I invested 15 minutes passing my eyes on the IDR list archive Joel
> mentioned(scary!).
> You were very concise describing aaaall that discussion in such polide way.
> 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.
> Em qua., 18 de ago. de 2021 às 20:11, Jeffrey Haas <jhaas at pfrc.org>
> escreveu:
>> ORFs are a challenging feature and haven't gotten a lot of deployment for
>> a number of reasons.
>> At a high level, they're a very coarse filter.  Since each new ORF type
>> adds to the logical AND condition, you start having to be more and more
>> permissive in what you permit in the policy.  Since a significant amount of
>> common ISP policies require matching things in tuples, this doesn't
>> translate super well into many types of automatically generated ORFs.
>> The ext-community-orf feature was effectively supplanted by Rt-Constrain
>> (RFC 4684).
>> The as-path ORF was challenging because different vendors have different
>> ideas about what "regex" means and what the input tokens are.  Consider for
>> example Juniper vs. Cisco regex matching.  The abstract fix would have been
>> to define a regex that is for the feature.  I half suspect if people pushed
>> on this these days, they'd want PCRE. :-)
>> The RD-ORF work is part of some ongoing discussion about how to deal with
>> VRF overwhelm (prefix-limit exceed).
>> -- Jeff (IDR co-chair)
>> On Aug 18, 2021, at 1:10 PM, Douglas Fischer <fischerdouglas at gmail.com>
>> wrote:
>> Hello!
>> I also found a recent draft(expires Novembre 2021) about using Route
>> Distinguisher as a Value on ORF.
>> https://datatracker.ietf.org/doc/draft-wang-idr-rd-orf/
>> Em qua., 18 de ago. de 2021 às 11:41, Humberto Galiza <
>> humbertogaliza at gmail.com> escreveu:
>>> Hi,
>>> Is anyone aware of any vendor that supports Outbound Route Filtering
>>> (ORF) based on anything other than prefix-lists?
>>> I found these two old IETF drafts (both expired :-/) which supported
>>> the idea of filtering based on community and as-path respectively, but
>>> I wasn't able to understand if they were ever discussed at the WG and
>>> if there was any outcome of the discussion (I suspect the authors are
>>> no longer even working with the mentioned companies in the drafts):
>>> -
>>> https://datatracker.ietf.org/doc/html/draft-chen-bgp-ext-community-orf-02
>>> - https://datatracker.ietf.org/doc/html/draft-ietf-idr-aspath-orf-13
>>> Any info is very much appreciated.
>>> Thanks,
>> --
>> Douglas Fernando Fischer
>> Engº de Controle e Automação
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210819/58d72814/attachment.html>

More information about the NANOG mailing list