Hi Med, See comments inline:
> 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? > [YL] I think we disagree each other on this. DS-lite defines that a tunnel identifier (tid) should be added to the NAT table. In the classic ds-lite draft, the authors suggest the IPv6 address is the tid. In the gi-ds-lite draft, the tid is the CID, and in the extra-lite draft, the tid is the L2 header. From the specification point of view, they are all the same. However, we need drafts to describe how to apply this concept on different technologies. For example, gi-dslite describes how to make the tid to the CID in the mobile environment. So far we heard few mobile operators found it interesting. I think there is value to have different drafts to discuss how to define and use the dslite tunnel id in different technologies. > 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? > [YL] Why (c) has to be N:1? I can argue this is N:M.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
