Re: [bess] Comments on draft-sajassi-bess-evpn-ip-aliasing-02

[[e-mail]]

Hi Jorge,






Please see in-line with [Yubao_2].






Thanks,


Yubao














原始邮件



发件人：Rabadan,Jorge(Nokia-US/MountainView)
收件人：王玉保10045807;
抄送人：[e-mail];
日 期 ：2021年07月28日 18:18
主 题 ：Re: Re:Comments on draft-sajassi-bess-evpn-ip-aliasing-02




Hi Yubao,


 


Please see in-line with [jorge].


Thanks.


Jorge


 



From: [e-mail] <[e-mail]>
 Date: Wednesday, July 28, 2021 at 9:53 AM
 To: Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]>
 Cc: [e-mail] <[e-mail]>
 Subject: Re:Comments on draft-sajassi-bess-evpn-ip-aliasing-02



 


Hi Jorge,


 


Thanks for your email, but I still don't understand why an ESI is needed here.


I  know there is a static-route 1.1.1.1 on Leaf-2, but my question is that how leaf-2 knows the overlay nexthop of 50.0.0.0/24 is 1.1.1.1  (by which that ARP entry is found out at last)?

[jorge] leaf-2 does a recursive resolution. It has a RT5 for 50.0.0.0/24 with next-hop e.g., Leaf-1, and ESI=ESI-1. So when Leaf-2 receives packets with IP DA = 50.0.0.x, it will have a route installed pointing at the local ESI-1, and the local ESI-1 is associated to 1.1.1.1, for which leaf-2 has a route (static or igp).


As you illustrated in slide 7, Leaf-2 can't get this information from VNF-1 directly, 

[jorge] but it does get it via RT5 with ESI, which is resolved locally.


Leaf-2 just have to get this informatio from the IP Prefix Route Advertisement  of Leaf-1 or Leaf-4,


But you explained that these route are advertised without GW-IP. 


I don't understand it very well.

[jorge] see above. Hope it helps now.


maybe you mean we can inferred from the ESI field that the overlay nexthop is the static-route 1.1.1.1 whose ESI is ESI-1?


This approach maybe works.


but the IP address 1.1.1.1 can be directly advertised as GW-IP overlay index along with prefix 50.0.0.0/24 naturally if we don't manually change its behavior.


so why should we bother to infer from a manual-configured ESI? 

[jorge] Some points:


The ESI can be auto derived as indicated in the draft

Using the GW-IP as overlay-index is used in interface-ful models and the use-cases resolved by an RT2 in draft-ietf-bess-evpn-prefix-advertisement. Non upgraded PEs may have an issue with the resolution. However the ESI as an overlay-index resolved to AD routes is documented in the prefix-advertisement draft.




[Yubao_2] Non-upraded PEs may have an issue to resolution an ESI to an static-route too.

                  I don't think these two similar issues should be a big concern.

                 Most of protocol extensions have similar issues.

                The ESI overlay index is just used in the bump in the wire use case in draft-ietf-bess-evpn-prefix-advertisement.

        In that use case, the ESI is configured on L2 ACs and its Ethernet A-D per EVI is advertised for a BD,

        But in the use case we discussed here, there are no BD1 or BD2 on Leaf-5.

        They are very different use cases and forwarding procedures.




        Even in the Bump-in-the-wire use case, although the RT-5 route has the ESI23 as overlay index,

        but how does the DGWs know which BD should that ESI23 belongs to ?

        Note that many BDs(or MAC-VRFs) can advertise Ethernet A-D per EVI routes for the same ESI23 independently.




        so I think Bump-in-the-wire is very different from the ESI for static-route.

        And the control-plane defined in Bump-in-the-wire may be not so sufficient for the ESI for static-route.

        




Here we really want to use the ESI as an overlay index and resolve based on the AD routes, which gives a consistent solution for the three use cases in the draft, and other things like e.g., not only aliasing, but also primary/backup behavior


 





[Yubao_2]  Use GW-IP overlay index, primary/backup behavior can also be supported.


                  Leaf-1/2/3/4 will advertise a RT-5 route for 1.1.1.1 separately, and they can advertise different preferences/metrics separately.


                  GW-IP overlay index can be a consistent solution whether the PE-CE BGP sessions are established between Leaf-1/2/3/4 and VNF-1 or between DGW and VNF-1.






Yubao


 


 


原始邮件



发件人：Rabadan,Jorge(Nokia-US/MountainView)



收件人：王玉保10045807;



抄送人：[e-mail];



日 期 ：2021年07月28日 14:46



主 题 ：Re: Comments on draft-sajassi-bess-evpn-ip-aliasing-02




Hi Yubao,


 


Thanks for your email. Yes, you misunderstood the use-case 😊 but these are good questions, we will clarify in the next revision.


 


1.       The IP Prefix routes are advertised with the ESI and always a zero-GW-IP.


a.       Three co-authors of this draft are also co-authors of draft-ietf-bess-evpn-prefix-advertisement and the latter explicitly prohibits the use of non-zero ESI and non-zero GW-IP simultaneously. So you will not see the use of the GW-IP in draft-sajassi-bess-evpn-ip-aliasing.


b.       In fact that is also one of my comments for draft-mackenzie-bess-evpn-l3aa-proto-00: using non-zero ESI *and* non-zero GW-IP in the IP Prefix routes is non-backwards compatible and will break interoperability with existing RRs. But I will send a separate email with my comments.


 


2.       About the use-case of slide 7:


a.       As mentioned, the (virtual) ES is associated to the VNF loopback, i.e. 1.1.1.1, and its operational state is tied to the reachability of that loopback.


b.       On leaf-1/2/3/4, the reachability of the loopback is determined by a static-route or IGP, and can be used along with BFD to speed up fault detection.


c.       As an example, suppose leaf-2 has a static-route to 1.1.1.1 with next-hops {20.0.0.1,20.0.0.2,20.0.0.3}, and 1.1.1.1 is associated to ES-1.


1. The ARP resolution to those next-hops is done as usual, nothing especial, it’s done as soon as the static-route is added.


2. ES-1 will be oper-up as long as the static route is active in the IP-VRF route-table. When it goes inactive, ES-1 will go down and the AD routes withdrawn.


3. Obviously, and individual AC going down in leaf-2 will not make the static-route inactive, hence will not bring down the ES. The IRB going down will make the static-route inactive, hence the ES will go down.


d.       A similar example would work with an IGP instead of a static route to 1.1.1.1.


 


I think that should clarify your questions.


Let me know otherwise.


 


Thanks.


Jorge


 


 



From: [e-mail] <[e-mail]>
 Date: Wednesday, July 28, 2021 at 12:14 AM
 To: Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]>
 Cc: [e-mail] <[e-mail]>
 Subject: Comments on draft-sajassi-bess-evpn-ip-aliasing-02



 


Hi Jorge,


 


This is the detailed explanation of the question I asked in the IETF 111 meeting. 


In page 7 of slides-111-bess-sessa-evpn-ip-aliasing, when leaf-5 send traffic to leaf-2,  how does leaf-2 find the corresponding ARP entry for 20.0.0.2 or 20.0.0.1 or 20.1.1.3 ?


I guess the GW-IP 1.1.1.1 will be advertised as overlay index along with the ESI.


But the draft-ietf-bess-evpn-prefix-advertisement-11 does not define an IP Prefix Advertisement Route with both GW-IP and ESI both as overlay index.


I suggest that this should be updated if you want to do so.


And the preference of ESI overlay index should be considered higher than GW-IP overlay index for Leaf-5's sake.


But the preference of ESI overlay index should be considered lower than (or maybe they should both be used? ) GW-IP overlay index for Leaf-2's sake


These are new rules that can't be found in draft-ietf-bess-evpn-prefix-advertisement-11 .


 


But on the contary,  if the IP Prefix Advertisement Route has a GW-IP overlay index,


It can support the same protection procedures without any ESI overlay index.


( The details to do such protection using GW-IP overlay index I have described in draft-wang-bess-evpn-arp-nd-synch-without-irb-06. )


So I don't get the point why we need two redundant overlay index?


Can you clearify it?


 


Maybe an IP Prefix Route Style with a GW-IP overlay index is engough here.


And such Route Style is in compliance with  draft-ietf-bess-evpn-prefix-advertisement-11 already.


 


Another question is that: If the ESI overlay index is advertised, when will the IP A-D per EVI route of Leaf-2 be withdrawn?


When the IRB interface on Leaf-2 fails?


When one of the three ACs fails?


When all of the three ACs fails?


If you want to do so, I suggest that the ESI-1 to be configured onto the IRB interfaces,


But in Figure 2 of  draft-sajassi-bess-evpn-ip-aliasing-02, I see the ESI is configured on the ACs of the BDs.


 


Is anything I have misunderstood?


 


Best,


Yubao