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

[GangChen <[e-mail]>]

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.

Best Regards


Gang

> - Philip
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>