Re: [v6ops] New Version Notification for draft-xie-v6ops-framework-md-ipv6only-underlay-03.txt

[Chongfeng Xie <[e-mail]>]

Hi, Eduard,
Thank you for your new comments, please see my feedback inline below,

From: Vasilenko Eduard
Date: 2022-09-06 00:26
To: [e-mail]; list; V6Ops-Chairs
Subject: RE: RE: New Version Notification for draft-xie-v6ops-framework-md-ipv6only-underlay-03.txt
Hi Chongfeng,
 
As soon as the source Carrier would translate IPv4 into IPv6
It would become pure/normal IPv6.
Destination or transit Carriers should know nothing about original AS translation.
No special efforts are needed to improve the path for such traffic.
[Xie]: I basically agree with your description, except for one point, the egress PE at the destination AS can know that this IPv6 packet received is converted based on the mapping rule, it can see the IPv6 mapping prefix of the ingress PE in the source address of its packet. In this way, the core router only supports IPv6-only forwarding, and the network will be concise because it avoids  various types of IPv4-IPv6 transition devices along the path. 

Hence, I am still missing the draft purpose/problem.
[Xie]:  Based on many years of IPv6 practice, we feel that such a framework is very valuable for the design and operation of the network. This document puts forward the feature description, requirements, mapping rule-based working principle, etc. maybe other contentsneed to be included in it.  However, this draft does not focus on specific protocol design, and this kind of work can be carried out in other related working groups in the future.
 
Eduard

Best regards
Chongfeng
From: [e-mail] [mailto:[e-mail]] 
Sent: Monday, September 5, 2022 2:09 PM
To: list <[e-mail]>; V6Ops-Chairs <[e-mail]>
Cc: Vasilenko Eduard <[e-mail]>
Subject: Re: RE: New Version Notification for draft-xie-v6ops-framework-md-ipv6only-underlay-03.txt
 
 
Hi, Eduard,
Thank you very much for your review and comments,  please see my feedback inline tagged as [Xie] below,
 
From: Vasilenko Eduard
Date: 2022-09-05 15:38
To: [e-mail]; Liushucheng (Will LIU, Strategy & Industry Development); chongfeng.xie
CC: xing
Subject: RE: RE: New Version Notification for draft-xie-v6ops-framework-md-ipv6only-underlay-03.txt
Hi Chongfeng,
 
1.       Give me something to read about ADPT. Looks like there is a new translation technology. MAP-E/T calls the telco side “Border relay”.
               [Xie]: ADPT is function entity in PE if this framework,  currently its scope is different from that of "Borderaly relay" in MAP-E/MAP-T.  Nevertheles, I think the name can be adjusted later if necessary. 
 
2.       It is impossible to imagine that Public Server has been appointed a private IPv4 address and hidden behind some CGNAT. No point, CGNAT should reserve the pubic IP address for such a server anyway.
Hence, I do not see a use case when double translation is happening (for the client that is behind CGNAT and for the server that is behind CGNAT too).
IMHO: servers on the internet always have a public IP address. Hence, no translation happens on the destination Carrier.
               [Xie]:   I agree with your statement that generally servers alwasy have public IP address on the Internet.  This framework in my draft uses IPv4-IPv6 mapping rule for the public IPv4 and IPv6 address translation in PE, double translation can work for this case, it doesn't handle private IPv4 and public IPv4 address translation of CGNAT.    
 
3.       All the time you are talking about something cross-Carrier. Only service stitching (VPN and plain Internet) exists between Carriers.
I still believe that RFC 8950 is all that we need to successfully stitch VPN services. Plain IPv6 is easy to stitch by plain BGP.
                  [Xie]: The framework in the draft talks about IPv4 service delivery over IPv6-only multi-domain networks, including the case of within single operator and that of cross-opertaors. From the stanpoint of a operator, we need a consistent dataplane solution that has less IPv4-IPv6 version along the data path.  RFC8950 defines the advertising of IPv4 NLRI or VPN-IPv4 NLRI with a next-hop address that belongs to the IPv6 protocol.  For a given BGP annoucement, the value of IPv6 next-hop changes AS by AS.   If we use the next-hop address in RFC8950 as the tunnel endpoint for IPv4 service delivery, the outer destination address of IPv6 packet may change along the path, in some links, IPv6 packets may be restored to IPv4 packets an then back to IPv6 packets, which make the network complex.  I don't know my explaintion is clear enough.
 
4.       I am still misled by “underlay” terminology. “Underlay” is possible only when we have the inner and outer header, then underlay is a reference to the outer.
General peering between Carriers is assumed to have only one header. Hence, overlay/underlay terminology is not relevant.
                  [Xie] :  Adopting the word of "underlay" is the suggestion of Brian carpenter. What you said is the narrow definition of underlay given from the perspective of protocol. Underlay also has its broad definition. For IPv4 as a service, underlay refers to an end-to-end IPv6 network used to carry IPv6-native and residual IPv4 services. 
 
IMHO: The only thing that Carriers could do to improve IPv6 adoption is to implement 464XLAT (or any other transition technology).
Everything else would happen automatically on the path to implement 464XLAT.
     [Xie]: Yes, 464XLAT has been deployed by several operators worldwide, and its client has been supported by mainstream mobile OS.  I am also carrying out the 464XLAT field trial in mobile network now.  For a larges-scale network,  464XLAT provides IPv6-only acess in mobile core network,  a multi-domain framework in this draft can be used for the IPv4 service delivery across multi-domain IPv6 transit core, I think they can concatenate with each other to realize  end-to-end IPv4 service delivery.  
 
Eduard
 
 
Highly thanks again!
 
Best regards
Chongfeng
From: [e-mail] [mailto:[e-mail]] 
Sent: Saturday, September 3, 2022 6:32 AM
To: Vasilenko Eduard <[e-mail]>; Liushucheng (Will LIU, Strategy & Industry Development) <[e-mail]>; chongfeng.xie <[e-mail]>
Cc: xing <[e-mail]>
Subject: Re: RE: New Version Notification for draft-xie-v6ops-framework-md-ipv6only-underlay-03.txt
 
Hi, Eduard,
Attached is my feedback for your comments. Thank you again for your review and raising so many comments, which are very enlightening and constructive.
In addition, I hope some of your comments can be put to v6ops maillist, if it is ok for you.
 
Best regards
Chongfeng
 
 
From: Vasilenko Eduard <[e-mail]> 
Sent: Thursday, September 1, 2022 4:34 PM
To: [e-mail]
Cc: Liushucheng (Will LIU, Strategy & Industry Development) <[e-mail]>; Xipengxiao <[e-mail]>
Subject: RE: New Version Notification for draft-xie-v6ops-framework-md-ipv6only-underlay-03.txt
 
Additional attempt to push the message.
Ed/
From: Vasilenko Eduard 
Sent: Wednesday, August 31, 2022 5:00 PM
To: '[e-mail]' <[e-mail]>
Cc: Liushucheng (Will LIU, Strategy & Industry Development) <[e-mail]>; Xipengxiao <[e-mail]>
Subject: RE: New Version Notification for draft-xie-v6ops-framework-md-ipv6only-underlay-03.txt
 
Hi Chongfeng,
Slides:
You mention something about PLAT, but core slides (5-8) are only about VPN interconnect between different Carriers.
I do not understand how is it different from any VPN that exists in BGP from the last millennium.
Well, in reality, VPN for this case (IPv4 over IPv6) has been defined only recently (RFC 8950).
It looks like you do not request anything (on slides) above proposed in RFC 8950.
 
https://www.ietf.org/archive/id/draft-xie-v6ops-framework-md-ipv6only-underlay-03.txt
“Framework” is some sort of “solution” that should be discussed in 6man.
 
Almost never “underlay” of different carriers are connected because of security reasons (option C is accepted only between affiliated companies). ASBR has exactly this goal: terminate “underlay” (MPLS or SR-MPLS or SRv6) and hand over plain IP traffic to peer (plain traffic has only 1 header, overlay/underlay terminology is not applicable).
IPv6 would change nothing in this Telco business. “Underlay” terminology is just not relevant between ASBRs of different carriers.
Underlay (tunnel) would stop at the ASBR and would be started again on the peer ASBR.
Moreover, your terminology later in the document (“user”, “server”) is related to “overlay”, not “underlay”.
In fact, looks like your document is about “overlays stitching”.
 
I do not like this definition of “IPv6-only”: “IPv6-centric network in which data packets are forwarded upon IPv6 capability”.Because IPv4 may be forwarded in parallel – this definition permits it.Quotation: “IPv6-only networks should support the forwarding of IPv4 service data”.It is strange in general when you are asking that “IPv6-only” network should support all combinations of IPv4 users or IPv4 servers.
 
Double PLAT translation on the traffic path:
1.       Does not exists in the real world because the destination (server) is always not translated in its domain (nobody is hiding the server behind CGNAT)
2.       It is not possible to optimize because private IPv4 address space behind PLATs is not possible to synchronize between carriers.
Hence, it is not possible to develop translation technology that would work cross-Carrier.
 
Conclusion:
currently, we have many ways to stitch “overlays”: dual-stack, VPNs (including option B or A), and tunnels (GRE, L2TPv3, VxLAN).
I have not understood what you would like to improve in this.
I have not understood the problem. The general reference to better CAPEX and OPEX does not give any clue on how.
 
Eduard
 
From: internet-drafts
Date: 2022-08-18 16:02
To: Chenhao Ma; Chongfeng Xie; Gyan Mishra; Mohamed Boucadair; Thomas Graf; Xing Li
Subject: New Version Notification for draft-xie-v6ops-framework-md-ipv6only-underlay-03.txt
 
A new version of I-D, draft-xie-v6ops-framework-md-ipv6only-underlay-03.txt
has been successfully submitted by Chenhao Ma and posted to the
IETF repository.
 
Name: draft-xie-v6ops-framework-md-ipv6only-underlay
Revision: 03
Title: Framework of Multi-domain IPv6-only Underlay Networks and IPv4 as a Service
Document date: 2022-08-18
Group: Individual Submission
Pages: 22
URL:            https://www.ietf.org/archive/id/draft-xie-v6ops-framework-md-ipv6only-underlay-03.txt
Status:         https://datatracker.ietf.org/doc/draft-xie-v6ops-framework-md-ipv6only-underlay/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-xie-v6ops-framework-md-ipv6only-underlay
Diff:           https://www.ietf.org/rfcdiff?url2=draft-xie-v6ops-framework-md-ipv6only-underlay-03
 
Abstract:
   For the IPv6 transition, dual-stack deployments require both IPv4 and
   IPv6 forwarding capabilities to be deployed in parallel.  IPv6-only
   is considered as the ultimate stage where only IPv6 transfer
   capabilities are used while ensuring global reachability for both
   IPv6 and IPv4 (usually known as IPv4aaS).  This document specifies
   requirements and proposes a framework for deploying IPv6-only as the
   underlay in multi-domain networks.
 
                                                                                  
 
 
The IETF Secretariat