...

One filter rule in ROSv7 compared to ROSv6 can have only one set of "match" and one set of "set", which means that if you want to match by more than one parameter set multiple parameters you will have to add more than one rule, for example, match static default route and apply action acceptconfiguration line.

Multiple rules without action are stacked in single rules and executed in order like firewall rules, the reason is that "set" parameter order is important and by writing one "set"s per line, allows for easier understanding from top to bottom on what actions were applied.

For example, match static default route and apply action accept can be written in one config line because multiple matchers are allowed:

/routing/filter/rule
add chain=ospf_in match-prfx-value="dst<equal>0.0.0.0/0"
add chain=ospf_in match-protocol=static action=accept

Multiple rules without action are stacked in single rules and executed in order like firewall rules.
For example, ROSv6 For example, ROSv6 rule "/routing filter add chain=ospf_in prefix=172.16.0.0/16 prefix-length=24 protocol=static action=accept" converted to ROSv7 would be:

/routing/filter/rule
add chain=ospf_in match-prfx-value="dst<subsumes>172.16.0.0/16"
add chain=ospf_in match-num-value="dst-len<equals>24"
add chain=ospf_in match-protocol=static action=accept

...

Another example, match prefixes from 172.16.0.0/16 range with prefix length equal to 24 and set bgp med and prepend values

/routing/filter/rule
add chain=BGP_OUT match-num-value=dst-len<equal>24 match-prfx-value=dst<subsumes>172.16.0.0/16 
add chain=BGP_OUT set-num-value=bgp-med<assign>20
add chain=BGP_OUT set-num-value=bgp-path-prepend<assign>2 
add chain=BGP_OUT action=accept

We can modify this rule to tale less configuration lines but sacrifice readability:

/routing/filter/rule
add chain=BGP_OUT match-num-value=dst-len<equal>24 match-prfx-value=dst<subsumes>172.16.0.0/16 set-num-value=bgp-med<assign>20
add chain=BGP_OUT set-num-value=bgp-path-prepend<assign>2 action=accept

It is also possible to match prefix length range like this

/routing/filter/rule
add chain=BGP_OUT match-num-value=dst-len<greater-than>13,dst-len<less-than>31 
add chain=BGP_OUT match-prfx-value=dst<subsumes>172.16.0.0/16 
add chain=BGP_OUT action=accept

Filter rules now can be used to match or set communities,  large communities, and extended communities from community list:

/routing/filter/large-community-set
add set=myLargeComSet community=200001:200001:10 


/routing/filter/rule
add chain=bgp_in set-bgp-communities-large="modify<append>myLargeComSet" action=accept

Since route target is encoded in extended community attribute to chamnge or match RT you need to operate on extended community attribute, for example:

/routing/filter/large-community-set
add set=myLargeComSet community=200001:200001:10 


/routing/filter/rule
add chain=bgp_in set-bgp-communities-large="modify<append>myLargeComSet" action=acceptext=modify<append>RT:327824:20

RPKI

RouterOS implements an RTR client. You connect to the server which will send route validity information. This information then can be used to validate routes in route filters against a group with "rpki-validate" and further in filters "match-rpki" can be used to match exact state.

...