[bess] EVPN Multihoming and Symmetric IRB

[Muthu Arul Mozhi Perumal <[e-mail]>]

Hi Everyone,

draft-ietf-bess-evpn-inter-subnet-forwarding does not explicitly describe
the implications of EVPN multihoming on IRB. It seems to assume that the
IRB procedures can be easily extrapolated to multihoming following RFC 7432
and it says so at least for the mobility procedures described in section 4.

However, I think there are key implications of multihoming for symmetric
IRB.

Fast Convergence:
Section 8.2 of RFC 7432 says the following:
<snip>
   Upon a failure in connectivity to the attached segment, the PE
   withdraws the corresponding set of Ethernet A-D per ES routes.  This
   triggers all PEs that receive the withdrawal to update their next-hop
   adjacencies for all *MAC addresses* associated with the Ethernet
   segment in question.  If no other PE had advertised an Ethernet A-D
   route for the same segment, then the PE that received the withdrawal
   simply invalidates the *MAC entries *for that segment.  Otherwise, the
   PE updates its next-hop adjacencies accordingly.
</snip>

Clearly, it describes fast convergence only for the MAC addresses of TSs
(and not for their IP addresses). In symmetric IRB, the ingress PE performs
a route lookup for the destination TS prefix in IP-VRF and forwards the
packet to the egress PE. Hence, the above fast convergence is not
applicable. It however is applicable for asymmetric IRB where the
destination subnet is configured in the ingress PE and it performs a lookup
in the BT corresponding to the destination subnet and forwards the frame.

Aliasing and Backup Path:
With symmetric IRB, the ingress PE cannot use alias label (i.e. label
advertised in AD per EVI route) to load balance traffic sent to egress PEs
multihomed to the same CE, since the egress PE needs to first perform a
route lookup for the destination prefix in the IP-VRF to forward the
packet. The ingress PE instead needs to rely on multipath techniques
applicable to L3VPN (such as BGP multipath).

Now, coming to the backup path, section 8.4 of RFC 7432 says the following:
<snip>
   The backup path is a closely related function, but it is used in
   Single-Active redundancy mode.  In this case, a PE also advertises
   that it has reachability to a given EVI/ES using the same combination
   of Ethernet A-D per EVI route and Ethernet A-D per ES route as
   discussed above, but with the "Single-Active" bit in the flags of the
   ESI Label extended community set to 1.  A remote PE that receives a
   MAC/IP Advertisement route with a non-reserved ESI SHOULD consider
   the *advertised MAC address* to be reachable via any PE that has
   advertised this combination of Ethernet A-D routes, and it SHOULD
   install a backup path for that MAC address.
</snip>

Clearly, it describes the backup path only for the MAC address of the TS
(and not for their IP address). Hence, it is not applicable to symmetric
IRB. It however is applicable to asymmetric IRB.

Is my understanding correct? Shouldn't the implications of multihoming on
symmetric IRB be explicitly captured
in draft-ietf-bess-evpn-inter-subnet-forwarding?

Regards,
Muthu