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

From: Philip Matthews <[email-masked]>
Date: Thu, 1 Nov 2012 10:06:04 -0400

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. 

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? 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.

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? 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.

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.

- Philip

---

From: GangChen <[email-masked]>
Date: Sat, 3 Nov 2012 06:13:15 +0800

Hi Philip,

2012/11/1, Philip Matthews <[email-masked]>:
> 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

> 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.

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: MAWATARI Masataka <[email-masked]>
Date: Tue, 06 Nov 2012 15:15:29 +0900

Dear authors,

* On Sat, 3 Nov 2012 06:13:15 +0800

> 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

---

From: Philip Matthews <[email-masked]>
Date: Tue, 6 Nov 2012 11:35:49 -0500

> We are still opening on this point. I guess that is only the matter of

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

> 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.

> regarding to -CGN and -CE, which is hardly organized in such way
>

---

From: GangChen <[email-masked]>
Date: Wed, 7 Nov 2012 04:58:02 +0800

Hi Philip,

2012/11/7, Philip Matthews <[email-masked]>:
>>> I read your draft with interest.   I need to re-read it more carefully,
>>> but
>>> here are some preliminary comments:
>>>

Ok. I would add it as an open question in the slides to see opinions
from the group.

> I think it would be interesting if you said a bit more about these reasons

Will add at the next version

Best Regards

Gang