Hi Jorge,
I don't agree with you for that the recursive resolution for such ESI overlay
index is already there.
Current recursive resolution is very different from such ESI overlay index.
Please see in-line with [Yubao].
Thanks,
Yubao
原始邮件
发件人：Rabadan,Jorge(Nokia-US/MountainView)
收件人：王玉保10045807;
抄送人：bess@ietf.org;
日 期 ：2021年07月28日 21:23
主 题 ：Re: Re:Comments on draft-sajassi-bess-evpn-ip-aliasing-02
Hi Yubao,
Assuming we agree we can’t have a RT5 with non-zero GW-IP and non-zero ESI,
I’ll try to compare using a) gw-ip *or* b) ESI in the RT5 for this use case
when leaf-5 is a non-upgraded PE:
a) non-zero GW-IP. Suppose if Leaf-5 is a non-upgraded PE but it complies with
draft-evpn-prefix-advertisement. Leaf-5 receives a RT5 with GW-IP=1.1.1.1, and
will expect a RT2 to resolve the overlay index. So Leaf-5 will not forward any
traffic till that RT2 is received. You could extend your suggestion to
advertise an RT2 with the VNF loopback, but the MAC could not be the VNF MAC,
or you would run into issues. Also the RT2 would need IP-VRF route-target and
label. Also we don’t want to do that, we want to leave the RT2 for either the
interface-ful model, or the symmetric IRB model. Using RT2s in the
interface-less model would bring ambiguity and issues.
[Yubao] I don't think the GW-IP have to expect a RT2 to resolve the overlay
index.
It just need to expect to find the GW-IP in the FIB, regardless of that
which form of route will be resolved.
In this use case, it will be another RT5 route for 1.1.1.1.
As you have pointed out, this is nothing new. so it will works.
b) non-zero ESI. A non-upgraded Leaf-5 receives the RT5 with non-zero ESI and
will expect a RT1 to resolve the overlay index as per
draft-evpn-prefix-advertisement. When the RT1 comes along, it may not do
aliasing, but it will forward the traffic.
[Yubao] If you mean the procedures in the Bump-in-the-wire use case,
I would say that the ESI23 will expect a RT1 to resolve the overlay
index,
But not a random RT1 of ESI23, it Must be the RT1 of an expected BD.
But an IP-VRF may have many BDs attached to it, all of them may
advertise a RT1 for ESI23.
Which BD's RT1 should the ESI23 of that RT5 be resolved?
The Bump-in-the-wire contains such requirements, but this use case
don't.
I don't think they can be considered as the same procedure.
So I don't think that a non-upgraded Leaf-5 should act as you have
expected.
(b) is the solution we chose in this draft because it is simpler (no complexity
associated to RT2s) and it is already there also for ESes associated to
physical links.
[Yubao] I don't agree with that it is already there. please see my above
explanation.
I don't see any other usage of ESI overlay index in RT5 route, except
for the Bump-in-the-wire use case.
Are there other ESI usage specifications for RT5 that I have missed out
?
If you want to use the VNF loopback for the resolution of the RT5 to another
RT5, please use a different attribute, and not the GW-IP since it will cause
backwards interop issues.
[Yubao] Interfaceful mode says that the GW-IP overlay index will be used for
the recursive route resolution,
not for just a pre-restricted RT1, it just happens to be a RT1 in that
use case.
just like it happens to be another RT5 in this use case.
So I think the gap between Interfaceful mode and this use case is more
smaller
than the gap between Bump-in-the-wire and this use case.
Because in Bump-in-the-wire use case that expected RT1 need to be found
out among lots of competitors of the same ESI.
[Yubao] This is the orignal text in Interfaceful mode :
o GW IP address=IRB-IP of the SBD (this is the Overlay Index
that will be used for the recursive route resolution).
[Yubao] I don't think the route-type is pre-restricted before the recursive
route resolution. it is techincally not necessary.
If you know draft-ietf-bess-evpn-prefix-advertisement has said
that in wich section , let me know please.
About your comment that RT5s can be advertised with all the leaf nodes with
different attributes, sure, then you rely on the bgp best path selection done
on the Leaf-5, nothing new. Here we want the simple primary/backup signaling
decided by the multihomed leaf nodes, in the same way it is done for L2.
[Yubao] Maybe you mean it is the same way as L2 EVPNs on Leaf-5,
But it will be differnt way on Leaf-2 and on Leaf-5.
I think the difference between L2 and L3 service is just in expectation,
But Leaf-2 don't have to be so different from Leaf-5.
Will the dataplane be extended on Leaf-2 ?
Thanks.
Jorge
From: wang.yub...@zte.com.cn <wang.yub...@zte.com.cn>
Date: Wednesday, July 28, 2021 at 2:06 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com>
Cc: bess@ietf.org <bess@ietf.org>
Subject: Re:Comments on draft-sajassi-bess-evpn-ip-aliasing-02
Hi Jorge,
Please see in-line with [Yubao_2].
Thanks,
Yubao
原始邮件
发件人：Rabadan,Jorge(Nokia-US/MountainView)
收件人：王玉保10045807;
抄送人：bess@ietf.org;
日 期 ：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: wang.yub...@zte.com.cn <wang.yub...@zte.com.cn>
Date: Wednesday, July 28, 2021 at 9:53 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com>
Cc: bess@ietf.org <bess@ietf.org>
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;
抄送人：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.
1. The IP Prefix routes are advertised with the ESI and always a
zero-GW-IP.
1. 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.
2. 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:
1. 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.
2. 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.
3. 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.
1. 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
