Re: [DMM] User Plane Protocol Study in 3GPP

[Dino Farinacci]

That sounds like you want to do IPv4 over IPv6. Do you think carriers will 
build an IPv6-only NGC at this point in time?

Dino

> On Mar 20, 2018, at 6:33 PM, Satoru Matsushima  
> wrote:
> 
> Next header type maybe?
> Interestingly GTP-U doesn’t have it.
> 
> Sent from my iPhone
> 
> 2018/03/20 18:17、Dino Farinacci のメール:
> 
>> How? Please summarize in one sentence and don’t me to a draft.
>> 
>> Dino
>> 
>>> On Mar 20, 2018, at 10:24 AM, Satoru Matsushima 
>>>  wrote:
>>> 
>>> Yes , supports IPv4 PDU with minimum effort.
>>> 
>>> Sent from my iPhone
>>> 
>>> 2018/03/20 16:47、Lyle Bertz のメール:
>>> 
 I did not get to ask but I know your presentation talks about IPv6 but is 
 there a requirement to support IPv4 mobile or dual stack?
 
 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] User Plane Protocol Study in 3GPP

[Satoru Matsushima]

Next header type maybe?
Interestingly GTP-U doesn’t have it.

Sent from my iPhone

2018/03/20 18:17、Dino Farinacci のメール:

> How? Please summarize in one sentence and don’t me to a draft.
> 
> Dino
> 
>> On Mar 20, 2018, at 10:24 AM, Satoru Matsushima 
>>  wrote:
>> 
>> Yes , supports IPv4 PDU with minimum effort.
>> 
>> Sent from my iPhone
>> 
>> 2018/03/20 16:47、Lyle Bertz のメール:
>> 
>>> I did not get to ask but I know your presentation talks about IPv6 but is 
>>> there a requirement to support IPv4 mobile or dual stack?
>>> 
>>> 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] User Plane Protocol Study in 3GPP

[Dino Farinacci]

How? Please summarize in one sentence and don’t me to a draft.

Dino

> On Mar 20, 2018, at 10:24 AM, Satoru Matsushima  
> wrote:
> 
> Yes , supports IPv4 PDU with minimum effort.
> 
> Sent from my iPhone
> 
> 2018/03/20 16:47、Lyle Bertz のメール:
> 
>> I did not get to ask but I know your presentation talks about IPv6 but is 
>> there a requirement to support IPv4 mobile or dual stack?
>> 
>> 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] User Plane Protocol Study in 3GPP

[Satoru Matsushima]

BTW 5G Rel-15 doesn’t support IPv4v6 type session. But Docomo is trying to get 
back v4v6 to the updated Rel-15 stage 2 spec.
I don’t know why. 

> 2018/03/20 16:47、Lyle Bertz のメール:
> 
> I did not get to ask but I know your presentation talks about IPv6 but is 
> there a requirement to support IPv4 mobile or dual stack?
> 
> Lyle

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

Re: [DMM] User Plane Protocol Study in 3GPP

[Satoru Matsushima]

Yes , supports IPv4 PDU with minimum effort.

Sent from my iPhone

2018/03/20 16:47、Lyle Bertz のメール:

> I did not get to ask but I know your presentation talks about IPv6 but is 
> there a requirement to support IPv4 mobile or dual stack?
> 
> Lyle

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

Re: [DMM] User Plane Protocol Study in 3GPP

[Lyle Bertz]

I did not get to ask but I know your presentation talks about IPv6 but is
there a requirement to support IPv4 mobile or dual stack?

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

[DMM] New version to draft-ietf-dmm-ondemand-mobility - 14

[Moses, Danny]

Hi,

I update the draft with some minor editorial fixes, mainly to the pseudo code 
part. These are mainly breaking long lines so that they do not exceed the 72nd 
column.

You can continue addressing draft-ietf-dmm-ondemand-mobility-13 for WGLC review 
- there are no other modifications.

Thanks and regards,
Danny

-
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Arashmid Akhavain]

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:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Tuesday, March 20, 2018 7:48 AM
To: sarik...@ieee.org
Cc: dmm 
Subject: Re: [DMM] [E] Re: draft-bogineni-dmm-optimized-mobile-user-plane-00

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 >
Reply-To: "sarik...@ieee.org" 
>
Date: Tuesday, March 20, 2018 at 3:43 AM
To: Sri Gundavelli >
Cc: "Bogineni, Kalyani" 
>,
 Lyle Bertz >, dmm 
>
Subject: Re: [DMM] [E] Re: draft-bogineni-dmm-optimized-mobile-user-plane-00



On Tue, Mar 20, 2018 at 11:28 AM, Sri Gundavelli (sgundave) 
> wrote:
>  [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.


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 > on behalf of 
"Bogineni, Kalyani" 
>
Date: Tuesday, March 20, 2018 at 3:14 AM
To: Lyle Bertz >, dmm 
>
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.



___
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] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-dlif-01.txt]

[Satoru Matsushima]

Thanks authors,

Actually this draft sounds interesting for me. Some points for that are 
following:

1. Utilizing existing control plane for distributed mobility functions.
2. Those mobility functions could be programmed through some interface, i.e: FPC
3. I’d see some similarity with MFA ideas.
4. SRv6 could be user plane protocol with the control plane protocol.

One question here is that whether the authors are interested in User Plane 
white paper which Kalyani lead files this solution.

Cheers,
--satoru

> 2018/03/06 22:17、Carlos Jesús Bernardos Cano のメール:
> 
> Hi,
> 
> We have submitted a revised version of our draft addressing the
> comments we got in Singapore:
> 
> - Added some statements about which model from draft-ietf-dmm-
> deployment-models our solution follows (addressing a comment received
> from Sri).
> - Added some text relating to draft-ietf-dmm-ondemand-mobility
> (addressing a comment received from Danny).
> 
> Additionally, we added some terminology from draft-ietf-dmm-deployment-
> models and other minor changes.
> 
> In Singapore we got quite good support of the document. I'd like to
> request feedback/reviews from the WG.
> 
> Thanks!
> 
> Carlos
> 
> 差出人: internet-dra...@ietf.org
> 件名: I-D Action: draft-bernardos-dmm-pmipv6-dlif-01.txt
> 日付: 2018年3月2日 17:16:29 GMT
> 宛先: 
> 返信先: internet-dra...@ietf.org
> 
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
>Title   : Proxy Mobile IPv6 extensions for Distributed 
> Mobility Management
>Authors : Carlos J. Bernardos
>  Antonio de la Oliva
>  Fabio Giust
>  Juan Carlos Zuniga
>  Alain Mourad
>   Filename: draft-bernardos-dmm-pmipv6-dlif-01.txt
>   Pages   : 32
>   Date: 2018-03-02
> 
> Abstract:
>   Distributed Mobility Management solutions allow for setting up
>   networks so that traffic is distributed in an optimal way and does
>   not rely on centralized deployed anchors to provide IP mobility
>   support.
> 
>   There are many different approaches to address Distributed Mobility
>   Management, as for example extending network-based mobility protocols
>   (like Proxy Mobile IPv6), or client-based mobility protocols (as
>   Mobile IPv6), among others.  This document follows the former
>   approach, and proposes a solution based on Proxy Mobile IPv6 in which
>   mobility sessions are anchored at the last IP hop router (called
>   mobility anchor and access router).  The mobility anchor and access
>   router is an enhanced access router which is also able to operate as
>   local mobility anchor or mobility access gateway, on a per prefix
>   basis.  The document focuses on the required extensions to
>   effectively support simultaneously anchoring several flows at
>   different distributed gateways.
> 
>   This document introduces the concept of distributed logical
>   interface, which is a software construct that allows to easily hide
>   the change of anchor from the mobile node.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-bernardos-dmm-pmipv6-dlif/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-bernardos-dmm-pmipv6-dlif-01
> https://datatracker.ietf.org/doc/html/draft-bernardos-dmm-pmipv6-dlif-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-bernardos-dmm-pmipv6-dlif-01
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> ___
> 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] some test results of different network overlay methods

[Pablo Camarillo (pcamaril)]

Hi Tom,

Inline.

Cheers,
Pablo.
From: Tom Herbert 
Date: Sunday, 18 March 2018 at 16:28
To: "Pablo Camarillo (pcamaril)" 
Cc: dmm , Uma Chunduri 
Subject: Re: [DMM] some test results of different network overlay methods


On Sun, Mar 18, 2018, 1:40 PM Pablo Camarillo (pcamaril) 
> wrote:

Hi Tom, Kalyani,



If the SR processing of the two SIDs is done by the end host, then I believe 
the results for SR are obviously not valid.

Pablo,

Why isn't this valid?

What is the use case of an end linux host performing decapsulation or End SID 
processing?  By the time a packet reaches a Linux host terminating TCP it will 
contain only a single IP destination address == the host terminating the TCP 
session.

I expect that the only valuable use case to measure is encapsulation or 
insertion, see the  performance results 
https://irtf.org/anrw/2017/anrw17-final3.pdf for insert and encap on Linux.

If the end host is processing two SIDs, it means that you are doing twice SR 
processing. You will have an extra ‘End’ function processing, which involves 
updating the DA to the next segment, doing an IP lookup and forwarding.
Then you will restart and do again the processing. Overall, you do twice SR 
processing.

For example if I send  10 sids to a destination, all of which terminate on that 
destination, it will have to do SR END function processing 10 times.  This is 
true but there is no practical reason to do this.

In practice when host A sends a packet with 2 SIDs, one will be to host B and 
the next to host C.  Only B will do END function processing, C will simply 
receive the packet.  Therefore while your test is accurate it has no practical 
use.






Also in all the hardware-based routing platforms for which we have done interop 
https://tools.ietf.org/html/draft-filsfils-spring-srv6-interop-00#section-2, we 
have SRv6 running at linecard rate.



Note that I find this performance testing work interesting, and I’m willing to 
help you carry them. However, for next releases I would also consider 
leveraging projects like linux foundation fdio CSIT 
https://wiki.fd.io/view/CSIT/Description, in order to have a more methodical 
and accurate results (ILA has higher throughput than native IPv6 with a lower 
TPS).


To be clear, this is testing a real TCP stack and host terminating 
encapsulation (not just router performance). For this purpose the tests are 
methodical and accurate.
See above

The big difference in performance have a lot to do how well NICs deal with 
different encapsulations and EH in case of SR. The most interesting result, I 
think, is IPIP (and SR/IPIP) with drop in TPS. This indicates that device (in 
this case ixgbe) isn't getting 5-tuple hash for RSS. It's not parsing over 
headers to find ports for hash. Interestingly, it was able to parse into L4 
when just SR header is present. Capabilities for things like this will vary 
between NICs.

Indeed, this is very interesting. Thanks for pointing it out. I believe NICs 
providers will eventually fix this.

Tom




Thanks.



Cheers,

Pablo.


De:Tom Herbert >
Enviado:viernes, 16 de marzo de 2018 7:58 p. m.
Para:Uma Chunduri
Cc: dmm
Asunto: Re: [DMM] some test results of different network overlay methods

On Fri, Mar 16, 2018 at 12:40 PM, Uma Chunduri 
> wrote:
> Great work, Thank you Kalyani & Tom.
>
> 2 quick questions:
>
> 1.  I presume SR inline is just SRH with 2 SIDs as mentioned - didn't see the 
> topology used. Do intermediate nodes handle these SIDs, with pointer update 
> in SRH?

Two hosts connected back to back. SR processing done by end host.

> 2.  Also for Geneve  - it's IP4 encap and VNI no TLVs?
>
No TLVs. GUE uses RCO extension. Other than that all the variants
should be out of the box with no options set. Encapsulations are
v4/v4, SRv6 and ILA are all IPv6.

I'll post the all the configuration scripts to github once I have some time.

Tom


> --
> Uma C.
>
>
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Bogineni, Kalyani
> Sent: Friday, March 16, 2018 11:16 AM
> To: dmm >
> Subject: [DMM] some test results of different network overlay methods
>
>
> All:
>
> Here are some raw performance test results based on our understanding of the 
> different network overlay methods. We welcome discussion and comments.
>
> Kalyani and Tom
> ___
> 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

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] [E] Re: draft-bogineni-dmm-optimized-mobile-user-plane-00

[Behcet Sarikaya]

On Tue, Mar 20, 2018 at 11:47 AM, Sri Gundavelli (sgundave) <
sgund...@cisco.com> 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 
> Reply-To: "sarik...@ieee.org" 
> Date: Tuesday, March 20, 2018 at 3:43 AM
> To: Sri Gundavelli 
> Cc: "Bogineni, Kalyani" , Lyle
> Bertz , dmm 
>
> Subject: Re: [DMM] [E] Re: draft-bogineni-dmm-optimized-
> mobile-user-plane-00
>
>
>
> On Tue, Mar 20, 2018 at 11:28 AM, Sri Gundavelli (sgundave) <
> sgund...@cisco.com> wrote:
>
>> >  [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.
>>
>>
> 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  on behalf of "Bogineni, Kalyani" <
>> kalyani.bogin...@verizonwireless.com>
>> Date: Tuesday, March 20, 2018 at 3:14 AM
>> To: Lyle Bertz , dmm 
>> Subject: Re: [DMM] [E] Re: draft-bogineni-dmm-optimized-m
>> obile-user-plane-00
>>
>> Will MFA be proposed as an option
>> draft-gundavelli-dmm-mfa-00 [KB] I will let Sri answer this.
>>
>> ___
>> 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] [E] Re: draft-bogineni-dmm-optimized-mobile-user-plane-00

[Behcet Sarikaya]

On Tue, Mar 20, 2018 at 11:28 AM, Sri Gundavelli (sgundave) <
sgund...@cisco.com> wrote:

> >  [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.
>
>
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  on behalf of "Bogineni, Kalyani" <
> kalyani.bogin...@verizonwireless.com>
> Date: Tuesday, March 20, 2018 at 3:14 AM
> To: Lyle Bertz , dmm 
> Subject: Re: [DMM] [E] Re: draft-bogineni-dmm-optimized-m
> obile-user-plane-00
>
> Will MFA be proposed as an option
> draft-gundavelli-dmm-mfa-00 [KB] I will let Sri answer this.
>
> ___
> 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)"
 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" 
> 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

___
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] [E] Re: draft-bogineni-dmm-optimized-mobile-user-plane-00

[Lyle Bertz]

Kalyani,

Thanks so much.

Lyle

On Tue, Mar 20, 2018 at 11:14 AM, Bogineni, Kalyani <
kalyani.bogin...@verizonwireless.com> wrote:

> Lyle:
>
>
>
> Thank you for your comments. The document is still work-in-progress. The
> future revisions will address your comments.
>
>
>
>
>
> *From:* dmm [mailto:dmm-boun...@ietf.org] *On Behalf Of *Lyle Bertz
> *Sent:* Tuesday, March 20, 2018 6:57 AM
> *To:* dmm 
> *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
>
>
>
>
>
>
>
>
>
>
>
>
>
___
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] [E] Re: draft-bogineni-dmm-optimized-mobile-user-plane-00

[Sri Gundavelli (sgundave)]

>  [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 > on behalf of 
"Bogineni, Kalyani" 
>
Date: Tuesday, March 20, 2018 at 3:14 AM
To: Lyle Bertz >, dmm 
>
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.

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

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

[Bogineni, Kalyani]

Lyle:

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


From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Lyle Bertz
Sent: Tuesday, March 20, 2018 6:57 AM
To: dmm 
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






___
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

Re: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-14.txt

[Sri Gundavelli (sgundave)]

Authors:

This draft is under WGLC. We were not expecting you guys to post an update
during LC period.

Please let the WG know about the changes in version -18.

WG: Please post WGLC comments on version 13 and not on -14.


Thanks
Sri


On 3/19/18, 7:21 AM, "dmm on behalf of internet-dra...@ietf.org"
 wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>This draft is a work item of the Distributed Mobility Management WG of
>the IETF.
>
>Title   : On Demand Mobility Management
>Authors : Alper Yegin
>  Danny Moses
>  Kisuk Kweon
>  Jinsung Lee
>  Jungshin Park
>  Seil Jeon
>   Filename: draft-ietf-dmm-ondemand-mobility-14.txt
>   Pages   : 15
>   Date: 2018-03-19
>
>Abstract:
>   Applications differ with respect to whether they need IP session
>   continuity and/or IP address reachability.  The network providing the
>   same type of service to any mobile host and any application running
>   on the host yields inefficiencies.  This document describes a
>   solution for taking the application needs into account by selectively
>   providing IP session continuity and IP address reachability on a per-
>   socket basis.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-14
>https://datatracker.ietf.org/doc/html/draft-ietf-dmm-ondemand-mobility-14
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-ondemand-mobility-14
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>___
>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