Hi Chongfeng, It seems like we have a situation of not seeing the forest for the trees, so let me iterate my comments at the mic here: what problem are you trying to solve here, since the draft doesn’t talk about the problem statement and jumps directly in describing a solution! Furthermore, the solution proposes a new overlay encapsulation which itself has many issues. So, has anyone complained about VxLAN encapsulation and extra 8-byte header, that you are trying to reinvent yet another encapsulation. I haven’t heard any such complaints.
I would highly recommend before talking about a solution document, you write a draft that talks about the issues with VxLAN encapsulation header and why the extra 8-byte is creating issues in operators’ networks. Then after presenting this draft and reaching WG consensus, then you can work and present your solution draft. So, let me go over a few things: 1. History: There is a saying that history doesn’t repeat itself but often rhymes. However, in this case the history has repeated itself. As I said on the mic, there was a proposal to encapsulate host MAC addresses in underlay IPv6 header about 10 years ago or so. It got presented at NOV3 and the WG did not entertain it. Out of many different encapsulation proposals, only a few got selected (i.e., GENEVE, VxLAN, NVGRE) and even out of all these three VxLAN became a prominent one. 2. As I mentioned at the mic, this encap breaks SRv6 encap because in many scenarios, SR Extended Header is not used and instead uSIDs are encapsulated in the lower bits of IPv6 header directly. Your proposal breaks that! 3. Besides VNI, there are other fields in the VxLAN header that are needed to be carried such as several flag bits and group-policy-id field. Your proposal breaks that! 4. These days, the most common service mode is IRB which means we even don’t need the Ethernet header when encapsulating the host packet! So, you are working to optimize something that the industry has move on from. Cheers, Ali From: Chongfeng Xie <chongfeng....@foxmail.com> Date: Tuesday, November 12, 2024 at 4:11 AM To: Zafar Ali (zali) <z...@cisco.com> Cc: bess <bess@ietf.org> Subject: [bess] Fw: New Version Notification for draft-xie-bess-evpn-extension-evn6-00.txt Hi Ali, Thank you for your comments to EVN6 during the BESS session. I'd like to clarify your concern, you mentioned that IPv6 address generated by mapping MAC address may hinder the use of SRv6, I don't think so, since SIDs is contained in the SRH header, a source node can originate an IPv6 packet with a SID in the destination address of the IPv6 header, following the proceduer of section 4 of RFC8754. In addition, I think EVN6 (defined in draft-xls-intarea-evn6) is a kind of efficent and flexible approach of carrying Ethernet Virtual Network over IPv6. Best regards Chongfeng ________________________________ From: 【外部账号】<mailto:internet-dra...@ietf.org> Date: 2024-07-26 12:25 To: Chongfeng Xie<mailto:xie...@chinatelecom.cn>; Guoliang Han<mailto:guoliang....@indirectionnet.com>; Jibin Sun<mailto:su...@chinatelecom.cn>; Xing Li<mailto:x...@cernet.edu.cn> Subject: New Version Notification for draft-xie-bess-evpn-extension-evn6-00.txt A new version of Internet-Draft draft-xie-bess-evpn-extension-evn6-00.txt has been successfully submitted by Chongfeng Xie and posted to the IETF repository. Name: draft-xie-bess-evpn-extension-evn6 Revision: 00 Title: EVPN Route Types and Procedures for EVN6 Date: 2024-07-25 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/archive/id/draft-xie-bess-evpn-extension-evn6-00.txt Status: https://datatracker.ietf.org/doc/draft-xie-bess-evpn-extension-evn6/ HTMLized: https://datatracker.ietf.org/doc/html/draft-xie-bess-evpn-extension-evn6 Abstract: EVN6 is a mechanism designed to carry Ethernet virtual networks, providing Ethernet connectivity to customer sites dispersed on public IPv6 networks. At the data layer, EVN6 directly places the Ethernet frames in the payload of IPv6 packet, and dynamically generates the IPv6 addresses of the IPv6 header using host MAC addresses and other information, then sends them into IPv6 network for transmission. This document proposes extensions to EVPN for EVN6, including two new route types and related procedures. The IETF Secretariat
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
