On Tue, Mar 27, 2018 at 7:36 AM, Sri Gundavelli (sgundave) <sgund...@cisco.com> wrote: > Tom: > > I am not against the use of the term “transformation” in ILA function > naming, but honestly I do not understand the difference. I have not seen > any documentation for such interpretation as you explained below. I have > looked at RFC 2663 and other specs, but I did find any such text. > > Lets look at two nodes, one with a NAT function and another with a ILA > function. > > #1 The NAT function intercepts the packets coming on an ingress interface, > look at certain header/payload fields and replaces certain fields with > certain other fields. It creates a temporary state for that mapping, which > we call it as NAT Mapping entry. The modified packet is sent on the egress > interface. > > #2 The ILA function (on ILA-L) intercepts the packet coming on an ingress > interface, looks at certain header fields, and replaces certain bits with > some other bits. For this replacement it looks at its cache, or obtains a > mapping entry which is very similar to NAT entry. The modified packet is > sent on the egress interface. > > > Now, for #2, your argument is that there is an inverse function some where > else in the other side of the network and that makes the original packet > go out to the correspondent node, and that the same does not happen for > #1. I agree with that, but, when you explain the sequence of steps that > these functions execute on a given packet (on a given node), there is very > little difference. Collectively, what ILA-L and ILA-R may achieve may be > different from what NAT realizes, but they are very similar functions when > you see them individually. > The difference is that the endpoints agree on what the addresses are for a flow. In NAT this does not happen so there is a descrepancy, in ILA there is always agreement. In this way ILA transformations are a method to make transparent network overlays.
Tom > > Sri > > > > > On 3/23/18, 3:36 AM, "Tom Herbert" <t...@quantonium.net> wrote: > >>On Tue, Mar 20, 2018 at 4:53 AM, Sri Gundavelli (sgundave) >><sgund...@cisco.com> 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" <marco.lieb...@neclab.eu> 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: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
