On 12/5/24 8:20 AM, Felix Huettner wrote: >>> + struct ipv4_netaddr addr = networks->ipv4_addrs[i]; >>> + ds_put_format(&s, " %s/%d", addr.addr_s, addr.plen); >>> + } >>> + /* We do not need the ipv6 LLA. Since it is last in the list we >>> just >>> + * skip it. */ >> Should we instead use >> in6_is_lla(&op->lrp_networks.ipv6_addrs[j].addr) >> ? >> >> If this has the potential of breaking things (e.g., when users >> explicitly set a LLA into the LRP.networks - although, is that even >> supported and OK?) we could add a helper to ovn-util.[hc]: >> >> lrp_networks_to_string(const struct lport_addresses *, struct ds *) >> >> Like that we don't make assumptions in northd.c about how addresses are >> stored by the ovn-util module. > I took a look into why there is even the need to ignore the generated > ipv6 address in the first place. It would seem to me more logical if the > address list contained all addresses a given port_binding has, instead > of ignoring one. > However i saw multiple places (e.g. bfd_monitor_run in pinctrl.c) that > check if there is any ipv6 address and if yes use the first one. > So for a previous ipv4 only port adding now this generated v6 address > would cause a behaviour change. > I am extremely uncertain if this would be breaking in any way. > > I will therefor add the helpers to ovn-util as you suggested. >
Sounds good, thanks! _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
