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

Reply via email to