Re: [bess] Comments on  draft-ietf-bess-evpn-prefix-advertisement and draft-wang-bess-evpn-distributed-bump-in-the-wire

2021-11-12 Thread wang.yubao2 
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 
 Date: Friday, November 12, 2021 at 8:04 AM
 To: Rabadan, Jorge (Nokia - US/Mountain View) 
 Cc: 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 t

Re: [bess] Comments on  draft-ietf-bess-evpn-prefix-advertisement and draft-wang-bess-evpn-distributed-bump-in-the-wire

2021-11-12 Thread Rabadan, Jorge (Nokia - US/Mountain View) 
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.
  *   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.
Thanks.
Jorge


From: wang.yub...@zte.com.cn 
Date: Friday, November 12, 2021 at 8:04 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
Cc: 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 
Date: Friday, July 30, 2021 at 5:18 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
Cc: bess@ietf.org 
Subject: Re:Comments on  draft-ietf-bess-evpn-prefix-advertisement



Hi Jorge,



Thank you for your e

Re: [bess] Comments on  draft-ietf-bess-evpn-prefix-advertisement and draft-wang-bess-evpn-distributed-bump-in-the-wire

2021-11-11 Thread wang.yubao2 
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 
 Date: Friday, July 30, 2021 at 5:18 PM
 To: Rabadan, Jorge (Nokia - US/Mountain View) 
 Cc: 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,


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

Re: [bess] Comments on  draft-ietf-bess-evpn-prefix-advertisement and draft-wang-bess-evpn-distributed-bump-in-the-wire

2021-11-11 Thread Rabadan, Jorge (Nokia - US/Mountain View) 
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.


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



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

Thanks.
Jorge


From: wang.yub...@zte.com.cn 
Date: Friday, July 30, 2021 at 5:18 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
Cc: 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,

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 and R1_BD2.

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 
Date: Friday, July 30, 2021 at 5:01 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
Cc: 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