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

[Tom Herbert]

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
>>>&g

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

[Sri Gundavelli (sgundave)]

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.


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 a

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

[Dino Farinacci]

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 <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

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Tom Herbert]

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

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

[Lyle Bertz]

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  wrote:

> On Tue, Mar 20, 2018 at 4:37 AM, Sri Gundavelli (sgundave)
>  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" <
> dmm-boun...@ietf.org
> > on behalf of t...@quantonium.net> wrote:
> >
> >>On Tue, Mar 20, 2018 at 3:57 AM, Lyle Bertz 
> 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

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

[Marco Liebsch]

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

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

[Sri Gundavelli (sgundave)]

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)"
 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" on behalf of t...@quantonium.net> wrote:
>
>>On Tue, Mar 20, 2018 at 3:57 AM, Lyle Bertz 
>>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

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

[Sri Gundavelli (sgundave)]

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"  wrote:

>On Tue, Mar 20, 2018 at 3:57 AM, Lyle Bertz  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

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

[Tom Herbert]

On Tue, Mar 20, 2018 at 3:57 AM, Lyle Bertz  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

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

[Lyle Bertz]

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?

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