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 <fischerdoug...@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 <jh...@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 <fischerdoug...@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 < >> humbertogal...@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 >