...

/routing ospf interface-template
add network=192.168.0.0/24 area=backbone_v2
add network=2001:db8::/64 area=backbone_v3
add network=ether1 area=backbone_v3

Another big difference is that ROSv7 uses templates to match interface against template and apply configuration from matched template.  OSPF menus interface and neighbormenus are  contains read only entries purely for configuration, to monitor adjacent neighbors or interface status there are two new menu interface-state and neighbor-statestatus monitoring.

All route distribution control is now done purely with routing filter select, no more redistribution knobs in the instance. This gives greater flexibility on (Since v7.1beta7 redistribution knob is back, but you still need to use routing filters to set route costs and type if necessary). This gives greater flexibility on what routes from which protocols you want to redistribute.
For example, let's say you want to redistribute only static IPv4 routes from the 192.168.0.0/16 network range.

/routing ospf instance
set backbone_v2 out-filter-chain=ospfv2ospf_out_select redistribute=static
/routing filter select-rule add chain=ospfv2_out_select do-where=ospf_out

/routing filter rule add chain=ospf_out rule="if (dst in 192.168.0.0/16) { action accept}"

...

There is a complete redesign of the BGP configuration compared to ROSv6. The first biggest difference is that there is no more instance and peer configuration menus. Instead, we have connection, template and session menus.
The reason for such structure is to strictly split parameters that are responsible for connection and change of these parameters requires immediate connection termination and parameters that do not tear existing connection when changedparameters that are BGP protocol specific.

Let's start with the Template. It contains all BGP protocol related configuration options. It can be used as a template for dynamic peers and apply a similar config to a group of peers. Note that this is not the same as peer groups on Cisco devices, where the group is more than just a common configuration.

...

Most of the parameters are similar to ROSv6 except that some are grouped in the output and input section making the config more readable and easier to understand whether option is applied on input or output. If you are familiar with capsman CapsMan then the syntax is the same, for example, to specify output selection chain you set output.filter-chain=myBgpChain.

You can even inherit template parameters from another template, for example:

/routing/bgp/template 
add name=myAsTemplate as=65500 output.filter-chain=myAsFilter
set default template=myAsTemplate

Another important aspect of the new routing configuration is Routing Instance, which sets router-id and group peers in one instance. RouterOS adds a default instance which picks instance-id from any interface highest IP. The default BGP template by default is set to use the "default" instance.
If for any reason you need to tweak or add new instances it can be done in /routing instance menu.

...

Other great debugging information on all routing processes can be monitored from /routing stats menu

[admin@v7_ccr_bgp] /routing/stats/process> print interval=1
Columns: TASKS, PRIVATE-MEM-BLOCKS, SHARED-MEM-BLOCKS, PSS, RSS, VMS, RETIRED, ID, PID, RPID, PROCESS-TIME, KERNEL-TIME, CUR-B>
# TASKS PRIVATE-M SHARED-ME PSS RSS VMS RET ID PID R PROCESS-TI KERN>
0 routing tables 12.2MiB 20.0MiB 18.7MiB 42.2MiB 83.4MiB 8 main 319 0 19s750ms 8s50>
rib >
connected networks >
1 fib 512.0KiB 0 7.4MiB 30.9MiB 83.4MiB fib 384 1 5s160ms 22s5>
2 ospf 1024.0KiB 1024.0KiB 5.9MiB 25.9MiB 83.4MiB 382 ospf 388 1 1m42s170ms 1m31>
connected networks >
3 fantasy 512.0KiB 0 2061.0KiB 5.9MiB 83.4MiB fantasy 389 1 1s410ms 870m>
4 configuration and reporting 40.0MiB 512.0KiB 45.0MiB 64.8MiB 83.4MiB static 390 1 12s550ms 1s17>
5 rip 768.0KiB 0 5.3MiB 24.7MiB 83.4MiB rip 387 1 1s380ms 1s20>
connected networks >
6 routing policy configuration 512.0KiB 256.0KiB 2189.0KiB 6.0MiB 83.4MiB policy 385 1 1s540ms 1s20>
7 BGP service 768.0KiB 0 2445.0KiB 6.2MiB 83.4MiB bgp 386 1 6s170ms 9s38>
8 BGP Input 10.155.101.217 8.8MiB 6.0MiB 15.6MiB 38.5MiB 83.4MiB 20 21338 1 25s170ms 3s23>
BGP Output 10.155.101.217 >
9 Global memory 256.0KiB global 0 0 >
-- [Q quit|D dump|C-z pause|right]

...

Route filtering differs a bit from ROSv6. In the BGP template, you can now specify output.filter-chain, output.filter-select, input.filter as well as several input.accept-* options.

...

/routing/filter/rule 
add chain=bgp_in rule={ 
  "if ([prfx-value is=dst<subsumes>192dst in 192.168.0.0/16]) then={ action accept}} "
add chain=bgp_in rule={ 
  num-value set="set bgp-local-pref<sub>1; 
 pref num-prop1; set= bgp-igp-metric<assign>ospfmetric ospf-ext-metric; 
  action=accept 
}accept" 

...

Lastly, you might notice that network menu is missing and probably wondering how to advertise your own networks. Now you would need to add a route to the routing table before being able to advertise it to the remote peer.
So networks are added in firewall address-list and referenced in BGP configuration.
Following ROSv6 network configuration:

/routing bgp network add network=192.168.0.0/24

in v7 would translate to:

 synchronize=yes
/ip route add dst-address=192.168.0.0/24 type=blackhole

would translate to v7 as:

/ip/firewall/address-list/
add list=bgp-networks address=192.168.0.0/24

/ip/route 
add dst-address=192.168.0.0/24 type=blackhole

/routing/filterbgp/ruleconnection
addset chain=bgppeer_outname rule={ if ([prfx-value is=dst<subsumes>192.168.0.0/24]) then={ action accept }}output.network=bgp-networks

There is more configuration to be done when adding just one network, but offers simplicity when you have to deal with large amount of networks. v7 even allows to specify for each bgp connection its own set of networks. 

Routing Filters

Starting from ROSv7.1beta4, routing filter configuration is changed to script-like configuration. Rule now can have "if .. then" syntax to set parameters or apply actions based on conditions from "if" statement.

...

/routing/filter/rule
add chain=ospf_in rule={ 
  "if ([prfx-value is=dst<equal>0dst==0.0.0.0/0] && [protocol ==static]) \
  then={ action=accept }
}"

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 rule={
  "if ([prfx-value is=dst<subsumes>172dst in 172.16.0.0/16] && \
      [num-value is=dst-len<equals>24dst-len==24] && \
      [protocol static]) \
  then={ actionprotocol==static) { 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 rule={ 
  "if ([num-value is=dst-len<equal>24dst-len==24] && \
dst      [prfx-value is=dst<subsumes>172in 172.16.0.0/16]) { \n
  then={
    num-value set=bgp-med<assign>20;
   set num-valuebgp-med 20; set= bgp-path-prepend<assign>2prepend 2;
    action accept;
  }
}"

It is also possible to match prefix length range like this

/routing/filter/rule
add chain=BGP_OUT rule={
  "if ([num-value is=dst-len<greater-than>13] && \
      [num-value is=dst-len<less-than>31]dst-len>13 && \
      [prfx-value is=dst<subsumes>172dst-len<31 && dst in 172.16.0.0/16]) \
  then={ action accept }
}"

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

/routing/filter/rule
add chain=bgp_in rule={" bgp-communities-large append= 200001:200001:10 }"

If there are a lot of community sets, that need to be applied in multiple rules, then it is possible to define community sets and use them to match or set:

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


/routing/filter/rule
add chain=bgp_in rule={" bgp-communities-large-set append-set= myLargeComSet }"

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

/routing/filter/rule
add chain=bgp_in rule={" bgp-communities-ext append=RT 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 the exact state.

...