On Tue, Mar 20, 2018 at 4:53 AM, Sri Gundavelli (sgundave) <[email protected]> wrote: > > ILA-NAT-GW, or Locator-Rewrite Function ,,,should all work I guess. > Sri,
I still like the term 'address transformation'. The difference between transformation and translation is that no information is lost in transformation (pointed out by Mark Smith on ila list) whereas translations may be imperfect. A transformation is always reversible and must be reversed before delivery to the final destination. Tom > Sri > > > > > On 3/20/18, 4:42 AM, "Marco Liebsch" <[email protected]> wrote: > >>What about naming it nicely locator re-writing? Which is what it does and >>community reacts differently >>on certain terms such as NAT.. >> >>marco >> >>-----Original Message----- >>From: dmm [mailto:[email protected]] On Behalf Of Sri Gundavelli >>(sgundave) >>Sent: Dienstag, 20. März 2018 12:40 >>To: Tom Herbert; Lyle Bertz >>Cc: dmm >>Subject: Re: [DMM] draft-bogineni-dmm-optimized-mobile-user-plane-00 >> >>But, in any case, NAT is not such a bad word, its just that it pushed >>IPv6 deployments out by 20 years. >> >>Sri >> >>On 3/20/18, 4:37 AM, "dmm on behalf of Sri Gundavelli (sgundave)" >><[email protected] on behalf of [email protected]> wrote: >> >>>Tom: >>> >>>> ILA is not NAT! :-) >>> >>>As seen from the end point, I agree ILA is not NAT. But, that the >>>function that is needed at two places where you do translation of the >>>addresses from SIR to LOCATOR, or LOCATOR to SIR is a NAT function, and >>>you have a mapping state similar to NAT state. That¹s a NAT :-) >>> >>> >>>Sri >>> >>>On 3/20/18, 4:29 AM, "dmm on behalf of Tom Herbert" >>><[email protected] on behalf of [email protected]> wrote: >>> >>>>On Tue, Mar 20, 2018 at 3:57 AM, Lyle Bertz <[email protected]> >>>>wrote: >>>>> We'll be quite time constrained during this session so I thought I >>>>>would ask a couple of simple questions which I hope have already >>>>>been addressed in previous e-mails: >>>>> >>>>> 1. Figures 14 & 15 are described as options and do not include an SMF. >>>>> However, Figures 16 & 17 do. It is a bit confusing. Are 14 & 15 >>>>>incorrect or is an option to skip the SMF? If correct, how does one >>>>>do any policy in those figures? >>>>> >>>>> 2. ILA appears to be super NAT'g (more than 1 NAT) but it is >>>>>unclear how policy works. I am not sure that in its current state >>>>>the proposed ILA design addresses in Section 3. Although it is >>>>>noted that not all functions are supported at a specific UPF it is >>>>>unclear that policy, lawful intercept, etc.. is supported at all. >>>>>Will this be section be updated? >>>>> >>>>Hi Lyle, >>>> >>>>ILA is not NAT! :-) It is an address transformation process that is >>>>always undone before the packet is received so that receiver sees >>>>original packet. In this manner ILA is really just an efficient >>>>mechanism of creating network overlays. In this manner additional >>>>functionality (policy, lawful intercept, etc.) can be higher layers >>>>independent of the actual overlay mechanism. >>>> >>>>Tom >>>> >>>>> 3. Will a feature support comparison be made for each solution with >>>>>the UPF functions to ensure coverage? >>>>> >>>>> 4. Will MFA be proposed as an option ( >>>>> >>>>> draft-gundavelli-dmm-mfa-00 >>>>> >>>>> )? >>>>> >>>>> Thanks! >>>>> >>>>> Lyle >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> dmm mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>> >>>> >>>>_______________________________________________ >>>>dmm mailing list >>>>[email protected] >>>>https://www.ietf.org/mailman/listinfo/dmm >>> >>>_______________________________________________ >>>dmm mailing list >>>[email protected] >>>https://www.ietf.org/mailman/listinfo/dmm >> >>_______________________________________________ >>dmm mailing list >>[email protected] >>https://www.ietf.org/mailman/listinfo/dmm > _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
