Hi Yubao, I realized I did not respond to this (my apologies), and you reflected the same questions in your slides about draft-wang-bess-evpn-distributed-bump-in-the-wire during the BESS session. I think it is okay if you want to describe a “distributed” bump-in-the-wire scenario, but I don’t understand why you need any new extension.
* In your slide 5, the RT5s can be resolved to the proper RT1, based on the ESI overlay index. The ESI is unique (cannot be configured in multiple ESes) and the RT1 for the ESI carries the route-target of the BD, hence you have all the information to resolve the RT5. What are you missing? * In your slide 6 you have a use-case with two ACs in the same ESI23, and you seem to use the ethernet tag ID to encode the ACI. Can you not use a different virtual Ethernet Segment per BD instead, and use RT1s for each ESI? In that way you don’t need to use the ethernet-tag-id, which is used for vlan-aware-bundle in general. Thanks. Jorge From: wang.yub...@zte.com.cn <wang.yub...@zte.com.cn> Date: Friday, July 30, 2021 at 5:18 PM To: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com> Cc: bess@ietf.org <bess@ietf.org> Subject: Re:Comments on draft-ietf-bess-evpn-prefix-advertisement 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]<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-prefix-advertisement-11#section-4.3> ) 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]<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
