VXLAN demo, macadv routes have route distinguisher of 0:0

[ABrilliantBeast]

I ran the vxlan demo according to the instructions and it shows an rd of 0:0 for the macadv routes. The multicast routes have the 65000:10 and 20 rd's as expected. It still seems to work properly and the 'h' domain remains separate from the 'j', but it does seem a bit weird. Is this a change in behavior?

[root@host-10-64-247-29 ~]# docker exec -it g1 gobgp global rib -a evpn Network Next Hop AS_PATH Age Attrs *> [type:macadv][rd:0:0][esi:single-homed][etag:10][mac:aa:aa:aa:aa:aa:01][ip:][labels:[10]]0.0.0.0 00:02:04 [{Origin: i} {Extcomms: [VXLAN]}] *> [type:macadv][rd:0:0][esi:single-homed][etag:10][mac:aa:aa:aa:aa:aa:02][ip:][labels:[10]]192.168.10.4 00:02:04 [{Origin: i} {LocalPref: 100} {Originator: 192.168.0.2} {ClusterList: [1.1.1.1]} {Extcomms: [VXLAN]}] *> [type:macadv][rd:0:0][esi:single-homed][etag:20][mac:66:c2:bd:65:a0:ac][ip:][labels:[20]]192.168.10.5 00:03:47 [{Origin: i} {LocalPref: 100} {Originator: 192.168.0.3} {ClusterList: [1.1.1.1]} {Extcomms: [VXLAN]}] *> [type:macadv][rd:0:0][esi:single-homed][etag:20][mac:aa:aa:aa:aa:aa:01][ip:][labels:[20]]0.0.0.0 00:09:41 [{Origin: i} {Extcomms: [VXLAN]}] *> [type:macadv][rd:0:0][esi:single-homed][etag:20][mac:aa:aa:aa:aa:aa:02][ip:][labels:[20]]192.168.10.4 00:09:41 [{Origin: i} {LocalPref: 100} {Originator: 192.168.0.2} {ClusterList: [1.1.1.1]} {Extcomms: [VXLAN]}] *> [type:multicast][rd:65000:10][etag:10][ip:192.168.0.1]0.0.0.0 16:44:45 [{Origin: i} {Pmsi: type: ingress-repl, label: 0, tunnel-id: 192.168.0.1} {Extcomms: [65000:10]}] *> [type:multicast][rd:65000:10][etag:10][ip:192.168.0.2]192.168.10.4 16:44:42 [{Origin: i} {LocalPref: 100} {Originator: 192.168.0.2} {ClusterList: [1.1.1.1]} {Extcomms: [65000:10]} {Pmsi: type: ingress-repl, label: 0, tunnel-id: 192.168.0.2}] *> [type:multicast][rd:65000:10][etag:10][ip:192.168.0.3]192.168.10.5 16:44:40 [{Origin: i} {LocalPref: 100} {Originator: 192.168.0.3} {ClusterList: [1.1.1.1]} {Extcomms: [65000:10]} {Pmsi: type: ingress-repl, label: 0, tunnel-id: 192.168.0.3}] *> [type:multicast][rd:65000:20][etag:20][ip:192.168.0.1]0.0.0.0 16:44:45 [{Origin: i} {Pmsi: type: ingress-repl, label: 0, tunnel-id: 192.168.0.1} {Extcomms: [65000:20]}] *> [type:multicast][rd:65000:20][etag:20][ip:192.168.0.2]192.168.10.4 16:44:42 [{Origin: i} {LocalPref: 100} {Originator: 192.168.0.2} {ClusterList: [1.1.1.1]} {Extcomms: [65000:20]} {Pmsi: type: ingress-repl, label: 0, tunnel-id: 192.168.0.2}] *> [type:multicast][rd:65000:20][etag:20][ip:192.168.0.3]192.168.10.5 16:44:40 [{Origin: i} {LocalPref: 100} {Originator: 192.168.0.3} {ClusterList: [1.1.1.1]} {Extcomms: [65000:20]} {Pmsi: type: ingress-repl, label: 0, tunnel-id: 192.168.0.3}]

[ABrilliantBeast]

I've captured tcpdumps of the bgp updates and the RD is 0:0 in them, and bgp vrf shows the two VRF defined with the expected RD's and RT's.