Figure out timeline for snabbvmx lwaftr configuration migration

[wingo]

This is a bug that needs @mwiget :) We are migrating the configuration of the lwaftr over to a standard YANG model. This means that the configuration syntax changes, and that the configuration will incorporate the binding table as well. We're still working out details. In the meantime internally when we see an old configuration, we transparently migrate it to the new format. Eventually we should fix all users to just take the new format directly. So my question to you is, when is a good time to migrate over the snabbvmx lwaftr to use the new configuration format?

If you check out the "yang" branch of the lwaftr then run "snabb lwaftr migrate-configuration old.conf" you will see what the new format looks like (currently). Probably in the next couple weeks things will change in minor ways but that's the big picture.

[mwiget]

@wingo, happy to look into it. For easier discussion, I migrated one of the smaller example configs I have and show it here. I have a few questions:

the config is now in a single file, which also includes mac addresses, which were previously given as arguments to snabb. Is snabb lwaftr now capable of reconfiguring itself beyond just the binding table?

I have an issue with including the mac addresses in the config. They are somewhat a "runtime thing" and should ideally be taken from the NIC directly, or provided as arguments to snabb.

The binding table looks much easier now, making my "glue" script between Junos config store and snabb config a lot easier.

binding-table {
  br-address fd00:4600:8888::2;
  psid-map {
    addr 193.5.1.2;
    psid-length 6;
    reserved-ports-bit-count 0;
    shift 10;
  }
  softwire {
    ipv4 193.5.1.2;
    padding 0;
    psid 4;
    b4-ipv6 fd00:4600::1004;
    br 0;
  }
  softwire {
    ipv4 193.5.1.2;
    padding 0;
    psid 2;
    b4-ipv6 fd00:4600::1002;
    br 0;
  }
  softwire {
    ipv4 193.5.1.2;
    padding 0;
    psid 1;
    b4-ipv6 fd00:4600::1001;
    br 0;
  }
  softwire {
    ipv4 193.5.1.2;
    padding 0;
    psid 5;
    b4-ipv6 fd00:4600::1005;
    br 0;
  }
  softwire {
    ipv4 193.5.1.2;
    padding 0;
    psid 3;
    b4-ipv6 fd00:4600::1003;
    br 0;
  }
}
external-interface {
  allow-incoming-icmp true;
  error-rate-limiting {
    packets 600000;
    period 2;
  }
  generate-icmp-errors true;
  ip 172.20.0.2;
  mac 02:cf:69:15:00:00;
  mtu 9000;
  next-hop {
    mac 02:02:02:02:02:02;
  }
  reassembly {
    max-fragments-per-packet 40;
    max-packets 20000;
  }
}
internal-interface {
  allow-incoming-icmp true;
  error-rate-limiting {
    packets 600000;
    period 2;
  }
  generate-icmp-errors true;
  hairpinning false;
  ip 2001:db8::1;
  mac 02:cf:69:15:00:00;
  mtu 9000;
  next-hop {
    mac 02:02:02:02:02:02;
  }
  reassembly {
    max-fragments-per-packet 40;
    max-packets 20000;
  }
}

[wingo]

Thanks for the feedback, Marcel.

Note that there are some fixes in https://github.com/Igalia/snabb/pull/557 so that configuration settings with their default value won't be printed in a migrated schema.

The lwaftr is not yet capable of reloading its configuration when anything changes (e.g. ingress filters). I am not exactly sure what the final setup is going to look like there -- probably there will be some extra app in the config graph that will periodically check for messages. One thing that could happen after a message would be to update the binding table in place, and things carry on. Another thing would be to trigger a complete reconfiguration. In that case probably we would recreate the app graph or something. Probably also we should be able to reload just the binding table. That's the general direction where we're headed.

Regarding the MAC addresses it's an interesting question and I don't know the right answer. We do need to fabricate mac addresses in some cases (e.g. vmdq multiple interfaces). I think though that if you don't care you can set them to 00:00:00:00:00:00 and that is fine.

I'm glad the binding table change works for you. Note that we have now fixed the defaults for "padding" and also for "br", and that the precise names of the configuration settings may change over the next couple weeks. I think we just had a high-entropy annealing moment and things can settle down again.

[mwiget]

I liked the separate binding file from the configuration parts, because it allowed me to detect changes in either or both of them and take appropriate actions: if only the binding table changed, send a SIGHUP to snabb, otherwise terminate it so it gets restarted. Done by file comparisons.

On MAC addresses: For our use case, I prefer to pass them as arguments, because I have that information available at runtime. Putting it into the config breaks somewhat the portability of the config to another server, or more importantly to simply run multiple instances with the exact same configuration data, except the mac addresses, which are interface dependent.

I'm fine putting dummy addresses in there, as long as I can still set it via command arguments.

[wingo]

Closing this bug; snabbvmx migration will happen as needed.