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
