My questions are if must describe these concepts in a training class to a group of network operations personnel: 1. What term would the conversation devolve to? 2. What would one say to distinguish it from NAT in a manner that is acceptable to the trainees in the class (you've answered that Tom)? 3. Do we actually lose a lot of time by picking terminology that sounds distinct but in reality could have been efficiently expressed using other / less words?
I would make a slight correction to Sri's statement about NAT being not so bad. Generally that is correct but Carrier Grade NAT is not always favorable for various reasons beyond the IPv6 push out. On Tue, Mar 20, 2018 at 11:40 AM, Tom Herbert <[email protected]> wrote: > 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
