Subject: ORF implementation issue

From: "Stephen Waters" <[email-masked]>
Date: Mon, 15 Jul 2002 15:35:45 +0100

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: Jeffrey Haas <[email-masked]>
Date: Mon, 15 Jul 2002 10:53:05 -0400

On Mon, Jul 15, 2002 at 03:35:45PM +0100, Stephen Waters wrote:
> 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.

I may be reading too much into things, however this is my opinion:

I think that ORFs were only ever intended to be a very coarse grained
method of sending around policy.  The lack of a useful policy algebra
means that all you can ever send is one coarse level of a given
policy element (communities, prefix lists, etc.) and see if it goes
beyond there.  This makes in the responsibility of the entity
constructing the ORFs to make them perhaps more permissive that one would
want them to be.

Now given that they are only good for coarse grained policy, what are
they good for?  You cite the lack of wild cards as an example of
why they are coarse.

Making rfc 2547 scale is probably the most obvious.  The route target
communities provide exactly the coarse filter element that is needed.
One could probably construct other examples.

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

Given the coarseness of the tool, it is perhaps better to allow the
user to manually construct the list rather than to derive the list
from policy.

Note that given a particular regular expression, you *could* construct
the list of all possibile matches.  Its just combinatorically messy.

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

It would be useful to have default policies for each ORF type
(or not) on a configurable basis along with a default policy when
running ORFs.  Does this adequately restate the above?

-- 
Jeff Haas 
NextHop Technologies