Re: Outbound Route Filtering (ORF) vendor support

2021-08-20 Thread Robert Raszuk
> This means you'd need to tag EVERYTHING - and that may be operationally
> problematic for Internet routes.

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)

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.

Of course native filtering based on communities itself may also be cool.

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.

Best,
R.



On Fri, Aug 20, 2021 at 9:34 PM Jeffrey Haas  wrote:

> On Fri, Aug 20, 2021 at 04:04:35PM -0300, Douglas Fischer wrote:
> > 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.
>
> The IXP would need to have a mechanism that fits nicely into their route
> server and operational infrastructure.  The mechanism I was referring to
> previously for having it in their IRR was how the RSng infrastructure Merit
> operated years ago worked.  In those days, the route server was the ISI
> software.
>
> (Note that this is historical.)
>
> > 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.
>
> Code-wise, it's simple.
>
> Operationally, it's an interesting mess.  Rt-Constrain is a filter that
> says
> "if you have one of these Extended Communities, you can send it".  This
> means you'd need to tag EVERYTHING - and that may be operationally
> problematic for Internet routes.
>
> Some of the related issues are tangentially covered in a proposal to do
> Rt-Constrain on things other than just Extended Communities.
>
>
> https://datatracker.ietf.org/doc/html/draft-zzhang-idr-bgp-rt-constrains-extension-01
>
> > 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.
>
> While I'm clearly a fan of Wide communities, I'd suggest that running an
> entire deployment via the -rpd mechanism still seems operationally
> challenging.  I guess we'll see how that works out.
>
> -- Jeff
>


Re: Outbound Route Filtering (ORF) vendor support

2021-08-20 Thread Jeffrey Haas
On Fri, Aug 20, 2021 at 04:04:35PM -0300, Douglas Fischer wrote:
> 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.

The IXP would need to have a mechanism that fits nicely into their route
server and operational infrastructure.  The mechanism I was referring to
previously for having it in their IRR was how the RSng infrastructure Merit
operated years ago worked.  In those days, the route server was the ISI
software.

(Note that this is historical.)

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

Code-wise, it's simple.

Operationally, it's an interesting mess.  Rt-Constrain is a filter that says
"if you have one of these Extended Communities, you can send it".  This
means you'd need to tag EVERYTHING - and that may be operationally
problematic for Internet routes.

Some of the related issues are tangentially covered in a proposal to do
Rt-Constrain on things other than just Extended Communities.

https://datatracker.ietf.org/doc/html/draft-zzhang-idr-bgp-rt-constrains-extension-01

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

While I'm clearly a fan of Wide communities, I'd suggest that running an
entire deployment via the -rpd mechanism still seems operationally
challenging.  I guess we'll see how that works out.

-- Jeff


Re: Outbound Route Filtering (ORF) vendor support

2021-08-20 Thread Douglas Fischer
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 
escreveu:

>
>
> > On Aug 19, 2021, at 12:18 AM, Douglas Fischer 
> 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 ?
> >  And after that, send-me just the routes that are tagged with the
> community ?"
> > 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


Re: Outbound Route Filtering (ORF) vendor support

2021-08-19 Thread Jeffrey Haas



> On Aug 19, 2021, at 9:04 AM, james jones  wrote:
> 
> PCRE or death. Tell me if I am wrong, but I thought PCRE was the most widely 
> used regex lib these day anyways. I also thought it was already in Junos.

Junos is a very wide topic.

In Juniper's BGP implementation, there are two regular expression engines: one 
for communities, one for as-paths.  Neither are PCRE.

The implementation of regular expression matching in high availability software 
is a bit of a talk all on its own.

-- Jeff



Re: Outbound Route Filtering (ORF) vendor support

2021-08-19 Thread james jones
PCRE or death. Tell me if I am wrong, but I thought PCRE was the most widely 
used regex lib these day anyways. I also thought it was already in Junos.

Sent from my iPhone

> On Aug 19, 2021, at 7:56 AM, Jeffrey Haas  wrote:
> 
> 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  
>> 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 
>>  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
> 


Re: Outbound Route Filtering (ORF) vendor support

2021-08-19 Thread Jeffrey Haas



> On Aug 19, 2021, at 12:18 AM, Douglas Fischer  
> 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 ?
>  And after that, send-me just the routes that are tagged with the 
> community ?"
> 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



Re: Outbound Route Filtering (ORF) vendor support

2021-08-19 Thread Jeffrey Haas
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  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 
> mailto: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



Re: Outbound Route Filtering (ORF) vendor support

2021-08-19 Thread Robert Raszuk
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 
wrote:

> Thanks Jeffrey!
>
> Well, I invested 15 minutes passing my eyes on the IDR list archive Joel
> mentioned(scary!).
> You were very concise describing ll 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 ?
>  And after that, send-me just the routes that are tagged with the
> community ?"
> 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 
> 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 
>> 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 

Re: Outbound Route Filtering (ORF) vendor support

2021-08-18 Thread Douglas Fischer
Thanks Jeffrey!

Well, I invested 15 minutes passing my eyes on the IDR list archive Joel
mentioned(scary!).
You were very concise describing ll 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 ?
 And after that, send-me just the routes that are tagged with the
community ?"
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 
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 
> 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


Re: Outbound Route Filtering (ORF) vendor support

2021-08-18 Thread Joel Halpern

You may want to examine the IDR lsit archive
https://mailarchive.ietf.org/arch/browse/idr/?q=orf
for discussion of the orf proposal and the difficulties people have with it.

Yours,
Joel

On 8/18/2021 1:10 PM, Douglas Fischer 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 
mailto: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




Re: Outbound Route Filtering (ORF) vendor support

2021-08-18 Thread Douglas Fischer
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