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:dmm-boun...@ietf.org] 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)" <dmm-boun...@ietf.org on behalf of sgund...@cisco.com> 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" ><dmm-boun...@ietf.org on behalf of t...@quantonium.net> wrote: > >>On Tue, Mar 20, 2018 at 3:57 AM, Lyle Bertz <lyleb551...@gmail.com> >>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 >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>> >> >>_______________________________________________ >>dmm mailing list >>dmm@ietf.org >>https://www.ietf.org/mailman/listinfo/dmm > >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
