Subject: [bess] Implications of using non-anycast IRB GW MAC address

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Wed, 28 Apr 2021 16:52:51 +0530

draft-ietf-bess-evpn-inter-subnet-forwarding describes two ways of
assigning the default GW MAC address in section 4.1:

<snip>
   1.  All the PEs for a given tenant subnet use the same anycast
       default gateway IP and MAC addresses.  On each PE, this default
       gateway IP and MAC addresses correspond to the IRB interface
       connecting the BT associated with the tenant's VLAN to the
       corresponding tenant's IP-VRF.

   2.  Each PE for a given tenant subnet uses the same anycast default
       gateway IP address but its own MAC address.
</snip>

It says that option-1 is recommended because of the ease of anycast MAC
address provisioning. However, option-2 is not prohibited. I think using a
non-anycast default GW MAC address has certain implications on the mobility
procedures (section 7) that is not well described in the draft:

Section 7.1 says the following:
<snip>
   The source NVE upon receiving this MAC/IP Advertisement route,
   realizes that the MAC has moved to the target NVE.  It updates its
   MAC-VRF and IP-VRF table accordingly with the adjacency information
   of the target NVE.  In the case of the asymmetric IRB, the source NVE
   also updates its ARP table with the received adjacency information
   and in the case of the symmetric IRB, the source NVE removes the
   entry associated with the received (MAC, IP) from its local ARP
   table.  It then withdraws its EVPN MAC/IP Advertisement route.

*   Furthermore, it sends an ARP probe locally to ensure that the MAC is
 gone.  If an ARP response is received, the source NVE updates its ARP
 entry for that (IP, MAC) and re-advertises an EVPN MAC/IP   Advertisement
route for that (IP, MAC) along with MAC Mobility   Extended Community with
the sequence number incremented by one.*  The
   source NVE also exercises the MAC duplication detection procedure in
   section 15.1 of [RFC7432].
</snip>

Now, if the source NVE uses a non-anycast default GW MAC address, then it
will receive an ARP response for its ARP probe since the ARP response will
be sent back to the non-anycast MAC address. This may cause the source NVE
to think that the TS has moved back, resulting in re-advertisement of the
EVPN MAC/IP route for that (IP, MAC) along with the MAC mobility EC with
the seq. number incremented by one.

To avoid this problem, source NVE needs to understand that the ARP response
was received over the MPLS/IP core instead of over the access-facing IRB
interface and discard it.

In section 7.2 the draft says the following:
<snip>
   o  The target NVE passes the ARP request to its locally attached TSes
      and *when it receives the ARP response*, it updates its IP-VRF and
      ARP table with the host (MAC, IP) information.  It also sends an
      EVPN MAC/IP Advertisement route with both the MAC and IP addresses
      filled in along with MAC Mobility Extended Community with the
      sequence number set to the same value as the one for MAC-only
      advertisement route it sent previously.
</snip>

In the above, the ARP request is originated by the source NVE. Hence, if
the source NVE uses a non-anycast default gateway MAC address, then the ARP
response will be sent back to the source NVE, instead of being locally
consumed by the target NVE and causing it to perform the procedures
described above.

In section 7.3, the draft says the following:
<snip>
   The target NVE passes the ARP request to its locally attached TSes
   and *when it receives the ARP response*, it updates its MAC-VRF, IP-
   VRF, and ARP table with the host (MAC, IP) and local adjacency
   information (e.g., local interface).  It also sends an EVPN MAC/IP
   advertisement route with both the MAC and IP address fields filled in
   along with MAC Mobility Extended Community with the sequence number
   incremented by one.
</snip>

The problem here is the same if the source NVE uses a non-anycast default
GW MAC address..

Should there be a better description in the draft on the implications of
using non-anycast default GW MAC address?

Are there IRB deployments using non-anycast default GW MAC address for
hosts/servers (other than the one used only for OAM)?

Regards,
Muthu