Subject: cooperative route filtering questions and comments

From: Jeffrey Haas <[email-masked]>
Date: Mon, 29 Apr 2002 13:05:29 -0400

I'm reviewing the ORF documents and several questions have occured to me:

When you receive a given ORF, the action type may be ADD, REMOVE or
REMOVE-ALL.  However, it is unstated whether or not an ADD is also
an implicit replace.  Consider the following:

The BGP Speaker receives an ADD with a match of PERMIT for a community
ORF of community set C1 and then it later (but not necesarily immediately)
followed by another ADD of PERMIT for the same C1 without an intervening
REMOVE, are there now two C1's in the ORF list?

Similarly, if one receives an ADD with a match of PERMIT for C1 and
then receives an ADD with a many of DENY for C1, the behavior should
be to PERMIT for C1, correct?  

However, if the behavior of ADD is to replace or ignore, then
the second ADD of C1 as a DENY may result in either the PERMIT
(sent first) to be replaced or the later DENY (sent second) to be ignored.

Thanks to the communities specification being ambiguous, we also have
the issue of ordering and duplicate communities within a given ORF.
If one receives an ADD for a community set C1 and then a REMOVE
for C2 where the elements of C1 and C2 are the same but in a 
different order, should the REMOVE still take place or should C2
fail to match unless C2 was explicitly sent?

I believe that this implies that the receiving BGP Speaker must
store the exact ORF received for purposes of ORF list manipulation
regardless of internal implementation.

The current ORF specification has room for a BGP Speaker to advertise
both the cooperative route filtering capability and route refresh
at the same time.  Since ORFs overload the RouteRefresh message
type, this now means that a receiving speaker must now determine
if the message is an ORF message or a plain RouteRefresh message
from the length of the message.  A sentence in the specification
that spells this out would be nice.

When one specifies REMOVE-ALL, this Action is encoded in the
ORF along with a Match bit.  This seems to imply (currently)
that one can do a REMOVE-ALL on all PERMITs and a REMOVE-ALL
on DENYs separately.  I suspect that REMOVE-ALL was intended
to reflect removing all ORFs of a particular type.  As such,
it should be noted as ignoring the Match bit when being processed.

Would this also apply to an explicit REMOVE?  I.e., if ADD is
not an replace operation, does a Speaker need to look for
the Match bit when processing REMOVEs?

-- 
Jeff Haas 
NextHop Technologies

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 29 Apr 2002 12:49:34 -0700

Jeff,

> an implicit replace.  Consider the following:

in the context of community-based ORFs ADD is also an implicit replace.

> REMOVE, are there now two C1's in the ORF list?

Just C1.
  
> (sent first) to be replaced or the later DENY (sent second) to be ignored.

The result is DENY for C1.

> fail to match unless C2 was explicitly sent?

The REMOVE still takes place (as C1 and C2 are sets, and the order of 
elements within a set doesn't matter).

> that spells this out would be nice.

we'll add this to the next revision of the text.

> it should be noted as ignoring the Match bit when being processed.

ditto.

> the Match bit when processing REMOVEs?

in the context of community-based ORFs ADD is a replace operation.

Yakov.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 29 Apr 2002 15:57:18 -0400

Yakov,

Thanks for all of the clarifications.  Looking forward to seeing
the next revision.

On Mon, Apr 29, 2002 at 12:49:34PM -0700, Yakov Rekhter wrote:
[...]

-- 
Jeff Haas 
NextHop Technologies