How is it planned to implement this in the new style configuration? As own service bound to interfaces (denest) or as part of an interface?

Yes, I think set service ra interface ... or something like that might be the best option. That would eliminate the template generator script all together and I was thinking to remove interface by interface from the generator, as the rewrite progresses.
Since it needs a migrator script for each interface then as well, even if the option are the same.

aone migrator for all interfaces is sufficient (see mew bridge interface and migrator 0-to-1 in interfaces)

On the other hand it still can live in the interface directly which would spare the migrator. VLANs are a good example - I‘ve written a common function to parse it in each interface. I am not fully convinced on any implementation be it under an interface or as dedicated service.

Other vendors like cisco place it under each and every interface.

Also the XML definition could live in a central place and included as e.g. via GCC preprocessor so it is defined only once though. It eliminates a lot of duplicated information. Makefile then can piece it together.

Btw, doesnt FRR come with RA,too?

@dmbaturin advice?

Hmm, that's actually a good point (http://docs.frrouting.org/en/latest/ipv6.html). I started with implementing it as service, it has the advantage that you don't have the duplicated template code. I would lean the towards implementing it for frr rather then using radvd. I currently have set service ipv6-ra interface eth3 ... as CLI path which I would stay with, or should it then be moved into protocol? I'll focus on implementing it for frr, since the CLI path is different the current as well as a new implementation could coexist for testing so we can find the best way out.

very basic example (uses default paramaters):

 service {
+    ipv6-ra {
+        interface eth3 {
+            disable
+            prefix 2001:db8:cafe:beef::/64 {
+            }
+            prefix 2001:db8:dead:beef::/64 {
+            }
+        }
+    }

syning against frr ist the harder part compared to rewriting a conf file and restart radvd or stop is if all configs are removed. I'll try to get it done using frr, if it's in a new path anyway it won't really matter. If it works well, it would give us the advantage of a) remove radvd entirely from the iso and b) having a central backend.

• What other nodes will be unter the prefix tagNode?
• How would namesevrers be configured?

Currently I use:

vyos@vyos# show interfaces ethernet eth0 vif 500 | strip-private
 address xxxx:xxxx:200:50::FFFF/64
 address xxx.xxx.151.238/28
 ipv6 {
     dup-addr-detect-transmits 1
     router-advert {
         cur-hop-limit 64
         link-mtu 0
         managed-flag true
         max-interval 600
         other-config-flag false
         prefix xxxx:xxxx:200:50::/64 {
             autonomous-flag true
             on-link-flag true
             valid-lifetime 2592000
         }
         reachable-time 0
         retrans-timer 0
         send-advert true
     }
 }

I just have a gut feeling its better suited under the interface instead of a dedicated service. For FRR, have a look into the BFD implementation

You can announce multiple prefixes with different options. If you leave for each interface all the options need to be generated (like it is right now), or manually setup or generate for vyos-1x. Also you need to consider that you may send RAs on vif and stuff like that only. dup-addr-detect-transmits has not real anything to do with sending RAs.

DNS and DNSSL is basically encapsulated into the interface defintion.
set service ipv6-ra interface ethx dssl (tagnode) and teh same for DNS.

I just tested frr sending RAs, setup manually which works quite well. So, now it needs the determined what path it should go (stay in interface or move out to service) and if we go with frr for it or stay with radvd. I would be in favor of frr.

If FRR has all we need we should use it - drops one additional dependency

Yup, I tested almost all parameters we have currently in our cli, works all quite well. So, I'm going to implement it under service then?

Personally I would keep it under the interface itself but @dmbaturin should have the final decission

current hop limit is per default set to 64, but can't be set in frr while is was/is possible for radvd. I'd propose to use the the frr options only and not using the current existing ones, that way migration will become easier since the option 'current hop limit' could be just skipped and removed during migration.
Any ideas? Or should we stay with radvd for that purpose?
I would only do it for 1.3 and not backport into 1.2-rolling.

Opinions?

end: sudo sh -c "VYOS_TAGNODE_VALUE='$VAR(../../@)' ${vyos_conf_scripts_dir}/router-advert.py" would have to be in /opt/vyatta/share/vyatta-cfg/templates/interfaces/ethernet/node.tag/ipv6/router-advert/node.def
I can set that statically, which removes then the benefit for the use of other passes, IPv6 RAs can be sent over quite some interfaces.