Hi Jorge,
Please see in-line with [yubao].
Thanks
Yubao
原始邮件
发件人：Rabadan,Jorge(Nokia-US/MountainView)
收件人：王玉保10045807;
抄送人：bess@ietf.org;
日 期 ：2021年11月13日 03:00
主 题 ：Re: Re:Comments on draft-ietf-bess-evpn-prefix-advertisement and
draft-wang-bess-evpn-distributed-bump-in-the-wire
Hi Yubao,
Thanks for explaining, although I’m afraid we disagree on both things 😊 but
that’s ok. Others can chime in as well.
If you receive an RT1 with ESI-1 and a route-target identifying BD1, the RT5
with ESI-1 can be resolved to the RT1, hence the traffic will use the IRB
connected to BD1 (and the MAC of the IRB as MAC SA). You have all the
information, so it is up to the implementation how to use it or if it can use
it.
[Yubao] I agree with you on that such implementation can be used in slide 5.
but I haven't considered it is as a good choice because of the following
considerations:
the first reason is that: this requires the RT-1 per EVI routes of
BD-10 and BD-20 to be imported into the context of the IP-VRF,
But we would like to treat BD-10 and BD-20 as normal BDs of [RFC9135],
I don't think a normal BD of [RFC9135] would import all or parts of its
RT-1 per EVI routes into the context of the IP-VRF of its IRB.
because that behavior will burden the IP-VRF if no Bump-in-the-wire
RT-5 routes will be received in the future.
the second reason is that: If the use case of slide 5 is slightly
changed, that implementation will not work.
Now we can imagine that VA1 and VA2 are provisioned on the same pair of
TS nodes, and these TS nodes are attached to NVE2 and NVE3 using ESI23 as
illustrated in slide 6.
In this use case, that implementation will not work. But the RT-5
routes with a route-target identifying a BD (described in slide 5) will work
well.
Note that slide 5 is still a centerlized Bump-in-the-wire use case, but
BD-10 and BD-20 are assumed to be all configured on all the DGWs.
The supplementary overlay index is mainly used in slide 6, which is a
distributed Bump-in-the-wire use case and not all of the NVEs should be
configured with BD-10 or BD-20.
That's why the left side of slide 6 is a NVE node, but the left side of
slide 5 is a DGW node.
The slide 5 is about the route processing improvement in centerlized
multiple Bump-in-the-wire insances, whether ESI23a and ESI23b is the same ESI23
or not.
The slide 6 is about the route processing improvement in distributed
multiple Bump-in-the-wire insances, especially when ESI23a and ESI23b is the
same ESI23.
I also disagree with the reasons you give to not use a virtual ES. The virtual
ES spec is implemented and deployed for a long time now.
[Yubao] I agree with you on that the vES draft is there for a long time, but
not long enough than [draft-ietf-bess-evpn-inter-subnet-forwarding].
What we have concerned on is that, hove a existing normal BD of
[draft-ietf-bess-evpn-inter-subnet-forwarding] can be smoothly evolved into a
distributed Bump-in-the-wire or a IP-aliasing-enhanced symmetric IRB.
Even in the future, there would be some normal BDs of
[draft-ietf-bess-evpn-inter-subnet-forwarding] which don't use a vES at the
network operator's choice.
we want to help these deployments to be soothly evolved into a
distributed Bump-in-the-wire or a IP-aliasing-enhanced symmetric IRB.
I think that we can't assume that the original form of BDs of
[draft-ietf-bess-evpn-inter-subnet-forwarding] will not be deployed after the
vES is introduced.
Thanks.
Jorge
From: wang.yub...@zte.com.cn <wang.yub...@zte.com.cn>
Date: Friday, November 12, 2021 at 8:04 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com>
Cc: bess@ietf.org <bess@ietf.org>
Subject: Re:Comments on draft-ietf-bess-evpn-prefix-advertisement and
draft-wang-bess-evpn-distributed-bump-in-the-wire
Hi Jorge,
Please see in-line with [yubao].
Thanks
Yubao
原始邮件
发件人：Rabadan,Jorge(Nokia-US/MountainView)
收件人：王玉保10045807;
抄送人：bess@ietf.org;
日 期 ：2021年11月12日 04:06
主 题 ：Re: Re:Comments on draft-ietf-bess-evpn-prefix-advertisement and
draft-wang-bess-evpn-distributed-bump-in-the-wire
Hi Yubao,
I realized I did not respond to this (my apologies), and you reflected the same
questions in your slides about
draft-wang-bess-evpn-distributed-bump-in-the-wire during the BESS session.
I think it is okay if you want to describe a “distributed” bump-in-the-wire
scenario, but I don’t understand why you need any new extension.
[Yubao] Thanks for your response, I will explain why we need the Supplementary
Overlay Index (or the ACI-specific Ethernet A-D mode) in the following.
· In your slide 5, the RT5s can be resolved to the proper RT1, based on
the ESI overlay index. The ESI is unique (cannot be configured in multiple
ESes) and the RT1 for the ESI carries the route-target of the BD, hence you
have all the information to resolve the RT5. What are you missing?
[Yubao] In my slide 5, I mainly wan't to say that, when there are two
Bump-in-the-wire instances in the same IP-VRF,
Those RT-5 routes don't known which source MAC should their
corresponding data packets be encapsulated with,
even if their ESI are different.
The notes2 in slide 5 is mainly talking about the use case of slide 6.
But Those RT-5 routes don't known inside which BD should their ESI be
resolved either, even if their ESI are different.
So I put it together with notes1 in the slide 5, but I have no time to
explain the reasons in the prensetation.
So, as I explained above, the information is not enough even if their
ESI are different, that's why we let the RT5 routes carry the export
Router-Targets of the BD/SBD.
Please note that in slide 5, there are no SBD. Those RT-1 per EVI
routes will be imported into BD-10 or BD-20 respectively.
[Yubao] Some paragraphs from RFC9136 section 4.3 Bump-in-the-wire may help us
to understand this:
* The IP packet destined to IPx is encapsulated with:
- Inner source MAC = IRB1 MAC.
- Inner destination MAC = M2 (this MAC will be obtained from
the EVPN Router's MAC Extended Community received along
with the RT-5 for SN1). Note that the EVPN Router's MAC
Extended Community is used in this case to carry the TS's
MAC address, as opposed to the MAC address of the NVE/PE.
- Tunnel information for the NVO tunnel is provided by the
Ethernet A-D route per EVI for ESI23 (VNI and VTEP IP for
the VXLAN case).
· In your slide 6 you have a use-case with two ACs in the same ESI23,
and you seem to use the ethernet tag ID to encode the ACI. Can you not use a
different virtual Ethernet Segment per BD instead, and use RT1s for each ESI?
In that way you don’t need to use the ethernet-tag-id, which is used for
vlan-aware-bundle in general.
[Yubao] We can't use different vES per BD instead, because we can't assume that
BD-10 and BD-20 is always a new BD, which is created after
draft-wang-bess-evpn-distributed-bump-in-the-wire.
These BDs may be already there for a long time before they will be
given a virtual-appliance (VA1 or VA2) who will make them become to BDs of
bump-in-the-wire instances in the future.
So, before the evolution, they have nothing different from normal BDs,
I don't think there are any motivations for them to be deployed in the form of
vES other than a normal ESI.
The vESes have other disadvantages, for example, the RT-4 routes will
be increased. the service carving will be complicated, the management will be
complicated, etc.
Thanks.
Jorge
From: wang.yub...@zte.com.cn <wang.yub...@zte.com.cn>
Date: Friday, July 30, 2021 at 5:18 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com>
Cc: bess@ietf.org <bess@ietf.org>
Subject: Re:Comments on draft-ietf-bess-evpn-prefix-advertisement
Hi Jorge,
Thank you for your email.
I know that EVPN application will pick up one.
But my question is how can you make sure that the exact one in your expectation
will be picked out?
Other scenarios just need to pick up one for all RT-2 routes that refers to
that ESI,
but the Bump-in-the-wire use case need to pick the exact one per each RT-5
route.
That's the difference.
In the example I have described , if the IP-VRF picks up the RT1 route
R1_BD2<RD=BD-20, ESI23, 0>,
The data packets to SN1 will be sent over another BD (BD-20), and BD-20 can't
reach SN1.
That's the problem.
Note that BD-20 and BD-10 are on the same ES but on different VLAN of that ES.
This problem requires the EVPN Application to use both R5's RD and ESI overlay
index to ensure that only R1_BD1 will be picked out.
As far as I know, such approach has never been used in symmetric IRB, for
ARP/ND tables and for interface-ful models up to now.
Whe should note that EVPN not only have port-based service interface, but also
have VLAN-based service interface.
When the EVPN Instances on ESI23 uses VLAN-based service interface, and these
BDs are integrated with the same Routing Instance (IP-VRF),
How can the IP-VRF pick out the exact one (behind which the prefix SN1 of that
RT-5 lies there) from many RT-1 routes (one per BD) ?
Do you think that each one (if it is picked out) of them will reach SN1 ?
If anything about the problem statement is not clear, let me know where is it
please.
This is the example (based on Figure 7 of [IP Prefix Advertisement] ) I have
described for problem statement, I repeat it here:
"To be clear, If the DGW1 receives a RT-5 route R5 (IPL=24, IP=SN1, ESI=ESI23,
from NVE2) 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 ?"
Thanks,
Yubao
原始邮件
发件人：Rabadan,Jorge(Nokia-US/MountainView)
收件人：王玉保10045807;
抄送人：bess@ietf.org;
日 期 ：2021年07月30日 21:47
主 题 ：Re: Comments on draft-ietf-bess-evpn-prefix-advertisement
Hi Yubao,
For GW-IP overlay indexes, until the PE does not receive at least one RT2 for
the GW-IP, you can’t resolve the RT5. If you receive multiple for the same IP
with the same key, it is bgp best path selection. If you receive multiple for
the same IP, different key, the EVPN application picks up one. Implementations
have been doing that selection for symmetric IRB, for ARP/ND tables and for
interface-ful models for years, why is it a problem.
Similar for ESI as overlay index.
Thanks.
Jorge
From: wang.yub...@zte.com.cn <wang.yub...@zte.com.cn>
Date: Friday, July 30, 2021 at 5:01 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com>
Cc: bess@ietf.org <bess@ietf.org>
Subject: Comments on draft-ietf-bess-evpn-prefix-advertisement
Hi Jorge,
In our discussion in another thread, we discussed two types ot the use cases of
draft-ietf-bess-evpn-prefix-advertisement,
They are the GW-IP as overlay index use cases (just let me call them
GW-IP-Style use-cases for short) and the Bump-in-the-wire use case.
I think it is better to discuss it more clearly in a new thread.
1) For the GW-IP-Style use cases, thank you for telling me that the following
text may be contradictory (But I don't think it is like that, I will explain it
later) with my approach :
". 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."
It seems that we have to find out that RT-2 before the recursive
resolution.
I just don't know that how can we know there is such a RT-2 before the
recursive resolution ?
We should note that the keys of that RT-2 is <RD, IP, MAC>, but the GW-IP
is just an IP.
So how can we find out that RT-2 just using an IP before the recursive
resolution?
2) For the ESI as overlay index use cases, there is similar text as the
following:
". 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."
Given that the keys of RT-1 are <RD, ESI, Ethernet Tag ID>,
So how can we find out that RT-2 before recursive resolution just using <ESI,
Ethernet Tag ID> ?
3) For Bump-in-the-wire use case, we would find many RT-1 routes for that ESI
even after the recursive rosolution.
Just take the Figure 7 of [IP Prefix Advertisement] for example,
How can DGW1 in that Figure find out the exact RT-1 of <ESI23, BD-10> ?
We should note that the RDs of BDs are different from the RD of that IP-VRF.
To be clear, If the DGW1 receives a RT-5 route R5 (IPL=24, IP=SN1,
ESI=ESI23, from NVE2) 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 ?
4) For Bump-in-the-wire use case, Both of NVE2 and NVE3 will advertise a RT-5
route to DGW1,
Will the common ESI23 of these two RT-5 routes be resolved to the same
RT-1 route? and how?
Note that even the RD of BD-10 will be different on NVE2 and NVE3.
When they are the same RD,I think there wil be method that the RT-5 from
NVE3 can be resolved to the same RT-1 from NVE2.
5) For Bump-in-the-wire use case, If NVE3 advertise another RT-5 route R5b for
another BD (say BD-20) but for the another prefix (e.g. SN2) of the same IP-VRF.
If the RD of that R5b is the same as R5 (see question 3), will the ESI23
of R5b be resolved to the same RT-1 as what R5 will be resolved to?
It seems that they will, according current procedures. But is this result
in expectation ?
Note that ESI23 is provisioned on attachment ports, but both BD-10 and
BD-20 can have an separate AC on the same port.
Regards,
Yubao_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
