Re: [Ila] [DMM] draft-bogineni-dmm-optimized-mobile-user-plane-00

[Tom Herbert <[e-mail]>]

On Tue, Mar 27, 2018 at 7:36 AM, Sri Gundavelli (sgundave)
<[e-mail]> 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" <[e-mail]> wrote:
>
>>On Tue, Mar 20, 2018 at 4:53 AM, Sri Gundavelli (sgundave)
>><[e-mail]> 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" <[e-mail]> 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:[e-mail]] 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)"
>>>><[e-mail] on behalf of [e-mail]> 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"
>>>>><[e-mail] on behalf of [e-mail]> wrote:
>>>>>
>>>>>>On Tue, Mar 20, 2018 at 3:57 AM, Lyle Bertz <[e-mail]>
>>>>>>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
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>>>>
>>>>>>
>>>>>>_______________________________________________
>>>>>>dmm mailing list
>>>>>>[e-mail]
>>>>>>https://www.ietf.org/mailman/listinfo/dmm
>>>>>
>>>>>_______________________________________________
>>>>>dmm mailing list
>>>>>[e-mail]
>>>>>https://www.ietf.org/mailman/listinfo/dmm
>>>>
>>>>_______________________________________________
>>>>dmm mailing list
>>>>[e-mail]
>>>>https://www.ietf.org/mailman/listinfo/dmm
>>>
>