On Tue, Mar 20, 2018 at 4:37 AM, Sri Gundavelli (sgundave) <[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 :-) > I prefer term transformation :-) But in any case, this is definitely not stateful NAT and because the transformations are paired ILA does not have the issues that are typically associated with NAT.
Tom > > 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
