Hi Muthu and everyone else,
The IP Aliasing in Symmetric IRB is described in
draft-sajassi-bess-evpn-ip-aliasing-00 .
It works well for each local host<IP,MAC> learned on the IRB interface.
I think when the IRB interface itself is configured with an anycast Gateway
IP-address for its corresponding subnet,
the IP address of the IRB interface itself doesn't have an explicit ESI to be
announced together with its own MAC/IP address in current documents,
Can we use an vESI for IRB interface itself or its corresponding MAC-VRF (which
is similar ot the I-ESI concept)?
This issue exists in both symmetric IRB and asymmetric IRB.
Thanks
Bob
On Wed, 24 Apr 2019 09:57:51 +0530
Muthu Arul Mozhi Perumal <muthu.a...@gmail.com> wrote:
> 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
