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

[GangChen <[e-mail]>]

Hi Philip,

2012/11/7, 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.

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

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

Will add at the next version

Best Regards

Gang

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