Hi Wei, Thanks for the reply.
About the ESI, the issue is not the ESI format, but I’m questioning why using an ESI and not other fields that do not clash with the procedures for ESIs in existing specs. About the VXLAN header, I didn’t refer to the flag fields, but the Group policy ID field and the LSI field (in your draft). Thx Jorge From: Wei Wang <weiwan...@foxmail.com> Date: Thursday, March 6, 2025 at 4:53 PM To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>, Aijun Wang <wangai...@tsinghua.org.cn>, 'Luc André Burdet' <laburdet.i...@gmail.com>, bess@ietf.org <bess@ietf.org> Cc: 'Haibo Wang' <rainsword.w...@huawei.com> Subject: Re: [bess] Re: 答复: 答复: New Version Notification for draft-wang-bess-l3-accessible-evpn-08.txt CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi Jorge, Please see my replies inline with [WW]. Best Regards, Wei 原始邮件 ________________________________ 发件人：Jorge Rabadan (Nokia) <jorge.rabadan=40nokia....@dmarc.ietf.org> 发件时间：2025年3月6日 02:04 收件人：Aijun Wang <wangai...@tsinghua.org.cn>, 'Luc André Burdet' <laburdet.i...@gmail.com>, bess@ietf.org <bess@ietf.org> 抄送：'Haibo Wang' <rainsword.w...@huawei.com>, 'Wei Wang' <weiwan...@foxmail.com> 主题：[bess] Re: 答复: 答复: New Version Notification for draft-wang-bess-l3-accessible-evpn-08.txt Hi Aijun, I share the questions and doubts that Luc and Jeffrey already expressed. The text in the new version does not help, at least not me 😊 It talks about IP Prefix routes, but you seem to talk about L2 end to end? Maybe the document would benefit of a packet walkthrough (data plane and control plane). But my main concerns are: 1. You are using a non-zero ESI in the control plane to signal these LSIs. ESIs for type-2s or type-5s require the resolution based on type-1s. Not clear why you are overloading the ESI for this. [WW]: In control plane, we also give another solution as shown in Figure 5 of https://datatracker.ietf.org/doc/html/draft-wang-bess-l3-accessible-evpn-08, to define a new ESI type to avoid overloading. 2. You are using a field in the VXLAN header that is already used in https://datatracker.ietf.org/doc/html/draft-lrss-bess-evpn-group-policy-01 - till now, either in VXLAN or VXLAN GPE, we never had a field that means a different thing depending on a different flag. That would increase data path complexity.. [WW]: In Figure 2 of draft-lrss-bess-evpn-group-policy-01, the editor has defined the leftmost bit (G Bit), and the S bit we have defined is immediately to the right of the G bit, so the two bits do not overlap. Thanks, Jorge From: Aijun Wang <wangai...@tsinghua.org.cn> Date: Tuesday, March 4, 2025 at 10:55 PM To: 'Luc André Burdet' <laburdet.i...@gmail.com>, bess@ietf.org <bess@ietf.org> Cc: 'Haibo Wang' <rainsword.w...@huawei.com>, 'Wei Wang' <weiwan...@foxmail.com> Subject: [bess] 答复: 答复: New Version Notification for draft-wang-bess-l3-accessible-evpn-08.txt CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi, Luc: Let’s take the Figure 2 in https://datatracker.ietf.org/doc/html/draft-wang-bess-l3-accessible-evpn-08#name-introduction as one example: The branches of customer C(C-A or C-B) that located under respective MAN want to communicate with each other, via the layer 2 domain. The communication between different branches should be isolated. “MAN(Metro Area Network)” is the layer 3 network of the service provider. “Backbone” is backbone network of the service provider The customer C buy the EVPN layer 2 service(Let’s call it EVPN C) at the “Backbone” of the service provider. It wants its branches connect to its EVPN layer 2 service(EVPN C), then it should use one VxLAN tunnel service to connect the sites to their corresponding PE devices. Let’s call the tunnel identifier as LSI(Logical Service Identifier). The LSI can be used to differentiate the traffic from different branches(C-A, or C-B). Within the backbone of the service provider, there is VNI(for EVPN C) that allocated to customer C, but there is no place to transmit the information about their different branches(C-A, or C-B). Then, we need to expand the encoding of VxLAN encapsulation, to include such information, to achieve the similar effect of QinQ for VLAN, and also the extension of the related control plane. For the extension of VxLAN encapsulation, it is necessary to ask the approve from the NVO3 WG, but I think the requirements should be first confirmed within BESS WG. We will add the reference to draft-ietf-nvo3-vxlan-gpe in next version. Wish the above explanation can give you some helps. Best Regards Aijun Wang China Telecom 发件人: Luc André Burdet [mailto:laburdet.i...@gmail.com] 发送时间: 2025年3月4日 23:37 收件人: Aijun Wang <wangai...@tsinghua.org.cn>; bess@ietf.org 抄送: 'Haibo Wang' <rainsword.w...@huawei.com>; 'Wei Wang' <weiwan...@foxmail.com> 主题: Re: [bess] 答复: New Version Notification for draft-wang-bess-l3-accessible-evpn-08.txt Hi Aijun, I have difficulty with the problem you are trying to solve, could you expand on that section a little ? Other than that, shouldn’t this document go through NVO3 first, to define the dataplane aspects of extending VxLAN-GPE? Once dataplane is defined, it can (separately) move through BESS for signaling aspects. The document doesn’t refer to draft-ietf-nvo3-vxlan-gpe - this should be a normative reference if you are extending vxlan-gpe. Regards, Luc André Luc André Burdet | Cisco | laburdet.i...@gmail.com<mailto:laburdet.i...@gmail.com> | Tel: +1 613 254 4814 From: Aijun Wang <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>> Date: Friday, February 28, 2025 at 05:02 To: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>> Cc: 'Haibo Wang' <rainsword.w...@huawei.com<mailto:rainsword.w...@huawei.com>>, 'Wei Wang' <weiwan...@foxmail.com<mailto:weiwan...@foxmail.com>> Subject: [bess] 答复: New Version Notification for draft-wang-bess-l3-accessible-evpn-08.txt Hi, All experts: After several rounds offline discussions about the previous version of this document, with our Chair, Jeffery Zhang, we updated again the related descriptions, to reflect the converged conclusions. We would like to seek more broader reviews of this document and get some constructive comments to forward it. We have also applied one time slot on the coming IETF 122 meeting to make one presentation. If the time slot is granted, let's discuss it further on the meeting, or after the meeting. Please take some time to review it https://datatracker.ietf.org/doc/html/draft-wang-bess-l3-accessible-evpn If you are familiar with the layer 2 access interface(VLAN based, VLAN bundle, VLAN awared) of EVPN(RFC 7432), then it is easy to understand the aim and solution of this draft. Thanks in advance for your efforts! And thank also Jeffrey Zhang for the discussions to improve the document. Best Regards Aijun Wang China Telecom -----邮件原件----- 发件人: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> [mailto:internet-dra...@ietf.org] 发送时间: 2025年2月28日 17:04 收件人: Aijun Wang <wang...@chinatelecom.cn<mailto:wang...@chinatelecom.cn>>; Haibo Wang <rainsword.w...@huawei.com<mailto:rainsword.w...@huawei.com>>; Wei Wang <weiwan...@foxmail.com<mailto:weiwan...@foxmail.com>> 主题: New Version Notification for draft-wang-bess-l3-accessible-evpn-08.txt A new version of Internet-Draft draft-wang-bess-l3-accessible-evpn-08.txt has been successfully submitted by Aijun Wang and posted to the IETF repository. Name: draft-wang-bess-l3-accessible-evpn Revision: 08 Title: Layer-3 Accessible EVPN Services Date: 2025-02-28 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/archive/id/draft-wang-bess-l3-accessible-evpn-08.txt Status: https://datatracker.ietf.org/doc/draft-wang-bess-l3-accessible-evpn/ HTMLized: https://datatracker.ietf.org/doc/html/draft-wang-bess-l3-accessible-evpn Diff: https://author-tools.ietf.org/iddiff?url2=draft-wang-bess-l3-accessible-evpn-08 Abstract: This draft describes layer-3 accessible EVPN service interfaces, which aim is to connect the layer 2 customers to one EVPN backbone, via the layer 3 network, and keep the traffic isolation among different layer 2 customers. It proposes to extend the VxLAN packet format to transfer the customer's Virtual Network Identifier(VNI) information, and also the related control plane extension. The IETF Secretariat _______________________________________________ BESS mailing list -- bess@ietf.org<mailto:bess@ietf.org> To unsubscribe send an email to bess-le...@ietf.org<mailto:bess-le...@ietf.org>
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
