Re: [v6ops] Comments on draft-ietf-v6ops-nat64-experience-00

[Philip Matthews <[e-mail]>]

On 2012-11-02, at 18:13 , GangChen wrote:

> Hi Philip,
> 
> 2012/11/1, Philip Matthews <[e-mail]>:
>> Hi authors:
>> 
>> I read your draft with interest.   I need to re-read it more carefully, but
>> here are some preliminary comments:
>> 
>> 1) The title of the draft is "NAT64 Operational Experiences", but I feel the
>> draft reads much more like "NAT64 Deployment Considerations".   I didn't see
>> any place where the draft says "This is what we did and it worked well (or
>> it didn't work well)". That is, it is not really relating the specific
>> experience of an operator in deploying NAT64 so much as describing things
>> that an operator should take into account when planning their own NAT64
>> deployment.
> 
> Thanks for the comments. Regarding the word of "Experiences", I
> searched the definition from a dictionary. It usually refers to
> "knowledge or practical wisdom gained from what one has observed,
> encountered, or undergone". It's true it involves a particular
> instance of encountering or undergoing something. Whereas, we didn't
> describe such particular behavior (what we did), since the texts seems
> to be time-sensitive. It tends to be ephemeral as a documented output
> in RFC. So it may be more effective/worthwhile to discuss generalized
> knowledge/problems being addressed in the document.
> 
> We are still opening on this point. I guess that is only the matter of
> structuring texts

It is just a suggestion, but I think this title change would reflect the document contents better.

> 
> 
>> 2) Section 3.1 has the sentence:
>>   It is advantageous from the vantage-point of
>>   troubleshooting and traffic engineering to carry the IPv6 traffic
>>   natively for as long as possible within an access network and
>>   translates only at or near the network egress.
>> I think it would be interesting and helpful to say more about why you feel
>> this is true.  Can you give some specific examples?
> 
> In our practices, NAT64 is positioned on the location of border
> routers. As you mentioned, the reason for that is for cost reasons.
> Other gains are simplification of traceability and network
> provisioning in one network domain. AFAIK, the cases are also shared
> by other operators in the author list.

I think it would be interesting if you said a bit more about these reasons in the draft.

> 
> 
>> Though today I suspect
>> most operators will try to centralize their NAT64 boxes for cost reasons, I
>> can see in the future an operator that is forced to go pure IPv6 and is
>> planning a large rollout, and will be worried that centralizing NAT64 will
>> not scale well and will thus consider pushing NAT64 to closer to the
>> customer.
> 
> The concerns were actually discussed when we do the network planning.
> One point is native IPv6 communications would bypass the NAT64. Those
> traffic offload on NAT64 should be encouraged if an operator is forced
> to go pure IPv6. In some sense, the concerns of scalability on NAT64
> may be alleviated.
> 
> 
>> 3) Section 3.2 on HA Considerations has the sentence:
>>    Given that short
>>   lived sessions account for most of the bindings, hot-standby does not
>>   offer much benefit for those sessions.
>> Just curious if you have evidence or a reference that backs up this claim?
> 
> Statistic of service traffic in a mobile network could be the evidence
> depending on the colleted data. Most traffic (almost 94% of amount of
> traffic) is accounted by Http, WAP browsing, which are short lived
> sessions.
> 
>> This is certainly frequently stated for NAT44, but I haven't seen hard facts
>> in the case of NAT64. I am especially wondering if the fact that some
>> traffic (like DNS traffic and native IPV6 traffic) doesn't go through the
>> NAT64 would change the situation from the NAT44 case.
> 
> I guess the situation on NAT64 is similar with NAT44, since all IPv4
> connections to the IPv4 Internet from IPv6-only clients must traverse
> the NAT64.
> 
>> 4) The draft is currently organized so that section 3 discusses the
>> NAT64-CGN case, and section 4 discusses the same topics in the NAT64-CPE
>> case.  I suggest you consider organizing the draft differently, so that you
>> have a series of sections discussing a topic (e.g Load Balancing or MTU),
>> and within the section you first discuss the NAT64-CGN case and then the
>> NAT64-CPE case. I suggest that this would allow you to discuss each topic
>> more fully, and would emphasis the similarities or differences between the
>> CGN and CPE cases.  Just a suggestion.
> 
> Thanks for the suggestions. Some texts in same topics for NAT64-CGN
> and -CE could be structured. Yet, there are also different topics
> regarding to -CGN and -CE, which is hardly organized in such way
> 
> BTW, the term "CE" is likely confused with CPE. What we indicated is
> actually a load-balancer in front of enterprise network, e.g. data
> center. If the group agree, we intend to rename it as "Front End" to
> precisely indicate the meaning.
> 
> Best Regards
> 
> 
> Gang
> 
>> - Philip
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>> 
>