Re: [v6ops] WG Call For Adoption: draft-xie-v6ops-framework-md-ipv6only-underlay-05

[Chongfeng Xie <[e-mail]>]

Hi Eduard，
Thank you for your support and comments.  Please see my feedback inline tagged [Chongfeng],

 
From: Eduard Metz
Date: 2022-11-25 16:46
To: Ron Bonica
CC: [e-mail]
Subject: Re: [v6ops] WG Call For Adoption: draft-xie-v6ops-framework-md-ipv6only-underlay-05
Support adoption of this draft, some review comments below.

cheers,
  Eduard

General
I interpreted the document as a framework for transport / transit networks, based e.g on Figure 1. Section 7, case 2 however describes the integration with a transition mechanism at the UE/CPE. I would think these are decoupled and integration is an (optional) optimization, but not necessarily an integral component of the framework. Also some requirements are towards integration.

[Chongfeng]: Yes, this document discusses framework mainly for transit networks. This document tries to explain IPv6-only from the perspective of the overall network of the operator, rather than a specific scenario, so some requirements are about integration, integration with a transition mechanism at the UE/CPE will be useful for end-to-end data delivery.  However,  from the perspective of technologies, these can be decoupled and integration can be considered as an optimization.

What use-case is (or multiple) are being targeted with the framework? I still assume it is transport, in which case I would suggest a decoupling from CPE/UE based mechanisms and maybe have a separate chapter on optimization regarding / integration with common IPv4aaS  and IPv6 transition mechanisms.
[Chongfeng]: This is a good suggestion, we will consider it. 


Not all terminology is explained / abbreviations are expanded, for example:
- IPv6 underlay; what is meant with this?    
[Chongfeng]: The term is adopted is based on Brian's suggestion，it is a contrast to the upper-layer services , it means that the defined IPv6-only framework does not require the upper-layer services to be IPv6-only,


- ADPT; described but not expanded? Seems to be introduced in this document? 
[Chongfeng]: OK, I will try to do this in the next version.


Introduction
"This document does not introduce any new IPv6 transition mechanisms nor  IPv4aaS". 
Doesn't the multi-domain solution described in the document constitute a new solution?
[Chongfeng]: This draft is trying to define a network framework, which should be a overall IPv6-only framework from the perspective of network operators. It should not try  to design new technologies, but try to leverage texisting technologies, such as IPv6-only transition mechanism. In addition, capabilities that are needed but not yet available can be defined later.

Section 4
"Therefore, there is an urgent need for multi-domain IPv6-only solution ..". 
I assume the framework/solution described also applies to single domain?
[Chongfeng]: Yes, it also applies to single domain.

Section 5
Requirement 1: beneficial to wider IPv6 adoption
Reduction of IPv4 address consumption is not a requirement for this specific case I assume, ease the introduction of IPv6 is.
[Chongfeng]:  Based on our experience, IPv4 and IPv6 actually compete with each other  in Internet, less utilization of IPv4 will be beneficial to more IPv6 adoption. 

Requirement 3: optimized end-to-end
“From UE to egress, the packets of IPv4 service can be translated (or  encapsulated) into IPv6 packets within the UE or CPE, and there should be no IPv4-IPv6 conversion before they reach the egress of the  network.”
Should this state “no IPv6-IPv4” conversion? (instead of IPv4-IPv6?)
[Chongfeng]:  Yes, I will change it. :-)

Also, is the UE/CPE in scope? According to figure 1 it is not?
[Chongfeng]: The UE/CPE is not in the scope of the network, but we have to consider it when we discuss the network:-). 

Requirement 4: support of double translation and encapsulation
There appears to be a lot of “solution description” in this requirement.
Is the requirement to have conversion functions only at the edge and to have a single solution/concept for encapsulation or translation approaches. 
[Chongfeng]： Yes, the conversion function should be at the edge of the network, and it mainly leverage the existing encapsulation or translation approaches at the data plane. 

Section 6.2.3:
“Multi-domain IPv6-only networks need to support both translation and encapsulation technologies for IPv4 data delivery” 
At the ingess/egress also an IPv4 forwarding function is needed to forward to the right egress network node (via encap / mapping) or right interface towards an external network.
[Chongfeng]:  Yes, I agree with you, this point will be incorporated in the future version.

Section 7
I understood case 1 to be the scope of this framework, case 2 to me defines a different scope.
[Chongfeng]:  Case 2 can be considered as an extension of this framework.


Thanks again for your support and comments. If there is anything unclear in my reply, please feel free to put it forward.

Chongfeng








On Fri, Nov 18, 2022 at 10:54 PM Ron Bonica <rbonica=[e-mail]> wrote:
Folks,
 
This message initiates a WG call for adoption for draft-xie-v6ops-framework-md-ipv6only-underlay-05. To accommodate the American holiday, the call for adoption will end on December 9, 2022.
 
                                                       Ron
 

Juniper Business Use Only
_______________________________________________
v6ops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops