Hi Yubao,
For GW-IP overlay indexes, until the PE does not receive at least one RT2 for
the GW-IP, you can’t resolve the RT5. If you receive multiple for the same IP
with the same key, it is bgp best path selection. If you receive multiple for
the same IP, different key, the EVPN application picks up one. Implementations
have been doing that selection for symmetric IRB, for ARP/ND tables and for
interface-ful models for years, why is it a problem.
Similar for ESI as overlay index.
Thanks.
Jorge
From: wang.yub...@zte.com.cn <wang.yub...@zte.com.cn>
Date: Friday, July 30, 2021 at 5:01 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com>
Cc: bess@ietf.org <bess@ietf.org>
Subject: Comments on draft-ietf-bess-evpn-prefix-advertisement
Hi Jorge,
In our discussion in another thread, we discussed two types ot the use cases of
draft-ietf-bess-evpn-prefix-advertisement,
They are the GW-IP as overlay index use cases (just let me call them
GW-IP-Style use-cases for short) and the Bump-in-the-wire use case.
I think it is better to discuss it more clearly in a new thread.
1) For the GW-IP-Style use cases, thank you for telling me that the following
text may be contradictory (But I don't think it is like that, I will explain it
later) with my approach :
". If the RT-5 specifies a GW IP address as the Overlay Index,
recursive resolution can only be done if the NVE has received and
installed an RT-2 (MAC/IP route) specifying that IP address in
the IP address field of its NLRI."
It seems that we have to find out that RT-2 before the recursive
resolution.
I just don't know that how can we know there is such a RT-2 before the
recursive resolution ?
We should note that the keys of that RT-2 is <RD, IP, MAC>, but the GW-IP
is just an IP.
So how can we find out that RT-2 just using an IP before the recursive
resolution?
2) For the ESI as overlay index use cases, there is similar text as the
following:
". If the RT-5 specifies an ESI as the Overlay Index, recursive
resolution can only be done if the NVE has received and
installed
an RT-1 (Auto-Discovery per-EVI) route specifying that ESI."
Given that the keys of RT-1 are <RD, ESI, Ethernet Tag ID>,
So how can we find out that RT-2 before recursive resolution just using <ESI,
Ethernet Tag ID> ?
3) For Bump-in-the-wire use case, we would find many RT-1 routes for that ESI
even after the recursive rosolution.
Just take the Figure 7 of [IP Prefix
Advertisement]<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-prefix-advertisement-11#section-4.3>
for example,
How can DGW1 in that Figure find out the exact RT-1 of <ESI23, BD-10> ?
We should note that the RDs of BDs are different from the RD of that IP-VRF.
To be clear, If the DGW1 receives a RT-5 route R5 (IPL=24, IP=SN1,
ESI=ESI23, from NVE2) and two RT1 routes R1_BD1<RD=BD-10, ESI23, 0> and
R1_BD2<RD=BD-20, ESI23, 0>.
These two RT1 routes both can be imported into the same IP-VRF instance.
Which RT-1 route will R5's ESI overlay index be resolved to?
The R1_BD1 or the R1_BD2 ?
4) For Bump-in-the-wire use case, Both of NVE2 and NVE3 will advertise a RT-5
route to DGW1,
Will the common ESI23 of these two RT-5 routes be resolved to the same
RT-1 route? and how?
Note that even the RD of BD-10 will be different on NVE2 and NVE3.
When they are the same RD,I think there wil be method that the RT-5 from
NVE3 can be resolved to the same RT-1 from NVE2.
5) For Bump-in-the-wire use case, If NVE3 advertise another RT-5 route R5b for
another BD (say BD-20) but for the another prefix (e.g. SN2) of the same IP-VRF.
If the RD of that R5b is the same as R5 (see question 3), will the ESI23
of R5b be resolved to the same RT-1 as what R5 will be resolved to?
It seems that they will, according current procedures. But is this result
in expectation ?
Note that ESI23 is provisioned on attachment ports, but both BD-10 and
BD-20 can have an separate AC on the same port.
Regards,
Yubao
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
