Hi Muthu,
Please see in line with the label "[Bob]".
Regards,
Bob
原始邮件
发件人:MuthuArulMozhiPerumal <muthu.a...@gmail.com>
收件人:王玉保10045807;
抄送人:bess@ietf.org <bess@ietf.org>;
日 期 :2019年04月25日 14:08
主 题 :Re: [bess] EVPN Multihoming and Symmetric IRB
Hi Bob,
Thanks for your response. Please see inline.
On Thu, Apr 25, 2019 at 6:28 AM <wang.yub...@zte.com.cn> wrote:
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.
Glad to know that my understand that fast convergence, aliasing and backup path
as described in RFC 7432 is applicable only for host MAC addresses and not for
their IP addresses is correct :) I think it is important to capture this
implication for symmetric IRB in draft-ietf-bess-evpn-inter-subnet-forwarding
and probably add a reference to draft-sajassi-bess-evpn-ip-aliasing to indicate
how those functionalities can be realized in the symmetric IRB case.
On a different note, when IP aliasing is used, I think it slightly modifies the
definition of symmetric IRB because the egress PE is no longer doing a lookup
in the IP-VRF, rather forwarding the packet on the ES after doing a LFIB
lookup. This should perhaps be captured in draft-sajassi-bess-evpn-ip-aliasing.
[Bob]: I agree with you on the slight conceptual inconsistency with the
symmetric IRB concept.
Because the alias label is a Layer 2 Label not a Layer 3 Label, and I think
there is another issue.
The issue is that the encapsulation of L2 Label is different from the
encapsulation of L3 Label on the ethernet header's appearance in MPLS dataplane.
In MPLS dataplane, Data Packets are typicall encapsulated without an inner
ethernet header in Symmetric IRB procedures because of the nature of its L3
Label.
But now in ip aliasing it is replaced with an L2 Label and an encapsulation
with an inner ethernet header.
I think it will be an modification in the sender PE too.
Note that now the destination MAC will be a RMAC (also known as "Router's MAC")
instead of a host mac.
I don't know exactly how to forward an ethernet packet in a MAC-VRF given that
its D-MAC is a RMAC.
Can we assume that the RMAC is the same as the IRB interface's own MAC?
If we can't, I don't know how to forward it.
If we can, it can be forwared according to EVPN IRB procedures again but it is
not so symmetric.
And I think the RMAC is not used in MPLS symmetric IRB according to current
documents, this is another modification IMHO.
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,
Why do we need a non-zero ES for the anycast gateway IP address? My
understanding is that you include the gateway IP address in the MAC/IP
advertisement route for MAC address aliasing so that the receiver can check if
the received IP address matches with the locally configured anycast gateway IP
address. Does it serve any other purpose?
[Bob]: Let's take the following figure for an example:
/---- PE1----\
L2PE PE3----CE2
\---- PE2----/
PE1/PE2 is the PEs for EVPN IRB, and PE3 is just an L3 PE without IRB.
When the IRB iterface's own MAC/IP address is anycast address,
It is necessary for the L2PE to load-balance traffic to PE1/PE2 via an ESI of
these IRB interfaces, rather than do MAC mobile between PE1 and PE2.-
I think it is necessary for PE3 too. Although PE3 may have other options to do
the load-balancing.
Regards,
Muthu
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