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

["Rabadan, Jorge (Nokia - US/Mountain View)" <[e-mail]>]

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.
     *   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.
     *   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.



  1.  About the use-case of slide 7:
     *   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.
     *   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.
     *   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.

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

                      ii.   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.

                     iii.   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.

     *   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<https://datatracker.ietf.org/meeting/111/materials/slides-111-bess-sessa-evpn-ip-aliasing-00>, 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<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-prefix-advertisement-11#section-3.2> .



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<https://datatracker.ietf.org/doc/html/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<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-prefix-advertisement-11#section-3.2> 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<https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing-02#section-1.3>-02, I see the ESI is configured on the ACs of the BDs.



Is anything I have misunderstood?



Best,

Yubao