Hi Jorge,
I still don't agree that the procedures on Leaf-5 are already in
draft-ietf-bess-evpn-prefix-advertisement-11.
Note that the key of RT1 route is <RD, ESI, Ethernet Tag ID>, not just <ESI,
Ethernet Tag ID>.
Take the DGW1 of the Bump-in-the-wire use case for example,
If the DGW1 receives a RT-5 route R5 (IPL=24, IP=SN1, ESI=ESI23) 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 ?
Because that the RD of RT-1 route in Bump-in-the-wire is not the same as yours.
Thus the procedures of that use case is not the same as the discussed use case.
Doing anything different than what is in section 4.3 will not interoperate with
non-upgraded DGW1.
Actually, I have used ESI as overlay index in the early revision of
draft-wang-bess-evpn-arp-nd-synch-without-irb .
But later I found that the route resolution of the Bump-in-the-wire use case is
not the same as I have expected at that time.
But the GW-IP overlay index is much better.
So I mainly use the GW-IP Overlay index, I just use the ESI Overlay index when
there is already an ESI (e.g. the ESI is configured for other purpose),
I don't think we need to configure an ESI just for using it as overlay index.
Note that even in Bump-in-the-wire use case, the ESI23 is configured for BD-10
(see Figure 7 of IP prefix advertisement), not just for using it as overlay
index.
Please see more in-line with [Yubao_3]
Thanks,
Bob.
原始邮件
发件人：Rabadan,Jorge(Nokia-US/MountainView)
收件人：王玉保10045807;
抄送人：bess@ietf.org;
日 期 ：2021年07月29日 00:14
主 题 ：Re: Re:Comments on draft-sajassi-bess-evpn-ip-aliasing-02
Hi Yubao,
More in-line.
Thanks.
Jorge
From: wang.yub...@zte.com.cn <wang.yub...@zte.com.cn>
Date: Wednesday, July 28, 2021 at 5:35 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,
I don't agree with you for that the recursive resolution for such ESI overlay
index is already there.
[jorge] The resolution of an RT5 with non-zero ESI to a RT1 is already in
draft-ietf-bess-evpn-prefix-advertisement. The resolution of an RT5 with
non-zero ESI to a local ESI for the synchronization or the route-table belongs
to the ip-aliasing draft. See more below.
[Yubao_3] As I discussed above, the resolution procedures there is very
different from here.
Please see more in-line below with [Yubao_3]
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.
<<<<<<<<<<<<<<<<<
[jorge] I don’t think I pointed that out. Let me clarify:
A RT5 that uses the NLRI next-hop for resolution (so no overlay index) can be
resolved to another RT5. That is, if the RT5’s next-hop was 1.1.1.1 and you
have another RT5 for 1.1.1.1/32, I agree that is not new. But this is not the
case we are discussing.
A RT5 that uses a GW-IP overlay index for resolution it is expecting a RT2 as
per draft-ietf-bess-evpn-prefix-advertisement:
“ . If an NVE receives an RT-5 that specifies an Overlay Index, the
NVE cannot use the RT-5 in its IP-VRF unless (or until) it can
recursively resolve the Overlay Index.
<snip>
. 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.”
[Yubao_3] The NLRI next-hop just should be resolved in the underlay network, it
can't be resolved to another RT-5.
The draft-ietf-bess-evpn-prefix-advertisement just talks about the use
cases it contains,
So it uses the phrase "can only be done", not "MUST only be done", it is
very cautious.
In old use cases (e.g. Interfaceful mode), we should make sure the GW-IP
can be resolved to RT-2.
But in new use cases, it is not necessary to be restricted to that.
If I extend a new Extended Community to replace the GW-IP, it will bring
us no better benefits than the GW-IP itself.
The GW-IP that is resolved to RT5 will bring no harms to existing
implements.
<<<<<<<<<<<<<<<<<
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.
<<<<<<<<<<<<<<<<<<<<<<
[jorge] I’m referring to this text in
draft-ietf-bess-evpn-prefix-advertisement. As specified in the ip-aliasing
draft, to import the RT1 we slap the IP-VRF route-target on it:
. 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.
[Yubao_3] Please see my above explanations. Just an ESI is not enough.
This is just the necessary condition for Bump-in-the-wire use case,
not the sufficient condition for that use case.
Not the necessary condition for other use cases either.
<<<<<<<<<<<<<<<<<<<<<<
(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
?
<<<<<<<<<<<<<<<<<<<<<<
[jorge] I’m referring to sections 3.1 and 3.2 in
draft-ietf-bess-evpn-prefix-advertisement which specify the rules of use for
the RT5. Doing anything different than what is in 3.1 and 3.2 will bring
backwards compatibility issues.
[Yubao_3] As my above explanation, the entire rules are very different
actually.
These two section's just covers the necessary condition of the
Bump-in-the-wire use case,
They can't cover the sufficient condition of the ESI resolution of
the Bump-in-the-wire use case.
Just think about two RT1 routes (with the same ESI and different RD)
both matches the recursive lookup.
It is typical use case where an IP-VRF have more than one BDs on the
same ES been attached to it.
<<<<<<<<<<<<<<<<<<<<<<
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.
<<<<<<<<<<<<<<<<<<<<<<<
[jorge] From the prefix-advertisement draft:
. If an NVE receives an RT-5 that specifies an Overlay Index, the NVE
cannot use the RT-5 in its IP-VRF unless (or until) it can recursively
resolve the Overlay Index. . 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.
. 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.
If your implementation resolves an RT5 with non-zero GW-IP to a RT5, it is
something else not defined in the prefix-advertisement draft. But do not expect
other implementations following the prefix-advertisement draft to resolve it to
anything different than a RT2.
[Yubao_3] We should not expect other implementations to arbitrarily resolve an
RT5 with non-zero ESI to any existing RT1 of that ESI , they
should be cautious about that. Other attributes have to be checked during the
recursive lookup.
That's why I don't agree that the ESI overlay index approach in the
discussed use case will have better backward compatiblilities.
<<<<<<<<<<<<<<<<<<<<<<<
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 ?
<<<<<<<<<<<<<<<<<<<<<<<<
[jorge] yes, I mean similar forwarding as in L2 EVPN. The primary/backup mode
is of course optional, the main use case is the aliasing mode.
[Yubao_3] Do you think a non-upgraded DGW1 (see Figure 7 of IP prefix
advertisement) will load-balance traffics to both NVE2 and NVE3 ? In
draft-ietf-bess-evpn-prefix-advertisement-11 both NVE2 and NVE3 will advertise
RT5 routes but only one of them advertises RT1 route. But in your
implementation, Both NVE2 and NVE3 should advertise RT1 routes but only one of
them will advertise RT5 route. They are just two different control-plane
procedures.
<<<<<<<<<<<<<<<<<<<<<<<<
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:
1. The ESI can be auto derived as indicated in the draft
2. 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.
1. 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
n_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
