Subject: RE: ORF implementation issue

From: "Natale, Jonathan" <[email-masked]>
Date: Mon, 15 Jul 2002 13:03:48 -0400

I see this as equivalent to the "implied deny all" rule.  I am assuming
there is a way to replace/preempt this with a "permit all" in ORF.  If not,
then I would agree that this makes things very difficult for the manager.

-----Original Message-----
From: Stephen Waters [mailto:[email-masked]] 
Sent: Monday, July 15, 2002 10:36 AM
To: [email-masked]
Subject: ORF implementation issue

Having implemented ORF, I have a few issues with the draft. Here is the
first one...

"If a particular route maintained by a BGP speaker doesn't match any
   of the ORF entries of any of the (non-empty) ORFs associated with a
   particular peer, then this route should not be advertised to the
   peer."

I think this makes things very difficult for the manager.  The idea with ORF
(I think) is to 
reduce the local processing of routes by warning your peer about routes you
are definitely not interested in.

Since there is no support for wild cards in spec., this text would require
the manager to set up ORF entries (to be sent to the peer) for every
conceivable community-mix that may be of interest. If he misses some, or a
new community appears on the block, useful routes may be lost.

For example, I am will to accept routes with any one of 300 different
communities, and am not interested in 20 other community groups.  I would
need to send 20 DENY filters, and 300 PERMIT filters.

Now the problem:

A route can carry a number of communities, and new community numbers will
come and go.  This would cause we to have to update my filters constantly.

I have taken the view that blocking useful routes would be very bad, and if
the ORF filtering is in any doubt, the route should be sent and the local
filtering on the remote peer can make the final decision.

So, in my implementation, if there is no matching ORF filter, the route is
passed. Taking this approach also means that I can no reduce my ORF to a
list of explicit DENY filters (with the occasional imbedded PERMIT).  This
approach also means that if community lists change, the result is much less
likely to result in lost useful routes, and unwanted routes carrying strange
new community lists can be filtered as and when the manager has time.

Comments?

Regards, Steve.

---

From: "Stephen Waters" <[email-masked]>
Date: Tue, 16 Jul 2002 09:35:30 +0100

Thanks for the responses to the mail below.

I just thought I summarize the views expressed in the mail I received:

1) don't use ORF if it doesn't suit your filtering needs.

This translates to:  If want to accept most routes, and filter the odd annoying one, you probably don't want ORF since this could involve entering a large number of permit filters.  

Regardless of your policy model, you also have to live with the fact that if routes you like start picking up new community IDs along their merry way, you will lose routes until you fix the filters.

2) we need a 'permit-all' alternative to the 'deny-all' default.

My view on this is that the default could be changed to 'permit-all'. This is not a 'firewall'; it's a feature to help save processing bandwidth where back-stop local policy is there to make the final call.

Steve.

> From: Stephen Waters 
> Sent: Monday, July 15, 2002 3:36 PM
> To: [email-masked]
> Having implemented ORF, I have a few issues with the draft. 
> Here is the first one...
> 
> 
> I think this makes things very difficult for the manager.  
> The idea with ORF (I think) is to 
> reduce the local processing of routes by warning your peer 
> about routes you are definitely not interested in.
> 
> Since there is no support for wild cards in spec., this text 
> would require the manager to set up ORF entries (to be sent 
> to the peer) for every conceivable community-mix that may be 
> of interest. If he misses some, or a new community appears on 
> the block, useful routes may be lost.
> 
> For example, I am will to accept routes with any one of 300 
> different communities, and am not interested in 20 other 
> community groups.  I would need to send 20 DENY filters, and 
> 300 PERMIT filters.
> 
> Now the problem:
> 
> A route can carry a number of communities, and new community 
> numbers will come and go.  This would cause we to have to 
> update my filters constantly.
> 
> I have taken the view that blocking useful routes would be 
> very bad, and if the ORF filtering is in any doubt, the route 
> should be sent and the local filtering on the remote peer can 
> make the final decision.
> 
> So, in my implementation, if there is no matching ORF filter, 
> the route is passed. Taking this approach also means that I 
> can no reduce my ORF to a list of explicit DENY filters (with 
> the occasional imbedded PERMIT).  This approach also means 
> that if community lists change, the result is much less 
> likely to result in lost useful routes, and unwanted routes 
> carrying strange new community lists can be filtered as and 
> when the manager has time.
> 
> Comments?
> 
> Regards, Steve.
>