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
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
