Hi Yiu,
Please see inline.
Cheers,
Med
-Message d'origine-
De : Lee, Yiu [mailto:yiu_...@cable.comcast.com]
Envoyé : mardi 18 mai 2010 21:58
À : BOUCADAIR Mohamed NCPI/NAD/TIP; Sri Gundavelli
Cc : softwires@ietf.org
Objet : Re: [Softwires] GI-DS-lite as working group item?
Hi Med,
I think we are on the same page. So your concern is the current draft didn't
limit to the scale to 3gpp. IMHO, this draft suggests a way to use a
tunnel-id to identify the client in AFTR. In this context, this doesn't
limit the scale to 3gpp only. In theory any client using tunnel may use it
(e.g. PPP). I don't now why IETF wants to limit it to 3gpp based deployment.
Med: This is why I asked for a big picture view rather than a single solution.
Please refer to my previous messages, I included links to
http://tools.ietf.org/html/draft-miles-behave-l2nat-00 or
http://tools.ietf.org/html/draft-arkko-dual-stack-extra-lite-00 for instance
which are generic solutions. Should we define a generic table structure for all
enhanced NAT tables?
I don't see how this draft to suggest a centralized NAT. Can you show me any
part in the draft may have suggested that?
Med: This is the main argument of the draft: unavailability of sufficient
private IPv4 addresses to service all UEs behind a CGN. The valid scenario for
GI-DS-Lite is case (c) below which is a centralised model IMHO:
(a) Co-located model: the NAT is co-located in the PGW/GGSN. No issue with
private IPv4 addresses. GTP TID can be used as de-multiplexing factor if
required.
(b) 1:1 model: the CGN and the PGW/GGSN are not embedded in the same device.
Each PGW/GGSN is configured how to reach its attached CGN. There is no private
IPv4 @ depletion problem.
(c) N:1 model: a single CGN serve a group of PGW/GGSN. Indeed, having +16M of
customers is a valid case (centralised model)
Does this make sense for you?
Yes, if an operator wants to use
a giant NAT, this draft won't stop it. But this draft doesn't suggest it
either. Like what you said, this is deployment issue, not the spec enforcing
it.
As far as proposing IPv6, I agree the draft can put more words on it. I will
try to work with the authors off-line to suggest some text to them.
Med: Hope to see there how Gi-DS-lite is a migration tool for IPv6.
Cheers,
Yiu
On 5/18/10 3:48 AM, mohamed.boucad...@orange-ftgroup.com
mohamed.boucad...@orange-ftgroup.com wrote:
Hi Yiu,
Yes, I understand that point. My comment was related to the claim that
GI-DS-Lite allows to migrate to IPv6...which I still don't agree with.
What you mentioned is valid for any NAT-based solution. My concerns are as
follows:
(1) Since it seems that 3GPP is interested in this proposal and the 3GPP
recommends DS and IPv6-only, the scope of the document should be restricted to
that context. (Need to check if the GI-ds-lite has been moved to the main
document of the TR of the IPv6 SI)
(2) No Fixed network considerations should be elaborated in the document
(3) The problem statement should be clarified for IETF. Is there any issue
with depletion of private IPv4 addresses? Clarify why this is a problem and
for what deployment context? I still don't encourage centralise NAT approach.
(4) Ensure that the proposed solution is not another showstopper for the
deployment of IPv6. This is for consistency of the overall IETF work. This
does not prevent any SP to do whatever it wants, but from a standardisation
perspective alternative solutions to delay IPv6 should be avoided. Gi-Ds-lite
for me is one of these category of solutions. It can even lead to NAT444 since
the AD can embed a NAT function.
I had other concerns with the procedure of the adoption of this document:
- It seems to me that the current charter does not allow for adopting it. I
asked the chair to clarify but with no answer.
Cheers,
Med
-Message d'origine-
De : Lee, Yiu [mailto:yiu_...@cable.comcast.com]
Envoyé : mardi 18 mai 2010 03:07
À : BOUCADAIR Mohamed NCPI/NAD/TIP; Sri Gundavelli
Cc : softwires@ietf.org
Objet : Re: [Softwires] GI-DS-lite as working group item?
Hi Med,
Med: If the network is IPv6-only (likely the major base of UEs would be
IPv6-enabled, right?), the use of NAT64 would be more appropriate (hence
avoiding tunnelling) that crossing a NAT44 device. No?
For some operators, NAT64 may make more sense; for others, GI-DS-lite may be
more useful. In this end, GI-DS-lite just provides a simple way to address
the IPv4 exhaustion issue w/o change in the MH. I think there is value for
IETF to work on it.
Cheers,
Yiu
*
This message and any attachments (the message) are confidential and intended
solely for the addressees.
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration.
France Telecom Group shall not be liable for the message if altered, changed
or falsified.
If you are not the intended addressee of this message,
