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

[Chongfeng Xie <[e-mail]>]

Hi Bing,

Thank you for your comments, please see my feedback inline [Chongfeng],

 
From: Liubing (Leo)
Date: 2023-12-14 16:22
To: Chongfeng Xie; [e-mail]
Subject: RE: [v6ops] Fw: New Version Notification for draft-xie-v6ops-evn6-00.txt
Hi Chongfeng,
 
I feel that the EVN6 is a smart design to take advantage of the IPv6-ready underlay, with a set of more efficient message encapsulation methods. I have some comments as below.
[Chongfeng] Thank you!

1. Compared with VxLAN, EVN6 does omit the UDP header and VxLAN header; however, it can achieve the same effect from an encapsulation point of view if it is implemented in the way of SRv6 Programming (RFC8986).
That is, the whole 128bit IPv6 address as SID, the corresponding forwarding behavior can be End.DT2U defined in RFC8986 4.11. For the sender, it can look up the IPv6 address of the PE of the opposite end according to the MAC address; and the receiver can match the source IPv6 address in the packet as the SID to the End.DT2U operation, which in turn will put the MAC address inside the IPv6 load to the MAC address. IPv6 load inside the MAC address read out, multiplexing the VxLAN forwarding behavior. Because SRv6 already has a large number of implementations, there is no need to change the current data plane compared to EVN6.

[Chongfeng]
1) AS We all know, SRv6 relies on SRH extension headers and its use is also required in the Limited domain. EVN6 does not rely on extension headers. It uses native IPv6 packets to carry Ethernet data frames, which is not limited in this regard, making it conducive to provide L2 services across operators.

2) The dynamically generated addresses of EVN6 are beneficial for reducing the risk of DDOS attacks. In tunnel approach with static and explicit end point addresses, a datagram sent from the host is directly encapsulated using a source and destination IPv6 addresses, so that the IPv6 address of the tunnel endpoint has a 1:N relationship with multiple hosts. Since the IPv6 address is static and explicit, it can easily become a target of DDOS attacks. In EVN6, due to the use of mapping MAC addresses to IID, there is a 1:1 relationship between subnet hosts and generated IPv6 addresses, and IPv6 addresses are also dynamically generated, this avoids the risk of attacks on static and explicit addresses.
 




2. In current design, the MAC address was put into the IPv6 IID, is it necessary? Since the MAC address could also be easily fetched in the IPv6 payload, which is just the ethernet frame. If only ENI was embed in the IPv6 address, then we can maximize the reuse of VxLAN forwarding behavior (i.e., look up the table according to VNI/ENI), and the changes to the data plane are smaller compared to current approach.

[Chongfeng] With EVN6, including the Ethernet source and destination MAC addresses, or their variant, in the outer IPv6 tunnel packet IID fields would generally satisfy the requirements of variable fields for ECMP or LAG in the underlay network. Of course, we can discuss the what information should be embedded in IID further later on.


3. A rough thought: is it possible to remove the BGP control plane to make the whole solution as simplified as possible? Say, we could consider leveraging embedding more information in the IPv6 address and combining it with a small amount of auto-configuration on the SDN management plane. 
[Chongfeng] I agree with your suggestion，We also hope that the control plane can be simpler，auto-configuration on the SDN management plane can be an option of control plane.
 
B.R.
Bing


Thank you again for your comments, and I am looking forward to receiving more comments and suggestions from you.

Best regards

Chongfeng 
 
From: v6ops <[e-mail]> On Behalf Of Chongfeng Xie
Sent: Thursday, November 9, 2023 1:32 PM
To: list <[e-mail]>
Subject: [v6ops] Fw: New Version Notification for draft-xie-v6ops-evn6-00.txt
 
 
Folks,
 
We have just submitted a new draft of EVN6, which is about the mapping of ethernet virtual network to IPv6 Underlay for transmission. Myabe you have noticed that it has been discussed in 6man WG. We are looking forward to receiving more comments and suggestions from you.
 
Best regards
Chongfeng
 
From: 【外部账号】
Date: 2023-11-09 13:19
To: Chongfeng Xie; Congxiao Bao; Mark Smith; Xing Li
Subject: New Version Notification for draft-xie-v6ops-evn6-00.txt
A new version of Internet-Draft draft-xie-v6ops-evn6-00.txt has been
successfully submitted by Chongfeng Xie and posted to the
IETF repository.
 
Name:     draft-xie-v6ops-evn6
Revision: 00
Title:    EVN6: A Framework of Mapping of Ethernet Virtual Network to IPv6 Underlay
Date:     2023-11-09
Group:    Individual Submission
Pages:    14
URL:      https://www.ietf.org/archive/id/draft-xie-v6ops-evn6-00.txt
Status:   https://datatracker.ietf.org/doc/draft-xie-v6ops-evn6/
HTMLized: https://datatracker.ietf.org/doc/html/draft-xie-v6ops-evn6
 
 
Abstract:
 
   This document describes the mechanism of mapping of Ethernet Virtual
   Network to IPv6 Underlay for transmission.  Unlike the existing
   methods, this approach places the Ethernet frames to be transmitted
   directly in the payload of IPv6 packets, i.e., L2 over IPv6, and uses
   stateless mapping to generate IPv6 source and destination addresses
   from the host's MAC addresses, Ethernet Virtual Network identifier
   and site prefixes.  The IPv6 packets generated in this way carry
   Ethernet frames and are routed to the destination site across public
   IPv6 network.
 
 
 
The IETF Secretariat