Hi Med,
> Dear Cameron, all, GI-DSLite does not define any protocol but an > architecture where a tunnel is used together with a new enhanced NAT44 table > (because more de-multiplexing information than for basic NAT44 table is > required). So, what should be standardised there? (1) The behaviour of > the gateway? (2) The tunnel establishment "procedure"? This is an > operational consideration as a matter of fact. In addition, the tunnel is not > required in the majority of the scenarios. Normal routing actions can be done > in > the gateway to redirect the traffic to the appropriate CGN. I don't see a > deployment context where more that +16M UEs (or Access Devices) will be > serviced > by the same CGN device. (3) The structure of the enhanced NAT table?: > Other proposals are on the table such as Layer-2 Aware NAT > (http://tools.ietf.org/html/draft-miles-behave-l2nat-00) or Per-interface NAT > (http://tools.ietf.org/html/draft-arkko-dual-stack-extra-lite-00). Should we > define a generic table structure for all enhanced NAT? The document does > not define the problem to be solved and neither why a new solution is > required. > Is the targeted problem a valid problem to be solved? Please find below my > analysis on the mobile use case. Several scenarios can be envisaged as listed > below: > (a) Co-located model: the NAT is co-located in the PGW/GGSN. No > issue with private IPv4 addresses. GTP TID can even be used a 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. **BUT** which Service Provider will accept to service this > huge > amount of UEs with the same node (if we suppose that a mega centralised CGN > implementation is found in the market)? This is single point of failure > design > which SHOULD NOT BE RECOMMENDED. IMHO it is N:1 and that's why GI-DS lite is interesting to the operators. I agree with you that having 16M+ MNs NAT'ed by a single CGN is something I have not heard of, yes there there is a problem. Let's hope that we are not going to have that problem. If IPv6 migration progresses fast we may not. Regards, Behcet _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
