Re: [DMM] New Liaison Statement, "CP-173160: New Study Item on User Plane Protocol in 5GC"

[Bogineni, Kalyani]

Sri:

Here is one edit in the last sentence to allow IETF to take feedback from 3GPP:

"Please let us know if you need any additional information. Also please provide 
any evaluation criteria that
could help us in progressing our work to support 5G."

Kalyani

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Monday, July 9, 2018 11:51 AM
To: Arashmid Akhavain ; dmm@ietf.org
Subject: [E] Re: [DMM] New Liaison Statement, "CP-173160: New Study Item on 
User Plane Protocol in 5GC"

Hi Arashmid/Kalyani,

Thank you both for your feedback.

Yes, we thought its better to keep the focus on problem statement and 
requirement analysis. We don’t want to prematurely high-light any solution 
documents to SDO. Which did not go through proper review process, as it will 
only result in confusing them.


> Having said that however, I think a general statement about proof of 
>concepts can help the cause.

The current text provides an high-level update and status on where the WG is 
going, and a also a pointer to all documents under review. I am personally not 
keen on making additional edits, unless you guys think the change is absolutely 
needed and will make a difference in CT4 discussion.
So, if you are keen on seeing any such changes, please propose the exact text. 
But, if you have no objections to the current response, we can let this go. In 
future liaisons we can have detailed technical exchanges.


Sri



On 7/9/18, 7:23 AM, "Arashmid Akhavain" 
wrote:

>Hi Sri,
>
>Thank you for your clarifying email. The POC draft talks about the SRv6 
>demos and I can see how it can be seen as a document advocating a 
>particular solution strategy.
>So, I agree that we should stay away from specific POCs and drafts in 
>the LS. Having said that however, I think a general statement about 
>proof of concepts can help the cause.
>
>At this point I think it is more important to discuss the GAPs in 
>existing system rather than focusing on different solutions. That's why 
>I really like what
>draft-hmm-dmm-5g-uplane-analysis-00 is trying to do.
>
>Cheers,
>Arashmid
>   
>
>> -Original Message-
>> From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
>> Sent: 08 July 2018 19:29
>> To: Arashmid Akhavain ; dmm@ietf.org
>> Subject: Re: New Liaison Statement, "CP-173160: New Study Item on 
>> User Plane Protocol in 5GC"
>> 
>> Hi Arashmid,
>> 
>> We were trying to avoid this debate on inclusion/exclusions of 
>>individual I-  D’s, but looks like we are just doing that. That is 
>>fine. Lets review the  situation.
>> 
>> The approach on what documents to be explicitly listed is based on 
>> the following principles.
>> 
>> #1 Provide references to DMM WG documents that have any relation to 
>>the  study item in 5GC.
>> #2 Include references to individual I-D’s that have done broader  
>>requirement/solution analysis/comparative study on the topic of mobile 
>>user  plane optimization; documents that are not advocating a specific 
>>solution.
>> We also wanted to apply the constraint of documents that have had  
>>substantial discussions in the working group. In other words, 
>>documents that  were reviewed by the WG and received significantly 
>>high number of  comments.
>> 
>> 
>> For #1: we have included draft-ietf-dmm-srv6-mobile-uplane-02.txt, as 
>>its a  WG document on track for standardization.
>> 
>> For #2: we have included draft-bogineni as there were many  
>>discussions/presentations/conference calls on that draft. We have also  
>>included draft-hmm-dmm-5g-uplane-analysis-00, but however this draft 
>>was  published recently and had near zero discussions in the WG. But 
>>given the  quality of the document and noting that its about 
>>requirement analysis and  as its not advocating a specific solution, 
>>we chose to keep this document in  the list.
>> 
>> We have not included any other I-D’s which have not had enough 
>>discussions  and which are solution specific documents. Not that we 
>>have not established  the draft applicability to the 3GPP study item. 
>>These include:
>> 
>> draft-auge-dmm-hicn-mobility-00,
>> draft-auge-dmm-hicn-mobility-deployment-options-00,
>> draft-camarillo-dmm-srv6-mobile-pocs-00,
>> draft-gundavelli-dmm-mfa-00
>> draft-homma-dmm-5gs-id-loc-coexistence-01,
>> 
>> 
>> 
>> Now, if this sounds unreasonable or unfair, we have two options.
>> 
>> #1 Remove references to all individual drafts and only include WG 
>> documents
>> #2: Include every single I-D (WG and non WG) documents.
>> 
>> 
>> All - Please comment.
>> 
>> 
>> 
>> Sri
>> 
>> 
>> 
>> 
>> 
>> 
>> On 7/8/18, 2:14 PM, "Arashmid Akhavain"
>> 
>> wrote:
>> 
>> >Hi Sri,
>> >Thank you for the reply. Pablo's draft is rather different as it 
>> >describes the two POCs addressing the mobile core data plane.
>> >Referencing the POCs in the LS can help put things into perspective 
>> >and sort of backs up all the analysis work that everyone have been 
>> >involved in 

[DMM] FW: [E] New Version Notification for draft-bogineni-dmm-optimized-mobile-user-plane-01.txt

[Bogineni, Kalyani]

Hi:

An updated version of the optimized mobile user plane document has been posted.
This could be sent to CT4 along with the reply to the LS.

Best Regards,
Kalyani and co-authors

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Friday, June 29, 2018 5:12 AM
To: Alberto Rodriguez-Natal ; Dino Farinacci 
; Tom Herbert ; Luca Muscariello 
; Bogineni, Kalyani ; 
Giovanna Carofiglio ; Jordan Auge ; 
Arashmid Akhavain ; Pablo Camarillo 
; Shunsuke Homma 
Subject: [E] New Version Notification for 
draft-bogineni-dmm-optimized-mobile-user-plane-01.txt


A new version of I-D, draft-bogineni-dmm-optimized-mobile-user-plane-01.txt
has been successfully submitted by Luca Muscariello and posted to the IETF 
repository.

Name:   draft-bogineni-dmm-optimized-mobile-user-plane
Revision:   01
Title:  Optimized Mobile User Plane Solutions for 5G
Document date:  2018-06-29
Group:  Individual Submission
Pages:  65
URL:   
http://www.ietf.org/id/draft-bogineni-dmm-optimized-mobile-user-plane-01.txt
Status:
https://datatracker.ietf.org/doc/draft-bogineni-dmm-optimized-mobile-user-plane/
Htmlized:   
https://tools.ietf.org/html/draft-bogineni-dmm-optimized-mobile-user-plane-01
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-bogineni-dmm-optimized-mobile-user-plane
Diff:
https://www.ietf.org/rfcdiff?url2=draft-bogineni-dmm-optimized-mobile-user-plane-01

Abstract:
   3GPP CT4 has approved a study item to study different mobility
   management protocols for potential replacement of GTP tunnels between
   UPFs (N9 Interface) in the 3GPP 5G system architecture.

   This document provides an overview of 5G system architecture in the
   context of N9 Interface which is the scope of the 3GPP CT4 study item
   [CP-173160-1], [TS.23.501-3GPP], [TS.23.502-3GPP], [TS.23.503-3GPP],
   [TS.29.244-3GPP], [TS.29.281-3GPP], [TS.38.300-3GPP], and
   [TS.38.401-3GPP].

   Architecture requirements for evaluation of candidate protocols are
   provided.  Optimization of the user plane can be in different ways -
   packet overhead, transport integration, etc.

   Several IETF protocols are considered for comparison: SRv6, LISP, ILA
   and several combinations of control plane and user plane protocols.


  


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.

The IETF Secretariat

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

[DMM] FW: [E] New Version Notification for draft-bogineni-dmm-optimized-mobile-user-plane-01.txt

[Bogineni, Kalyani]

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Friday, June 29, 2018 5:12 AM
To: Alberto Rodriguez-Natal ; Dino Farinacci 
; Tom Herbert ; Luca Muscariello 
; Bogineni, Kalyani ; 
Giovanna Carofiglio ; Jordan Auge ; 
Arashmid Akhavain ; Pablo Camarillo 
; Shunsuke Homma 
Subject: [E] New Version Notification for 
draft-bogineni-dmm-optimized-mobile-user-plane-01.txt


A new version of I-D, draft-bogineni-dmm-optimized-mobile-user-plane-01.txt
has been successfully submitted by Luca Muscariello and posted to the IETF 
repository.

Name:   draft-bogineni-dmm-optimized-mobile-user-plane
Revision:   01
Title:  Optimized Mobile User Plane Solutions for 5G
Document date:  2018-06-29
Group:  Individual Submission
Pages:  65
URL:
http://www.ietf.org/id/draft-bogineni-dmm-optimized-mobile-user-plane-01.txt
Status:
[KB] 
 
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dbogineni-2Ddmm-2Doptimized-2Dmobile-2Duser-2Dplane_=DwICaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiSODh8aDRjdCeGgd9Mzr2tsDA8-g976yWB1sPbdMo=UciidxMh2XZ1Dlmw_mft2XPXu_mzSJipGaqlWwqiPgc=2Lq25W90_26NoOC9TwU6ubIFThgJhU8WSVpLL3S5aNY=
Htmlized:   
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbogineni-2Ddmm-2Doptimized-2Dmobile-2Duser-2Dplane-2D01=DwICaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiSODh8aDRjdCeGgd9Mzr2tsDA8-g976yWB1sPbdMo=UciidxMh2XZ1Dlmw_mft2XPXu_mzSJipGaqlWwqiPgc=g2EETkep5Jt11cquL6Dfi2cg1BsqDJjyFkGuwagU91U=
Htmlized:   
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dbogineni-2Ddmm-2Doptimized-2Dmobile-2Duser-2Dplane=DwICaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiSODh8aDRjdCeGgd9Mzr2tsDA8-g976yWB1sPbdMo=UciidxMh2XZ1Dlmw_mft2XPXu_mzSJipGaqlWwqiPgc=G__A129y3f2fi2cSVYbMSxnXnqhegNEuoTUyCMoi8So=
Diff:   
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dbogineni-2Ddmm-2Doptimized-2Dmobile-2Duser-2Dplane-2D01=DwICaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiSODh8aDRjdCeGgd9Mzr2tsDA8-g976yWB1sPbdMo=UciidxMh2XZ1Dlmw_mft2XPXu_mzSJipGaqlWwqiPgc=3w6pxL4elqGo-pq49qDe04LywFE4mV6-k7I2i8b0QuI=

Abstract:
   3GPP CT4 has approved a study item to study different mobility
   management protocols for potential replacement of GTP tunnels between
   UPFs (N9 Interface) in the 3GPP 5G system architecture.

   This document provides an overview of 5G system architecture in the
   context of N9 Interface which is the scope of the 3GPP CT4 study item
   [CP-173160-1], [TS.23.501-3GPP], [TS.23.502-3GPP], [TS.23.503-3GPP],
   [TS.29.244-3GPP], [TS.29.281-3GPP], [TS.38.300-3GPP], and
   [TS.38.401-3GPP].

   Architecture requirements for evaluation of candidate protocols are
   provided.  Optimization of the user plane can be in different ways -
   packet overhead, transport integration, etc.

   Several IETF protocols are considered for comparison: SRv6, LISP, ILA
   and several combinations of control plane and user plane protocols.


  


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.

The IETF Secretariat

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

Re: [DMM] IETF102 - Call for agenda items

[Bogineni, Kalyani]

Dapeng, Sri:

Can you include this in the agenda?

Topic Name: Optimized Mobile User Plane Solutions for 5G 
Presenter Name: Kalyani Bogineni and others
Time: 30 minutes
Draft Reference: draft-bogineni-dmm-optimized-mobile-user-plane-solutions.txt

Kalyani

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Thursday, May 3, 2018 5:32 PM
To: dmm@ietf.org
Subject: [E] [DMM] IETF102 - Call for agenda items

The DMM working group is planning to meet in IETF 102, week of 16th of July, 
2018 at Montreal. We currently have requested for one meeting, which is a 2.5 
hour slot.

We realize in IETF101 we had many items with a fully packaged agenda, and could 
not allocate enough time for any of the topics. For this meeting, we want to 
avoid that problem by asking for an additional meeting slot, but we want to be 
sure there are enough items for discussion before we lock the resources.

So, if you need a presentation slot, please send your request to the chairs (as 
a response to this email) with the following information. We still have time 
and so its not required that you need a published I-D, but do let us know in 
the next few days if you are planning to make a presentation. 


  ---
>Topic Name:
>Presenter Name:
>Time:
>Draft Reference: (Optional)
>---

Regards
Dapeng & Sri
>>
>

___
dmm mailing list
dmm@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dmm=DwICAg=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=3YmCyVAoiC_ugQMmv8VcJoITk2D8QR4ZHgE34zzz0CY=AHrommWakT2klf1og05nny7we_JVQm8flSZ8ZZ7ASgw=

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

Re: [DMM] New Liaison Statement, "CP-173160: New Study Item on User Plane Protocol in 5GC"

[Bogineni, Kalyani]

Sri:

Providing information on the various protocols options in IETF in a 
comprehensive way will be useful not only to
3GPP but also to ETSI/ITU which is also working on NG protocols as pointed out 
by some folks at IETF #101. Each SDO
can make use of that information as needed.

Kalyani

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Friday, April 13, 2018 7:06 PM
To: Arashmid Akhavain ; dmm@ietf.org
Subject: [E] Re: [DMM] New Liaison Statement, "CP-173160: New Study Item on 
User Plane Protocol in 5GC"

Hi Arashmid,





I am not seeing a relation to the LS Response and the July 2018 deadline

that you are referring to. I think there is some disconnect here. Lets

review what we the chairs are thinking.





1. The work in IETF related to User-Plane optimizations will continue for

many months. When there is a LS Request, we will send a LS response. We

will use LS query/response as a means to gather feedback from the SDO

community, and provide an update on the status of all the documents in DMM

at this time. The status includes update on WG documents and individual

I-D’s under discussions.



2. We are not going with the assumption that there will only be a single

LS request/response for this entire UP Study, but we will keep exchanging

information based on the progress, and whenever we need additional

clarifications. 



3. There are multiple proposals in IETF. As we have indicated in the past,

we are not going to recommend THE single solution and put it on a platter

for 3GPP consumption, but rather the focus will be on characterization of

each approach that we take up in DMM WG.



Now, keeping this in mind, if there is a good reason not to send the LS

Response now, delay it by some time, or if we believe there is nothing to

respond, we can discuss and decide to do just that. Hope this makes sense.



Bottomline, all feedback is welcome!





Sri 









On 4/13/18, 1:35 PM, "Arashmid Akhavain" 

wrote:



>Hi Sri,

>Thank you for getting back to us. They listed a few dates there. The

>final deadline is I guess July 2018.

>Are we targeting anything earlier?

>

>Arashmid 

>

>> -Original Message-

>> From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]

>> Sent: 13 April 2018 12:47

>> To: Arashmid Akhavain ; dmm@ietf.org

>> Subject: Re: New Liaison Statement, "CP-173160: New Study Item on User

>> Plane Protocol in 5GC"

>> 

>> Hi Arashmid,

>> 

>> We provide the status of the related work items in DMM, and seek any

>> clarifications on their CT4 work. Key thing from our point of view is

>>to get

>> their feedback on the work we are doing and try to meet their timelines.

>> 

>> Sri

>> 

>> 

>> On 4/12/18, 10:53 AM, "Arashmid Akhavain"

>> 

>> wrote:

>> 

>> >Hi Sri,

>> >

>> >Any idea what the plan is once we pass this information to CT4?

>> >

>> >Arashmid

>> >

>> >> -Original Message-

>> >> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli

>> >> (sgundave)

>> >> Sent: 12 April 2018 12:47

>> >> To: dmm@ietf.org

>> >> Subject: Re: [DMM] New Liaison Statement, "CP-173160: New Study Item

>> >> on User Plane Protocol in 5GC"

>> >>

>> >> Please review and post your comments. Chairs will draft a response

>> >>for WG  review.

>> >>

>> >> Sri

>> >>

>> >>

>> >> On 4/11/18, 11:16 AM, "Liaison Statement Management Tool"

>> >> 

>> >> wrote:

>> >>

>> >> >Title: CP-173160: New Study Item on User Plane Protocol in 5GC

>> >> >Submission Date: 2018-04-11 URL of the IETF Web page:

>> >> >https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_liaison_1572_=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=HzWn613RHnz3I2LqLeSynqPwGlz9DKPBbb8gsskSANw=9CURIbNAYuWQYF-7wjuFSRJTLB5XX_6f8C3FJHODsRA=

>> >> >Please reply by 2018-07-20

>> >> >From: Satoru Matsushima 

>> >> >To: Sri Gundavelli ,Dapeng Liu

>> >> >

>> >> >Cc: Dapeng Liu ,Terry Manderson

>> >> >,Distributed Mobility Management

>> >> >Discussion List ,Sri Gundavelli

>> >> >,Suresh Krishnan  Response

>> Contacts:

>> >> >georg.mayer.hua...@gmx.com,3gppliai...@etsi.org

>> >> >Technical Contacts:

>> >> >Purpose: For action

>> >> >

>> >> >Body: 1. Overall Description:

>> >> >3GPP working group of CT4 (Core and Terminal) would like to inform

>> >> >the IETF that CT4 has initiated a study item on user plane protocol

>> >> >in 5GC for Release-16 of 5G phase 2 (see CP-173160).

>> >> >

>> >> >Based on the outcome from the IETF / 3GPP Coordination meeting at

>> >> >IETF#100, 3GPP CT4 got aware that IETF DMM 

Re: [DMM] [E] Re: New Liaison Statement, "CP-173160: New Study Item on User Plane Protocol in 5GC"

[Bogineni, Kalyani]

Charlie:

The study item in CT4 was related to N9 interface and hence the focus of the 
initial draft was on UPF and SMF.
Since then, the different proponents have provided details beyond N9. The I-D 
can potentially document the details 
Beyond N9 (to N3 and for supporting services based interfaces to UPF and the 
mapping system).

Kalyani

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Charlie Perkins
Sent: Friday, April 13, 2018 5:33 PM
To: Distributed Mobility Management Discussion List 
Subject: [E] Re: [DMM] New Liaison Statement, "CP-173160: New Study Item on 
User Plane Protocol in 5GC"

Hello folks,

The liaison statement seems to suggest that the existing work in 3GPP is either 
to develop the 5G architecture, or to see how well the current evolution of 
GTP-U fits the 5G architecture as developed.  It is natural to also expect that 
the thinking about the 5G architecture has been influenced by the known 
behavior and features of GTP-U.  The further guidance in the Liaison statement 
seems to recommend familiarity with 23.50{1,2,3} and 33.501.

I've had a look at some of the documents, and they can be pretty heavy sledding.

draft-bogineni-dmm-optimized-mobile-user-plane-00 is somewhat more compact.  
And yet it also focuses a lot of attention on SMF as well as UPF.

Is the IETF expected to make comments only about UPF?

Some previous discussion suggested that whatever UPF would be developed in the 
IETF, needed to be independent of the control plane.  But presumably 3GPP would 
like a UPF that offered the control features that are required for SMF as well. 
 That's a lot of additional features.  It seems to place additional constraints 
on whether or not an IETF user-plane protocol would be useful for 3GPP.

If the task is only to provide information to 3GPP about what [dmm] is doing, 
then the task is manageable.  But if we are also required to describe how an 
IETF user-plane protocol meets or does not meet the requirements in 
{2,3}3.50{1,2,3} -- that's a difficult task. Moreover, the charging framework 
has usually been considered outside the jurisdiction of IETF if I remember 
correctly -- something about anti-trust.

Regards,
Charlie P.



On 4/11/2018 11:16 AM, Liaison Statement Management Tool wrote:
> Title: CP-173160: New Study Item on User Plane Protocol in 5GC 
> Submission Date: 2018-04-11 URL of the IETF Web page: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.
> org_liaison_1572_=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomB
> TQ=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&
> m=SDlSTr5K3kYW4bZNdVjPCG1QlHoW1FwCy8zhuckWENY=MC1hRj5vHFkbqU9xmuUN4j
> OnJNbQQYGZiLsztz4irPc=
> Please reply by 2018-07-20
> From: Satoru Matsushima 
> To: Sri Gundavelli ,Dapeng Liu 
> 
> Cc: Dapeng Liu ,Terry Manderson 
> ,Distributed Mobility Management Discussion 
> List ,Sri Gundavelli ,Suresh 
> Krishnan  Response Contacts: 
> georg.mayer.hua...@gmx.com,3gppliai...@etsi.org
> Technical Contacts:
> Purpose: For action
>
> Body: 1. Overall Description:
> 3GPP working group of CT4 (Core and Terminal) would like to inform the IETF 
> that CT4 has initiated a study item on user plane protocol in 5GC for 
> Release-16 of 5G phase 2 (see CP-173160).
>
> Based on the outcome from the IETF / 3GPP Coordination meeting at IETF#100, 
> 3GPP CT4 got aware that IETF DMM WG is currently working on a possible 
> candidate protocol for the 3GPP 5G user plane protocol.
>
> 3GPP CT4 wants to emphasize that currently there is no related evaluation 
> ongoing in 3GPP. Nevertheless, a study item was approved for such a study to 
> start in the second half of 2018. The study will evaluate between existing 
> solutions within 3GPP and other protocols, based on the Release 16 stage 2 
> (system architecture) requirements.
>
> 3GPP CT4 would like to point IETF DMM to the following specifications on 
> GTP-U. The Release 16 stage 2 requirements are not yet known but it is worth 
> looking at latest GTP-U spec which will be evaluated through the study as the 
> existing protocol.
>
> • [1] 3GPP TS 29.281 (V15.1.0): GPRS Tunnelling Protocol User Plane 
> (GTPv1-U)
>
>
> Following technical report provides information of how 3GPP considered GTP-U 
> apply to user plane of 5G_ph1:
>
> • [2] 3GPP TR 29.891 (V15.0.0): 5G System – Phase 1; CT4 Aspects
>
>
> Furthermore, 3GPP would like to give the following general guidance to IETF 
> DMM, regarding user plane transport within 3GPP networks. These are technical 
> specifications that include also the necessary information to understand 
> which architectural, QoS, security-related and high-level requirements GTP-U 
> currently complies to within 5G_ph1.
>
> • [3] 3GPP TS 23.501 (V15.0.0): System 

Re: [DMM] New Liaison Statement, "CP-173160: New Study Item on User Plane Protocol in 5GC"

[Bogineni, Kalyani]

Sri:

When do you intend to send the response back? The next CT4 meeting is 21st ­ 
25th May 2018.
We could send a version of the document 
draft-bogineni-dmm-optimized-mobile-user-plane 
and see if CT4 has comments. We are working on a revision of the document based 
on the 
comments/feedback received at IETF #101. 

Kalyani

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Thursday, April 12, 2018 12:47 PM
To: dmm@ietf.org
Subject: [E] Re: [DMM] New Liaison Statement, "CP-173160: New Study Item on 
User Plane Protocol in 5GC"

Please review and post your comments. Chairs will draft a response for WG 
review.

Sri


On 4/11/18, 11:16 AM, "Liaison Statement Management Tool" 
wrote:

>Title: CP-173160: New Study Item on User Plane Protocol in 5GC 
>Submission Date: 2018-04-11 URL of the IETF Web page: 
>https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.o
>rg_liaison_1572_=DwIF-g=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ
>=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=4
>DlJ00EUx2xtO4XafGCV4RwsBOCR_MV1E2kq0tzFyVA=Dx8oaGf7w9gVoXKLOaqcERnUCO
>uTA5p11KN5X7gM16U=
>Please reply by 2018-07-20
>From: Satoru Matsushima 
>To: Sri Gundavelli ,Dapeng Liu 
>
>Cc: Dapeng Liu ,Terry Manderson 
>,Distributed Mobility Management Discussion 
>List ,Sri Gundavelli ,Suresh Krishnan 
> Response Contacts: 
>georg.mayer.hua...@gmx.com,3gppliai...@etsi.org
>Technical Contacts:
>Purpose: For action
>
>Body: 1. Overall Description:
>3GPP working group of CT4 (Core and Terminal) would like to inform the 
>IETF that CT4 has initiated a study item on user plane protocol in 5GC 
>for Release-16 of 5G phase 2 (see CP-173160).
>
>Based on the outcome from the IETF / 3GPP Coordination meeting at 
>IETF#100, 3GPP CT4 got aware that IETF DMM WG is currently working on a 
>possible candidate protocol for the 3GPP 5G user plane protocol.
>
>3GPP CT4 wants to emphasize that currently there is no related 
>evaluation ongoing in 3GPP. Nevertheless, a study item was approved for 
>such a study to start in the second half of 2018. The study will 
>evaluate between existing solutions within 3GPP and other protocols, 
>based on the Release
>16 stage 2 (system architecture) requirements.
>
>3GPP CT4 would like to point IETF DMM to the following specifications 
>on GTP-U. The Release 16 stage 2 requirements are not yet known but it 
>is worth looking at latest GTP-U spec which will be evaluated through 
>the study as the existing protocol.
>
>€  [1] 3GPP TS 29.281 (V15.1.0): GPRS Tunnelling Protocol User Plane
>(GTPv1-U)
>
>
>Following technical report provides information of how 3GPP considered 
>GTP-U apply to user plane of 5G_ph1:
>
>€  [2] 3GPP TR 29.891 (V15.0.0): 5G System ­ Phase 1; CT4 Aspects
>
>
>Furthermore, 3GPP would like to give the following general guidance to 
>IETF DMM, regarding user plane transport within 3GPP networks. These 
>are technical specifications that include also the necessary 
>information to understand which architectural, QoS, security-related 
>and high-level requirements GTP-U currently complies to within 5G_ph1.
>
>€  [3] 3GPP TS 23.501 (V15.0.0): System Architecture for the 5G System
>€  [4] 3GPP TS 23.502 (V15.0.0): Procedures for the 5G System
>€  [5] 3GPP TS 23.503 (V15.0.0): Policy and Charging Framework for the 5G
>System
>€  [6] 3GPP TS 33.501 (V0.6.0): Security Architecture (work in progress)
>
>2. Actions:
>To IETF DMM:
>ACTION:CT4 respectfully asks IETF DMM to provide any information that
>may be relevant to the above CT4 work by July 2018.
>
>
>3. Date of Next CT and CT4 Meetings:
>CT4#83 26th Feb ­ 2nd Mar 2018 Montreal, CAN
>CT#79  19th ­ 20th Mar 2018Chennai, India
>CT4#84 16th ­ 20th April 2018  Kunming, China
>CT4#85 21st ­ 25th May 2018Osaka, Japan
>CT#80  11th ­ 12th June 2018   La Jolla, USA
>CT4#85-bis   9th ­13th July 2018   TBD, France
>CT4#86 20st ­ 24th Aug 2018TBD, USA
>Attachments:
>
>CP-180116
>
>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_lib_d
>t_documents_LIAISON_liaison-2D2018-2D04-2D11-2D3gpp-2Dtsgc=DwIF-g=u
>dBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiSODh8aDRjdCeGgd9MznLHMY
>KgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=4DlJ00EUx2xtO4XafGCV4RwsBOCR_M
>V1E2kq0tzFyVA=OqWwMzQ6eW0MRMWDEiwEAl3UJqJHOQB3t0zh4ouqMX8=
>t-ct4-dmm-cp-173160-new-study-item-on-user-plane-protocol-in-5gc-attach
>men
>t-1.doc
>

___
dmm mailing list
dmm@ietf.org

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] [E] New Version Notification for draft-bogineni-dmm-optimized-mobile-user-plane-00.txt

[Bogineni, Kalyani]

All:

The document has provided an overview of the 3GPP 5G architecture with focus on 
N9 interface.
Several IETF protocol candidates have been included in this white paper. The 
authors would
like to get comments/discussion on the document so that the evaluation of the 
proposals can be
done.

A conference call will be held on Wednesday 14th March from 10:00 AM - 11:30 AM 
US ET.


-- Do not delete or change any of the following text. --


Join WebEx 
meeting<https://verizonone.webex.com/verizonone/j.php?MTID=mea214c00b8123f66b665d420d4f98d0a>
Meeting number (access code): 597 039 434
Meeting password: 7326kb


Join from a video system or application
Dial 597039...@verizonone.webex.com<sip:597039...@verizonone.webex.com>

Join by phone
+1-800-365-8460 US Toll Free
+1-210-795-0492 US San Antonio Toll
Global call-in 
numbers<https://verizonone.webex.com/verizonone/globalcallin.php?serviceType=MC=650601647=1>
  |  Toll-free calling 
restrictions<https://www.webex.com/pdf/tollfree_restrictions.pdf>




-Original Message-
From: Bogineni, Kalyani
Sent: Monday, March 5, 2018 6:14 PM
To: dmm@ietf.org; i...@ietf.org
Cc: Bogineni, Kalyani <kalyani.bogin...@verizonwireless.com>; Arashmid Akhavain 
<arashmid.akhav...@huawei.com>; Tom Herbert <t...@quantonium.net>; Alberto 
Rodriguez Natal (natal) <na...@cisco.com>; Dino Farinacci <farina...@gmail.com>
Subject: FW: [E] New Version Notification for 
draft-bogineni-dmm-optimized-mobile-user-plane-00.txt



A new version of I-D, draft-bogineni-dmm-optimized-mobile-user-plane-00.txt
has been successfully submitted by Tom Herbert and posted to the IETF 
repository.

Name:   draft-bogineni-dmm-optimized-mobile-user-plane
Revision:   00
Title:  Optimized Mobile User Plane Solutions for 5G
Document date:  2018-03-05
Group:  Individual Submission
Pages:  39
URL:   
https://www.ietf.org/id/draft-bogineni-dmm-optimized-mobile-user-plane-00.txt


Abstract:
   3GPP CT4 has approved a study item to study different mobility
   management protocols for potential replacement of GTP tunnels between
   UPFs (N9 Interface) in the 3GPP 5G system architecture.

   This document provides an overview of 5G system architecture in the
   context of N9 Interface which is the scope of the 3GPP CT4 study item
   [23501, 23502, 23503, 23203, 29244, 29281, 38300, 38401]. The
   requirements for the network functions and the relevant interfaces
   are provided.

   Reference scenarios and criteria for evaluation of various IETF
   protocols are provided.

   Several IETF protocols are considered for comparison: SRv6, LISP, ILA
   and several combinations of control plane and user plane protocols.




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.

The IETF Secretariat



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

[DMM] FW: [E] New Version Notification for draft-bogineni-dmm-optimized-mobile-user-plane-00.txt

[Bogineni, Kalyani]

A new version of I-D, draft-bogineni-dmm-optimized-mobile-user-plane-00.txt
has been successfully submitted by Tom Herbert and posted to the IETF 
repository.

Name:   draft-bogineni-dmm-optimized-mobile-user-plane
Revision:   00
Title:  Optimized Mobile User Plane Solutions for 5G
Document date:  2018-03-05
Group:  Individual Submission
Pages:  39
URL:   
https://www.ietf.org/id/draft-bogineni-dmm-optimized-mobile-user-plane-00.txt


Abstract:
   3GPP CT4 has approved a study item to study different mobility
   management protocols for potential replacement of GTP tunnels between
   UPFs (N9 Interface) in the 3GPP 5G system architecture.

   This document provides an overview of 5G system architecture in the
   context of N9 Interface which is the scope of the 3GPP CT4 study item
   [23501, 23502, 23503, 23203, 29244, 29281, 38300, 38401]. The
   requirements for the network functions and the relevant interfaces
   are provided.

   Reference scenarios and criteria for evaluation of various IETF
   protocols are provided.

   Several IETF protocols are considered for comparison: SRv6, LISP, ILA
   and several combinations of control plane and user plane protocols.


  


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.

The IETF Secretariat

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

Re: [DMM] IETF101 - Call for agenda items

[Bogineni, Kalyani]

Sri:

Can you include this in the agenda?

Topic Name: Optimized Mobile User Plane Solutions for 5G
Presenter Name: Kalyani Bogineni
Time: 30 minutes
Draft Reference: draft-bogineni-dmm-optimized-mobile-user-plane-solutions-xy.txt

Kalyani

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Friday, February 23, 2018 7:44 PM
To: dmm@ietf.org
Subject: [E] Re: [DMM] IETF101 - Call for agenda items

Gentle reminder. 

The DMM WG scheduled is to meet in London, on Tuesday; 15:50-18:20; Afternoon 
session II.

https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_meeting_101_agenda.html=DwICAg=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=OTSVgI3ozPhs0c_LOcx1PVChX2jyMh1y88CmUR34HQs=lYub_Nr7BCAucf6sLruhiltVbjxQQqjGoQ5cBvaVxNY=

Please send your proposals that you want to be included in the agenda.


Sri



On 2/7/18, 1:16 PM, "dmm on behalf of Sri Gundavelli (sgundave)"
 wrote:

>The DMM working group is planning to meet in IETF 101, at London. If 
>you need a presentation slot, please send your request to the chairs 
>with the following information.
>
>
>Topic Name:
>Presenter Name:
>Time:
>Draft Reference:
>
>
>Thanks!
>Dapeng & Sri
>
>
>
>>
>
>___
>dmm mailing list
>dmm@ietf.org
>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailm
>an_listinfo_dmm=DwICAg=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&
>r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=OT
>SVgI3ozPhs0c_LOcx1PVChX2jyMh1y88CmUR34HQs=aHD_lLO6FH_eeWxMo1COnoB44JL
>m1w359nC6QQzWwBg=

___
dmm mailing list
dmm@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dmm=DwICAg=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=OTSVgI3ozPhs0c_LOcx1PVChX2jyMh1y88CmUR34HQs=aHD_lLO6FH_eeWxMo1COnoB44JLm1w359nC6QQzWwBg=

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

[DMM] Revised white paper for optimized mobile user plane solutions for 5G

[Bogineni, Kalyani]

Here is the revised version of the white paper based on the comments received 
on last week's call.

-  Architecture diagrams for roaming and non-roaming scenarios as well 
as non-roaming architecture

for multiple PDU sessions and concurrent access to 2 data networks

-  UPF and N9 requirements

-  Table for evaluation of protocols against requirements

-  Updated ILA section from Tom (proponents will be giving text for 
other protocols)

Please let me know any comments.

Next call will be on 20th February 9:30 - 11:00 AM UE ET.

Kalyani






draft-bogineni-dmm-optimized-mobile-user-plane-solutions-xy2.docx
Description: draft-bogineni-dmm-optimized-mobile-user-plane-solutions-xy2.docx
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [E] [Ila] Non-mobility functions in Uplane [was Re: review comments on ] draft-ietf-dmm-srv6-mobile-uplane-00.txt]

[Bogineni, Kalyani]

Response inline.

-Original Message-
From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Satoru Matsushima
Sent: Friday, February 9, 2018 3:53 AM
To: Bogineni, Kalyani <kalyani.bogin...@verizonwireless.com>
Cc: i...@ietf.org; dmm <dmm@ietf.org>
Subject: [E] [Ila] Non-mobility functions in Uplane [was Re: review comments on 
] draft-ietf-dmm-srv6-mobile-uplane-00.txt]

Kalyani,
# Subject changed.

> 
> Maybe you can see SRv6 mobile uplane as a set of SRv6 functions like a SRv6 
> profile for mobile with some augment.
> 
> When it comes to service function type UPF, you name it. Following draft 
> exhibits how service chain can be done by SRv6:
> [KB] I think these are non-mobility functions as being discussed on the email 
> thread with Marco Liebsch.


I saw that discussion. Non-mobility functions of which deployed on SGi/Gi-LAN 
types can still be considered as functions deployed in N6.
IMO I couldn’t find that assumption in TS23.501. So it would be a clarification 
point whether those type of UP functions can be deployed within mobility 
management data path programmed by SMF utilizing (multiple) N9.

Thought?
[KB] My colleague in SA2 pointed me to section 5.8 in 23.501. 

Cheers,
--satoru
___
ila mailing list
i...@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ila=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=Lfncf6GKwV3VXzMDab1Zrt4pS5e7aPPp71q5GG4KJoA=-oaS94clL2rlhMkX3t5-vZnam6do2O_1QFL8qMP4u0g=
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [Ila] [E] Re: review comments on ] draft-ietf-dmm-srv6-mobile-uplane-00.txt

[Bogineni, Kalyani]

Satoru:

Comments inline.

-Original Message-
From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com] 
Sent: Friday, February 9, 2018 3:25 AM
To: Bogineni, Kalyani <kalyani.bogin...@verizonwireless.com>
Cc: i...@ietf.org; dmm <dmm@ietf.org>
Subject: Re: [Ila] [E] Re: review comments on ] 
draft-ietf-dmm-srv6-mobile-uplane-00.txt

Hello Kalyani,

> 
> When you see UPF specifically it should be controlled by SMF through N4, they 
> are not the UPFs.
> But you might see them as UPFs if a SMF doesn’t control them directly but the 
> SMF can put the sessions to it through some other means.
> 3GPP SA2 has studied on that case (ETSUN). We consider how SMF deal with that 
> case and SRv6 may help to solve the issues to it in simpler way.
> Please let me know if you are interested in.
> [KB] is there a TR for ETSUN that I can read?

You can read it later on this September. See 
https://urldefense.proofpoint.com/v2/url?u=https-3A__portal.3gpp.org_ngppapp_CreateTdoc.aspx-3Fmode-3Dview-26contributionUid-3DSP-2D170743=DwIFaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=A4gJxIMQxDhuwbITGRX_eHAfWF36yy799w_bFx5TDFc=ZNR28OMiy-m_kDk3BNz7y8KuA-bfdBBr2HeRt8WQl5c
[KB] Thank you

> 
> [KB] I think your document needs to separate out 3 architectures: one for 4G 
> - SGW/PGW; one for 4G - CUPS; and one for 5G - UPF.

If you mean SRv6 Mobile Uplane draft, it is already a WG document, not my 
draft. So I’d collect opinions on this from WG. I’m sorry for that.
As a co-author of the draft, I’m afraid I disagree. SRv6 Mobile Uplane draft 
specifies SRv6 functions for mobile user plane, which should be architecture 
agnostic.

[KB] Sections 7.2, 7.3 refer to 3GPP terminology like eNB, SGW, PGW. My comment 
was suggesting that you include 5G terminology and CUPS terminology 
as well so it is clear how your proposal can be used in various scenarios.

> 
> [KB] I am also still not clear if the blue icons (which I think represent 
> IP/MPLS nodes) in your slides are included in SRv6 architecture or not.

I put some text what those icons indicate. Please find them in the slides. The 
blue icons represent IPv6 or SRv6 node.
[KB] Seems like the IPv6/SRv6 nodes do not interact with SMF. Is that the 
intent? 

Cheers,
--satoru

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

Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Bogineni, Kalyani]

Uma - It will support mobility scenarios similar to what SGW/PGW support in 4G. 
And will also support
local access to the DN.
Kalyani

From: Uma Chunduri [mailto:uma.chund...@huawei.com]
Sent: Thursday, February 8, 2018 9:13 PM
To: Bogineni, Kalyani <kalyani.bogin...@verizonwireless.com>; Sri Gundavelli 
(sgundave) <sgund...@cisco.com>; Marco Liebsch <marco.lieb...@neclab.eu>; Dino 
Farinacci <farina...@gmail.com>
Cc: i...@ietf.org; dmm <dmm@ietf.org>
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

Kalyani -

In-line [Uma]:

--
Uma C.

From: Bogineni, Kalyani [mailto:kalyani.bogin...@verizonwireless.com]
Sent: Thursday, February 08, 2018 6:07 PM
To: Uma Chunduri <uma.chund...@huawei.com<mailto:uma.chund...@huawei.com>>; Sri 
Gundavelli (sgundave) <sgund...@cisco.com<mailto:sgund...@cisco.com>>; Marco 
Liebsch <marco.lieb...@neclab.eu<mailto:marco.lieb...@neclab.eu>>; Dino 
Farinacci <farina...@gmail.com<mailto:farina...@gmail.com>>
Cc: i...@ietf.org<mailto:i...@ietf.org>; dmm <dmm@ietf.org<mailto:dmm@ietf.org>>
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt


Uma:

The goal of the white paper is to understand how each of the proposals impact 
N3, N4, SMF and gNB as is listed in Section of the white paper.
[Uma]: Absolutely. I got that. But I am not asking about the whitepaper below.
I am not getting which mobility scenario is covered by ILA 
proposal in the subject line if you don't include N3?


Here is the extract from Section 4 of the CT4 study item. They say that 
coordination with other working groups will be done as needed. So
documenting the proposals is important.


- from CT4 Study item 

As CT4 is not responsible for selecting the user plane protocol in the RAN 
(e.g. N3, F1-U), and since the user plane protocol in the 5GC cannot be decided 
irrespectively of the user plane protocol supported in the RAN, the study will 
have to involve coordination with RAN3.

Coordination will also be required with CT3 for potential impacts on N6, and 
with SA2 if the work has possible impacts on the stage 2 specifications.

-

Kalyani

From: Uma Chunduri [mailto:uma.chund...@huawei.com]
Sent: Thursday, February 8, 2018 8:07 PM
To: Sri Gundavelli (sgundave) <sgund...@cisco.com<mailto:sgund...@cisco.com>>; 
Bogineni, Kalyani 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>;
 Marco Liebsch <marco.lieb...@neclab.eu<mailto:marco.lieb...@neclab.eu>>; Dino 
Farinacci <farina...@gmail.com<mailto:farina...@gmail.com>>
Cc: i...@ietf.org<mailto:i...@ietf.org>; dmm <dmm@ietf.org<mailto:dmm@ietf.org>>
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

Hi Tom, Kalyani -

I fully agree what Sri said below.

>From Section 7.2 of the subject line:


 ---> --->--->
DN to ILA-R  ILA-R to ILA-N   ILA-N to gNB gNB to UE
   ++   ++   ++   ++
   | Application|   | Application|   | Application|   | Application|
   ++   ++   ++   ++
   | L4 |   | L4 |   | L4 |   | L4 |
   ++   ++   ++   ++
   |IPv6|   | IPv6 (ILA) |   |IPv6|   |  PDU Layer |
   ++ | ++ | ++   ++
   | L2 | | | L2 | | |   GTP-U|   | AN Protocol|
   ++ | ++ | ++   |   Layers   |
  || |   UDP/IP   |   ||
 N6   <--N9 -->   N3 ++   ++
 |L2  |
 ++

If this were to be nextgen and seeking key benefits of ID/LOCs, I strongly 
suggest changing the content of the draft to make this fully anchorless i.e., 
including N3 else I am not seeing *any mobility* scenario  that is being solved 
by ILA.

As it stands - eNB/gNB mobility would be taken care by S1U/N3. Meaning both X2 
based and S1 based handovers/mobility (used 4G terminology, but I meant 
equivalent interfaces) is out of the scope for ILA.

If you were to bring in transformation concept (tunnel-free concept) or ILA-N 
it has to be on gNB not UPF (not even staging BP UPF).


Please tell me if my understanding is incorrect here. I have few more questions 
on the draft and shall wait.

--
Uma C.

From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Thursday, February 08, 2018 4:14 PM
To: Bogineni, Kalyani 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bog

Re: [DMM] [Ila] [E] Re: review comments on ] draft-ietf-dmm-srv6-mobile-uplane-00.txt

[Bogineni, Kalyani]

Satoru:

Thank you for pointing out further documents.

Responses inline:

-Original Message-
From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Satoru Matsushima
Sent: Thursday, February 8, 2018 4:00 AM
To: Bogineni, Kalyani <kalyani.bogin...@verizonwireless.com>
Cc: i...@ietf.org; dmm <dmm@ietf.org>
Subject: Re: [Ila] [E] Re: review comments on ] 
draft-ietf-dmm-srv6-mobile-uplane-00.txt

Hello Kalyani,

> [..snip..]

> Your slides 9 – 13 show interactions between UPFs and SMF. There are 2 kinds 
> of UPFs:
> Anchor type UPF and service function type UPF. What are the functionalities 
> of these?

Please find some functionalities in the SRv6 mobile Uplane draft:
[KB] Your section 5.2 means that UPF closer to radio network is like SGW and 
your section 5.3 means that
 UPF closer to Internet is like PGW. 

When it comes to anchor, it should be equivalent with PSA, PDU Session Anchor, 
in TS23.501 of 3GPP 5G_ph1 terminology.
[KB] in 5G, the functionality of the 2 UPFs can be implemented as one combined 
function or could be implemented as 
2 separate functions with N9 in between. 

You would also find various SRv6 functions in the network programming draft:


Maybe you can see SRv6 mobile uplane as a set of SRv6 functions like a SRv6 
profile for mobile with some augment.

When it comes to service function type UPF, you name it. Following draft 
exhibits how service chain can be done by SRv6:
 [KB] I think these are non-mobility functions as being discussed on the email 
thread with Marco Liebsch.

> What are the changes in SMF functionalities to support SRv6? Is the 
> interface between SMF and UPFs based on N4/Sx (PFCP in TS 29.244)?

SMF functionalities seems still work in progress so that I couldn’t say clearly 
what the change to it.
In CUPS architecture for both Rel-14 and Rel-15, PFCP is expected as Sx and N4 
for SRv6 Uplane with no change to over-the-wire messages in basic mode 
operation:

[KB] CUPS does not support branching point function as in 5G. 

> Also you show IPv6/SRv6 nodes in those slides. Are the UPFs ‘overlaid’ on 
> IPv6/SRv6 nodes?
> Are these UPFs VNFs? Or are UPFs implemented on IPv6/SRv6 nodes?
>  

When you see UPF specifically it should be controlled by SMF through N4, they 
are not the UPFs.
But you might see them as UPFs if a SMF doesn’t control them directly but the 
SMF can put the sessions to it through some other means.
3GPP SA2 has studied on that case (ETSUN). We consider how SMF deal with that 
case and SRv6 may help to solve the issues to it in simpler way.
Please let me know if you are interested in.
[KB] is there a TR for ETSUN that I can read?

[KB] I think your document needs to separate out 3 architectures: one for 4G - 
SGW/PGW; one for 4G - CUPS; and one for 5G - UPF.

[KB] I am also still not clear if the blue icons (which I think represent 
IP/MPLS nodes) in your slides are included in SRv6 architecture or not.

Cheers,
--satoru
___
ila mailing list
i...@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ila=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=dR68JI_amykfLiJQo5cQmTXwKdX_Pn7g-Th7RudMVeM=xyt0QGlLtTQfHmezWhutpRYBAw5sEsJlHuzrsihNJbM=
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Bogineni, Kalyani]

Sri:

Even though N3 is shown for 5G and S1-U for 4G, my understanding is that there 
are commons sub-layers in the protocol stack
that are common to both 4G and 5G radio accesses that could be re-used. The 
adaptation from GTP to IP has to happen
somewhere, either in the radio node or in the UPF. The UPF closer to the radio 
node also does the adaptation. Are there any
other ideas?

Kalyani

From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
Sent: Wednesday, February 7, 2018 12:23 PM
To: Bogineni, Kalyani <kalyani.bogin...@verizonwireless.com>; Marco Liebsch 
<marco.lieb...@neclab.eu>; Dino Farinacci <farina...@gmail.com>
Cc: i...@ietf.org; dmm <dmm@ietf.org>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

Hi Kalyani,

For all the approaches that we are talking (ILA, LISP, SRv6 ..etc), there are 
two nodes that's where the translation/tunneling is happening. In a generic 
sense, it could be a layer-2 termination point, a first-hop router, or a 
transit router. When seen from 3GPP lens, there is only UPF and the N4 
interface that you talk about. But, there is N3 (eNB to UPF) and then there are 
also other nodes where there is an impact.  The translation/tunneling/steering 
may very well happen on some router connected to the service cloud/core (on 
N6),  or at some exit router where there is no 3GPP UPF function and there is 
no N4.


So, there are two key questions here:

1.) Is the UPF only node that is impacted here? Is the assumption that these 
protocols are doing some translation/tunneling only on UPF node? Or, we can 
introduce a two types of IP forwarding nodes, one collocated with UPF and 
another without UPF. I know how this discussion will go in 3GPP; they will 
insist and say they we will never recognize any other node other what they 
created.

2.) Is N4 the only interface to these two types of node variants. Or we will 
have N4' to these both types of nodes from some AF (which can interwork with 
the service bus), and we don't' touch N4.

Marco's point is to keep this generic and not make this very UPF specific, as 
it will be too restrictive.



Sri




From: "Bogineni, Kalyani" 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>
Date: Tuesday, February 6, 2018 at 1:23 PM
To: Marco Liebsch <marco.lieb...@neclab.eu<mailto:marco.lieb...@neclab.eu>>, 
Sri Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, Dino Farinacci 
<farina...@gmail.com<mailto:farina...@gmail.com>>
Cc: "i...@ietf.org<mailto:i...@ietf.org>" 
<i...@ietf.org<mailto:i...@ietf.org>>, dmm <dmm@ietf.org<mailto:dmm@ietf.org>>
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt


Marco, Sri:



Here is the services based 5G architecture.



[cid:image001.png@01D3A0AF.BDC67FE0]



SMF is a control plane entity and talks to the User plane functions (UPF) 
through N4 interface as specified in 3GPP TS 29.244.



Here are two variants:



Option 1: Mapping DB talks to the UPFs using a variant of N4 possibly.



[cid:image002.png@01D3A0AF.BDC67FE0]



Option 2: Here there is no direct interface between Mapping Db and UPFs. UPFs 
also support APIs like the control plane functions.



[cid:image003.png@01D3A0AF.BDC67FE0]



The architecture is extensible and additional control plane or user plane 
functions can be added.



Is this what you had in mind?



Kalyani



-Original Message-
From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <sgund...@cisco.com<mailto:sgund...@cisco.com>>; 
Dino Farinacci <farina...@gmail.com<mailto:farina...@gmail.com>>
Cc: i...@ietf.org<mailto:i...@ietf.org>; dmm <dmm@ietf.org<mailto:dmm@ietf.org>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt



It could be a nice option to keep the data plane specific control (the mapping 
DB you refer to) in the user plane and take a common N4 to update the mapping 
DB in case of mobility. But I think that clashes with the clear data plane / 
control plane separation in nextgen. And: there may be data plane solutions 
which don't come with a control plane / mapping system. For these the N4 needs 
to disseminate complete forwarding states (an more, e.g. for chargeable event 
monitoring, device dormancy support etc.) to all relevant data plane nodes, 
means the ones that hold a state for the mobile.



Btw, in terms of compatibility with nextgen, so far N4 is terminated only in 
few types of core data plane nodes with a dedicated role. We may investigate 
options to push forwarding and further policies from the (nextgen) control 
plane to other data plane nodes which don't terminate N4.



marco



-Original

Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Bogineni, Kalyani]

Marco:

There are 2 kinds of non-mobility nodes/functions:

-  One set is what you are referring to as N6 based functions, also 
called Gi-LAN functions that could be
chained to PGW/UPF on Gi/SGi/N6.

-  The second set of functions are related to transport (IP/MPLS) over 
which mobility traffic traverses.

The first set needs some kind of policy/charging control and will need 
interaction to the services interface.
The second set possibly don't need policy/charging control.

We need to see if some of the protocol choices like SRv6 are trying to address 
the second set also.

Kalyani

From: Marco Liebsch [mailto:marco.lieb...@neclab.eu]
Sent: Thursday, February 8, 2018 5:03 AM
To: Marco Liebsch <marco.lieb...@neclab.eu>; Sri Gundavelli (sgundave) 
<sgund...@cisco.com>; Bogineni, Kalyani <kalyani.bogin...@verizonwireless.com>; 
Dino Farinacci <farina...@gmail.com>
Cc: i...@ietf.org; dmm <dmm@ietf.org>
Subject: RE: [DMM] [Ila] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

..sorry, correction in my first sentence below:
"True, control plane impact on data plane can be on N3, N9 but also on N6."..

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Donnerstag, 8. Februar 2018 10:50
To: Sri Gundavelli (sgundave); Bogineni, Kalyani; Dino Farinacci
Cc: i...@ietf.org<mailto:i...@ietf.org>; dmm
Subject: Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

Hi Kalyani,

My take on your latest feedback:
> I think you are talking about 2 features: one for mobility that needs the 
> database; another
> for non-mobility state transfer between user plane nodes (not necessarily 
> mobility nodes).

True, control plane impact on data plane can be on N3, N9 but also on N9. The 
latter is probably what you classify as non-mobility.
My point was to not break the N4 but rather look towards a reasonable and 
extensible protocol solution so that mapping
rules can be carried over it. In such case the mapping DB may be co-located 
with the SMF or external to the SMF. My main point
was to not make the control plane configuring the data plane through the 
service-based interfaces.

About the second case, I think it's interesting enough to include N6 where the 
mapping system would control
the data plane to steer traffic to the mobile's UPF(s). Think about 
decentralizing the UPFs and relocating a
UPF mid-session. The plain old but popular DMM scenario: How to enable IP 
address- and session continuity
when the anchor UPF changes.

Best regards,
marco


From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
Sent: Mittwoch, 7. Februar 2018 18:23
To: Bogineni, Kalyani; Marco Liebsch; Dino Farinacci
Cc: i...@ietf.org<mailto:i...@ietf.org>; dmm
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

Hi Kalyani,

For all the approaches that we are talking (ILA, LISP, SRv6 ..etc), there are 
two nodes that's where the translation/tunneling is happening. In a generic 
sense, it could be a layer-2 termination point, a first-hop router, or a 
transit router. When seen from 3GPP lens, there is only UPF and the N4 
interface that you talk about. But, there is N3 (eNB to UPF) and then there are 
also other nodes where there is an impact.  The translation/tunneling/steering 
may very well happen on some router connected to the service cloud/core (on 
N6),  or at some exit router where there is no 3GPP UPF function and there is 
no N4.


So, there are two key questions here:

1.) Is the UPF only node that is impacted here? Is the assumption that these 
protocols are doing some translation/tunneling only on UPF node? Or, we can 
introduce a two types of IP forwarding nodes, one collocated with UPF and 
another without UPF. I know how this discussion will go in 3GPP; they will 
insist and say they we will never recognize any other node other what they 
created.

2.) Is N4 the only interface to these two types of node variants. Or we will 
have N4' to these both types of nodes from some AF (which can interwork with 
the service bus), and we don't' touch N4.

Marco's point is to keep this generic and not make this very UPF specific, as 
it will be too restrictive.



Sri




From: "Bogineni, Kalyani" 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>
Date: Tuesday, February 6, 2018 at 1:23 PM
To: Marco Liebsch <marco.lieb...@neclab.eu<mailto:marco.lieb...@neclab.eu>>, 
Sri Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, Dino Farinacci 
<farina...@gmail.com<mailto:farina...@gmail.com>>
Cc: "i...@ietf.org<mailto:i...@ietf.org>" 
<i...@ietf.org<mailto:i...@ietf.org>>, dmm <dmm@ietf.org<mailto:dmm@ietf.org>>
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert

Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Bogineni, Kalyani]

Sri:

The white paper should bring out the impacts to the system (N3, etc) when we 
compare the different proposals.

Kalyani

From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
Sent: Wednesday, February 7, 2018 12:23 PM
To: Bogineni, Kalyani <kalyani.bogin...@verizonwireless.com>; Marco Liebsch 
<marco.lieb...@neclab.eu>; Dino Farinacci <farina...@gmail.com>
Cc: i...@ietf.org; dmm <dmm@ietf.org>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

Hi Kalyani,

For all the approaches that we are talking (ILA, LISP, SRv6 ..etc), there are 
two nodes that's where the translation/tunneling is happening. In a generic 
sense, it could be a layer-2 termination point, a first-hop router, or a 
transit router. When seen from 3GPP lens, there is only UPF and the N4 
interface that you talk about. But, there is N3 (eNB to UPF) and then there are 
also other nodes where there is an impact.  The translation/tunneling/steering 
may very well happen on some router connected to the service cloud/core (on 
N6),  or at some exit router where there is no 3GPP UPF function and there is 
no N4.


So, there are two key questions here:

1.) Is the UPF only node that is impacted here? Is the assumption that these 
protocols are doing some translation/tunneling only on UPF node? Or, we can 
introduce a two types of IP forwarding nodes, one collocated with UPF and 
another without UPF. I know how this discussion will go in 3GPP; they will 
insist and say they we will never recognize any other node other what they 
created.

2.) Is N4 the only interface to these two types of node variants. Or we will 
have N4' to these both types of nodes from some AF (which can interwork with 
the service bus), and we don't' touch N4.

Marco's point is to keep this generic and not make this very UPF specific, as 
it will be too restrictive.



Sri




From: "Bogineni, Kalyani" 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>
Date: Tuesday, February 6, 2018 at 1:23 PM
To: Marco Liebsch <marco.lieb...@neclab.eu<mailto:marco.lieb...@neclab.eu>>, 
Sri Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, Dino Farinacci 
<farina...@gmail.com<mailto:farina...@gmail.com>>
Cc: "i...@ietf.org<mailto:i...@ietf.org>" 
<i...@ietf.org<mailto:i...@ietf.org>>, dmm <dmm@ietf.org<mailto:dmm@ietf.org>>
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt


Marco, Sri:



Here is the services based 5G architecture.



[cid:image001.png@01D3A017.F7D6D560]



SMF is a control plane entity and talks to the User plane functions (UPF) 
through N4 interface as specified in 3GPP TS 29.244.



Here are two variants:



Option 1: Mapping DB talks to the UPFs using a variant of N4 possibly.



[cid:image002.png@01D3A017.F7D6D560]



Option 2: Here there is no direct interface between Mapping Db and UPFs. UPFs 
also support APIs like the control plane functions.



[cid:image003.png@01D3A017.F7D6D560]



The architecture is extensible and additional control plane or user plane 
functions can be added.



Is this what you had in mind?



Kalyani



-Original Message-
From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <sgund...@cisco.com<mailto:sgund...@cisco.com>>; 
Dino Farinacci <farina...@gmail.com<mailto:farina...@gmail.com>>
Cc: i...@ietf.org<mailto:i...@ietf.org>; dmm <dmm@ietf.org<mailto:dmm@ietf.org>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt



It could be a nice option to keep the data plane specific control (the mapping 
DB you refer to) in the user plane and take a common N4 to update the mapping 
DB in case of mobility. But I think that clashes with the clear data plane / 
control plane separation in nextgen. And: there may be data plane solutions 
which don't come with a control plane / mapping system. For these the N4 needs 
to disseminate complete forwarding states (an more, e.g. for chargeable event 
monitoring, device dormancy support etc.) to all relevant data plane nodes, 
means the ones that hold a state for the mobile.



Btw, in terms of compatibility with nextgen, so far N4 is terminated only in 
few types of core data plane nodes with a dedicated role. We may investigate 
options to push forwarding and further policies from the (nextgen) control 
plane to other data plane nodes which don't terminate N4.



marco



-Original Message-

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)

Sent: Dienstag, 6. Februar 2018 04:07

To: Dino Farinacci

Cc: dmm; i...@ietf.org<mailto:i...@ietf.org>

Subject: Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for 

Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Bogineni, Kalyani]

Arashmid - response inline

From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Arashmid Akhavain
Sent: Wednesday, February 7, 2018 11:14 AM
To: Bogineni, Kalyani <kalyani.bogin...@verizonwireless.com>; Marco Liebsch 
<marco.lieb...@neclab.eu>
Cc: i...@ietf.org; dmm <dmm@ietf.org>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

The database is simply a vehicle to locate UPFs in the network. As UPFs move 
around,  the database gets updated and notifies other UPFs
that are interested to receive this information. The records could be of course 
augmented to store additional information.

Option 1 might require changes to N4. But given the small number of required 
instructions, I don't think these changes will be significant.

Options 2 will use the APIs which I think is a more flexible and perhaps 
easier. The mapping database (in a distributed model which I think need to be 
used in MN) will also use this method to synchronise its nodes, load balance, 
etc. We don't need any special interface here.

Kalyani, you talked about non-mobility state transfer between the UPFs. 
Wouldn't this info. use the established data path between the UPFs (i.e. N9)?
[KB] I was trying to understand what Marco meant by the text in his email that 
I highlighted in yellow.


Arashmid



From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Bogineni, Kalyani
Sent: 07 February 2018 08:20
To: Marco Liebsch <marco.lieb...@neclab.eu<mailto:marco.lieb...@neclab.eu>>
Cc: i...@ietf.org<mailto:i...@ietf.org>; dmm <dmm@ietf.org<mailto:dmm@ietf.org>>
Subject: Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

Marco:

I think you are talking about 2 features: one for mobility that needs the 
database; another for non-mobility state transfer
between user plane nodes (not necessarily mobility nodes).

Kalyani

From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Wednesday, February 7, 2018 3:40 AM
To: Bogineni, Kalyani 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>
Cc: i...@ietf.org<mailto:i...@ietf.org>; dmm 
<dmm@ietf.org<mailto:dmm@ietf.org>>; Dino Farinacci 
<farina...@gmail.com<mailto:farina...@gmail.com>>; Sri Gundavelli (sgundave) 
<sgund...@cisco.com<mailto:sgund...@cisco.com>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

Kalyani, even with Option 1 I see much impact on the control plane as it 
implies that SMF offers/uses service to/from the Mapping DB utilizing the 
service-based interfaces.
My comment was more about whether we need or should introduce a new building 
block into the control plane at all.

marco


From: Bogineni, Kalyani [mailto:kalyani.bogin...@verizonwireless.com]
Sent: Mittwoch, 7. Februar 2018 03:56
To: Marco Liebsch
Cc: Sri Gundavelli (sgundave); Dino Farinacci; 
i...@ietf.org<mailto:i...@ietf.org>; dmm
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt


Marco:

Response Inline

From: Marco Liebsch [mailto:marco.lieb...@neclab.eu]
Sent: Tuesday, February 6, 2018 5:10 PM
To: Bogineni, Kalyani 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>
Cc: Sri Gundavelli (sgundave) <sgund...@cisco.com<mailto:sgund...@cisco.com>>; 
Dino Farinacci <farina...@gmail.com<mailto:farina...@gmail.com>>; 
i...@ietf.org<mailto:i...@ietf.org>; dmm <dmm@ietf.org<mailto:dmm@ietf.org>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

Hi Kalyani,

my current take is to keep the data plane independent of a specific mapping 
base. Even if it comes with an extended control plane per the two options that 
you draw, I personally don't think that SMF and UPF/Data Plane should 
communicate through the service-based architecture.
[KB] Does this mean you prefer option 1 because option 2 shows APIs from both 
UPFs and Mapping DB to the services based interfaces?


marco


On 6. Feb 2018, at 22:30, Bogineni, Kalyani 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>
 wrote:

Marco, Sri:



Here is the services based 5G architecture.







SMF is a control plane entity and talks to the User plane functions (UPF) 
through N4 interface as specified in 3GPP TS 29.244.



Here are two variants:



Option 1: Mapping DB talks to the UPFs using a variant of N4 possibly.







Option 2: Here there is no direct interface between Mapping Db and UPFs. UPFs 
also support APIs like the control plane functions.







The architecture is extensible and additional control plane or user plane 
functions can be added.



Is this what you had in mind?



Kalyani



-Original Message-
From: ila [mailto:ila-boun..

Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Bogineni, Kalyani]

Marco:

Response Inline

From: Marco Liebsch [mailto:marco.lieb...@neclab.eu]
Sent: Tuesday, February 6, 2018 5:10 PM
To: Bogineni, Kalyani <kalyani.bogin...@verizonwireless.com>
Cc: Sri Gundavelli (sgundave) <sgund...@cisco.com>; Dino Farinacci 
<farina...@gmail.com>; i...@ietf.org; dmm <dmm@ietf.org>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

Hi Kalyani,

my current take is to keep the data plane independent of a specific mapping 
base. Even if it comes with an extended control plane per the two options that 
you draw, I personally don't think that SMF and UPF/Data Plane should 
communicate through the service-based architecture.
[KB] Does this mean you prefer option 1 because option 2 shows APIs from both 
UPFs and Mapping DB to the services based interfaces?


marco


On 6. Feb 2018, at 22:30, Bogineni, Kalyani 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>
 wrote:

Marco, Sri:



Here is the services based 5G architecture.







SMF is a control plane entity and talks to the User plane functions (UPF) 
through N4 interface as specified in 3GPP TS 29.244.



Here are two variants:



Option 1: Mapping DB talks to the UPFs using a variant of N4 possibly.







Option 2: Here there is no direct interface between Mapping Db and UPFs. UPFs 
also support APIs like the control plane functions.







The architecture is extensible and additional control plane or user plane 
functions can be added.



Is this what you had in mind?



Kalyani



-Original Message-
From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <sgund...@cisco.com<mailto:sgund...@cisco.com>>; 
Dino Farinacci <farina...@gmail.com<mailto:farina...@gmail.com>>
Cc: i...@ietf.org<mailto:i...@ietf.org>; dmm <dmm@ietf.org<mailto:dmm@ietf.org>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt



It could be a nice option to keep the data plane specific control (the mapping 
DB you refer to) in the user plane and take a common N4 to update the mapping 
DB in case of mobility. But I think that clashes with the clear data plane / 
control plane separation in nextgen. And: there may be data plane solutions 
which don't come with a control plane / mapping system. For these the N4 needs 
to disseminate complete forwarding states (an more, e.g. for chargeable event 
monitoring, device dormancy support etc.) to all relevant data plane nodes, 
means the ones that hold a state for the mobile.



Btw, in terms of compatibility with nextgen, so far N4 is terminated only in 
few types of core data plane nodes with a dedicated role. We may investigate 
options to push forwarding and further policies from the (nextgen) control 
plane to other data plane nodes which don't terminate N4.



marco



-Original Message-

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)

Sent: Dienstag, 6. Februar 2018 04:07

To: Dino Farinacci

Cc: dmm; i...@ietf.org<mailto:i...@ietf.org>

Subject: Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt



> The UPF sends IP packets. The UPF is part of the NGC core, right? So

>the packets from the UPF get to a map-resolver and map-server via IP.

>It's pretty simple. At least it should be.



Sure, that LISP control plane packet is an IP packet. But, every message that 
is going between CP and UP will be named and numbered in 3GPP specs, and so 
said in my first mail that its probably a new interface specific to LISP.



With any of the IETF protocols, PMIPv6/LISP/ILA, it can be argued that these 
are IP packets. But, we should note that there is interworking needed with the 
3GPP authentication infrastructure, and the protocol specific control plane. 
Note that these protocols are not doing MN identity establishment. May be I 
could be wrong here on the assumptions you have around LISP MN capabilities, 
but to me MN is a standard 3GPP UE with no special capabilities such as 
MIPv6/LISP MN stack.







Sri













On 2/5/18, 6:52 PM, "Dino Farinacci" 
<farina...@gmail.com<mailto:farina...@gmail.com>> wrote:



>> Sure, but I assume the mapping table/DB is some where else in some

>>central  location and not on the UPF?

>

>True.

>

>> The question is how does the UPF fetch that entry and if the

>>interface for  that query is built on some 3GPP interface, or its

>>internal to LISP with  no bearing on the access technology.

>

>The UPF sends IP packets. The UPF is part of the NGC core, right? So

>the packets from the UPF get to a map-resolver and map-server via IP.

>It's pretty simple. At least it should be.

>

>Dino

>

>>

>

Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Bogineni, Kalyani]

Marco, Sri:



Here is the services based 5G architecture.



[cid:image001.png@01D39F65.E35E55C0]



SMF is a control plane entity and talks to the User plane functions (UPF) 
through N4 interface as specified in 3GPP TS 29.244.



Here are two variants:



Option 1: Mapping DB talks to the UPFs using a variant of N4 possibly.



[cid:image002.png@01D39F66.D298DBB0]



Option 2: Here there is no direct interface between Mapping Db and UPFs. UPFs 
also support APIs like the control plane functions.



[cid:image003.png@01D39F66.D298DBB0]



The architecture is extensible and additional control plane or user plane 
functions can be added.



Is this what you had in mind?



Kalyani



-Original Message-
From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <sgund...@cisco.com>; Dino Farinacci 
<farina...@gmail.com>
Cc: i...@ietf.org; dmm <dmm@ietf.org>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt



It could be a nice option to keep the data plane specific control (the mapping 
DB you refer to) in the user plane and take a common N4 to update the mapping 
DB in case of mobility. But I think that clashes with the clear data plane / 
control plane separation in nextgen. And: there may be data plane solutions 
which don't come with a control plane / mapping system. For these the N4 needs 
to disseminate complete forwarding states (an more, e.g. for chargeable event 
monitoring, device dormancy support etc.) to all relevant data plane nodes, 
means the ones that hold a state for the mobile.



Btw, in terms of compatibility with nextgen, so far N4 is terminated only in 
few types of core data plane nodes with a dedicated role. We may investigate 
options to push forwarding and further policies from the (nextgen) control 
plane to other data plane nodes which don't terminate N4.



marco



-Original Message-

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)

Sent: Dienstag, 6. Februar 2018 04:07

To: Dino Farinacci

Cc: dmm; i...@ietf.org<mailto:i...@ietf.org>

Subject: Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt



> The UPF sends IP packets. The UPF is part of the NGC core, right? So

>the packets from the UPF get to a map-resolver and map-server via IP.

>It's pretty simple. At least it should be.



Sure, that LISP control plane packet is an IP packet. But, every message that 
is going between CP and UP will be named and numbered in 3GPP specs, and so 
said in my first mail that its probably a new interface specific to LISP.



With any of the IETF protocols, PMIPv6/LISP/ILA, it can be argued that these 
are IP packets. But, we should note that there is interworking needed with the 
3GPP authentication infrastructure, and the protocol specific control plane. 
Note that these protocols are not doing MN identity establishment. May be I 
could be wrong here on the assumptions you have around LISP MN capabilities, 
but to me MN is a standard 3GPP UE with no special capabilities such as 
MIPv6/LISP MN stack.







Sri













On 2/5/18, 6:52 PM, "Dino Farinacci" 
<farina...@gmail.com<mailto:farina...@gmail.com>> wrote:



>> Sure, but I assume the mapping table/DB is some where else in some

>>central  location and not on the UPF?

>

>True.

>

>> The question is how does the UPF fetch that entry and if the

>>interface for  that query is built on some 3GPP interface, or its

>>internal to LISP with  no bearing on the access technology.

>

>The UPF sends IP packets. The UPF is part of the NGC core, right? So

>the packets from the UPF get to a map-resolver and map-server via IP.

>It's pretty simple. At least it should be.

>

>Dino

>

>>

>> Sri

>>

>>

>>

>> On 2/5/18, 6:42 PM, "Dino Farinacci" 
>> <farina...@gmail.com<mailto:farina...@gmail.com>> wrote:

>>

>>> I don't know what you mean. If you put the xTR function on an UPF,

>>> then by LISP spec definition, Map-Request, Map-Reply, and

>>> Map-Register functionality is part of the UPF.

>>>

>>> Dino

>>>

>>>> On Feb 5, 2018, at 5:27 PM, Sri Gundavelli (sgundave)

>>>> <sgund...@cisco.com<mailto:sgund...@cisco.com>> wrote:

>>>>

>>>> I suspect there might be a need for a new interface.

>>>>

>>>> Assuming the LISP mapping system stays in the control plane, next

>>>>to  SMF/AMF, and the xTR functions on the UPF, there needs to be

>>>>probably a  new interface along the lines of the N4, for managing

>>>>the LISP MAP  operations (Reg/Req/Reply/Notify..

Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Bogineni, Kalyani]

Dino:

This paper does describe the architecture. This information in a section would 
help and also explain what is different between
LISP and ILSR. Figure 3 shows SMF for ILSR, AMF+, Nsmf+, Namf+, and ILSR4. You 
can explain what the '+' means and what the
new functionalities in SMF for ILSR are and what ILSR4 is (is it a variant of 
N4/Sx - PFCP in 29.244).

Kalyani

-Original Message-
From: Dino Farinacci [mailto:farina...@gmail.com] 
Sent: Monday, February 5, 2018 9:44 PM
To: Bogineni, Kalyani <kalyani.bogin...@verizonwireless.com>
Cc: Tom Herbert <t...@quantonium.net>; i...@ietf.org; dmm <dmm@ietf.org>; Sri 
Gundavelli (sgundave) <sgund...@cisco.com>
Subject: Re: [Ila] [E] Re: [DMM] Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

> Please look at 3GPP TS 23.501 to understand the architecture of NGC. We tried 
> to explain that in the White paper.
> TS 23.502 has the procedures for the NGC. TS 23.503 specifies the policy and 
> charging control framework for NGC.
> CT4 has a technical report on protocol aspects for NGC in TR 29.891.
> 
> Your draft needs to describe how it fits in the 5G architecture, right now it 
> only addresses 4G.

This whitepaper (attached below) indicates how 
draft-farinacci-lisp-mobile-network fits into the 5G architecture. First of 
all, do you agree with it? And if so, do you think that information be put in a 
new section?

Dino

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

Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Bogineni, Kalyani]

Dino:

Please look at 3GPP TS 23.501 to understand the architecture of NGC. We tried 
to explain that in the White paper.
TS 23.502 has the procedures for the NGC. TS 23.503 specifies the policy and 
charging control framework for NGC.
CT4 has a technical report on protocol aspects for NGC in TR 29.891.

Your draft needs to describe how it fits in the 5G architecture, right now it 
only addresses 4G.

Kalyani



-Original Message-
From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Dino Farinacci
Sent: Monday, February 5, 2018 7:32 PM
To: Bogineni, Kalyani <kalyani.bogin...@verizonwireless.com>
Cc: Tom Herbert <t...@quantonium.net>; i...@ietf.org; dmm <dmm@ietf.org>; Sri 
Gundavelli (sgundave) <sgund...@cisco.com>
Subject: Re: [Ila] [E] Re: [DMM] Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

> On Feb 6, 2018, at 5:04 AM, Bogineni, Kalyani 
> <kalyani.bogin...@verizonwireless.com> wrote:
> 
> Dino:
> 
> Can you add a section to show how this proposal would fit in 5G architecture? 

Can you be more specific in what you’d like to see in the new section?

There are references throughout the draft where you see eNodeB and pGW that UPF 
functionality could be at the same network mode location. 

Dino
___
ila mailing list
i...@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ila=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=zf1KfRu4nUFsUT8IJVExPygA_iAC-h4BErkY_CE2ugM=oLQOKLOAxuYtjVD_qWMbiQjkmP9acy6Au0X6lpSiBvg=
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [E] Re: [Ila] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Bogineni, Kalyani]

Dino:

Can you add a section to show how this proposal would fit in 5G architecture? 

Kalyani

-Original Message-
From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Thursday, February 1, 2018 6:34 PM
To: Dino Farinacci 
Cc: i...@ietf.org; Tom Herbert ; dmm 
Subject: [E] Re: [Ila] [DMM] Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

Thank you Dino. 

WG -  Same comments for this draft. LISP is another LOC-ID proposal, with many 
common attributes (if I  may say, like two twins) shared with ILA; some 
differences in how the Locator (COA) and identifier (HOA) spaces are 
defined/used/managed, and with one key difference of tunneling vs translation. 
Please review.


Regards
Sri

On 2/1/18, 2:59 PM, "Dino Farinacci"  wrote:

>> ILA is one of the proposals on the table. This is not an adoption 
>>call at  this time, but asking the WG to review and open up some 
>>discussions that  will help IETF understand the problem/solutions, and 
>>pick the right
>> solution(s) for this problem statement. If there is interest and if 
>>the  work is in scope for the group, we will issue an adoption call at 
>>some  point in future. Please review.
>
>I just got on the dmm list. Here is another proposal:
>
>https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.o
>rg_doc_draft-2Dfarinacci-2Dlisp-2Dmobile-2Dnetwork_=DwICAg=udBTRvFv
>XC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_Y
>SwXBDiaofh47oilzaXYRYETcBynUdpT=0FPXpkwcIr_nXgnH3elSoIO0UbXQVCs2mAT1a
>FmeI30=GsKsl3A6sbXWSegMimugCGCWIdJey5Gt4pq_z6Ql1oA=
>
>Dino
>

___
ila mailing list
i...@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ila=DwICAg=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=0FPXpkwcIr_nXgnH3elSoIO0UbXQVCs2mAT1aFmeI30=c4jMVkWkS0nBsE4QFXON2NvUrA6Z4vZu0xTCtvI3hf4=

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

Re: [DMM] [E] Re: [Ila] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Bogineni, Kalyani]

Fred:

Can you add a section to show how this proposal will work in 5G architecture?

Kalyani

-Original Message-
From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Friday, February 2, 2018 11:00 AM
To: Templin, Fred L ; Dino Farinacci 
; Tom Herbert 
Cc: i...@ietf.org; dmm 
Subject: [E] Re: [Ila] [DMM] Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

Thank you Fred. 
 
There is a reason for mobile architectures shifting towards CP-UP split 
architecture (Ref: DMM WG documents + 3GPP CUPS), and the stated goal of 
further simplification in the mobile user plane (Reference: 3GPP CT4 Study item 
and 3GPP Liaison statement to DMM). Now, it will be good if we can explain how 
each of these protocols (ILA, LISP, AERO ..) address those key objectives 
around mobile user-plane optimization, else there is no reason for the WG to 
consider that specific protocol option. So, please do include this text in the 
I-D, and/or explain to the WG on how its addressing these issues.

WG - Please review AERO specs, along with the other proposals.




Sri



On 2/2/18, 7:40 AM, "Templin, Fred L"  wrote:

>Hi, please add AERO to the list:
>
>https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.o
>rg_doc_draft-2Dtemplin-2Daerolink_=DwICAg=udBTRvFvXC5Dhqg7UHpJlPps3
>mZ3LRxpb6__0PomBTQ=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilza
>XYRYETcBynUdpT=sCHryEZFtc7CtEHHHDax7-Ae9uuwPgGWuYf9-O1T12w=HIFgnfSr
>nLv7H1FRiA_sivkZ6tqIQkBDmLgnGi9logQ=
>
>AERO does IPv6 ND over tunnels, and supports mobility via dynamic 
>neighbor cache updates the same as any IPv6 link. Use cases include 
>(but are not limited to):
>
>- Enterprise mobile devices (cellphones, tablets, etc. as mobile 
>networks)
>- civil aviation networks (airplanes as mobile networks)
>- Unmanned Air Systems (drones as mobile networks)
>
>AERO has been discussed in this forum several years back, and has 
>continued to mature since that time. Maybe now is the time to start 
>talking about it again.
>
>Thanks - Fred
>

___
ila mailing list
i...@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ila=DwICAg=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=sCHryEZFtc7CtEHHHDax7-Ae9uuwPgGWuYf9-O1T12w=rVisbGTQdyRNwu8W6zgFJawofONn9JBd1ixzyMqefrQ=

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

Re: [DMM] white paper for optimized mobile user plane solutions for 5G

[Bogineni, Kalyani]

Folks have asked about an architecture with network slices. Here is a sample 
diagram.
We can review this also on the call to ensure that N9 use cases are covered 
properly.

I have also attached a powerpoint version.

[cid:image001.png@01D39AEA.3D0C2FF0]







Network Slices.pptx
Description: Network Slices.pptx
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [E] Re: [Ila] Questions about SRv6 mobile user-plane

[Bogineni, Kalyani]

Satoru:

There are 2 deployment scenarios for mobile core: overlay on packet transport 
and
integrated. Can you identify the line items applicable to the overlay 
architecture?

Kalyani

-Original Message-
From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Satoru Matsushima
Sent: Monday, January 29, 2018 1:30 AM
To: dmm 
Cc: Tom Herbert ; i...@ietf.org
Subject: [E] Re: [Ila] [DMM] Questions about SRv6 mobile user-plane

Hello Tom,

To make the overhead discussion quantitative and realistic, I’ve made a 
spreadsheet of user-plane total overhead comparison by deployment scenarios.


https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_spreadsheets_d_1Fx8ilE-5FbQPkhFBoSd-2DqRS5ok2IO1i0VZbmwzZJNVh0g_edit-3Fusp-3Dsharing=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=_lz35skZpHqFfzeq6RxkaHJWHMyiYtwcnWZimRwEENI=9LAu7dC44lPXoBoWT3q4QX5sjTPDhk1cmWlg7IQe8ks=

This includes not only for mobility, but also range of possible cases of real 
deployment in operators to fulfill isolation, quality and reliability 
requirements for mobile networks. Some of them seem most likely cases, but 
others sound extreme. But I’d like to share all those scenarios to make us 
aware of them when it comes to packet overhead in real deployments.

The total overhead length of the scenarios which exceed 2x SIDs (58) and 4x 
SIDs (90) cases are highlighted with red color to the number and the cell 
respectively in the sheet. Please take a look at it. The sheet looks a bit busy 
but you may find some interesting points, or errors. Any comments and 
corrections from all of you are really welcome.

Best regards,
--satoru


> 2018/01/27 2:13、Tom Herbert のメール:
> 
> Hello,
> 
> I am working on a comparison between ILA and SRv6 for the mobile user-plane. 
> I have some questions/comments about SRv6 and particularly on the example use 
> cases that were depicted in the slides that were presented in IETF100:
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_meeting_100_materials_slides-2D100-2Ddmm-2Dsrv6-2Dfor-2Dmobile-2Duser-2Dplane_=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=_lz35skZpHqFfzeq6RxkaHJWHMyiYtwcnWZimRwEENI=ZNHAtXtIVbyuoqhI52nadcPqREIaQSmrfuvqGd5eNs8=
> 
> - It's clear from the depicted use cases that extension header insertion is 
> being done by intermediate nodes, but extension header insertion is currently 
> prohibited by RFC8200. There was an I-D posted on 6man to allow this for SR, 
> but that was met with pushback. Is there going to be followup to resolve this?
> 
> - For the uplink use cases, this seems to be more like using SR to source 
> route to an egress router. In other words, it's not strictly related to 
> mobility. Is there some connection to mobility that I'm missing?
> 
> - The size or number of SR headers in the uplink cases seems to be larger 
> than necessary (IMO minimizing these is important since each additional sid 
> is ~1% overhead of standard MTU). In this first scenario sid[1]=A2::1 and 
> DA=A2::1-- this seems to be redundant information. Also this depicts a second 
> SR being inserted, but the first one should no longer be relevant. Why not 
> just discard the first one and save the overhead? In the second scenario, DA 
> is changing from A2::1 to A3::1, but AFAICT that was not done per the SR 
> processing. What is the operation that happened here? (it's actaully looks 
> like an ILA transfomation).
> 
> - Considering the points above, could this have been done in the following 
> manner to minimize overhead? A1 creates one SRH with one sid and makes DA=A2. 
> A2 makes DA=A3. At A3 SR is processed, DA is restored to Internet address, 
> and EH is removed.
> 
> - For downlink this does see to be relevant to mobility. But I have the same 
> question, wouldn't it be less overhead to only use one SRH and one sid? i.e. 
> A3 creates an SRH with just one sid that is the S:: (identifier in 
> identifier/locator speak) and set DA to A2, and then A2 sets DA to A1, A1 
> restores original packet for delivery.
> 
> - One possible typo. In the last use case slide SA=S:: and DA=D::, I believe 
> these should be swapped?
> 
> Thanks,
> Tom
> 
>  
> 
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dmm=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=_lz35skZpHqFfzeq6RxkaHJWHMyiYtwcnWZimRwEENI=6ufOvi6aVOB4UAgZ20C9fFetELBoi5NRATcN3cAtidY=

___
ila mailing list
i...@ietf.org

Re: [DMM] white paper for optimized mobile user plane solutions for 5G

[Bogineni, Kalyani]

Arashmid:

I was going to go through the process I followed to create the requirements in 
this white paper.

Ideal would be if some of the vendors can invite their SA2/CT4 counterparts to 
give an overview
of the architecture and of the interfaces/protocols in DMM WG.

Then we can see if what we captured as requirements in the white paper need 
modification.

Is there any vendor who can volunteer to do that?

Kalyani


From: Arashmid Akhavain [mailto:arashmid.akhav...@huawei.com]
Sent: Friday, January 26, 2018 11:40 AM
To: Bogineni, Kalyani <kalyani.bogin...@verizonwireless.com>; Sri Gundavelli 
(sgundave) <sgund...@cisco.com>; dmm@ietf.org
Cc: AshwoodsmithPeter <peter.ashwoodsm...@huawei.com>; TongWen 
<tong...@huawei.com>
Subject: [E] RE: [DMM] white paper for optimized mobile user plane solutions 
for 5G

Hi Kalyani,
Do you know if anyone from 3GPP will attend?

Arashmid

From: Bogineni, Kalyani [mailto:kalyani.bogin...@verizonwireless.com]
Sent: 25 January 2018 12:04
To: Sri Gundavelli (sgundave) <sgund...@cisco.com<mailto:sgund...@cisco.com>>; 
Arashmid Akhavain 
<arashmid.akhav...@huawei.com<mailto:arashmid.akhav...@huawei.com>>; 
dmm@ietf.org<mailto:dmm@ietf.org>
Cc: AshwoodsmithPeter 
<peter.ashwoodsm...@huawei.com<mailto:peter.ashwoodsm...@huawei.com>>; TongWen 
<tong...@huawei.com<mailto:tong...@huawei.com>>
Subject: RE: [DMM] white paper for optimized mobile user plane solutions for 5G

I can host a call on Thursday 1st February at 8:00 - 9:30 AM US ET. I think 
that works for most folks.
Folks who are interested can let me know and I will set up the WebEx.

Kalyani

From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
Sent: Thursday, January 25, 2018 11:49 AM
To: Bogineni, Kalyani 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>;
 Arashmid Akhavain 
<arashmid.akhav...@huawei.com<mailto:arashmid.akhav...@huawei.com>>; 
dmm@ietf.org<mailto:dmm@ietf.org>
Cc: AshwoodsmithPeter 
<peter.ashwoodsm...@huawei.com<mailto:peter.ashwoodsm...@huawei.com>>; TongWen 
<tong...@huawei.com<mailto:tong...@huawei.com>>
Subject: [E] Re: [DMM] white paper for optimized mobile user plane solutions 
for 5G

Hi Kalyani,

Call sounds great.  Wed or later works for me, but you can pick the day/time 
based on the feedback from all the interested folks.


Sri


From: "Bogineni, Kalyani" 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>
Date: Thursday, January 25, 2018 at 4:46 AM
To: Arashmid Akhavain 
<arashmid.akhav...@huawei.com<mailto:arashmid.akhav...@huawei.com>>, Sri 
Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, 
"dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>>
Cc: AshwoodsmithPeter 
<peter.ashwoodsm...@huawei.com<mailto:peter.ashwoodsm...@huawei.com>>, TongWen 
<tong...@huawei.com<mailto:tong...@huawei.com>>
Subject: RE: [DMM] white paper for optimized mobile user plane solutions for 5G

Sri, Arashmid:

I can host a call to review the requirements documented. It seems like folks 
would like to understand more before they can
provide feedback and comments.

I can host a call on Monday, January 29th. Can you suggest a time that would 
work for most time zones? I am located on US
East Coast.

Kalyani

From: Arashmid Akhavain [mailto:arashmid.akhav...@huawei.com]
Sent: Thursday, January 18, 2018 9:38 AM
To: Sri Gundavelli (sgundave) <sgund...@cisco.com<mailto:sgund...@cisco.com>>; 
Bogineni, Kalyani 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Cc: AshwoodsmithPeter 
<peter.ashwoodsm...@huawei.com<mailto:peter.ashwoodsm...@huawei.com>>; TongWen 
<tong...@huawei.com<mailto:tong...@huawei.com>>
Subject: [E] RE: [DMM] white paper for optimized mobile user plane solutions 
for 5G

Hi Sri,
Thank you for your reply and clarifications.
I think Kalyani's work is extremely valuable, but we also need to set an 
strategy for our reply back to 3GPP. Currently most discussions are about 
individual protocols such as SRV6, LISP/ILSP, ILNP, ILA, etc. which are really 
in one form or another a type of ID-Location approach.  I believe we first need 
to address 3GPP's request from the architecture point of view, before we dive 
into implementation details. Is there any discussion around different competing 
network architectures?

Not sure if you have seen a white paper titled "Evolving 5G Routing" by Docomo, 
Huawei and others. We also hosted a live webcast demo that shows two LTE slices 
using ID-Location for data path and distribute ID-Location information to 
interested eNodeBs via public cloud pub/sub service. The result is very 
promising and show

Re: [DMM] white paper for optimized mobile user plane solutions for 5G

[Bogineni, Kalyani]

I can host a call on Thursday 1st February at 8:00 - 9:30 AM US ET. I think 
that works for most folks.
Folks who are interested can let me know and I will set up the WebEx.

Kalyani

From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
Sent: Thursday, January 25, 2018 11:49 AM
To: Bogineni, Kalyani <kalyani.bogin...@verizonwireless.com>; Arashmid Akhavain 
<arashmid.akhav...@huawei.com>; dmm@ietf.org
Cc: AshwoodsmithPeter <peter.ashwoodsm...@huawei.com>; TongWen 
<tong...@huawei.com>
Subject: [E] Re: [DMM] white paper for optimized mobile user plane solutions 
for 5G

Hi Kalyani,

Call sounds great.  Wed or later works for me, but you can pick the day/time 
based on the feedback from all the interested folks.


Sri


From: "Bogineni, Kalyani" 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>
Date: Thursday, January 25, 2018 at 4:46 AM
To: Arashmid Akhavain 
<arashmid.akhav...@huawei.com<mailto:arashmid.akhav...@huawei.com>>, Sri 
Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, 
"dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>>
Cc: AshwoodsmithPeter 
<peter.ashwoodsm...@huawei.com<mailto:peter.ashwoodsm...@huawei.com>>, TongWen 
<tong...@huawei.com<mailto:tong...@huawei.com>>
Subject: RE: [DMM] white paper for optimized mobile user plane solutions for 5G

Sri, Arashmid:

I can host a call to review the requirements documented. It seems like folks 
would like to understand more before they can
provide feedback and comments.

I can host a call on Monday, January 29th. Can you suggest a time that would 
work for most time zones? I am located on US
East Coast.

Kalyani

From: Arashmid Akhavain [mailto:arashmid.akhav...@huawei.com]
Sent: Thursday, January 18, 2018 9:38 AM
To: Sri Gundavelli (sgundave) <sgund...@cisco.com<mailto:sgund...@cisco.com>>; 
Bogineni, Kalyani 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Cc: AshwoodsmithPeter 
<peter.ashwoodsm...@huawei.com<mailto:peter.ashwoodsm...@huawei.com>>; TongWen 
<tong...@huawei.com<mailto:tong...@huawei.com>>
Subject: [E] RE: [DMM] white paper for optimized mobile user plane solutions 
for 5G

Hi Sri,
Thank you for your reply and clarifications.
I think Kalyani's work is extremely valuable, but we also need to set an 
strategy for our reply back to 3GPP. Currently most discussions are about 
individual protocols such as SRV6, LISP/ILSP, ILNP, ILA, etc. which are really 
in one form or another a type of ID-Location approach.  I believe we first need 
to address 3GPP's request from the architecture point of view, before we dive 
into implementation details. Is there any discussion around different competing 
network architectures?

Not sure if you have seen a white paper titled "Evolving 5G Routing" by Docomo, 
Huawei and others. We also hosted a live webcast demo that shows two LTE slices 
using ID-Location for data path and distribute ID-Location information to 
interested eNodeBs via public cloud pub/sub service. The result is very 
promising and shows the capability of this architecture.

I believe the combination of the white paper and the demo could perhaps serve 
as a good starting point to get the architecture discussion going and that's 
where conference calls can come handy. I agree though let's start with the 
mailing list and move to calls next.

Best regards,
Arashmid Akhavain

From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
Sent: 17 January 2018 17:53
To: Arashmid Akhavain 
<arashmid.akhav...@huawei.com<mailto:arashmid.akhav...@huawei.com>>; Bogineni, 
Kalyani 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] white paper for optimized mobile user plane solutions for 5G

Arashmid  - We do have regular DMM working group meeting during the IETF week. 
I guess, what you are asking for is a WG-chair scheduled conference calls? DMM 
List may be very quite, but there have been regular conf calls between authors 
of some of the WG documents. Authors of FPC host those calls regularly. For the 
new work item that Kalyani is proposing, we need to have some discussions in 
the mailer and once the document is adopted as a WG document, we can certainly 
host some calls (author/chair scheduled) on a need basis. So, the first step is 
to post comments on the documents and trigger some discussions.


Sri



From: dmm <dmm-boun...@ietf.org<mailto:dmm-boun...@ietf.org>> on behalf of 
Arashmid Akhavain 
<arashmid.akhav...@huawei.com<mailto:arashmid.akhav...@huawei.com>>
Date: Wednesday, January 17, 2018 at 2:16 PM
To: "Bogineni, Kalyani" 
<kalyani.bogin...@verizonwi

Re: [DMM] white paper for optimized mobile user plane solutions for 5G

[Bogineni, Kalyani]

Sri, Arashmid:

I can host a call to review the requirements documented. It seems like folks 
would like to understand more before they can
provide feedback and comments.

I can host a call on Monday, January 29th. Can you suggest a time that would 
work for most time zones? I am located on US
East Coast.

Kalyani

From: Arashmid Akhavain [mailto:arashmid.akhav...@huawei.com]
Sent: Thursday, January 18, 2018 9:38 AM
To: Sri Gundavelli (sgundave) <sgund...@cisco.com>; Bogineni, Kalyani 
<kalyani.bogin...@verizonwireless.com>; dmm@ietf.org
Cc: AshwoodsmithPeter <peter.ashwoodsm...@huawei.com>; TongWen 
<tong...@huawei.com>
Subject: [E] RE: [DMM] white paper for optimized mobile user plane solutions 
for 5G

Hi Sri,
Thank you for your reply and clarifications.
I think Kalyani's work is extremely valuable, but we also need to set an 
strategy for our reply back to 3GPP. Currently most discussions are about 
individual protocols such as SRV6, LISP/ILSP, ILNP, ILA, etc. which are really 
in one form or another a type of ID-Location approach.  I believe we first need 
to address 3GPP's request from the architecture point of view, before we dive 
into implementation details. Is there any discussion around different competing 
network architectures?

Not sure if you have seen a white paper titled "Evolving 5G Routing" by Docomo, 
Huawei and others. We also hosted a live webcast demo that shows two LTE slices 
using ID-Location for data path and distribute ID-Location information to 
interested eNodeBs via public cloud pub/sub service. The result is very 
promising and shows the capability of this architecture.

I believe the combination of the white paper and the demo could perhaps serve 
as a good starting point to get the architecture discussion going and that's 
where conference calls can come handy. I agree though let's start with the 
mailing list and move to calls next.

Best regards,
Arashmid Akhavain

From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
Sent: 17 January 2018 17:53
To: Arashmid Akhavain 
<arashmid.akhav...@huawei.com<mailto:arashmid.akhav...@huawei.com>>; Bogineni, 
Kalyani 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] white paper for optimized mobile user plane solutions for 5G

Arashmid  - We do have regular DMM working group meeting during the IETF week. 
I guess, what you are asking for is a WG-chair scheduled conference calls? DMM 
List may be very quite, but there have been regular conf calls between authors 
of some of the WG documents. Authors of FPC host those calls regularly. For the 
new work item that Kalyani is proposing, we need to have some discussions in 
the mailer and once the document is adopted as a WG document, we can certainly 
host some calls (author/chair scheduled) on a need basis. So, the first step is 
to post comments on the documents and trigger some discussions.


Sri



From: dmm <dmm-boun...@ietf.org<mailto:dmm-boun...@ietf.org>> on behalf of 
Arashmid Akhavain 
<arashmid.akhav...@huawei.com<mailto:arashmid.akhav...@huawei.com>>
Date: Wednesday, January 17, 2018 at 2:16 PM
To: "Bogineni, Kalyani" 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>,
 "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>>
Subject: Re: [DMM] white paper for optimized mobile user plane solutions for 5G

Hi everyone,
Online meetings on a regular basis can perhaps help moving things forward.

Arashmid



From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Bogineni, Kalyani
Sent: 17 January 2018 15:20
To: dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] white paper for optimized mobile user plane solutions for 5G

Folks:

Here is the draft with 3GPP architecture described as much as relevant to N9 
interface.
I have extracted some diagrams from 3GPP specs and will redo them in ASCII 
after I get
some feedback on whether to include them or not in this document.

Kalyani

From: Bogineni, Kalyani
Sent: Wednesday, December 13, 2017 4:14 PM
To: dmm@ietf.org<mailto:dmm@ietf.org>
Cc: Bogineni, Kalyani 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>
Subject: white paper for optimized mobile user plane solutions for 5G

Folks:

In response to the 3GPP CT4 study item on user plane protocols, we propose that 
a white paper
be developed that can compare the different IETF protocols. Attached is an 
outline. Please let me
know if you would like to contribute.

Kalyani Bogineni
Verizon

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

Re: [DMM] white paper for optimized mobile user plane solutions for 5G

[Bogineni, Kalyani]

Responses inline as [KB]

Kalyani

From: Arashmid Akhavain [mailto:arashmid.akhav...@huawei.com]
Sent: Thursday, January 18, 2018 11:09 AM
To: Bogineni, Kalyani <kalyani.bogin...@verizonwireless.com>; Sri Gundavelli 
(sgundave) <sgund...@cisco.com>; dmm@ietf.org
Cc: AshwoodsmithPeter <peter.ashwoodsm...@huawei.com>; TongWen 
<tong...@huawei.com>
Subject: [E] RE: [DMM] white paper for optimized mobile user plane solutions 
for 5G

Hi Kalyani,

I was thinking something along this:

A section on each competing architecture where we first provide a description 
of each architecture.
[KB] Right now the outline has sections 7, 8, 9, and 10 for this purpose.

A section on the list and set of features that 3GPP requires and must be 
supported.
[KB] Section 4 in the white paper can be used to create a table of requirements 
to be used by each architecture

In the following sections we then make a deep dive into each architecture and 
describe/analyse how different architectures would support
each of the requested features.
[KB] That is the intent of Sections 7, 8, 9, and 10. There could be subsections 
for describing each architecture, show how this would
be in the 5G architecture framework, high-level flows for different scenarios 
listed in section 5, impacts to the existing 5G architecture,
self-evaluation of how the architecture compares to the requirements from 
section 4,

[KB] The following fits into Section 11. Table of requirements with added 
entries from the self-evaluation in sections 7, 8, 9, and 10.
Going through the above exercise we can perhaps tabulate the outcome of the 
investigation in a format like:

Arch1  Arch-2 Arch-N
Feature-1
Feature-2
Feature-N

Considering pros and cons of each architecture against the request features, at 
this point we should be ready to reply back to 3GPP with our recommended 
architecture.

[KB] Section 12 has the summary.

We then continue the work, and go into more details and follow the same format 
for different protocols supporting the recommended architecture and tabulate 
the outcome as

Arch1.1 Arch1.2Arch1.n
Feature-1
Feature-2
Feature-N

Taking ID-Location architecture as an example,  LISP/ILSR, ILNP, ILA, etc. will 
be Arch1.1, Arch1.2, Arch1.3, etc.

Now, here is my question. Have we already decided to go with the recommendation 
that ID-Location architecture should be the next generation of data path?
[KB] Are there any other protocols for consideration beyond Section 7, 8, 9, 
and 10? If so, they can be added.

If everyone is on board with this, then your suggested outline fits the bill 
and we can start working on it right away. If the decision hasn't been made 
then it would be perhaps a good idea to go one level up and talk about 
different architectures first. Mind you that I don't know and am simply curious 
to know what our starting point is.

Arashmid


From: Bogineni, Kalyani [mailto:kalyani.bogin...@verizonwireless.com]
Sent: 18 January 2018 10:21
To: Arashmid Akhavain 
<arashmid.akhav...@huawei.com<mailto:arashmid.akhav...@huawei.com>>; Sri 
Gundavelli (sgundave) <sgund...@cisco.com<mailto:sgund...@cisco.com>>; 
dmm@ietf.org<mailto:dmm@ietf.org>
Cc: AshwoodsmithPeter 
<peter.ashwoodsm...@huawei.com<mailto:peter.ashwoodsm...@huawei.com>>; TongWen 
<tong...@huawei.com<mailto:tong...@huawei.com>>; Bogineni, Kalyani 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>
Subject: RE: [DMM] white paper for optimized mobile user plane solutions for 5G

Arashmid:

The individual sections are supposed to allow the proponents of the protocols 
to show how the 5G architecture will be when
their protocol is used with the focus on N9. The criteria section lists the 
evaluation criteria from architectural perspective.

Do you see a need for a different kind of format?

Kalyani

From: Arashmid Akhavain [mailto:arashmid.akhav...@huawei.com]
Sent: Thursday, January 18, 2018 9:38 AM
To: Sri Gundavelli (sgundave) <sgund...@cisco.com<mailto:sgund...@cisco.com>>; 
Bogineni, Kalyani 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Cc: AshwoodsmithPeter 
<peter.ashwoodsm...@huawei.com<mailto:peter.ashwoodsm...@huawei.com>>; TongWen 
<tong...@huawei.com<mailto:tong...@huawei.com>>
Subject: [E] RE: [DMM] white paper for optimized mobile user plane solutions 
for 5G

Hi Sri,
Thank you for your reply and clarifications.
I think Kalyani's work is extremely valuable, but we also need to set an 
strategy for our reply back to 3GPP. Currently most discussions are about 
individual protocols such as SRV6, LISP/ILSP, ILNP, ILA, etc. which are really 
in one form or another a type of ID-Location approach.  I believe we first need 
to address 3GPP's request from the architecture point of view, before we dive 

Re: [DMM] white paper for optimized mobile user plane solutions for 5G

[Bogineni, Kalyani]

Arashmid:

The individual sections are supposed to allow the proponents of the protocols 
to show how the 5G architecture will be when
their protocol is used with the focus on N9. The criteria section lists the 
evaluation criteria from architectural perspective.

Do you see a need for a different kind of format?

Kalyani

From: Arashmid Akhavain [mailto:arashmid.akhav...@huawei.com]
Sent: Thursday, January 18, 2018 9:38 AM
To: Sri Gundavelli (sgundave) <sgund...@cisco.com>; Bogineni, Kalyani 
<kalyani.bogin...@verizonwireless.com>; dmm@ietf.org
Cc: AshwoodsmithPeter <peter.ashwoodsm...@huawei.com>; TongWen 
<tong...@huawei.com>
Subject: [E] RE: [DMM] white paper for optimized mobile user plane solutions 
for 5G

Hi Sri,
Thank you for your reply and clarifications.
I think Kalyani's work is extremely valuable, but we also need to set an 
strategy for our reply back to 3GPP. Currently most discussions are about 
individual protocols such as SRV6, LISP/ILSP, ILNP, ILA, etc. which are really 
in one form or another a type of ID-Location approach.  I believe we first need 
to address 3GPP's request from the architecture point of view, before we dive 
into implementation details. Is there any discussion around different competing 
network architectures?

Not sure if you have seen a white paper titled "Evolving 5G Routing" by Docomo, 
Huawei and others. We also hosted a live webcast demo that shows two LTE slices 
using ID-Location for data path and distribute ID-Location information to 
interested eNodeBs via public cloud pub/sub service. The result is very 
promising and shows the capability of this architecture.

I believe the combination of the white paper and the demo could perhaps serve 
as a good starting point to get the architecture discussion going and that's 
where conference calls can come handy. I agree though let's start with the 
mailing list and move to calls next.

Best regards,
Arashmid Akhavain

From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
Sent: 17 January 2018 17:53
To: Arashmid Akhavain 
<arashmid.akhav...@huawei.com<mailto:arashmid.akhav...@huawei.com>>; Bogineni, 
Kalyani 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] white paper for optimized mobile user plane solutions for 5G

Arashmid  - We do have regular DMM working group meeting during the IETF week. 
I guess, what you are asking for is a WG-chair scheduled conference calls? DMM 
List may be very quite, but there have been regular conf calls between authors 
of some of the WG documents. Authors of FPC host those calls regularly. For the 
new work item that Kalyani is proposing, we need to have some discussions in 
the mailer and once the document is adopted as a WG document, we can certainly 
host some calls (author/chair scheduled) on a need basis. So, the first step is 
to post comments on the documents and trigger some discussions.


Sri



From: dmm <dmm-boun...@ietf.org<mailto:dmm-boun...@ietf.org>> on behalf of 
Arashmid Akhavain 
<arashmid.akhav...@huawei.com<mailto:arashmid.akhav...@huawei.com>>
Date: Wednesday, January 17, 2018 at 2:16 PM
To: "Bogineni, Kalyani" 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>,
 "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>>
Subject: Re: [DMM] white paper for optimized mobile user plane solutions for 5G

Hi everyone,
Online meetings on a regular basis can perhaps help moving things forward.

Arashmid



From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Bogineni, Kalyani
Sent: 17 January 2018 15:20
To: dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] white paper for optimized mobile user plane solutions for 5G

Folks:

Here is the draft with 3GPP architecture described as much as relevant to N9 
interface.
I have extracted some diagrams from 3GPP specs and will redo them in ASCII 
after I get
some feedback on whether to include them or not in this document.

Kalyani

From: Bogineni, Kalyani
Sent: Wednesday, December 13, 2017 4:14 PM
To: dmm@ietf.org<mailto:dmm@ietf.org>
Cc: Bogineni, Kalyani 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>
Subject: white paper for optimized mobile user plane solutions for 5G

Folks:

In response to the 3GPP CT4 study item on user plane protocols, we propose that 
a white paper
be developed that can compare the different IETF protocols. Attached is an 
outline. Please let me
know if you would like to contribute.

Kalyani Bogineni
Verizon

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

Re: [DMM] [E] Re: white paper for optimized mobile user plane solutions for 5G

[Bogineni, Kalyani]

Folks:

The document is focused on compiling 3GPP requirements for potential 
replacement of GTP on N9
interface and to compare the various IETF protocols against those requirements. 
There will not be
specification development in this paper. As an operator, we would like to see 
that we utilize the best
protocols that would simplify the network and help in efficient utilization and 
operation of the networks.

There are many specifications in 3GPP (and many that are work-in-progress for 
5G). I compiled the 5G
Architecture description and requirements from many specifications from 3GPP 
SA2, CT and RAN WGs.
Please provide feedback on whether these requirements are sufficient to develop 
protocols in IETF
and to compare them.

The study in CT4 does not start till July 2018, so there is an opportunity to 
do some work in IETF and
use it in 3GPP.

===
Kalyani Bogineni, Ph.D.
Fellow, Technology Architecture & Strategy
Verizon, One Verizon Way, Basking Ridge, NJ 07920
[https://www.certmetrics.com/amazon/Telerik.Web.UI.WebResource.axd?imgid=0f8b72e68d5e45f59d7683fe343f0f15=rbi]<javascript:__doPostBack('ctl00$mainContent$ctrlBadgeList$rptActiveCerts$ctl00$lnkBtnShowBadge','')>



From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com]
Sent: Wednesday, January 17, 2018 5:37 PM
To: Satoru Matsushima <satoru.matsush...@gmail.com>
Cc: Bogineni, Kalyani <kalyani.bogin...@verizonwireless.com>; dmm@ietf.org
Subject: [E] Re: [DMM] white paper for optimized mobile user plane solutions 
for 5G

Hi dmm folks,

I think that Kalyani is going to send a revised version of the outtline not 
including the items that are not of interest in dmm group.

Regards,

Behcet

On Fri, Dec 15, 2017 at 7:17 PM, Satoru Matsushima 
<satoru.matsush...@gmail.com<mailto:satoru.matsush...@gmail.com>> wrote:
Hello Kalyani,

+1. White paper looks a good work to start the user-plane study here in IETF. I 
support it.

I think that comparison with quantitive measurements may need to use specific 
deployment metrics in each operator.

But through this white paper work, if we figure out clear criteria for 
apple-to-apple comparison to candidate protocols for 3GPP use cases, that would 
be greatly help to move the study forward.

Hope that make sense and work with you on it.

Cheers,
--satoru

> 2017/12/14 6:13、Bogineni, Kalyani 
> <kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>のメール:
>
> Folks:
>
> In response to the 3GPP CT4 study item on user plane protocols, we propose 
> that a white paper
> be developed that can compare the different IETF protocols. Attached is an 
> outline. Please let me
> know if you would like to contribute.
>
> Kalyani Bogineni
> Verizon
>
> ___
> dmm mailing list
> dmm@ietf.org<mailto:dmm@ietf.org>
> https://www.ietf.org/mailman/listinfo/dmm<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dmm=DwMFaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=qUxNU7-us1fbB3TN4NO1-T2Bo4VZWyqmizRRyE_dLtw=SUulEkrxX1-QL54oZJyU-sKVDQDzFku8eLEy9LS6yKU=>

___
dmm mailing list
dmm@ietf.org<mailto:dmm@ietf.org>
https://www.ietf.org/mailman/listinfo/dmm<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dmm=DwMFaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=qUxNU7-us1fbB3TN4NO1-T2Bo4VZWyqmizRRyE_dLtw=SUulEkrxX1-QL54oZJyU-sKVDQDzFku8eLEy9LS6yKU=>

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

[DMM] white paper for optimized mobile user plane solutions for 5G

[Bogineni, Kalyani]

Folks:

In response to the 3GPP CT4 study item on user plane protocols, we propose that 
a white paper
be developed that can compare the different IETF protocols. Attached is an 
outline. Please let me
know if you would like to contribute.

Kalyani Bogineni
Verizon



draft-bogineni-dmm-optimized-mobile-user-plane-solutions-00.docx
Description: draft-bogineni-dmm-optimized-mobile-user-plane-solutions-00.docx
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm