lib: Introducing a 3rd state for route-map match cmd: RMAP_NOOP

Introducing a 3rd state for route_map_apply library function: RMAP_NOOP

Traditionally route map MATCH rule apis  were designed to return
a binary response, consisting of either RMAP_MATCH or RMAP_NOMATCH.
(Route-map SET rule apis return RMAP_OKAY or RMAP_ERROR).
Depending on this response, the following statemachine decided the
course of action:

Action: Apply route-map match and return the result (RMAP_MATCH/RMAP_NOMATCH)
State1: Receveived RMAP_MATCH
THEN: If Routemap type is PERMIT, execute other rules if applicable,
otherwise we PERMIT!
Else: If Routemap type is DENY, we DENYMATCH right away

State2: Received RMAP_NOMATCH, continue on to next route-map, otherwise,
return DENYMATCH by default if nothing matched.

With reference to PR 4078 (https://github.com/FRRouting/frr/pull/4078),
we require a 3rd state because of the following situation:

The issue - what if, the rule api needs to abort or ignore a rule?:
"match evpn vni xx" route-map filter can be applied to incoming routes
regardless of whether the tunnel type is vxlan or mpls.
This rule should be N/A for mpls based evpn route, but applicable to only
vxlan based evpn route.

Today, the filter produces either a match or nomatch response regardless of
whether it is mpls/vxlan, resulting in either permitting or denying the
route.. So an mpls evpn route may get filtered out incorrectly.
Eg: "route-map RM1 permit 10 ; match evpn vni 20" or
"route-map RM2 deny 20 ; match vni 20"

With the introduction of the 3rd state, we can abort this rule check safely.
How? The rules api can now return RMAP_NOOP (or another enum) to indicate
that it encountered an invalid check, and needs to abort just that rule,
but continue with other rules.

Question: Do we repurpose an existing enum RMAP_OKAY or RMAP_ERROR
as the 3rd state (or create a new enum like RMAP_NOOP)?
RMAP_OKAY and RMAP_ERROR are used to return the result of set cmd.

We chose to go with RMAP_NOOP (but open to ideas),
as a way to bypass the rmap filter

As a result we have a 3rd state:
State3: Received RMAP_NOOP
Then, proceed to other route-map, otherwise return RMAP_PERMITMATCH by default.

Signed-off-by:Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>

1 files changed, 2 insertions, 2 deletions

diff --git a/zebra/redistribute.c b/zebra/redistribute.c
index b13f1170cd..dfff76664c 100644
--- a/zebra/redistribute.c
+++ b/zebra/redistribute.c
@@ -574,7 +574,7 @@ int zebra_add_import_table_entry(struct route_node *rn, struct route_entry *re,
 	struct route_entry *newre;
 	struct route_entry *same;
 	struct prefix p;
-	route_map_result_t ret = RMAP_MATCH;
+	route_map_result_t ret = RMAP_PERMITMATCH;
 	afi_t afi;
 
 	afi = family2afi(rn->p.family);
@@ -583,7 +583,7 @@ int zebra_add_import_table_entry(struct route_node *rn, struct route_entry *re,
 			afi, re->type, re->instance, &rn->p, re->ng.nexthop,
 			re->vrf_id, re->tag, rmap_name);
 
-	if (ret != RMAP_MATCH) {
+	if (ret != RMAP_PERMITMATCH) {
 		UNSET_FLAG(re->flags, ZEBRA_FLAG_SELECTED);
 		zebra_del_import_table_entry(rn, re);
 		return 0;