If you want it to be direct, specific, and self documenting, I’d suggest “Address Replacement Function”. Then verbalize it by saying casually “ARFing the packet”.
Dino > On Mar 23, 2018, at 10:36 AM, Tom Herbert <[email protected]> wrote: > > 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 _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
