Hi Jorge,
Thank you for your email.
I know that EVPN application will pick up one.
But my question is how can you make sure that the exact one in your expectation
will be picked out?
Other scenarios just need to pick up one for all RT-2 routes that refers to
that ESI,
but the Bump-in-the-wire use case need to pick the exact one per each RT-5
route.
That's the difference.
In the example I have described , if the IP-VRF picks up the RT1 route
R1_BD2<RD=BD-20, ESI23, 0>,
The data packets to SN1 will be sent over another BD (BD-20), and BD-20 can't
reach SN1.
That's the problem.
Note that BD-20 and BD-10 are on the same ES but on different VLAN of that ES.
This problem requires the EVPN Application to use both R5's RD and ESI overlay
index to ensure that only R1_BD1 will be picked out.
As far as I know, such approach has never been used in symmetric IRB, for
ARP/ND tables and for interface-ful models up to now.
Whe should note that EVPN not only have port-based service interface, but also
have VLAN-based service interface.
When the EVPN Instances on ESI23 uses VLAN-based service interface, and these
BDs are integrated with the same Routing Instance (IP-VRF),
How can the IP-VRF pick out the exact one (behind which the prefix SN1 of that
RT-5 lies there) from many RT-1 routes (one per BD) ?
Do you think that each one (if it is picked out) of them will reach SN1 ?
If anything about the problem statement is not clear, let me know where is it
please.
This is the example (based on Figure 7 of [IP Prefix Advertisement] ) I have
described for problem statement, I repeat it here:
"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 ?"
Thanks,
Yubao
原始邮件
发件人：Rabadan,Jorge(Nokia-US/MountainView)
收件人：王玉保10045807;
抄送人：bess@ietf.org;
日 期 ：2021年07月30日 21:47
主 题 ：Re: Comments on draft-ietf-bess-evpn-prefix-advertisement
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] 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
