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

[MAWATARI Masataka <[e-mail]>]

Dear authors,


* On Sat, 3 Nov 2012 06:13:15 +0800
* GangChen <[e-mail]> 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
> 
> 
> > 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.
> 
> 
> > 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.


I understood that NAT64-CE shows server-side applicability of NAT64.
If my understanding is correct, "Server Farm Edge" sounds better to
me, IMHO.


Kind Regards,
Masataka MAWATARI


> Best Regards
> 
> 
> Gang