Outbound Route Filtering (ORF) vendor support

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.

https://datatracker.ietf.org/doc/html/rfc4684

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,
R.

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

> 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>