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.
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? 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. Cheers, Yiu On 5/18/10 3:48 AM, "[email protected]" <[email protected]> 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:[email protected]] > Envoyé : mardi 18 mai 2010 03:07 > À : BOUCADAIR Mohamed NCPI/NAD/TIP; Sri Gundavelli > Cc : [email protected] > 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, please cancel it > immediately and inform the sender. > ******************************** >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
