Euro-IX export: individual VLANs in connection_list

[pierky]

As per @bluikko from #89...

According to PeeringDB the current way to list each member IP address in its own vlan_list element could be understood as each IPv4/IPv6 address being their own interface (=IXP port). The trouble here I think is that arouteserver does not really have the interface/port-level information and could not associate each IPv4 address with the corresponding IPv6 address.
Currently we just list IPv4 and IPv6 addresses in clients.yml without any way to distinguish which port they belong to.
Individual addresses within the same address family (multiple IPv4 addresses/multiple IPv6 addresses) muddy the waters here - should they be kept in their individual vlan_list elements? It seems to me so and that would make the difficulty. How to associate IPv4 address with its IPv6 counterpart to put them in the same vlan_list element, while keeping a separate vlan_list element for some other IPv4+IPv6 pair? It could be much easier if all IPv4+IPv6 addresses could be lumped in the same vlan_list element but I am not sure if this would still be any better to PeeringDB than having all of the IP addresses in their own individual vlan_list elements. Will update if I get a response to that question.
Example:

{
  "_comment": "Current definition",
  "asnum": 65520,
  "name": "Member",
  "connection_list": [
    {
      "ixp_id": 0,
      "vlan_list": [
        {
          "vlan_id": 0,
          "ipv4": {
            "address": "192.0.2.1"
          }
        },
        {
          "vlan_id": 0,
          "ipv6": {
            "address": "2001:db8::1"
          }
        }
      ]
    }
  ]
}

{
  "_comment": "New definition",
  "asnum": 65520,
  "name": "Member",
  "connection_list": [
    {
      "ixp_id": 0,
      "vlan_list": [
        {
          "vlan_id": 0,
          "ipv4": {
            "address": "192.0.2.1"
          },
          "ipv6": {
            "address": "2001:db8::1"
          }
        }
      ]
    }
  ]
}

And also...

I've found out that in PeeringDB each of the IP addresses indeed shows as a separate interface. But it is possible to manually edit that data at PeeringDB after it has imported the IX-F data. So seems the feedback was given in order to avoid this manual editing.