Hello Authors of https://datatracker.ietf.org/doc/html/rfc9014
I have few queries specifically on the "UMR" and "arp/nd flooding control" and might be inter-related >>>> https://datatracker.ietf.org/doc/html/rfc9014#section-3.5.1 MAC Address >>>> Advertisement >>>> Control<https://datatracker.ietf.org/doc/html/rfc9014#name-mac-address-advertisement-c> Host1-----NVE1-----PE1-----(WAN)-----PE2-----NVE2----Host2 For realization of UMR usage, does the logic entails that * the end-host (host1) shall learn the remote-hosts (host2) MAC and IP (in a remote DC/fabric/site for same-subnet) over data-plane via normal flood and learn via typical APR request/response; and o the eventual data flow from host1 to the host2 shall hits the UMR on NVE1 (first hop Vtep) * the first-hop vtep (NVE1) will not learn the MAC bindings over Control plane from the PE1 o as the PE1 will publish only UMR in place of all remote MACs hosted in remote DC/fabric/site. ? * This shall also mandate proxy-arp functionality on PE1 for the requests arising from the hosts (host1) in attached DC, o else request for same credentials (host2) shall flood the WAN from other attached hosts to the fabric. Or there is something more to it. >>>> https://datatracker.ietf.org/doc/html/rfc9014#section-3.5.2: ARP/ND >>>> Flooding >>>> Control<https://datatracker.ietf.org/doc/html/rfc9014#name-arp-nd-flooding-control> The ARP/ND queries should also be proxied by PE's (PE1 and PE2) to the request generated from inside the attached DC/fabric, as it will save on flooding over WAN. Anyways, PE shall absorb all the remote fabric info (RT-2's from remote fabrics) to realize UMR and shall avoid relaying it to the attached fabric/DC. Any thoughts on above shall be great. Regards, Saumya.
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
