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

[Chongfeng Xie <[e-mail]>]

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.