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

[Chongfeng Xie <[e-mail]>]

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



[e-mail]
 
From: Paolo Volpato
Date: 2024-01-03 23:02
To: Chongfeng Xie
CC: list
Subject: RE: [v6ops] Fw: New Version Notification for draft-xie-v6ops-evn6-00.txt
Hi Chongfeng,
 
After reading your draft, I’d like to share a few comments.
 
In the introduction, you could highlight the relationship between your work and EPVN (RFC 7432). 
It is true that EVPN assumes an MPLS data plane, and in your case the data plane is pure IPv6. But, apart from the different data planes, my impression is that your draft could be seen as a different flavor to carry EVPN, as the control plane should be pretty much the same.

[Chongfeng]:  EVPN is a approach to set up the L2 VPN service over MPLS or IP. it leverages the MP-BGP protocol and defines a new SAFI with value 70， so it can be considered as a control mechanism. For the case of EVN6, EVPN can be used as a control plane to setup up Ethernet Virtual Network over IPv6 underlay, of coure, it needs some extension.
 
You could also add a mention to SRv6 as an alternative option to carry EVN. In particular with SRv6 BE (with no SRH) the difference with a pure IPv6 underlay should be minimal.
 [Chongfeng]:  Yes, I can mention it in the introduction of EVN based on SRv6. However, there some differences, as I reply to the comments of Bing Liu,  there are the following 2 differences, 
                                       1) Firstly, 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.
 
In figure 2 it could be useful to show the length of the fields (e.g. 48 bit for the MAC address, 32 for the VEI, etc.). This because I am not sure how long the field “Length of Pref6” should be. Is it 8 bits? I guess that the field “Pref6” should be 64 bits.
  [Chongfeng]:  At present, there is no mandatory requirement for the length of Pref6 in the draft. It can be 48 bits or 64 bits of other values, operators can flexibly choose the length of Pref6 according to their own needs, but it is better to have a uniform length across the entire network.  Regarding to the length of filed "Length of Pref6", I think 8 bits is ok, I will add this in the next version.
 
In section 3 it is clearly said that the mechanisms to propagate the MAC address across the EVN are out of scope (e.g. they may be based on BGP). I just wonder if in section 4.2 you can just add a few words on how H2 determines the MAC address of H1 to communicate the first time (e.g. through ARP/NDP). Reading section 4.2 it seems that host H2 already knows everything of H1.
 
   [Chongfeng]:   Sure, I will add a few words on how H2 determins the MAC address of H1 to communcate the first time.
 
In the normative reference, RFC8200 could be added.

[Chongfeng]: Sure, I will add RFC8200 in the next version.
 
Best regards
Paolo

Best regards
Chongfeng
 
From: v6ops <[e-mail]> On Behalf Of Chongfeng Xie
Sent: Thursday, November 9, 2023 6:32 AM
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