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

From: Lyle Bertz <[email-masked]>
Date: Tue, 20 Mar 2018 10:57:26 +0000

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

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Tue, 20 Mar 2018 11:14:16 +0000

Lyle:

Thank you for your comments. The document is still work-in-progress. The future revisions will address your comments.

From: dmm [mailto:[email-masked]] On Behalf Of Lyle Bertz
Sent: Tuesday, March 20, 2018 6:57 AM
To: dmm <[email-masked]>
Subject: [E] Re: [DMM] draft-bogineni-dmm-optimized-mobile-user-plane-00

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?

[KB] Slide #12 in the presentation show the complete diagrams, the document needs to be updated.

https://datatracker.ietf.org/meeting/101/materials/slides-101-dmm-optimized-mobile-user-plane-solutions-for-5g-00

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?

[KB] the sections will be updated to show how each solution meets the requirements in Section 3.

3.      Will a feature support comparison be made for each solution with the UPF functions to ensure coverage?

[KB] That is the plan.

4.  Will MFA be proposed as an option
draft-gundavelli-dmm-mfa-00
[KB] I will let Sri answer this.
)?

Thanks!

Lyle

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 20 Mar 2018 11:28:24 +0000

>  [KB] I will let Sri answer this.

Nothing specific to MFA draft, but I will make a general comment.

If there is consensus to adopt draft-bogineni as a WG document, and if this work becomes part of the WG charter, I would think the document should include all IETF proposals under discussion for the given problem statement on user-pane optimization. At this point, its an individual I-D and it is up to the authors on what to include, or what to exclude.

Sri

From: dmm <[email-masked]<mailto:[email-masked]>> on behalf of "Bogineni, Kalyani" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 20, 2018 at 3:14 AM
To: Lyle Bertz <[email-masked]<mailto:[email-masked]>>, dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DMM] [E] Re: draft-bogineni-dmm-optimized-mobile-user-plane-00

Will MFA be proposed as an option
draft-gundavelli-dmm-mfa-00
[KB] I will let Sri answer this.

---

From: Tom Herbert <[email-masked]>
Date: Tue, 20 Mar 2018 04:29:17 -0700

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

> 4.  Will MFA be proposed as an option (
>
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm
>

---

From: Lyle Bertz <[email-masked]>
Date: Tue, 20 Mar 2018 11:31:03 +0000

Kalyani,

Thanks so much.

Lyle

On Tue, Mar 20, 2018 at 11:14 AM, Bogineni, Kalyani <
[email-masked]> wrote:

> Lyle:
>
>
>
> Thank you for your comments. The document is still work-in-progress. The
> future revisions will address your comments.
>
>
>
>
>
> *From:* dmm [mailto:[email-masked]] *On Behalf Of *Lyle Bertz
> *Sent:* Tuesday, March 20, 2018 6:57 AM
> *To:* dmm <[email-masked]>
> *Subject:* [E] Re: [DMM] draft-bogineni-dmm-optimized-mobile-user-plane-00
>
>
>
> 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?
>
> https://datatracker.ietf.org/meeting/101/materials/slides-
> 101-dmm-optimized-mobile-user-plane-solutions-for-5g-00
>
>
>
>
>
> 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
> intercept, etc.. is supported at all.  Will this be section be updated?
>
> draft-gundavelli-dmm-mfa-00 [KB] I will let Sri answer this.
>
> )?
>
>
>
> Thanks!
>
>
> Lyle
>
>
>
>
>
>
>
>
>
>
>
>
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 20 Mar 2018 11:37:39 +0000

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-masked]
on behalf of [email-masked]> wrote:

>>how
>>intercept,

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 20 Mar 2018 11:40:15 +0000

But, in any case, NAT is not such a bad word, its just that it pushed IPv6
deployments out by 20 years.

Sri

---

From: Tom Herbert <[email-masked]>
Date: Tue, 20 Mar 2018 04:40:47 -0700

> 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

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 20 Mar 2018 11:42:12 +0000

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-masked]] 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-masked] on behalf of [email-masked]> 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-masked] on behalf of [email-masked]> 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:
>>>
>>> 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,
>>

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 20 Mar 2018 11:43:51 +0000

> If there is consensus to adopt draft-bogineni as a WG document, and if
> this work becomes part of the WG charter, I would think the document should
> include all IETF proposals under discussion for the given problem statement
> on user-pane optimization.
>

> At this point, its an individual I-D and it is up to the authors on what
> to include, or what to exclude.
>
>
Right.

I think that 3GPP Study Item related drafts (there is also  Homma draft,
all ILA, LISP etc ID-Loc drafts and 5G work) are better
stay as purpose specific individual drafts.

Otherwise including them to dmm charter, a rechartering of such a scale I
believe should require a BoF.

My three cents :-)

Regards,
Behcet

> Sri
>
>
> From: dmm <[email-masked]> on behalf of "Bogineni, Kalyani" <
> [email-masked]>
> To: Lyle Bertz <[email-masked]>, dmm <[email-masked]>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 20 Mar 2018 11:47:39 +0000

Not sure I agree Behcet. Generally, the distributed mobility management charter does cover optimizations in user-plane and control plane. But, for now, lets not discuss if this is in scope for this WG, or not. Lets focus on technical discussions.

Sri

From: Behcet Sarikaya <[email-masked]<mailto:[email-masked]>>
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 20, 2018 at 3:43 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Cc: "Bogineni, Kalyani" <[email-masked]<mailto:[email-masked]>>, Lyle Bertz <[email-masked]<mailto:[email-masked]>>, dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DMM] [E] Re: draft-bogineni-dmm-optimized-mobile-user-plane-00

If there is consensus to adopt draft-bogineni as a WG document, and if this work becomes part of the WG charter, I would think the document should include all IETF proposals under discussion for the given problem statement on user-pane optimization.

At this point, its an individual I-D and it is up to the authors on what to include, or what to exclude.

Right.

I think that 3GPP Study Item related drafts (there is also  Homma draft, all ILA, LISP etc ID-Loc drafts and 5G work) are better
stay as purpose specific individual drafts.

Otherwise including them to dmm charter, a rechartering of such a scale I believe should require a BoF.

My three cents :-)

Regards,
Behcet
Sri

_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmm

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 20 Mar 2018 11:50:45 +0000

On Tue, Mar 20, 2018 at 11:47 AM, Sri Gundavelli (sgundave) <
[email-masked]> wrote:

> Not sure I agree Behcet. Generally, the distributed mobility management
> charter does cover optimizations in user-plane and control plane. But, for
> now, lets not discuss if this is in scope for this WG, or not. Lets focus
> on technical discussions.
>
>
I know it is procedural.
But it keeps coming up.
I was just reacting to your own mail,
you mentioned that all those drafts are individual.
I think it would help dmm people to see the full perspective.

Regards,
Behcet

> Sri
>
>
> From: Behcet Sarikaya <[email-masked]>
> Reply-To: "[email-masked]" <[email-masked]>
> To: Sri Gundavelli <[email-masked]>
> Cc: "Bogineni, Kalyani" <[email-masked]>, Lyle
> Bertz <[email-masked]>, dmm <[email-masked]>
>

---

From: Lyle Bertz <[email-masked]>
Date: Tue, 20 Mar 2018 11:50:56 +0000

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

> function
> >>>would ask
> >>>incorrect

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 20 Mar 2018 11:53:40 +0000

ILA-NAT-GW, or Locator-Rewrite Function ,,,should all work I guess.

Sri

---

From: Arashmid Akhavain <[email-masked]>
Date: Tue, 20 Mar 2018 15:20:08 +0000

I agree with Sri. However the aim is to have the WG to reference this draft as part of the response back to 3GPP.
Different contenders are welcomed to participate and provide analysis and comparsion.

Arashmid

From: dmm [mailto:[email-masked]] On Behalf Of Sri Gundavelli (sgundave)
Sent: Tuesday, March 20, 2018 7:48 AM
To: [email-masked]
Cc: dmm <[email-masked]>
Subject: Re: [DMM] [E] Re: draft-bogineni-dmm-optimized-mobile-user-plane-00

Sri

Right.

My three cents :-)

Regards,
Behcet
Sri

---

From: Tom Herbert <[email-masked]>
Date: Fri, 23 Mar 2018 03:36:24 -0700

> 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

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 23 Mar 2018 12:47:21 +0000

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

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 27 Mar 2018 14:36:56 +0000

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" <[email-masked]> wrote:

>>>What about naming it nicely locator re-writing? Which is what it does
>>>and
>>>community reacts differently
>>>>>>SMF.

---

From: Tom Herbert <[email-masked]>
Date: Tue, 27 Mar 2018 07:53:08 -0700

> 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