Subject: ORF implementation issue #2

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

Here's another issue that came up when implementing ORF:

The filters can be Normal, or Exact matching.  For the Normal case the draft says:

"NORMAL scope
   indicates that the remote peer should consider only those routes
   whose Communities attribute either is equal to the Communities list
   specified in the ORF, or exhibit a subset relation with the
   Communities list specified in the ORF."

This gives the manager a support issue with the defined ORFs. Since community IDs will come and go, and the local manager has no control over what community IDs a route will collect, it is not feasible to set up a filter (as defined in the draft) that will be a stable superset of the IDs carried by a route.

It is more likely that a core set of IDs carried by a route will remain constant, so allowing the Normal filter community-list to be a subset of the route's community-list is more useful/stable.

Alternatively, a third filter class is added:  Exact/Subset/Superset. All of these match 'exact',
subset => filter can be a subset of the route's IDs, superset is the old 'Normal'.

At the moment, I've take the approach to allow Normal filters to be a subset of the route, but unlike issue #1, this does need to be agreed. So, I should at least have a control to allow a peer to work in subset or superset mode when using ORFs to filter.

Steve.