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)?
As you illustrated in slide 7, Leaf-2 can't get this information from VNF-1
directly,
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.
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?
Yubao
原始邮件
发件人：Rabadan,Jorge(Nokia-US/MountainView)
收件人：王玉保10045807;
抄送人：bess@ietf.org;
日 期 ：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.
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.
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: wang.yub...@zte.com.cn <wang.yub...@zte.com.cn>
Date: Wednesday, July 28, 2021 at 12:14 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com>
Cc: bess@ietf.org <bess@ietf.org>
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_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
