Re: [v6ops] draft-xie-v6ops-reqirements-multi-domain-ipv6only

[Chongfeng Xie <[e-mail]>]

Hi， Xipeng,
Thank you for your review and useful suggestions.  For your first suggestion, I will try to provide an example to illustrate the softwire approach and the new one in the next version.  Your second suggestion is about the  structure the draft,  we plan to do it step by step along with the content of each section becomes more mature,  do you think this is ok?  
Best regards
Chongfeng
 
From: Xipengxiao
Date: 2022-07-07 15:50
To: [e-mail]; list
Subject: RE: RE: [v6ops] draft-xie-v6ops-reqirements-multi-domain-ipv6only
Hi Chongfeng,
 
Thanks for your reply.  In the current Section 5, if you provide an example like the following, it may greatly help the community understand your point:
 
Assuming CPE1 wants to send an packet to a destination in AS4 which is IPv4 only.  
How the current softwire approach will work (or will not work), in both control and data planes.  For example 
Control plane
                                                              i.      BR1 will announce the destination IPv4 route to PE5
                                                            ii.      How the IPv4 route will (or will not) propagate from PE5 to PE1
Data plane
                                                              i.      How the IPv4 packet from CPE1 will be encapsulated/decapsulated on the way to AS4 
How your framework/solution will work (at a high level), or if you don’t have a specific solution yet, how you want it to work

[CF]: I will try to provide the exmple based oyour suggestion in the next version.   n  
 
 
This way, Section 5 is not just about scenarios but about a solution (to the problem stated in Section 4), and people will not feel that it’s a distraction from the solution discussion.  In a sense, this merges Sections 5 & 7 together.  After introducing your framework/solution at a high level, you summarizes the requirements in Section 6, and the draft ends there.  I think this logic works better.  But of course this is just my suggestion for your consideration.  
 
XiPeng 
 
From: [e-mail] <[e-mail]> 
Sent: Wednesday, July 6, 2022 3:22 AM
To: Xipengxiao <[e-mail]>; list <[e-mail]>
Subject: Re: RE: [v6ops] draft-xie-v6ops-reqirements-multi-domain-ipv6only
 
Hi, Xipeng,
 
Thank you for your detailed review and comments,  and I try to answer your commments inline taged as [CF]:
 
 
From: Xipengxiao
Date: 2022-07-06 06:39
To: [e-mail]; v6ops list
Subject: RE: [v6ops] draft-xie-v6ops-reqirements-multi-domain-ipv6only
Hi Chongfeng,
 
I read your draft twice, but I may still have some misunderstanding.  With this disclaimer, I provide my comments below:
 
1.    Section 4: I think the draft identifies a problem that may be worth solving, that is, there is a need for multi-domain IPv6-only solutions to eliminate unnecessary v4-v6 conversions in the middle.
 
2.    Section 5: after reading the problem statement in Section 4, I expect some solution ideas here.  But Section 5 is about scenarios.   The scenarios seem unnecessarily comprehensive too.  I feel that the logic is distracted.
 
[CF]:  OK, I will reconsider the position of scenarios in section 5 to make the text straightforward, mabye it is better to put them  in the appendix.  
 
3.    Section 6: some requirements are related to the problem statement, others are not so related.  I suggest deleting those not so related to keep the logic clearer, e.g. R1, R5, R8 
[CF]: OK, we will revise the requirements based on your suggestions.
 
4.    Section 7: 
a.    This seems like a solution section to me.  So, should this draft be submitted to 6man?
 [CF]: This section only give the fundermental principles of this framework, it does not give a detailed illustration from the perpective of protocol, for instance, the BGP4+ extension for  exchanging of mapping rule,  this kind of work can be done in other WGs. 
 
b.    It’s not clear to me, how your framework/solution reduces v4-v6 conversions compared to existing softwire solutions.
[CF]: The following two points show how the framework reduces  v4-v6 conversions compared to existing softwire solutions.
          1. The softwire solutions generally use the next-hop address as the remote end-point for encapsulation, the next-hop address is only visible within a single AS, when IPv6 packets reaches the PE where the next-hop address resides, it will be de-capsulated.  With the new framework, the mapping rule can be exchanged between PEs of different ASes, so the original IPv4 packets can be encapsulated based on the mapping rule sent by the egress PE of other ASes. 
 
          2. This framework supports both encapsualtion and translation, so it can process the IPv6 packets generated by CLAT of UE without any IPv4-IPv6 conversion,  which has been metioned in section 8.   But with softwire solutions, the packets need to be resorted to IPv4 packets oginated from CLAT of UE, since encapsulation and translation are different mechanisms with different packet formats.
 
5.    Section 8:
a.    It may be worth comparing, how an IPv4 packet will be handled with and without your solution.  Is there a difference in the number of v4-v6 conversions?
          [CF]: Yes, this is supposed to be done in section 4, this section gives an example which has three v4-v6 conversions, this number can be reduced to one with the new framework. We will add the the comparison in the new version.
 
There are also some minor editorial comments: For the IPv6 transition, dual-stack deployments require both IPv4 and   IPv6 transfer capabilities are deployed in parallel.
 
XiPeng: the word “transfer” is a little strange.  Maybe “transport”?
[CF]: OK, we will replace it with "transport". 
 
   o  Multi-domain IPv6-only network: An IPv6-only network which
      consists of multiple ASes belonging to and operated by the same
      operator.
 
   o  Inter-domain IPv6-only network: An IPv6-only network which
      consists of multiple ASes belonging to and operated by different
      operators.
 
XiPeng: the meaning of domain is different in these two terms.  In the former, it means an AS.  In the latter, it means an administrative domain.  To avoid inconsistency, you may consider changing Multi-domain IPv6-only network to Multi-AS IPv6-only network
[CF]:  Yes, I agree with you, the terms in these two cases may cause  a little confustion, I am considering to change the term in the latter .     
 
The global industry has not given a unified definition of IPv6-only network so far.
 XiPeng: I think the ipv6-deployment-status draft now gives good definition of IPv6-only.  You may take a look. [CF]: Thank you, I will check it. Scenario 4: DC-to-DC, i.e., IPv6-only provide communications between   VMs hosted in cloud data centers, despite they are IPv4, IPv6 or   IPv4/IPv6 dual-stack. 
==>
Scenario 4: DC-to-DC, i.e., IPv6-only provides communications between   VMs hosted in cloud data centers, no matter they are IPv4, IPv6 or   IPv4/IPv6 dual-stack.
 [CF]: OK, we will revise it in the new version.


7.2.  ADPT
 
XiPeng: ADPT is not previously defined, and not defined here until in the middle of paragraph.  Suggest either defining it in the terminology section, and defining it in the 1st sentence of this paragraph
AFBR is not defined either.
[CF]: Thank you for your reminding, we will add the definition of ADPT in the terminalogy section.  AFBR is defined in RFC5565, I will add it to the terminalogy section also.  
 
 
Thank you again for your review.  BTW, this is version-00, more refinement needs to be done, we are looking forward to receiving more comments and suggestions. 
 
Best regards
Chongfeng
 
 
From: v6ops <[e-mail]> On Behalf Of Fred Baker
Sent: Sunday, July 3, 2022 8:00 PM
To: v6ops list <[e-mail]>
Subject: [v6ops] draft-xie-v6ops-reqirements-multi-domain-ipv6only
 
With this email, let me invite commentary on draft-xie-v6ops-reqirements-multi-domain-ipv6only. Please read the draft and raise any issues you might have with it.