[bess] Re: Fw: New Version Notification for draft-xie-bess-evpn-extension-evn6-00.txt

[Chongfeng Xie <[e-mail]>]

Hi Ali，

Thank you for your comments, sorry for my late reply  please see my feedback inline[Chongfeng]:

 
From: Ali Sajassi \(sajassi\)
Date: 2024-11-13 07:55
To: Chongfeng Xie; Zafar Ali (zali)
CC: bess; Ali Sajassi (sajassi)
Subject: [bess] Re: Fw: New Version Notification for draft-xie-bess-evpn-extension-evn6-00.txt
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! 
 [Chongfeng]: The EVN6 approach has been presented at 6man WG and Intarea WG respectively, at which we introduce the incentive of carrying Ethernet Virtual Network of native IPv6.

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. 
[Chongfeng]: Yes, EVN6 is an encapsulation mechanism. With the increasing deployment of IPv6, it is necessary to consider the relationship of IPv6 capability and encapsulation mechanisms. A variety of network virtualization over layer 3 methods have been developed and deployed. Each of these methods treat both IPv4 and IPv6 as functionally equivalent underlay network technologies, with both providing general unicast and multicast capabilities. IPv6 provides a number of capabilities not available in IPv4, and IPv6 has been widely deployed, then why not consider how they may be used to enhance the encapsulation of virtual network traffic with IPv6? This has been mentioned in draft-smith-enhance-vne-with-ipv6 in 2015.
 
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.
 [Chongfeng]: Thank you for your suggestion. 

 
So, let me go over a few things:
 
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.
              [Chongfeng]: Can you show me the draft of the proposal of encapsulating host MAC addresses in underlay IPv6 header? I don’t know why it wasn’t been entertained by the WG.  

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!
[Chongfeng]: The IETF does not specify that the 64-bits IID of an IPv6 address must be used to place uSIDs, the use of IID is open and different fields can be placed in IIDs depending on the their specific scenarios, for example, in 5G network, the network can assign different values to the IID of a terminal IPv6 address. 

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! 
[Chongfeng]: You mean draft-smith-vxlan-group-policy？ It was submitted in 2014, it seems that this is still individual draft. However, if it is indeed, flag bits and group-policy-id can also be carried in IID of IPv6 address.
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. 

[Chongfeng]: EVN6 uses IPv6 header to encapsulate L2 frame, instead of using the Ethernet header to encapsulate the host packet. 

Thank you again for your comments, we are looking forward to receiving more comments and suggestions.


Best regards

Chongfeng
 


 
From: Chongfeng Xie <[e-mail]>
Date: Tuesday, November 12, 2024 at 4:11 AM
To: Zafar Ali (zali) <[e-mail]>
Cc: bess <[e-mail]>
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: 【外部账号】
Date: 2024-07-26 12:25
To: Chongfeng Xie; Guoliang Han; Jibin Sun; Xing Li
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