Re: [bess] EVPN Multihoming and Symmetric IRB

[<[e-mail]>]

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 <[e-mail]> 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