Hi Yiu, Please see inline.
Cheers, Med -----Message d'origine----- De : Lee, Yiu [mailto:[email protected]] Envoyé : mardi 18 mai 2010 21:58 À : BOUCADAIR Mohamed NCPI/NAD/TIP; Sri Gundavelli Cc : [email protected] 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, "[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. > ******************************** > ********************************* 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. ******************************** _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
