Re: [DMM] WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

[Arashmid Akhavain]

Please accept this email as my support of this work and the document.

Best regards,
Arashmid Akhavain

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: 07 April 2021 13:35
To: dmm@ietf.org
Subject: [DMM] WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Working Group:

As we discussed in the last IETF meeting, we are issuing WGLC on 
draft-ietf-dmm-srv6-mobile-uplane-11.

The document went through several revisions and there were good amount of 
reviews on this document. I am very pleased with the quality of this document. 
The authors have addressed all the comments and there are no open issues that 
we are tracking at this time. We believe the document is ready for IESG reviews 
and like to confirm the same from the working group.

The following message commences a two week WGLC for all feedback.

Document Link:
https://www.ietf.org/archive/id/draft-ietf-dmm-srv6-mobile-uplane-11.txt


Please post any comments/concerns on this document.


Thanks!
Sri



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

Re: [DMM] Fwd: WGLC on draft-ietf-dmm-distributed-mobility-anchoring-11

[Arashmid Akhavain]

Yes, +1, I support this draft

Arashmid

Begin forwarded message:

From: Sri Gundavelli (sgundave) mailto:sgund...@cisco.com>>
Date: Wed, Jan 9, 2019 at 7:43 PM
Subject: [DMM] WGLC on draft-ietf-dmm-distributed-mobility-anchoring-11
To: dmm@ietf.org mailto:dmm@ietf.org>>




Folks – As we discussed in the WG meeting at IETF103, we are issuing WGLC on 
draft-ietf-dmm-distributed-mobility-anchoring-11.

The document went through several revisions and there were good amount of 
reviews on this document.  The authors have addressed all the comments and 
there are no open issues that we are tracking at this time. We believe the 
document is ready for IESG reviews and like to confirm the same from the 
working group.


The following message commences a two week WGLC for all feedback.

Document Link:
https://www.ietf.org/id/draft-ietf-dmm-distributed-mobility-anchoring-11.txt

The target status for this document is “Informational”.

Please post any comments/concerns on the draft.

Thanks!
Dapeng & Sri

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

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

Re: [DMM] draft-hmm-dmm-5g-uplane-analysis

[Arashmid Akhavain]

3GPP will decide on what works for them. IETF decides what works and gets 
adopted in IETF.


Arashmid

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Behcet Sarikaya
Sent: 29 November 2018 10:52
To: dmm 
Subject: [DMM] draft-hmm-dmm-5g-uplane-analysis


Hi all,
From the link Dave Allan provided, here I copy the content of CT4 liaison. 
There is a claim that this draft is not for 3GPP but for IETF. However if you 
read the liaison, it was originally submitted to CT4.
I think this liaison is show stopper, again sorry to say that.

Here is the liaison:
CT4 reviewed the IETF draft-hmm-dmm-5g-uplane-analysis-00 based on the input
discussion paper submitted to CT4 in C4-185292. CT4 thanks IETF DMM for their
analysis. CT4 would like to provide the following initial feedback on the same.
CT4 intends to do further analysis and provide any additional feedback, if any,
in future. CT4 would like to emphasize that the evaluation criteria for the
user plane protocol study (FS_UPPS) in 5GC shall be defined by 3GPP CT4 and the
work has just now started in 3GPP.


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

Re: [DMM] Call for adoption of draft-hmm-dmm-5g-uplane-analysis-02 as DMM WG document

[Arashmid Akhavain]

I vote for adoption. Valuable information have been gathered in this document.

Arashmid

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Luca Muscariello
Sent: 21 November 2018 04:13
To: sgund...@cisco.com
Cc: Luca Muscariello ; dmm@ietf.org
Subject: Re: [DMM] Call for adoption of draft-hmm-dmm-5g-uplane-analysis-02 as 
DMM WG document

Hi,

+1 for adoption. There is a lot of useful content in this document and adoption 
can only help to make it better.
IETF seems the primary audience to me.

Luca


On Wed, Nov 14, 2018 at 1:34 AM Sri Gundavelli (sgundave) 
mailto:sgund...@cisco.com>> wrote:
Folks:

During IETF 102 and 103, the authors of the document, 
draft-hmm-dmm-5g-uplane-analysis.txt have provided the overview of this 
document. The chairs felt there is good amount of work that went into the 
document and the analysis has value. The document quality is very high. There 
was also generally good feedback and interest for the work from the community. 
We are therefore considering adopting this document as a DMM WG document, to be 
moved on Informational Standards track.

There were also few concerns/comments on the 1.) Relevance of this document to 
3GPP in the immediate time frame 2.) Archival Value of the document 3.) Target 
Audience  - IETF or 3GPP.
On #3, there was also a view that the document should be restructured to make 
it IETF focussed.  With this background, we would like to ask the WG to provide 
some feedback on their interest for this work. Please provide substantial 
comments as why this should be adopted, or why it should not be adopted. If 
there is interest, and if there are no other concerns from AD/IESG/Others, then 
we may take up this work at some point.

Draft Pointer: https://tools.ietf.org/html/draft-hmm-dmm-5g-uplane-analysis-02

The adoption call will end on 4th of December, 2019.

Regards
Dapping & Sri
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF103 - Call for agenda items

[Arashmid Akhavain]

Hi Sri,

I would like to ask for 15 min. I will either present remotely myself or have 
someone present on my behalf. 
Here are the details of the presentation.

Thank you,
Arashmid

Topic Name: A Smooth Migration of Mobile Core User Plane from GTP to SRv6
Presenter Name: Arashmid Akhavian
Time: 15 min.
Draft Reference: draft-camarillo-dmm-srv6-mobile-pocs



> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli
> (sgundave)
> Sent: 08 October 2018 16:15
> To: dmm@ietf.org
> Subject: [DMM] IETF103 - Call for agenda items
> 
> Folks:
> 
> The DMM working group is planning to meet in Bangkok, on Thursday, Nov
> 8th, 2018, for a 2.5 hour session (subject to change). The IETF 103
> Preliminary Agenda has been posted and you can see it at,
> https://datatracker.ietf.org/meeting/103/agenda.html
> 
> 
> 
> If you need a presentation slot, please send your request to the chairs (as a
> response to this email) with the following information.
> 
> 
> > Topic Name:
> > Presenter Name:
> > Time:
> > Draft Reference:
> 
> 
> Regards
> Dapeng & Sri
> >>>
> >>
> >
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

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

[DMM] Live demo: SRv6 user plane in mobile core

[Arashmid Akhavain]

Hi everyone,

Last year, I presented a live demo to a few groups of the audience from the DMM 
WG and showed the concept behind the anchorless mobility (data plane) through 
the use of ID-LOC architecture and common cloud PUB/SUB technologies.

During IETF 102 in Montreal, we presented draft-camarillo-dmm-srv6-mobile-pocs 
and talked about putting together a proof of concept to show the use of SRv6 in 
in both 4G EPC and 5g mobile core user plane. We have been working on this 
proof of concept and were wondering if there is interest on the mailing list to 
see this POC live via a remote WebEx conference call. The demo is not long and 
will take about 30-45 minutes. However, we will gladly reserve more time on 
WebEx if there are people who would like to present slide materials or have 
further discussions on the subject.

We are currently aiming to setup this conference call sometime between Oct 
15-19. Please let us know if you are interested so that we can secure 
sufficient conference ports on WebEx.  Meanwhile here is a brief description of 
the demo:

We use OAI open source LTE software in conjunction with a modified version of 
the VPP SRv6 stack in our demo. The first phase of our work focuses on the 
migration path from existing GTP IPv4 based user plane to SRv6 based user 
plane. We employ SRv6 gateways (both physical,  and virtual) along the user 
plane adjacent to eNodeB and SPGW to seamlessly carry the user traffic over 
SRv6, eliminating UDP and GTP header and without any modifications to 3GPP 
control plane.

The demo is up and running in our lab and we can arrange for multiple sessions 
if need be.

Looking forward to your response,
Best regards,
Arashmid Akhavain








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

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

[Arashmid Akhavain]

Well put Sridhar… Thank you for the detailed clarification.

Speaking of QoS Flow Identifiers, I am assuming that mapping the QoS 
requirements from 5G core to the underlying transport nodes (routers, switches) 
and vice versa has not been changed. Is this correct Sridhar?

Arashmid

From: Sridhar Bhaskaran [mailto:sridhar.bhaska...@gmail.com]
Sent: 03 October 2018 12:29
To: Arashmid Akhavain 
Cc: sarik...@ieee.org; homma.shuns...@lab.ntt.co.jp; dmm@ietf.org
Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

>>A UPF is any function that can be executed on user traffic in mobile network. 
>>Having said that however, I think the first UPFs that we will see will be in 
>>the form of SGW, PGW.

Even this is not accurate.

A UPF is a 5G system core network entity whereas the SGW-U and PGW-U are EPC 
core network entities. 5G core network has many differences from EPC. To avoid 
confusion it should be noted that 5G NR radio can be deployed with EPC as the 
core network and technically such deployments can also be called as 5G 
deployments. But an UPF has no role in such deployments.

Some of the user plane functionalities of an UPF are completely different from 
SGW-U or PGW-U. Here are few differences (not exhaustive)

1. SGW-U and PGW-U --> one GTP-U tunnel per EPS bearer. No need of any QFI 
marking. UPF on the other hand has one GTP-U tunnel per PDU session. Different 
QoS flows within that PDU session are identified based on the QFI marking. So a 
UPF has to support QFI marking.
2. An UPF can support classification and encapsulation Ethernet frames whereas 
a SGW-U/PGW-U has no requirement to support classification and encapsulation of 
Ethernet frames.
3. An UPF supporting Ethernet PDU session type may support ARP proxying / IPv6 
ND Proxying whereas a SGW-U/PGW-U have no such requirement.
4. An UPF shall support RQI bit for reflective QoS. A PGW-U/SGW-U has no such 
requirement.

One may say that SGW-U / PGW-U also plays a role in user plane forwarding and 
hence why not call it a UPF?  For the lack of a better terminology, 3GPP has 
called the entity that performs the user plane functionalities and features 
within a 5G core network as UPF. Those functionalities are not exactly similar 
to EPC.

Thanks
Sridhar

On Tue, Oct 2, 2018 at 10:45 PM Arashmid Akhavain 
mailto:arashmid.akhav...@huawei.com>> wrote:
Not necessarily,

You are correct in that PGW is a UPF, but a UPF is by no means limited to PGW. 
A UPF is any function that can be executed on user traffic in mobile network. 
Having said that however, I think the first UPFs that we will see will be in 
the form of SGW, PGW.

Arashmid

From: dmm [mailto:dmm-boun...@ietf.org<mailto:dmm-boun...@ietf.org>] On Behalf 
Of Behcet Sarikaya
Sent: Tuesday, October 02, 2018 11:44 AM
To: Shunsuke Homma 
mailto:homma.shuns...@lab.ntt.co.jp>>
Cc: dmm mailto:dmm@ietf.org>>
Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

UPF is virtualized PGW, folks.
While PGW is fixed in location and possibly serving a large number of UE which 
are geographically in the area, that part of the city and that city itself, UPF 
can be deployed closer to the UE and thus probably serving smaller number of UEs

Behcet

On Mon, Oct 1, 2018 at 10:47 PM Shunsuke Homma 
mailto:homma.shuns...@lab.ntt.co.jp>> wrote:
Thanks Dark for your explaining what is UPF instead of me.

Alex, brief definitions of UPF are described in the section 4.1.1.1 of
this draft. Also, you can find more details in 3GPP TS23.501.

Regards,

Shunsuke

On 2018/10/01 20:32, dirk.von-h...@telekom.de<mailto:dirk.von-h...@telekom.de> 
wrote:
> Hi Alex,
> and sorry for jumping into the discussion...
>  From my and (AFAIK) 3GPPs understanding your smartphone is a UE - sitting on 
> the other side of RAN (gNB) - whereas a UPF normally is seen as UP entry (and 
> exit) of the 5G core (i.e. handling all UP traffic in a true CP/UP split 
> fashion).
> Any other ideas on this? Can someone imagine any scenario where UE implements 
> UPF?
> Thanks!
> Best Regards
> Dirk
>
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org<mailto:dmm-boun...@ietf.org>] On 
> Behalf Of Alexandre Petrescu
> Sent: Montag, 1. Oktober 2018 13:22
> To: dmm@ietf.org<mailto:dmm@ietf.org>
> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
>
>
>
> Le 01/10/2018 à 05:50, Shunsuke Homma a écrit :
>> Hi all,
>> # Sorry for my late response...
>>
>> Thank you for your lively discussion. It is very helpful for
>> understanding points which need supplemental explanation and more
>> consideration.
>>
>> Following the discussion, we're planning to update the I-D for
>> covering the points below:
>>
>> - termination points of GTP-U
>> (RANs and UPFs terminate GTP-U in 5GS.)
>
> Wha

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

[Arashmid Akhavain]

gt;> what the operator provides.
>>>> I agree with you that network should not touch/change original
>>>> header bits. GTP or any other encapsulation easily allow for this.
>>>> The question is whether we can provide for this without using
>>>> encapsulation. IPv6 might be the answer. But as Tom pointed out,
>>>> flow labels can still change in the middle. Is there any room for
>>>> improvement. SIDs might present an opportunity.
>>>
>>> Not if they are encapsulated and routers don’t touch packets inside.
>>>
>>> Dino
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> -Original Message-
>>>>> From: Dino Farinacci 
>>>>> [mailto:farina...@gmail.com<mailto:farina...@gmail.com>]
>>>>> Sent: 07 September 2018 13:08
>>>>> To: Arashmid Akhavain 
>>>>> mailto:arashmid.akhav...@huawei.com>>
>>>>> Cc: Tom Herbert mailto:t...@quantonium.net>>; 
>>>>> ta-miyas...@kddi-research.jp<mailto:ta-miyas...@kddi-research.jp>;
>>>>> dmm mailto:dmm@ietf.org>>
>>>>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
>>>>>
>>>>> I think you’ll still have the PHB re-marking issues I mentioned in
>>>>> previous emails. The question is, should the network touch/change
>>>>> any header bits of the packet the source has built. The answer
>>>>> should probably be no.
>>>>>
>>>>> Having said that, GTP did it the right way, even though it cost in
>>>>> header length.
>>>>>
>>>>> Dino
>>>>>
>>>>>> On Sep 7, 2018, at 8:26 AM, Arashmid Akhavain
>>>>> mailto:arashmid.akhav...@huawei.com>> wrote:
>>>>>>
>>>>>> Correct, flow labels can change along the path. That's why I like
>>>>>> the slicing
>>>>> concept.
>>>>>> UEs can request services with different attributes, operators
>>>>>> control how
>>>>> service request are mapped into slices. I should look into the air
>>>>> side of the business and see what happens there.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -Original Message-
>>>>>>> From: Tom Herbert 
>>>>>>> [mailto:t...@quantonium.net<mailto:t...@quantonium.net>]
>>>>>>> Sent: 07 September 2018 11:13
>>>>>>> To: Arashmid Akhavain 
>>>>>>> mailto:arashmid.akhav...@huawei.com>>
>>>>>>> Cc: Dino Farinacci mailto:farina...@gmail.com>>;
>>>>>>> ta-miyas...@kddi-research.jp<mailto:ta-miyas...@kddi-research.jp>; dmm 
>>>>>>> mailto:dmm@ietf.org>>
>>>>>>> Subject: Re: [DMM] Comments to
>>>>>>> draft-hmm-dmm-5g-uplane-analysis-01
>>>>>>>
>>>>>>> On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain
>>>>>>> mailto:arashmid.akhav...@huawei..com>> 
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> -Original Message-
>>>>>>>>> From: Dino Farinacci 
>>>>>>>>> [mailto:farina...@gmail.com<mailto:farina...@gmail.com>]
>>>>>>>>> Sent: 06 September 2018 18:59
>>>>>>>>> To: Arashmid Akhavain 
>>>>>>>>> mailto:arashmid.akhav...@huawei.com>>
>>>>>>>>> Cc: Tom Herbert mailto:t...@quantonium.net>>; 
>>>>>>>>> ta-miyasaka@kddi-
>>>>> research.jp<http://research.jp>;
>>>>>>>>> dmm mailto:dmm@ietf.org>>
>>>>>>>>> Subject: Re: [DMM] Comments to
>>>>>>>>> draft-hmm-dmm-5g-uplane-analysis-
>>>>> 01
>>>>>>>>>
>>>>>>>>>> Dino brought up a good point. Here is my two cents worth:
>>>>>>>>>
>>>>>>>>> Not sure which point.
>>>>>>>>>
>>>>>>>>>> As it was explained by Sridhar,  each UE can have multiple
>>>>>>>>>> contexts. For
>>>>>>>>> example, today some operators provide Da

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

[Arashmid Akhavain]

100% Agree with you Tom. And these are type of questions we need to answer when 
we talk about GTP replacement. The control plane in today's mobile core sets up 
the tunnel and ensure the uniformity of QoS in
both forward and backward path. 

Can you elaborate on using FAST?  FAST on UPFs?

Arashmid


> -Original Message-
> From: Tom Herbert [mailto:t...@quantonium.net]
> Sent: 07 September 2018 11:51
> To: Arashmid Akhavain 
> Cc: Dino Farinacci ; ta-miyas...@kddi-research.jp;
> dmm 
> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
> 
> On Fri, Sep 7, 2018 at 8:26 AM, Arashmid Akhavain
>  wrote:
> > Correct, flow labels can change along the path. That's why I like the 
> > slicing
> concept.
> > UEs can request services with different attributes, operators control how
> service request are mapped into slices. I should look into the air side of the
> business and see what happens there.
> 
> Arashmid,
> 
> Yes, slices are a good model. The key question is how does a user's packets
> get mapped to the right slice. Presumably, this is done at an ingress point
> into the network. There are two ingress points to be considered, one from
> UE into the network and one from Internet into network (return path). If the
> UE sets bits in the packet to get service in the forward path, we somehow
> need to have those bits available on packets in the return path to map
> incoming packets. In lieu or requiring the network to maintain a whole bunch
> of complex flow state, FAST arranges that the remote server reflects the bits
> in response packets.
> 
> Tom
> 
> >
> >
> >
> >> -----Original Message-
> >> From: Tom Herbert [mailto:t...@quantonium.net]
> >> Sent: 07 September 2018 11:13
> >> To: Arashmid Akhavain 
> >> Cc: Dino Farinacci ;
> >> ta-miyas...@kddi-research.jp; dmm 
> >> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
> >>
> >> On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain
> >>  wrote:
> >> >
> >> >
> >> >> -Original Message-
> >> >> From: Dino Farinacci [mailto:farina...@gmail.com]
> >> >> Sent: 06 September 2018 18:59
> >> >> To: Arashmid Akhavain 
> >> >> Cc: Tom Herbert ;
> >> >> ta-miyas...@kddi-research.jp; dmm 
> >> >> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-
> 01
> >> >>
> >> >> > Dino brought up a good point. Here is my two cents worth:
> >> >>
> >> >> Not sure which point.
> >> >>
> >> >> > As it was explained by Sridhar,  each UE can have multiple
> >> >> > contexts. For
> >> >> example, today some operators provide Data and VoLTE service to
> >> >> their customers. These two services are represented by separate
> >> >> GTP tunnels in the core with each tunnel tied up to a particular QoS.
> >> >> >
> >> >> > IPv4 didn't fit the bill when GTP work was under way as it
> >> >> > couldn't uniquely identify multiple UE
> >> >>
> >> >> There is no reason why it shouldn’t. And IPv6, for this use-case
> >> >> doesn’t add anything new other than a 28 bit
> >> >> traffic-class/flow-label that can provide more bits for “new
> functionality”.
> >> >
> >> >
> >> > [Arashmid]  And that's what I meant. Having a flow label is handy.
> >> > We can perhaps use it to identify different UE sessions.
> >> >
> >> Careful if you use the flow label to identify flows. It should be
> >> considered "soft identification" since it might not always be correct
> >> (it can be changed en route, isn't protected by any checksum, anyone
> >> can set it however they want, etc.). It's useful for things like ECMP
> >> that don't require 100% accuracy in identifying flow. The flow label
> >> was briefly considered for holding VNIs in network virtualization, but we
> talked them out of that.
> >>
> >> Tom
> >>
> >> >>
> >> >> > sessions/context/bearer. So, GTP and TEID did the job. But I
> >> >> > agree with
> >> >> Dino that IPv6 is much more versatile and is definitely worth
> >> >> looking at as an alternative.
> >> >>
> >> >> That is not what I said. I said “IP could have solved this problem”. And
> “IP”
> >> >> means either IPv4 or IPv6, or both at the same

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

[Arashmid Akhavain]

I understand your point, but there is no guarantee for a precise QoS without 
using some sort of encapsulation being it GTP, RSVP, etc. Even with tunnels, 
there is no guarantee that all nodes along the path have the same hardware 
capability and can provide the same QoS treatment.  

For example, the code points in routers need to be configured to correctly 
handle the EXP bits in MPLS labels. But there is no guarantee that all routers 
can support all values. The EXP values get mapped to code points but the 
mapping is not always one to one.  3-bit EXPs can map to 4 code points on those 
routers with less capable H/W.

Slicing is almost the same. It allows user traffic to be mapped to what the 
operator provides.
I agree with you that network should not touch/change original header bits. GTP 
or any other encapsulation easily allow for this. The question is whether we 
can provide for this without using encapsulation. IPv6 might be the answer. But 
as Tom pointed out, flow labels can still change in the middle. Is there any 
room for improvement. SIDs might present an opportunity.





> -Original Message-
> From: Dino Farinacci [mailto:farina...@gmail.com]
> Sent: 07 September 2018 13:08
> To: Arashmid Akhavain 
> Cc: Tom Herbert ; ta-miyas...@kddi-research.jp;
> dmm 
> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
> 
> I think you’ll still have the PHB re-marking issues I mentioned in previous
> emails. The question is, should the network touch/change any header bits of
> the packet the source has built. The answer should probably be no.
> 
> Having said that, GTP did it the right way, even though it cost in header
> length.
> 
> Dino
> 
> > On Sep 7, 2018, at 8:26 AM, Arashmid Akhavain
>  wrote:
> >
> > Correct, flow labels can change along the path. That's why I like the 
> > slicing
> concept.
> > UEs can request services with different attributes, operators control how
> service request are mapped into slices. I should look into the air side of the
> business and see what happens there.
> >
> >
> >
> >> -----Original Message-
> >> From: Tom Herbert [mailto:t...@quantonium.net]
> >> Sent: 07 September 2018 11:13
> >> To: Arashmid Akhavain 
> >> Cc: Dino Farinacci ;
> >> ta-miyas...@kddi-research.jp; dmm 
> >> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
> >>
> >> On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain
> >>  wrote:
> >>>
> >>>
> >>>> -Original Message-
> >>>> From: Dino Farinacci [mailto:farina...@gmail.com]
> >>>> Sent: 06 September 2018 18:59
> >>>> To: Arashmid Akhavain 
> >>>> Cc: Tom Herbert ; ta-miyasaka@kddi-
> research.jp;
> >>>> dmm 
> >>>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-
> 01
> >>>>
> >>>>> Dino brought up a good point. Here is my two cents worth:
> >>>>
> >>>> Not sure which point.
> >>>>
> >>>>> As it was explained by Sridhar,  each UE can have multiple
> >>>>> contexts. For
> >>>> example, today some operators provide Data and VoLTE service to
> >>>> their customers. These two services are represented by separate GTP
> >>>> tunnels in the core with each tunnel tied up to a particular QoS.
> >>>>>
> >>>>> IPv4 didn't fit the bill when GTP work was under way as it
> >>>>> couldn't uniquely identify multiple UE
> >>>>
> >>>> There is no reason why it shouldn’t. And IPv6, for this use-case
> >>>> doesn’t add anything new other than a 28 bit
> >>>> traffic-class/flow-label that can provide more bits for “new
> functionality”.
> >>>
> >>>
> >>> [Arashmid]  And that's what I meant. Having a flow label is handy.
> >>> We can perhaps use it to identify different UE sessions.
> >>>
> >> Careful if you use the flow label to identify flows. It should be
> >> considered "soft identification" since it might not always be correct
> >> (it can be changed en route, isn't protected by any checksum, anyone
> >> can set it however they want, etc.). It's useful for things like ECMP
> >> that don't require 100% accuracy in identifying flow. The flow label
> >> was briefly considered for holding VNIs in network virtualization, but we
> talked them out of that.
> >>
> >> Tom
> >>
> >>>>
> >>>>> sessions/conte

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

[Arashmid Akhavain]

Correct, flow labels can change along the path. That's why I like the slicing 
concept.
UEs can request services with different attributes, operators control how 
service request are mapped into slices. I should look into the air side of the 
business and see what happens there.



> -Original Message-
> From: Tom Herbert [mailto:t...@quantonium.net]
> Sent: 07 September 2018 11:13
> To: Arashmid Akhavain 
> Cc: Dino Farinacci ; ta-miyas...@kddi-research.jp;
> dmm 
> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
> 
> On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain
>  wrote:
> >
> >
> >> -Original Message-
> >> From: Dino Farinacci [mailto:farina...@gmail.com]
> >> Sent: 06 September 2018 18:59
> >> To: Arashmid Akhavain 
> >> Cc: Tom Herbert ; ta-miyas...@kddi-research.jp;
> >> dmm 
> >> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
> >>
> >> > Dino brought up a good point. Here is my two cents worth:
> >>
> >> Not sure which point.
> >>
> >> > As it was explained by Sridhar,  each UE can have multiple
> >> > contexts. For
> >> example, today some operators provide Data and VoLTE service to their
> >> customers. These two services are represented by separate GTP tunnels
> >> in the core with each tunnel tied up to a particular QoS.
> >> >
> >> > IPv4 didn't fit the bill when GTP work was under way as it couldn't
> >> > uniquely identify multiple UE
> >>
> >> There is no reason why it shouldn’t. And IPv6, for this use-case
> >> doesn’t add anything new other than a 28 bit traffic-class/flow-label
> >> that can provide more bits for “new functionality”.
> >
> >
> > [Arashmid]  And that's what I meant. Having a flow label is handy. We
> > can perhaps use it to identify different UE sessions.
> >
> Careful if you use the flow label to identify flows. It should be considered
> "soft identification" since it might not always be correct (it can be changed 
> en
> route, isn't protected by any checksum, anyone can set it however they want,
> etc.). It's useful for things like ECMP that don't require 100% accuracy in
> identifying flow. The flow label was briefly considered for holding VNIs in
> network virtualization, but we talked them out of that.
> 
> Tom
> 
> >>
> >> > sessions/context/bearer. So, GTP and TEID did the job. But I agree
> >> > with
> >> Dino that IPv6 is much more versatile and is definitely worth looking
> >> at as an alternative.
> >>
> >> That is not what I said. I said “IP could have solved this problem”. And 
> >> “IP”
> >> means either IPv4 or IPv6, or both at the same time.
> >
> >
> > [Arashmid]
> > How would we employ IPv4 to distinguish between different UE sessions.
> TOS?
> > Or you mean using encapsulation?
> >
> >>
> >> > A factor worth considering though is that the use of GTP and TEID
> >> > in mobile
> >> core allows operators to deal with QoS on their own terms. The
> >> tunnels with specific operator-controlled QoS are established by the
> >> control plane between eNB, SGW, and PGW. UEs or applications sitting
> >> in the UEs have no say in this. Well at least till the packet exits 
> >> operator's
> network.
> >>
> >> The problem with one header, is that if you re-mark (known as PHB
> >> markign in the ole days) you lose the original value. Encapsulation
> >> is useful here because you can map the inner to outer and anywhere
> >> along the path you can PHB remark on the outer header. And then the
> >> destination can see the orignal source’s ToS/QoS/TC/flow-label whatever.
> >
> >
> > [Arashmid] Yes, I agree. The original value is lost with PHB.
> > Encapsulation certainly makes things easier and the inner to outer
> > mapping trick has been widely used in IP and MPLS(multiple labels like
> > service and transport)
> >
> >>
> >> > Using the information in UE's IP packet header can jeopardise the
> >> > above tight QoS control. I think going
> >>
> >> Not if you encapsulate. But note with SRv6, you can possibly retain
> >> the original flow-label if the SID can retain those bits before
> >> overwriting the destination address from the option’s value.
> >
> > [Arashmid] Agree. Encapsulation does the trick again. That's why GTP
> > has worked well and served the purpos in the mobile back-haul so 

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

[Arashmid Akhavain]

Hi Tom and Dino,

Yes, I agree that these are the type of services that operator might want to 
look into to extend their revenue. Tom put it nicely: "it allows operators the 
chance to offer and monetize services that can benefit users".

I doubt that operators would like to allow dynamic QoS control to shift to UEs. 
But I think a mechanism that would allow QoS request to sit on the UE 
and the control to be done at the operator side would work well. This is value 
that the slicing concept in 5G brings to the table. It allows the operators
to setup preconfigured slices with different QoS, delay, jitter, etc behaviour. 
UE flows then will be mapped to appropriate 5G slice.

The complexity of the scheduler on the RAN side is a different story. But 
certainly use of the slicing concept makes the scheduler job less complicated.

Arashmid

> -Original Message-
> From: Dino Farinacci [mailto:farina...@gmail.com]
> Sent: 06 September 2018 19:01
> To: Tom Herbert 
> Cc: Arashmid Akhavain ; ta-
> miyas...@kddi-research.jp; dmm 
> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
> 
> I’d ask the question another way:
> 
> Would users like to set QoS bits that may charge them more for service?
> Could they set bits to get cheaper service?
> 
> Let alone if the operator can deliver the service (in this net-neutrality-less
> era).
> 
> Dino
> 
> > On Sep 6, 2018, at 3:15 PM, Tom Herbert  wrote:
> >
> > On Thu, Sep 6, 2018 at 2:49 PM, Arashmid Akhavain
> >  wrote:
> >> Dino brought up a good point. Here is my two cents worth:
> >>
> >> As it was explained by Sridhar,  each UE can have multiple contexts. For
> example, today some operators provide Data and VoLTE service to their
> customers. These two services are represented by separate GTP tunnels in
> the core with each tunnel tied up to a particular QoS.
> >>
> >> IPv4 didn't fit the bill when GTP work was under way as it couldn't
> uniquely identify multiple UE sessions/context/bearer. So, GTP and TEID did
> the job. But I agree with Dino that IPv6 is much more versatile and is
> definitely worth looking at as an alternative.
> >>
> >> A factor worth considering though is that the use of GTP and TEID in
> mobile core allows operators to deal with QoS on their own terms. The
> tunnels with specific operator-controlled QoS are established by the control
> plane between eNB, SGW, and PGW. UEs or applications sitting in the UEs
> have no say in this. Well at least till the packet exits operator's network.
> >>
> >> Using the information in UE's IP packet header can jeopardise the above
> tight QoS control. I think going down this path, operators need proof that
> they will be still in the driving seat and QoS cannot be dictated/tampered by
> the UE or any application running in it.
> >>
> >> Now, here is an interesting question for the operators. Would any
> operator be interested in allowing QoS  to be set by the UE or by applications
> running in the UE and charged for by the network? "Yes" could potentially
> imply impacts on the air interface, UE resource block allocation and can make
> scheduling on the RAN side much more complex.
> >>
> >
> > Hi Arashmid,
> >
> > I might pose the question a bit differently: Do operators want to
> > offer a rich set of services, e.g. QoS, and allow applications request
> > what services they want applied for their packets? I believe the
> > answer to that should be "yes" since it allows operators the chance
> > offer and monetize services that can benefit users. That is the easier
> > question to ask. The harder one is _how_ to do this in a secure,
> > generic, net neutrality compliant, practical, and fair manner that
> > doesn't require users to divulge the details of their content to the
> > provider or the whole Internet. Firewall and Service Tickets is being
> > proposed as one such mechanism to solve this (see
> > https://tools.ietf.org/html/draft-herbert-fast).
> >
> > Tom
> >
> >> Arashmid
> >>
> >>
> >>> -Original Message-
> >>> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dino Farinacci
> >>> Sent: 06 September 2018 12:45
> >>> To: Tom Herbert 
> >>> Cc: ta-miyas...@kddi-research.jp; dmm 
> >>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-
> 01
> >>>
> >>>> Behcet,
> >>>>
> >>>> I was thinking if TEID is need then that can be encoded in a
> >>>> locator easily enough.
> >>>>
> >>>> Tom
> &g

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

[Arashmid Akhavain]

> -Original Message-
> From: Dino Farinacci [mailto:farina...@gmail.com]
> Sent: 06 September 2018 18:59
> To: Arashmid Akhavain 
> Cc: Tom Herbert ; ta-miyas...@kddi-research.jp;
> dmm 
> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
> 
> > Dino brought up a good point. Here is my two cents worth:
> 
> Not sure which point.
> 
> > As it was explained by Sridhar,  each UE can have multiple contexts. For
> example, today some operators provide Data and VoLTE service to their
> customers. These two services are represented by separate GTP tunnels in
> the core with each tunnel tied up to a particular QoS.
> >
> > IPv4 didn't fit the bill when GTP work was under way as it couldn't
> > uniquely identify multiple UE
> 
> There is no reason why it shouldn’t. And IPv6, for this use-case doesn’t add
> anything new other than a 28 bit traffic-class/flow-label that can provide
> more bits for “new functionality”.


[Arashmid]  And that's what I meant. Having a flow label is handy. We can 
perhaps use it to identify
different UE sessions.

> 
> > sessions/context/bearer. So, GTP and TEID did the job. But I agree with
> Dino that IPv6 is much more versatile and is definitely worth looking at as an
> alternative.
> 
> That is not what I said. I said “IP could have solved this problem”. And “IP”
> means either IPv4 or IPv6, or both at the same time.


[Arashmid] 
How would we employ IPv4 to distinguish between different UE sessions. TOS?
Or you mean using encapsulation?

> 
> > A factor worth considering though is that the use of GTP and TEID in mobile
> core allows operators to deal with QoS on their own terms. The tunnels with
> specific operator-controlled QoS are established by the control plane
> between eNB, SGW, and PGW. UEs or applications sitting in the UEs have no
> say in this. Well at least till the packet exits operator's network.
> 
> The problem with one header, is that if you re-mark (known as PHB markign
> in the ole days) you lose the original value. Encapsulation is useful here
> because you can map the inner to outer and anywhere along the path you
> can PHB remark on the outer header. And then the destination can see the
> orignal source’s ToS/QoS/TC/flow-label whatever.


[Arashmid] Yes, I agree. The original value is lost with PHB. Encapsulation 
certainly
makes things easier and the inner to outer mapping trick has been widely used
in IP and MPLS(multiple labels like service and transport)

> 
> > Using the information in UE's IP packet header can jeopardise the
> > above tight QoS control. I think going
> 
> Not if you encapsulate. But note with SRv6, you can possibly retain the
> original flow-label if the SID can retain those bits before overwriting the
> destination address from the option’s value.

[Arashmid] Agree. Encapsulation does the trick again. That's why GTP has worked
well and served the purpos in the mobile back-haul so far.

> 
> Dino
> 
> >  down this path, operators need proof that they will be still in the driving
> seat and QoS cannot be dictated/tampered by the UE or any application
> running in it.
> >
> > Now, here is an interesting question for the operators. Would any operator
> be interested in allowing QoS  to be set by the UE or by applications running
> in the UE and charged for by the network? "Yes" could potentially imply
> impacts on the air interface, UE resource block allocation and can make
> scheduling on the RAN side much more complex.
> >
> > Arashmid
> >
> >
> >> -Original Message-
> >> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dino Farinacci
> >> Sent: 06 September 2018 12:45
> >> To: Tom Herbert 
> >> Cc: ta-miyas...@kddi-research.jp; dmm 
> >> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
> >>
> >>> Behcet,
> >>>
> >>> I was thinking if TEID is need then that can be encoded in a locator
> >>> easily enough.
> >>>
> >>> Tom
> >>
> >> Not if a locator is a PGW that is shared by many UEs.
> >>
> >> 3GPP wants per bearer awareness so they need a specific ID, that
> >> could have been the UE’s IP address. And with IPv6 it can be unique
> >> and not the issue that Sridhar brought up.
> >>
> >> If ILA was in use, just use the ILA-ID for this purpose.
> >>
> >> Dino
> >>
> >> ___
> >> dmm mailing list
> >> dmm@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dmm

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

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

[Arashmid Akhavain]

Dino brought up a good point. Here is my two cents worth:

As it was explained by Sridhar,  each UE can have multiple contexts. For 
example, today some operators provide Data and VoLTE service to their 
customers. These two services are represented by separate GTP tunnels in the 
core with each tunnel tied up to a particular QoS.

IPv4 didn't fit the bill when GTP work was under way as it couldn't uniquely 
identify multiple UE sessions/context/bearer. So, GTP and TEID did the job. But 
I agree with Dino that IPv6 is much more versatile and is definitely worth 
looking at as an alternative.

A factor worth considering though is that the use of GTP and TEID in mobile 
core allows operators to deal with QoS on their own terms. The tunnels with 
specific operator-controlled QoS are established by the control plane between 
eNB, SGW, and PGW. UEs or applications sitting in the UEs have no say in this. 
Well at least till the packet exits operator's network.

Using the information in UE's IP packet header can jeopardise the above tight 
QoS control. I think going down this path, operators need proof that they will 
be still in the driving seat and QoS cannot be dictated/tampered by the UE or 
any application running in it. 

Now, here is an interesting question for the operators. Would any operator be 
interested in allowing QoS  to be set by the UE or by applications running in 
the UE and charged for by the network? "Yes" could potentially imply impacts on 
the air interface, UE resource block allocation and can make scheduling on the 
RAN side much more complex.

Arashmid


> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dino Farinacci
> Sent: 06 September 2018 12:45
> To: Tom Herbert 
> Cc: ta-miyas...@kddi-research.jp; dmm 
> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
> 
> > Behcet,
> >
> > I was thinking if TEID is need then that can be encoded in a locator
> > easily enough.
> >
> > Tom
> 
> Not if a locator is a PGW that is shared by many UEs.
> 
> 3GPP wants per bearer awareness so they need a specific ID, that could have
> been the UE’s IP address. And with IPv6 it can be unique and not the issue
> that Sridhar brought up.
> 
> If ILA was in use, just use the ILA-ID for this purpose.
> 
> Dino
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

[Arashmid Akhavain]

Today TEID is a MUST in mobile core and as Sridhar indicated in his emails 
identifies a bearer or context.
I agree with Tom. A mechanism to encode the TEID should work.

Arashmid

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Behcet Sarikaya
Sent: 06 September 2018 12:18
To: Tom Herbert 
Cc: ta-miyas...@kddi-research.jp; dmm 
Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01


On Thu, Sep 6, 2018 at 10:40 AM Tom Herbert 
mailto:t...@quantonium.net>> wrote:
On Thu, Sep 6, 2018 at 3:24 AM, Sridhar Bhaskaran
mailto:sridhar.bhaska...@gmail.com>> wrote:
> My comments inline marked [SB]
>
>> > >>> It was never clear to me and no one could ever explain exactly why a
>> > >>> TEID is needed. I presumed for accounting reasons. But if there was a
>> > >>> one-to-one mapping between tunnel and user, why couldn’t the inner 
>> > >>> addresses
>> > >>> be used for accounting?
>> >
>> > [Sridhar] In EPC, each bearer has a GTPU tunnel. TEID identifies a
>> > tunnel and hence consequently a bearer. Once the bearer context is
>> > identified the QoS and charging policy applicable to the bearer is applied.
>> > So the purpose of TEID is not just for accounting. Its for QoS treatment,
>> > charging and bearer context identification.
>>
>> You told me what a TEID is but you didn’t say why you need to use it
>> versus using the destination IP address for the tunnel.
>>
>>
>> > In 5G, each PDU session has a GTPU tunnel. So TEID identifies the PDU
>> > session whereas the QFI carried in GTPU extension header identifies the
>> > flow. So in 5G TEID + QFI is used for QoS treatment and charging.
>>
>> When a packet is encapsulated in a tunnel, a packet has 4 addresses, which
>> tells us (1) the UE, (2) the destination it is talking to, (3) the
>> encapsualting node, and (4) the decapsulating node.
>>
>> So again, why use more space in the packet, when you have sufficient
>> information to identify a user, and therefore their packet policy?
>>
> [SB] Lets say we only use UE IP address and no TEID. How will you identify
> the bearer context the packet belongs? One UE may use multiple radio bearers
> / QoS flows. DSCP in IPv4 and Flow Label in IPv6 is one option but these are
> IP level markings which could be changed by any on path routers. In order to
> uniquely identify the bearer / qos flow a particular packet for a UE
> belongs, GTPU uses TEID.

Sridhar,

Couldn't the TEID be encoded in the outer IP address of an
encpasulation or network overlay in a similar way that VNIs are
encoded in IP addresses in virtual networking?

Tom

ILA if used would remove any need for tunneling and TEID is for tunneling.

Actually if you read 29.244 it is completely based on legacy protocols with no 
IdLoc content at all, as Shunsuke mentioned.

Behcet
>
> Also the IP addresses (at least for IPv4) allocated to UE by PGW / SMF are
> not always unique. The same IP pools can be shared across multiple PDNs /
> DNs as long as these PDNs / DNs are separate autonomous networks. So just
> relying on UE IP address alone will result in wrong context identification
> for the uplink traffic. There is a clear one to one mapping of Radio bearer
> to the EPS bearer / QoS flow required all the way upto the anchor node for
> charging and QoS treatment. This comes from the requirements in stage 2
> documents (c.f section 4.7 of TS 23.401 for EPC and 5.7 of TS 23.501 for
> 5G).
>
> There are also requirements to support non-IP protocols like Ethernet PDU
> and Unstructured PDU types in 5G.
>
>> >>
>> > >>> How can packets be sent if the session is not setup. If the session
>> > >>> is not setup, the encapsulator should have no state. And packets 
>> > >>> should be
>> > >>> dropped locally and not go far to get an error back. This sounds
>> > >>> architecturally broken.
>> >
>> > [Sridhar] The purpose of GTP-U error indication is to signal in band to
>> > the sender that a GTP-U tunnel endpoint (TEID) at the receiving side is 
>> > lost
>> > for any reason. "No session exist" does not mean Session
>>
>> What does lost mean? You mean the path from encapsulator to decapsulator
>> is not working? And since we are in a packet network, that path can be
>> restored quite quickly.
>
>
> [SB] Lost here means - the "context" at the receiving entity is deleted. For
> e.g due to administrative reasons, gNB or eNB removes the radio bearers and
> correspondingly the GTPU context. If gNB or eNB loses a context for known
> reasons, there could be signaling from gNB / eNB to AMF/MME and
> corresponding removal of PDU session / EPS bearer at the core network. But
> if the context is removed due to administrative reasons or unforeseen local
> errors, signaling from gNB / eNB to AMF / MME may not happen. Hence the GTPU
> error indication is an inband error detection mechanism.
>
> Note TEID identifies a context at the receiving side. So all GTPU error
> indication tells is that the receiver is not able to identify any context
> for the received TEID.
>
>>
>> > 

Re: [DMM] Fwd: New Version Notification for draft-hmm-dmm-5g-uplane-analysis-01.txt

[Arashmid Akhavain]

Alex,
I think you missed this disclaimer in 
"All values in the example are illustration purpose only"

Generally speaking, there is no guarantee for a point to point link.


Arashmid

> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alexandre
> Petrescu
> Sent: 20 August 2018 06:48
> To: dmm@ietf.org
> Subject: Re: [DMM] Fwd: New Version Notification for draft-hmm-dmm-5g-
> uplane-analysis-01.txt
> 
> Hi, thanks for the draft.  I am happy you wrote and published it.
> 
> I am looking forward for a packet capture from a live cellular network that
> illustrates this outer packet header format described in the draft.
> 
> In particular, the Source and Destination IPv6 addresses (not IPv4).
> 
> I can suppose that the two addresses would have same prefix, because that
> would be a point-to-point link and these links would have same prefix.  (i.e. 
> if
> the src is 2001:db8:1:1::1 then dst would be
> 2001:db8:1:1::2 and not 2001:db8:1:2::1).
> 
> This is only supposition from my side, because I have never seen a packet
> capture of this.
> 
> > 3.5.  Packet Format
> >
> >Figure 4 shows a packet format example of GTP-U over IPv6 that
> >carries an extension header for QFI and an IPv6 PDU.  All values in
> >the example are illustration purpose only.  The encoding of PDU
> >Session Container for QFI refers to [TS.38.415-3GPP].
> >
> >  0   1   2   3
> >  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >  Outer IPv6 Header
> >  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  |Version| DSCP=EF   |   Flow Label  |
> >  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  |  Payload Length   | NxtHdr=17(UDP)|Hop Limit  |
> >  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  |   |
> >  +   +
> >  |   |
> >  +   Source IPv6 Address +
> >  |2001:db8:1:1::1|
> >  +   +
> >  |   |
> >  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  |   |
> >  +   +
> >  |   |
> >  +  Destination IPv6 Address +
> >  |2001:db8:1:2::1|
> >  +   +
> >  |   |
> >  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> Alex
> 
> Le 10/08/2018 à 11:24, Shunsuke Homma a écrit :
> > Hi DMM folks,
> >
> > We reflected feedback from 3GPP CT4 on
> > draft-hmm-dmm-5g-uplane-analysis and uploaded the new version. We
> need
> > more reviews from both IETF and 3GPP for further improvement. We will
> > appreciate if you can give comments or feedback to this I-D.
> >
> > Best regards,
> >
> > Shunsuke
> >
> >
> >  Forwarded Message 
> > Subject: New Version Notification for
> > draft-hmm-dmm-5g-uplane-analysis-01.txt
> > Date: Fri, 10 Aug 2018 01:44:20 -0700
> > From: internet-dra...@ietf.org
> > To:  daniel.vo...@bell.ca , Daniel Voyer
> > , Takuya Miyasaka
> > , Satoru Matsushima
> > , Shunsuke Homma
> > 
> >
> >
> > A new version of I-D, draft-hmm-dmm-5g-uplane-analysis-01.txt
> > has been successfully submitted by Shunsuke Homma and posted to the
> > IETF repository.
> >
> > Name:    draft-hmm-dmm-5g-uplane-analysis
> > Revision:    01
> > Title:    User Plane Protocol and Architectural Analysis on 3GPP
> > 5G System Document date:    2018-08-10
> > Group:    Individual Submission
> > Pages:    30
> > URL:
> > https://www.ietf.org/internet-drafts/draft-hmm-dmm-5g-uplane-analysis-
> > 01.txt
> >
> > Status:
> > https://datatracker.ietf.org/doc/draft-hmm-dmm-5g-uplane-analysis/
> > Htmlized:
> > https://tools.ietf.org/html/draft-hmm-dmm-5g-uplane-analysis-01
> > Htmlized:
> > https://datatracker.ietf.org/doc/html/draft-hmm-dmm-5g-uplane-analysis
> > Diff:
> > https://www.ietf.org/rfcdiff?url2=draft-hmm-dmm-5g-uplane-analysis-01
> >
> > Abstract:
> >     This document analyzes the mobile user plane protocol and the
> >     architecture specified in 3GPP 5G documents.  The analysis work is
> > to
> >     clarify those specifications, extract protocol and architectural
> >     requirements and derive evaluation 

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

[Arashmid Akhavain]

I agree with the current LS

Arashmid

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Tuesday, July 17, 2018 3:49 PM
To: dmm@ietf.org
Subject: Re: [DMM] New Liaison Statement, "CP-173160: New Study Item on User 
Plane Protocol in 5GC"

All:

Thank you for the discussion today in the DMM meeting on the Liaison response 
to 3GPP CT4 group.  There was one comment at the microphone that we should not 
reference individual I-D's (non working documents) in the response. But, as we 
discussed and per the below summary, we have explained the criteria for 
inclusion / exclusion of I-D's.  If you still object to it, please let us know. 
We are extending the deadline for comments till Friday, 20th of July.

Dapeng & Sri




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

"Sri Gundavelli (sgundave)" mailto:sgund...@cisco.com>> 
Mon, 09 July 2018 17:35 UTCShow 
header<https://mailarchive.ietf.org/arch/browse/dmm/>

Ok!  Thank you Kalyani and Arashmid.





Change-1: Add to the last sentence.



"Also please provide any evaluation criteria that could help us in progressing 
our work to support 5G."



Change-2: Add to the second sentence, of second paragraph



+ " and building proof of concept demos."





Now, I need to pull this back for edits. Let me do that.  I hope this makes a 
difference in CT4 discussions.



All - Let us know if you have any issue with these additions, or to the 
original proposed text.





Sri

















On 7/9/18, 9:41 AM, "Bogineni, Kalyani" 
mailto:kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com%3cmailto:kalyani.bogin...@verizonwireless.com>>>
 wrote:



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 
mailto:arashmid.akhav...@huawei.com<mailto:arashmid.akhav...@huawei.com%3cmailto:arashmid.akhav...@huawei.com>>>;
 dmm@ietf.org<mailto:dmm@ietf.org<mailto:dmm@ietf.org%3cmailto: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" 
mailto:arashmid.akhav...@huawei.com<mailto:arashmid.akhav...@huawei.com%3cmailto:arashmid.akhav...@huawei.com>>>

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 
mailto:arashmid.akhav...@huawei.com<mailto:arashmid.akhav...@huawei.com%3cmailto:arashmid.akhav...@huawei.com>>>;
 dmm@ietf.org<mailto:dmm@ietf.org<mailto:dmm@ietf.org%3cmailto: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 d

Re: [DMM] Comment on SRv6-mobile-userplane

[Arashmid Akhavain]

Hi Uma,
You wrote:
“However, if this is seen as GTP replacement option, by moving TEID of the GTP 
header encoded into each SRv6 SID, the unintended consequence is we are making 
3GPP functionalities that are associated with TEID specific to one transport 
underlay.”

[Arashmid] Let me try a more generalized version of your statement:

“Constructing SIDs based on a specific structure locks the transport underlay 
to the specific service for which the SID is constructed for.”

The SID although routable but is only local the segment end point. How its 
construct locks the underlying transport layer to only a single service?

From: Uma Chunduri
Sent: Wednesday, July 18, 2018 12:31 PM
To: Arashmid Akhavain ; Pablo Camarillo 
(pcamaril) 
Cc: dmm@ietf.org; Alberto Rodriguez Natal (natal) ; 
spr...@ietf.org
Subject: RE: Comment on SRv6-mobile-userplane

Hi Arashmid,


>>[Uma]:  2 quick and minor corrections for the above first.“we encode the TEID 
>>into a SID”  ==> 
>>https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-02#section-5.1  
>>says “Note that in this mode the TEID is embedded in each SID.”
>>(section 5.1.3 confirms this)

 >[Arashmid] Embed vs Encode? Is this issue?

[Uma2:]It’s not embed or encode. It says each SID.



>[Arashmid] Today each PDU session gets its own set of TEIDs between eNB and 
>SGW and between SGW and PGW. For example for a UE with both internet access 
>and VoLTE, there are two GTP tunnels between the eNB and the SGW and two other 
>GTP tunnels between the SGW and the PGW.
>We maintain this in traditional mode.

[Uma2]: I am not questioning how each bearer get a different TEID or how 
separate tunnels are maintained per PDU session between eNB-SGW or SGW-PGW.  
It’s good this being planned to achieve in traditional mode. However, if this 
is seen as GTP replacement option, by moving TEID of the GTP header encoded 
into each SRv6 SID, the unintended consequence is we are making 3GPP 
functionalities that are associated with TEID specific to one transport 
underlay.
There are various other modes defined in the document, for example 
https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-02#section-5.3 
(called Enhanced mode with unchanged gNB GTP behavior)
In that case I see separation maintained and with a possibility of multiple 
SRv6 features, that can be applied in underlay as needed.

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

Re: [DMM] Comment on SRv6-mobile-userplane

[Arashmid Akhavain]

Hi Uma,

Please see my replies inline [Arashmid]

Cheers,
Arashmid

From: Uma Chunduri
Sent: Wednesday, July 18, 2018 11:50 AM
To: Arashmid Akhavain ; Pablo Camarillo 
(pcamaril) 
Cc: dmm@ietf.org; Alberto Rodriguez Natal (natal) ; 
spr...@ietf.org
Subject: RE: Comment on SRv6-mobile-userplane

Arash,


In-line [Uma]:

--
Uma C.

From: Arashmid Akhavain
Sent: Wednesday, July 18, 2018 9:18 AM

Hi Uma,
I am not sure if I understand your concern. In traditional mode, we encode the 
TEID into a SID. This is the mode that draft bogineni refers to as the simplest 
form of using SRv6 for the N9 interface.

[Uma]:  2 quick and minor corrections for the above first.

1.  “we encode the TEID into a SID”  ==> 
https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-02#section-5.1  
says “Note that in this mode the TEID is embedded in each SID.” (section 5.1.3 
confirms this)

[Arashmid] Embed vs Encode? Is this issue?


2.  Traditional mode as documented ietf-dmm-srv6 applies to both N3 and N9
[Arashmid] Yes, it does, but the focus of draft bogenini is N9

>Only the head nodes know that TEID has been encoded into the SID. Tandem nodes 
>treat the traffic as normal SRv6 traffic. Are you saying that the use of SRv6 
>in general forces the underlying say MPLS transport to convert to SRv6?

[Uma]:  The problem with removing GTP header and keeping the same in each SRH 
SIDs make the underlay specific to SRv6.
 Pablo’s below response says – “The Traditional mode is only 
offering GTP replacement for specific PDU sessions with complete independence 
from the transport network.”
I don’t see the draft text reflects this.

[Arashmid] Today each PDU session gets its own set of TEIDs between eNB and SGW 
and between SGW and PGW. For example for a UE with both internet access and 
VoLTE, there are two GTP tunnels between the eNB and the SGW and two other GTP 
tunnels between the SGW and the PGW. We maintain this in traditional mode.

For example in interworking model when we need to deal with IPv4 GTP tunnels, 
the SA and DA part of the SID will remain the same, but the TEID will be 
different. 4 GTP tunnels for the above mentioned UE sessions will produce 4 
SIDs which differ by the bits identifying the TEID



Cheers,
Arash

From: Uma Chunduri
Sent: Tuesday, July 17, 2018 3:10 PM
To: Pablo Camarillo (pcamaril) mailto:pcama...@cisco.com>>
Cc: dmm@ietf.org<mailto:dmm@ietf.org>; Arashmid Akhavain 
mailto:arashmid.akhav...@huawei.com>>; Alberto 
Rodriguez Natal (natal) mailto:na...@cisco.com>>; 
spr...@ietf.org<mailto:spr...@ietf.org>
Subject: RE: Comment on SRv6-mobile-userplane

[Added Spring too, as one of the chairs, Bruno asked us to discuss]

Hi Pablo,

Please see in in-line [Uma]:

--
Uma C.

From: Pablo Camarillo (pcamaril) [mailto:pcama...@cisco.com]
Sent: Tuesday, July 17, 2018 11:25 AM
To: Uma Chunduri mailto:uma.chund...@huawei.com>>
Cc: dmm@ietf.org<mailto:dmm@ietf.org>; Arashmid Akhavain 
mailto:arashmid.akhav...@huawei.com>>; Alberto 
Rodriguez Natal (natal) mailto:na...@cisco.com>>
Subject: Comment on SRv6-mobile-userplane

Hi Uma,

During the presentation of draft-bogineni-dmm-optimized-mobile-user-plane you 
have raised a comment saying that SRv6 mandates an integration in between the 
overlay and the underlay transport network.

I would like to clarify that this is NOT true. Please read 
https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-02#section-5.1
The Traditional mode is only offering GTP replacement for specific PDU sessions 
with complete independence from the transport network. No matter whether the 
transport is MPLS, IPv6 or whatever -without any SR at all-.


[Uma]:  It is positioned as one of the alternative to replace GTP-U in the data 
path.

From Section 5.1

“   In the traditional mobile network, an UE session is mapped 1-for-1
   with a specific GTP tunnel (TEID).  This 1-for-1 mapping is
   replicated here to replace the GTP encaps with the SRv6 encaps, while
   not changing anything else.

   This mode minimizes the changes required to the entire system and it
   is a good starting point for forming the common basis.  Note that in
   this mode the TEID is embedded in each SID.”

I also believe, that way because this is being sent as response to CT4 as a 
replacement alternative to GTP-U with SRv6 underlay in traditional mode.

https://tools.ietf.org/html/draft-bogineni-dmm-optimized-mobile-user-plane-01#section-6.1


“   In its most basic form, SRv6 can be used as a simple drop-in

   alternative for GTP tunnels.  The control plane in this approach

   remains the same, and still attempts to establish GTP-U tunnels and

   communicate TEIDs between the tunnel end points.  However, at the

   next level, SRv6 capable nodes use SIDs to direct user traffic

   between the UPFs.”


If we propose this is a drop-in replacement for GTP-U –  this could force (with 
the approval of 

Re: [DMM] Comment on SRv6-mobile-userplane

[Arashmid Akhavain]

Hi Tom,
Thank you for the reply. You are right, the underlay network doesn't care... I 
think this is also true for scenarios where the extension header is present.

Arashmid

-Original Message-
From: Tom Herbert [mailto:t...@quantonium.net] 
Sent: Wednesday, July 18, 2018 10:38 AM
To: Arashmid Akhavain 
Cc: Uma Chunduri ; Pablo Camarillo (pcamaril) 
; spr...@ietf.org; dmm@ietf.org
Subject: Re: [DMM] Comment on SRv6-mobile-userplane

On Wed, Jul 18, 2018 at 6:18 AM, Arashmid Akhavain 
 wrote:
> Hi Uma,
>
>
>
> I am not sure if I understand your concern. In traditional mode, we 
> encode the TEID into a SID. This is the mode that draft bogineni 
> refers to as the simplest form of using SRv6 for the N9 interface.
>
> Only the head nodes know that TEID has been encoded into the SID. 
> Tandem nodes treat the traffic as normal SRv6 traffic. Are you saying 
> that the use of SRv6 in general forces the underlying say MPLS 
> transport to convert to SRv6?

I think the terminology being used in the draft might be making this seem 
complicated than it actually is. AFAICT, SRv6 traditional mode is nothing more 
than IP in IP encapsulation, so the requirement of the underlay is that it 
forwards IPv6 and intermediate nodes treat the traffic as "normal IPv6 
traffic". There is no segment routing involved, no extension headers needed, 
and the only upgrade for the network is to support IPv6. One caveat to that is 
that some intermediate nodes may want to do DPI into transport layer to get 
ports for ECMP or other reasons, if that is desirable it would be easy enough 
to alternatively use a UDP encapsulation-- either continue with GTP or switch 
to a more generic one like GUE.

Tom

>
>
>
> Cheers,
>
> Arash
>
>
>
> From: Uma Chunduri
> Sent: Tuesday, July 17, 2018 3:10 PM
> To: Pablo Camarillo (pcamaril) 
> Cc: dmm@ietf.org; Arashmid Akhavain ; 
> Alberto Rodriguez Natal (natal) ; spr...@ietf.org
> Subject: RE: Comment on SRv6-mobile-userplane
>
>
>
> [Added Spring too, as one of the chairs, Bruno asked us to discuss]
>
>
>
> Hi Pablo,
>
>
>
> Please see in in-line [Uma]:
>
>
>
> --
>
> Uma C.
>
>
>
> From: Pablo Camarillo (pcamaril) [mailto:pcama...@cisco.com]
> Sent: Tuesday, July 17, 2018 11:25 AM
> To: Uma Chunduri 
> Cc: dmm@ietf.org; Arashmid Akhavain ; 
> Alberto Rodriguez Natal (natal) 
> Subject: Comment on SRv6-mobile-userplane
>
>
>
> Hi Uma,
>
>
>
> During the presentation of 
> draft-bogineni-dmm-optimized-mobile-user-plane
> you have raised a comment saying that SRv6 mandates an integration in 
> between the overlay and the underlay transport network.
>
>
>
> I would like to clarify that this is NOT true. Please read
> https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-02#secti
> on-5.1
>
> The Traditional mode is only offering GTP replacement for specific PDU 
> sessions with complete independence from the transport network. No 
> matter whether the transport is MPLS, IPv6 or whatever -without any SR at 
> all-.
>
>
>
>
>
> [Uma]:  It is positioned as one of the alternative to replace GTP-U in 
> the data path.
>
>
>
> From Section 5.1
>
> “   In the traditional mobile network, an UE session is mapped 1-for-1
>
>with a specific GTP tunnel (TEID).  This 1-for-1 mapping is
>
>replicated here to replace the GTP encaps with the SRv6 encaps, 
> while
>
>not changing anything else.
>
>
>
>This mode minimizes the changes required to the entire system and 
> it
>
>is a good starting point for forming the common basis.  Note that 
> in
>
>this mode the TEID is embedded in each SID.”
>
>
>
> I also believe, that way because this is being sent as response to CT4 
> as a replacement alternative to GTP-U with SRv6 underlay in traditional mode.
>
>
>
> https://tools.ietf.org/html/draft-bogineni-dmm-optimized-mobile-user-p
> lane-01#section-6.1
>
>
>
> “   In its most basic form, SRv6 can be used as a simple drop-in
>
>alternative for GTP tunnels.  The control plane in this approach
>
>remains the same, and still attempts to establish GTP-U tunnels and
>
>communicate TEIDs between the tunnel end points.  However, at the
>
>next level, SRv6 capable nodes use SIDs to direct user traffic
>
>between the UPFs.”
>
>
>
>
>
> If we propose this is a drop-in replacement for GTP-U –  this could 
> force (with the approval of IETF and 3GPP)  every operator to use 
> SRv6; as TEID functionality is basic to any 3GPP procedure (not only 
> for Xn, N2 and whatever mobility case out there, service request, 
> paging and you name i

Re: [DMM] Comment on SRv6-mobile-userplane

[Arashmid Akhavain]

Hi Uma,

I am not sure if I understand your concern. In traditional mode, we encode the 
TEID into a SID. This is the mode that draft bogineni refers to as the simplest 
form of using SRv6 for the N9 interface.
Only the head nodes know that TEID has been encoded into the SID. Tandem nodes 
treat the traffic as normal SRv6 traffic. Are you saying that the use of SRv6 
in general forces the underlying say MPLS transport to convert to SRv6?

Cheers,
Arash

From: Uma Chunduri
Sent: Tuesday, July 17, 2018 3:10 PM
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org; Arashmid Akhavain ; Alberto 
Rodriguez Natal (natal) ; spr...@ietf.org
Subject: RE: Comment on SRv6-mobile-userplane

[Added Spring too, as one of the chairs, Bruno asked us to discuss]

Hi Pablo,

Please see in in-line [Uma]:

--
Uma C.

From: Pablo Camarillo (pcamaril) [mailto:pcama...@cisco.com]
Sent: Tuesday, July 17, 2018 11:25 AM
To: Uma Chunduri mailto:uma.chund...@huawei.com>>
Cc: dmm@ietf.org<mailto:dmm@ietf.org>; Arashmid Akhavain 
mailto:arashmid.akhav...@huawei.com>>; Alberto 
Rodriguez Natal (natal) mailto:na...@cisco.com>>
Subject: Comment on SRv6-mobile-userplane

Hi Uma,

During the presentation of draft-bogineni-dmm-optimized-mobile-user-plane you 
have raised a comment saying that SRv6 mandates an integration in between the 
overlay and the underlay transport network.

I would like to clarify that this is NOT true. Please read 
https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-02#section-5.1
The Traditional mode is only offering GTP replacement for specific PDU sessions 
with complete independence from the transport network. No matter whether the 
transport is MPLS, IPv6 or whatever -without any SR at all-.


[Uma]:  It is positioned as one of the alternative to replace GTP-U in the data 
path.

From Section 5.1

“   In the traditional mobile network, an UE session is mapped 1-for-1
   with a specific GTP tunnel (TEID).  This 1-for-1 mapping is
   replicated here to replace the GTP encaps with the SRv6 encaps, while
   not changing anything else.

   This mode minimizes the changes required to the entire system and it
   is a good starting point for forming the common basis.  Note that in
   this mode the TEID is embedded in each SID.”

I also believe, that way because this is being sent as response to CT4 as a 
replacement alternative to GTP-U with SRv6 underlay in traditional mode.

https://tools.ietf.org/html/draft-bogineni-dmm-optimized-mobile-user-plane-01#section-6.1


“   In its most basic form, SRv6 can be used as a simple drop-in

   alternative for GTP tunnels.  The control plane in this approach

   remains the same, and still attempts to establish GTP-U tunnels and

   communicate TEIDs between the tunnel end points.  However, at the

   next level, SRv6 capable nodes use SIDs to direct user traffic

   between the UPFs.”


If we propose this is a drop-in replacement for GTP-U –  this could force (with 
the approval of IETF and 3GPP)  every operator to use SRv6; as TEID 
functionality is basic to any 3GPP procedure (not only for Xn, N2 and whatever 
mobility case out there, service request, paging and you name it..).
I don’t think you want to exclude SR-MPLS if operator wants (or any TE) it or 
transitioning to.

On the other hand if it is only for some PDU sessions then this need to be 
specifically mentioned in the draft as well as the “optimized mobile user 
plane” response.


Hence, if an operator would like to have integration of the overlay and 
underlay (for end-to-end network slicing), he can have such integration. If 
this is not desired, the dmm-srv6-mobile-uplane proposal can work completely 
independently from the transport, as already documented in the draft.

[Uma]: It would be great if we strive to achieve that independence as much as 
possible while focusing on the value and feature SRv6 brings it to the table.

I will check with the rest of co-authors of the draft to see whether we should 
clarify in the draft the independence from the transport network.

[Uma]: Sure, thanks for your consideration.

Cheers,
Pablo.
___
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"

[Arashmid Akhavain]

Hi Sri,

A minor addition to the end of this sentence would perhaps do the trick.

These proposals include protocol specifications based on new/existing 
protocols, proposals covering requirements/analysis/comparison of various 
approaches, and building proof of concept demos.

Arashmid

> -Original Message-
> From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
> Sent: 09 July 2018 11:51
> To: Arashmid Akhavain ; dmm@ietf.org
> Subject: Re: 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-mobilit

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

[Arashmid Akhavain]

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 for the last while.
> >
> >I agree, we do want to keep it simple, but the POCs can certainly add to
> >the strength of the LS.
> >
> >Regards,
> >Arashmid
> >
> >-Original Message-
> >From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
> >Sent: Saturday, July 07, 2018 2:25 AM
> >To: Arashmid Akhavain ; dmm@ietf.org
> >Subject: Re: New Liaison Statement, "CP-173160: New Study Item on User
> >Plane Protocol in 5GC"
> >
> >Hi Arashmid,
> >
> >Thanks for the feedback.
> >
> >I have added a link to the DMM WG pages and it has links to all the DMM
> >documents. I think that should be OK, we don’t have to explicitly list
> >out every single I-D at this stage. As we move forward and based on WG
> >discussions/progress, we can provide more detailed feedback on each
> >document. I suggest we keep this simple for now.
> >
> >
> >
> >> So, what happens next? We wait for their reply?
> >
> >This is just a response to the LS; more an information exchange on the
> >status/progress.
> >
> >
> >
> >Regards
> >Sri
> >
> >
> >
> >
> >On 7/6/18, 1:56 PM, "Arashmid Akhavain"
> 
> >wrote:
>

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

[Arashmid Akhavain]

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 for the last 
while.

I agree, we do want to keep it simple, but the POCs can certainly add to the 
strength of the LS.

Regards,
Arashmid

-Original Message-
From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] 
Sent: Saturday, July 07, 2018 2:25 AM
To: Arashmid Akhavain ; dmm@ietf.org
Subject: Re: New Liaison Statement, "CP-173160: New Study Item on User Plane 
Protocol in 5GC"

Hi Arashmid,

Thanks for the feedback.

I have added a link to the DMM WG pages and it has links to all the DMM 
documents. I think that should be OK, we don’t have to explicitly list out 
every single I-D at this stage. As we move forward and based on WG 
discussions/progress, we can provide more detailed feedback on each document. I 
suggest we keep this simple for now.



> So, what happens next? We wait for their reply?

This is just a response to the LS; more an information exchange on the 
status/progress.



Regards
Sri




On 7/6/18, 1:56 PM, "Arashmid Akhavain" 
wrote:

>Hi Sri,
>
>We might also want to add draft-camarillo-dmm-srv6-mobile-pocs-00
>under "Related Documents".
>
>Also, we might want to say something like:
>"Although we will NOT pick a particular approach, we will be ready to 
>provide further assistance to 3GPP regarding the technical details of 
>different candidates."
>
>So, what happens next? We wait for their reply?
>
>Cheers,
>Arashmid
>
>> -Original Message-
>> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli
>> (sgundave)
>> Sent: 06 July 2018 13:49
>> To: dmm@ietf.org
>> Subject: Re: [DMM] New Liaison Statement, "CP-173160: New Study Item 
>> on User Plane Protocol in 5GC"
>> 
>> We plan to send the following response to 3GPP CT4.  If you have any 
>>quick  comments/corrections/suggestions, please let us know in a day.
>> 
>> 
>> 
>> ³
>> Thank you for your Liaison request (Reference: CP-173160) and for 
>>sharing  the information on the status of the CT4 study item on 
>>user-plane protocol  for 5GC. The IETF DMM working group wants to 
>>acknowledge your request  and want to share the following update.
>> 
>> IETF DMM working is currently reviewing various proposals on 
>>approaches  for realizing optimizations in user-plane for mobile 
>>packet core. These  proposals include protocol specifications based on 
>>new/existing protocols  and proposals covering 
>>requirements/analysis/comparison of various  approaches. At this point 
>>of time, some of these documents are working  group documents and some 
>>are individual submissions and yet to be  adopted as working group 
>>documents.  Based on the working group interest,  feedback 
>>charter-scope, the working group may choose to adopt some of  these 
>>work items as working group documents and at that time will seek  
>>feedback from 3GPP.
>> 
>> We also would like to state that the DMM working group will not be in 
>>a  position to pick a single approach/solution as THE approach for 
>>user-plane  optimization. Most likely the working group may 
>>standardize more than one  approach, but will characterize each of 
>>these approaches based on its  technical capabilities and limitations. 
>>This approach would be consistent with  the approach that IETF took 
>>with IPv6 transitioning work, where IETF  standardized multiple 
>>approaches including DSLite, NAT64, Gi-DSLite and  other approaches.
>> 
>> Finally, IETF would like to point 3GPP to the following documents 
>> under consideration.
>> 
>> http://www.ietf.org/id/draft-bogineni-dmm-optimized-mobile-user-plane
>> -
>> 01.tx
>> t (Individual submission)
>> 
>> https://www.ietf.org/internet-drafts/draft-hmm-dmm-5g-uplane-analysis
>> -
>> 00.tx
>> t (Individual submission)
>> 
>> 
>> Related Documents:
>> 
>> 
>> https://www.ietf.org/id/draft-ietf-dmm-srv6-mobile-uplane-02.txt
>>(Working
>> group document)
>> 
>> 
>> Link to DMM Pages:
>> 
>> https://datatracker.ietf.org/wg/dmm/documents/
>> 
>> 
>> 
>> Please let us know if you need any additional information.
>> "
>> 
>> -
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On 4/11/18, 11:16 AM, "Liaison Statement Management Tool"
>> 
&

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

[Arashmid Akhavain]

Hi Sri,

We might also want to add draft-camarillo-dmm-srv6-mobile-pocs-00
under "Related Documents".

Also, we might want to say something like:
"Although we will NOT pick a particular approach, 
we will be ready to provide further assistance to 3GPP regarding 
the technical details of different candidates."

So, what happens next? We wait for their reply? 

Cheers,
Arashmid

> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli
> (sgundave)
> Sent: 06 July 2018 13:49
> To: dmm@ietf.org
> Subject: Re: [DMM] New Liaison Statement, "CP-173160: New Study Item on
> User Plane Protocol in 5GC"
> 
> We plan to send the following response to 3GPP CT4.  If you have any quick
> comments/corrections/suggestions, please let us know in a day.
> 
> 
> 
> ³
> Thank you for your Liaison request (Reference: CP-173160) and for sharing
> the information on the status of the CT4 study item on user-plane protocol
> for 5GC. The IETF DMM working group wants to acknowledge your request
> and want to share the following update.
> 
> IETF DMM working is currently reviewing various proposals on approaches
> for realizing optimizations in user-plane for mobile packet core. These
> proposals include protocol specifications based on new/existing protocols
> and proposals covering requirements/analysis/comparison of various
> approaches. At this point of time, some of these documents are working
> group documents and some are individual submissions and yet to be
> adopted as working group documents.  Based on the working group interest,
> feedback charter-scope, the working group may choose to adopt some of
> these work items as working group documents and at that time will seek
> feedback from 3GPP.
> 
> We also would like to state that the DMM working group will not be in a
> position to pick a single approach/solution as THE approach for user-plane
> optimization. Most likely the working group may standardize more than one
> approach, but will characterize each of these approaches based on its
> technical capabilities and limitations. This approach would be consistent with
> the approach that IETF took with IPv6 transitioning work, where IETF
> standardized multiple approaches including DSLite, NAT64, Gi-DSLite and
> other approaches.
> 
> Finally, IETF would like to point 3GPP to the following documents under
> consideration.
> 
> http://www.ietf.org/id/draft-bogineni-dmm-optimized-mobile-user-plane-
> 01.tx
> t (Individual submission)
> 
> https://www.ietf.org/internet-drafts/draft-hmm-dmm-5g-uplane-analysis-
> 00.tx
> t (Individual submission)
> 
> 
> Related Documents:
> 
> 
> https://www.ietf.org/id/draft-ietf-dmm-srv6-mobile-uplane-02.txt (Working
> group document)
> 
> 
> Link to DMM Pages:
> 
> https://datatracker.ietf.org/wg/dmm/documents/
> 
> 
> 
> Please let us know if you need any additional information.
> "
> 
> -
> 
> 
> 
> 
> 
> 
> 
> 
> 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://datatracker.ietf.org/liaison/1572/
> >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 

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

[Arashmid Akhavain]

Hi Sri,
There two drafts that DMM can perhaps use in the response. 

https://www.ietf.org/internet-drafts/draft-hmm-dmm-5g-uplane-analysis-00.txt
http://www.ietf.org/id/draft-bogineni-dmm-optimized-mobile-user-plane-01.txt

Please let us know how you would like to proceed and how we can help.

Arashmid

> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli
> (sgundave)
> Sent: 22 June 2018 12:24
> To: dmm@ietf.org
> Subject: Re: [DMM] New Liaison Statement, "CP-173160: New Study Item on
> User Plane Protocol in 5GC"
> 
> Folks - Back to this.
> 
> Any feedback on this? Now that we have waited for some time, I hope we
> now have a view on this LS. I tend to think we should send a response soon
> before the July deadline.
> 
> Sri
> 
> 
> 
> 
> 
> 
> 
> On 4/16/18, 9:47 AM, "dmm on behalf of Sri Gundavelli (sgundave)"
>  wrote:
> 
> >Hi Arashmid,
> >
> >I was not looking at their July date, but more about exchanging status
> >of the work and seek feedback.
> >
> >I think, we now are on the same page now.
> >
> >Sri
> >
> >
> >
> >
> >On 4/16/18, 8:37 AM, "Arashmid Akhavain"
> 
> >wrote:
> >
> >>Thanks Kalyani,
> >>That makes sense. The wording of the action item though sounded like
> >>3GPP was trying to impose a deadline.
> >>I just want to make sure that wasn't the case cause there is still a
> >>lot of work to be done.
> >>
> >>Arashmid
> >>
> >>> -Original Message-
> >>> From: Bogineni, Kalyani
> >>> [mailto:kalyani.bogin...@verizonwireless.com]
> >>> Sent: 16 April 2018 11:26
> >>> To: Arashmid Akhavain ; Sri
> Gundavelli
> >>> (sgundave) ; dmm@ietf.org
> >>> Subject: RE: New Liaison Statement, "CP-173160: New Study Item on
> >>> User Plane Protocol in 5GC"
> >>>
> >>> Arashmid - CT4 will start their study in July 2018. So work from
> >>>IETF can  provide input into that study.
> >>> Kalyani
> >>>
> >>> -Original Message-
> >>> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Arashmid
> >>>Akhavain
> >>> Sent: Monday, April 16, 2018 11:21 AM
> >>> To: Sri Gundavelli (sgundave) ; dmm@ietf.org
> >>> Subject: [E] Re: [DMM] New Liaison Statement, "CP-173160: New Study
> >>>Item  on User Plane Protocol in 5GC"
> >>>
> >>> Hi Sri,
> >>>
> >>> Thank you for clarification. I never suggested that IETF should
> >>>single out a  particular proposal. On the contrary, I believe DMM
> >>>should simply conduct  the study and provide 3GPP with all different
> >>>options. 3GPP will decide what  to do with the proposals from that
> >>>point on. As you mentioned there could  be several back and forth
> >>>between the two SDOs.
> >>>
> >>>
> >>>
> >>> So, while I agree with all points, I am still puzzled by the
> >>>following statement  in 3GPP email.
> >>>
> >>> What is the significance of the July 2018 date?
> >>>
> >>>
> >>>
> >>> ACTION:
> >>>
> >>> CT4 respectfully asks IETF DMM to provide any information that may
> >>> be relevant to the above CT4
> >>>
> >>> work by July 2018.
> >>>
> >>>
> >>>
> >>> Arashmid
> >>>
> >>>
> >>>
> >>> > -Original Message-
> >>>
> >>> > From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
> >>>
> >>> > Sent: 13 April 2018 19:06
> >>>
> >>> > To: Arashmid Akhavain ;
> dmm@ietf.org
> >>>
> >>> > Subject: Re: 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

Re: [DMM] draft-gundavelli-dmm-mfa

[Arashmid Akhavain]

Hi Marco,
Sorry about my tardy reply. Please see my comments inline [Arashmid]


From: Marco Liebsch [mailto:marco.lieb...@neclab.eu]
Sent: 11 May 2018 11:47
To: Arashmid Akhavain ; Sri Gundavelli 
; dmm@ietf.org
Subject: RE: draft-gundavelli-dmm-mfa

Hi Arashmid,

please find my take inline [ml].


From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Arashmid Akhavain
Sent: Donnerstag, 3. Mai 2018 23:38
To: Sri Gundavelli; dmm@ietf.org<mailto:dmm@ietf.org>
Subject: [DMM] draft-gundavelli-dmm-mfa

Hi Sri,
Please find below some questions and comments.

Best regards,
Arashmid

1- This technique certainly eliminates the need for fixed anchor points from 
the data plane point of view.
However, it is not clear what happens to other functions provided by the 
existing 3GPP fixed anchor points.
It should be possible to program the nodes for these additional functions as 
well. I think a list of existing functions or those required by 5G in 3GPP 
would be a good starting point for the discussion.

[ml] Good point, if we think about the MN's AG is a traditional data plane 
anchor with some extensions that enable it to be changed per the operation
described in this draft, all functions may move to the edge where the AG is 
deployed. That may work for metering, paging initiation and QoS
in case downstream labels are required for compatibility with the RAN.

[Arashmid] Do you mean that we move these functions into the AG itself? If so, 
then we need a mechanism to move say metering data from one AG to another
as MN moves around.

But then there is no QoS enforcement in a large part of the network in between
the CN and the MN's AG. Hence, the approach would benefit from enforcement of 
downlink QoS rules on the CN's anchor /CNA. What do you think?
[Arashmid] Yes, it allows policies to be enforced right at the edge. I think we 
should capture this in the draft. But let's discuss what happens to policies
(both uplink and downlink) as MN moves around.

2- Performance is another issue. How fast can we detect and then program MFA 
nodes? This is the issue that applies to all different approaches. I think 
performance merits a section in the draft.

[ml] The draft depicts a reactive approach, which should work and in the worst 
case it suffers from some packets' re-ordering after enforcing
the optimized route. Pro-active extensions should be possible and improve that 
situation.
[Arashmid] If I am not mistaken, while things are settling down, .the old AG 
can forward the packets to the new one as well. Yes we might end
up with out of order packets due to path latency differentials. But as you 
said, proactive measures can ease up the situation. Should this be reflected
in the draft?

3- An example with SRv6 and/or SRv6 with ID-LOC might serve the document well. 
Appendix?

[ml] Are you asking for details about other data plane protocols that are 
currently being discussed in the IETF? Since the MFA controller enforces 
policies
in the network edges (MN and CN side), these policies can result also in ILA or 
LISP mappings per an ingress node operation for the packets, no?
The current draft states at the beginning that it's not dependent on a 
particular data plane but it focuses on SRv6 so far. Which of the alternative 
data
plane protocols you think should be covered in the appendix?
[Arashmid] I was just thinking about adding an example for SRv6 since the draft 
singles it out. But a statement regarding ILA and LISP would certainly help to
highlight the versatility of the approach.

4- Page 5, end of MFA-MNA paragraph:
" Typically, the MFA-MNA function will be collocated with the UPF in the 3GPP 
5G system architecture."
Couldn't it be collocated with the gNB as well? Or did you purposely took gNB 
out to avoid touching the N3 interface?

[ml] The draft is supposed to be independent of a particular access network.. 
Move the MNA closer to the access network
and you may run your last mile protocol on a 1meter patch cable to the NB. 
That's loose coupling and keeps the interface between
control plane and the MNA decoupled from the interface between NB and control 
plane. Of course you may collocate
and run the MNA tightly coupled with any access-specific node and even merge 
the interfaces to the control plane.
[Arashmid] Yes, I agree. Thank you for clarifying.

5- When correspondent nodes are mobile themselves. e..g. UE-UE communication, 
isn't the MFA-CNA is just another MFA-MNA? Some clarification in the draft 
might come handy.

[ml] Sure. To differentiate between policy enforcement points on the data plane 
which are associated with the MN or the CN we
chose these abbreviations. They may be of the same type of node.

6- Page 14, figure 5: Need to change MFA-NMA-->MFA-MNA, and MFA-CAN--> MFA-CNA 
in the figure.

[ml] Thanks for spotting this, we'll correct in the update.

7- How does paging work? Not sure about this one, but is it possible for a UE 
to go to be idle (a new inactive state has also 

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

[Arashmid Akhavain]

You are right Uma,

Any deployment scenario (aside from green-field) will involve a combination of 
both address types.
IPv4 will be the dominant type at first while IPv6 gets introduced gradually.
Any mobility solution must address migration. Blank canvas is a nonstarter for 
operators.

Arashmid




> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Uma Chunduri
> Sent: 23 May 2018 13:08
> To: Dino Farinacci ; Satoru Matsushima
> 
> Cc: dmm 
> Subject: Re: [DMM] User Plane Protocol Study in 3GPP
> 
> Dear All,
> 
> For the Dino's question -
> 
> > Do you think carriers will build an IPv6-only NGC at this point in time?
> 
> I don't think so (from the existing deployments perspective, including early
> 5G transitions).
> 
> So, IMO - any mobility solution ought to be underlay independent - to allow
> flexibility for the operators. I see this discussion is independent of address
> space exhaustion or IPv6 address to UE..
> 
> --
> Uma C.
> 
> 
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dino Farinacci
> Sent: Tuesday, March 20, 2018 5:02 PM
> To: Satoru Matsushima 
> Cc: dmm 
> Subject: Re: [DMM] User Plane Protocol Study in 3GPP
> 
> That sounds like you want to do IPv4 over IPv6. Do you think carriers will
> build an IPv6-only NGC at this point in time?
> 
> Dino
> 
> > On Mar 20, 2018, at 6:33 PM, Satoru Matsushima
>  wrote:
> >
> > Next header type maybe?
> > Interestingly GTP-U doesn’t have it.
> >
> > Sent from my iPhone
> >
> > 2018/03/20 18:17、Dino Farinacci のメール:
> >
> >> How? Please summarize in one sentence and don’t me to a draft.
> >>
> >> Dino
> >>
> >>> On Mar 20, 2018, at 10:24 AM, Satoru Matsushima
>  wrote:
> >>>
> >>> Yes , supports IPv4 PDU with minimum effort.
> >>>
> >>> Sent from my iPhone
> >>>
> >>> 2018/03/20 16:47、Lyle Bertz のメール:
> >>>
>  I did not get to ask but I know your presentation talks about IPv6 but is
> there a requirement to support IPv4 mobile or dual stack?
> 
>  Lyle
> >>>
> >>> ___
> >>> dmm mailing list
> >>> dmm@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/dmm
> >>
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] draft-gundavelli-dmm-mfa

[Arashmid Akhavain]

Hi Sri,
Please find below some questions and comments.

Best regards,
Arashmid

1- This technique certainly eliminates the need for fixed anchor points from 
the data plane point of view.
However, it is not clear what happens to other functions provided by the 
existing 3GPP fixed anchor points.
It should be possible to program the nodes for these additional functions as 
well. I think a list of existing functions or those required by 5G in 3GPP 
would be a good starting point for the discussion.

2- Performance is another issue. How fast can we detect and then program MFA 
nodes? This is the issue that applies to all different approaches. I think 
performance merits a section in the draft.

3- An example with SRv6 and/or SRv6 with ID-LOC might serve the document well. 
Appendix?

4- Page 5, end of MFA-MNA paragraph:
" Typically, the MFA-MNA function will be collocated with the UPF in the 3GPP 
5G system architecture."
Couldn't it be collocated with the gNB as well? Or did you purposely took gNB 
out to avoid touching the N3 interface?

5- When correspondent nodes are mobile themselves. e.g. UE-UE communication, 
isn't the MFA-CNA is just another MFA-MNA? Some clarification in the draft 
might come handy.

6- Page 14, figure 5: Need to change MFA-NMA-->MFA-MNA, and MFA-CAN--> MFA-CNA 
in the figure.

7- How does paging work? Not sure about this one, but is it possible for a UE 
to go to be idle (a new inactive state has also been added in the spec) in one 
gNB and wake in another that connects to a different first hop router?

8- Page 19 after step 10: It might be useful to talk about how and when MFA-CN 
removes the rule for H1::/64 from AG-2. I guess it is something along what 
described in 4.3.

9-  Page 20, section 4.3, step 1: Might be useful to indicate how the system 
would know when a flow is inactive and hence the rules associated with it are 
no longer need.
___
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"

[Arashmid Akhavain]

Thanks Kalyani,
That makes sense. The wording of the action item though sounded like 3GPP was 
trying to impose a deadline.
I just want to make sure that wasn't the case cause there is still a lot of 
work to be done.

Arashmid

> -Original Message-
> From: Bogineni, Kalyani [mailto:kalyani.bogin...@verizonwireless.com]
> Sent: 16 April 2018 11:26
> To: Arashmid Akhavain <arashmid.akhav...@huawei.com>; Sri Gundavelli
> (sgundave) <sgund...@cisco.com>; dmm@ietf.org
> Subject: RE: New Liaison Statement, "CP-173160: New Study Item on User
> Plane Protocol in 5GC"
> 
> Arashmid - CT4 will start their study in July 2018. So work from IETF can
> provide input into that study.
> Kalyani
> 
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Arashmid Akhavain
> Sent: Monday, April 16, 2018 11:21 AM
> To: Sri Gundavelli (sgundave) <sgund...@cisco.com>; dmm@ietf.org
> Subject: [E] Re: [DMM] New Liaison Statement, "CP-173160: New Study Item
> on User Plane Protocol in 5GC"
> 
> Hi Sri,
> 
> Thank you for clarification. I never suggested that IETF should single out a
> particular proposal. On the contrary, I believe DMM should simply conduct
> the study and provide 3GPP with all different options. 3GPP will decide what
> to do with the proposals from that point on. As you mentioned there could
> be several back and forth between the two SDOs.
> 
> 
> 
> So, while I agree with all points, I am still puzzled by the following 
> statement
> in 3GPP email.
> 
> What is the significance of the July 2018 date?
> 
> 
> 
> ACTION:
> 
> CT4 respectfully asks IETF DMM to provide any information that may be
> relevant to the above CT4
> 
> work by July 2018.
> 
> 
> 
> Arashmid
> 
> 
> 
> > -Original Message-
> 
> > From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
> 
> > Sent: 13 April 2018 19:06
> 
> > To: Arashmid Akhavain <arashmid.akhav...@huawei.com>; dmm@ietf.org
> 
> > Subject: Re: 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"
> 
> > <arashmid.akhav...@huawei.com>
> 
> > 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 Akha

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

[Arashmid Akhavain]

Hi Sri,
Thank you for clarification. I never suggested that IETF should single out a 
particular proposal. On the contrary, I believe DMM should simply conduct the 
study and provide 3GPP with all different options. 3GPP will decide what to do 
with the proposals from that point on. As you mentioned there could be several 
back and forth between the two SDOs. 

So, while I agree with all points, I am still puzzled by the following 
statement in 3GPP email. 
What is the significance of the July 2018 date? 

ACTION:
CT4 respectfully asks IETF DMM to provide any information that may be relevant 
to the above CT4
work by July 2018.

Arashmid

> -Original Message-
> From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
> Sent: 13 April 2018 19:06
> To: Arashmid Akhavain <arashmid.akhav...@huawei.com>; dmm@ietf.org
> Subject: Re: 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"
> <arashmid.akhav...@huawei.com>
> 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 <arashmid.akhav...@huawei.com>; 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"
> >> <arashmid.akhav...@huawei.com>
> >> 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"
> >> >> <l...@ietf.org>
> >> >> wrote:
> >> >>
> >> >> >Title: CP-173160: New Study Item on User Plane Protocol in 5GC
> >> >> >Submission Date: 2018-04-11 URL 

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

[Arashmid Akhavain]

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 <arashmid.akhav...@huawei.com>; 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"
> <arashmid.akhav...@huawei.com>
> 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"
> >> <l...@ietf.org>
> >> 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://datatracker.ietf.org/liaison/1572/
> >> >Please reply by 2018-07-20
> >> >From: Satoru Matsushima <satoru.matsush...@g.softbank.co.jp>
> >> >To: Sri Gundavelli <sgund...@cisco.com>,Dapeng Liu
> >> ><maxpass...@gmail.com>
> >> >Cc: Dapeng Liu <maxpass...@gmail.com>,Terry Manderson
> >> ><terry.mander...@icann.org>,Distributed Mobility Management
> >> >Discussion List <dmm@ietf.org>,Sri Gundavelli
> >> ><sgund...@cisco.com>,Suresh Krishnan <sur...@kaloom.com> 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 

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

[Arashmid Akhavain]

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://datatracker.ietf.org/liaison/1572/
> >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#7919th ­ 20th Mar 2018Chennai, India
> >CT4#84   16th ­ 20th April 2018  Kunming, China
> >CT4#85   21st ­ 25th May 2018Osaka, Japan
> >CT#8011th ­ 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://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-04-11-3gpp-t
> >sgc
> >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
> https://www.ietf.org/mailman/listinfo/dmm
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Next Header in End.M.GTP6.D (draft-ietf-dmm-srv6-mobile-uplane-01)

[Arashmid Akhavain]

Hi Pablo,

We might need to add some clarification w.r.t state reduction as well and 
explain this in the context of different modes.

Cheers,
Arashmid

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Pablo Camarillo (pcamaril)
Sent: 10 April 2018 03:27
To: Kentaro Ebisawa ; dmm 
Subject: Re: [DMM] Next Header in End.M.GTP6.D 
(draft-ietf-dmm-srv6-mobile-uplane-01)

Hi Kentaro,

You are right. For each PDU session type you will have a different instance of 
an End.M.GTP6.D SID. We can add a note in the next revision of the draft in 
case this is not clear.

Thank you.

Cheers,
Pablo.

From: dmm > on behalf of 
Kentaro Ebisawa >
Date: Wednesday, 4 April 2018 at 11:08
To: dmm >
Subject: [DMM] Next Header in End.M.GTP6.D 
(draft-ietf-dmm-srv6-mobile-uplane-01)

Hi,

In "6.2. End.M.GTP6.D", how would SR Gateway know if user packet inside GTP is 
IPv4 or IPv6?
I think this info is required to set newly added SRH.NextHeader field in step 
3~5.

My understanding is that information would be provided by the control plane, 
and if that's correct, should SR Gateway have 2 (or more) SIDs corresponding to 
the type of user packet and also inform gNB to use different SIDs (dstAddr) 
based on user packet type?
One could also have SID per TEID, but I'm not sure if that's a good design 
choice considering the effort to reduce state in network nodes.

Thanks,
--
Kentaro Ebisawa 
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Arashmid Akhavain]

I agree on your comment about more use cases. We should consider all those 
scenarios and see what fits the bill.

Arashmid 

-Original Message-
From: Tom Herbert [mailto:t...@quantonium.net] 
Sent: 27 March 2018 15:59
To: Arashmid Akhavain <arashmid.akhav...@huawei.com>
Cc: Satoru Matsushima <satoru.matsush...@gmail.com>; dmm@ietf.org
Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1

On Tue, Mar 27, 2018 at 11:47 AM, Arashmid Akhavain 
<arashmid.akhav...@huawei.com> wrote:
> ID-LOC (SRV6, ILA, LISP, ILNP) would cover these use cases easily 
> since UE ID remains the same no matter what access technology we use.

Right, but I haven't seen anyone suggest GTP-U or CAPWAP for that list. There 
are more use cases now that seem to demand a more general and common 
encapsulation technique.

Tom

> Without ID-LOC, there is always going to be a need for all sort of 
> complicated control plane hand over procedures.
> Also, we end up with n2 interworking issue as we add more access technologies 
> to the mix.
>
> Arashmid
>
> -Original Message-
> From: Tom Herbert [mailto:t...@quantonium.net]
> Sent: 27 March 2018 14:25
> To: Arashmid Akhavain <arashmid.akhav...@huawei.com>
> Cc: Satoru Matsushima <satoru.matsush...@gmail.com>; dmm@ietf.org
> Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1
>
> On Tue, Mar 27, 2018 at 11:08 AM, Arashmid Akhavain 
> <arashmid.akhav...@huawei.com> wrote:
>> Tom,
>> Are you referring to a use case where the UE moves between different access 
>> technologies?
>>
> I think it's possible and should be a consideration. Countless devices are 
> already regularly multihomed between WiFi and mobile.
>
> Tom
>
>
>> Arashmid
>>
>>> IMO Unified concept in that encapsulation doesn’t seem to work i.n that 
>>> circumstance. When it comes to WiFi case, IETF has CAPWAP as the user plane 
>>> protocol which is also a foo-over-UDP variation.
>>>
>> Rigtht so if a WiFi network needs to talk to 3GPP network for a roaming 
>> device, what protocol are they going to use?
>>
>>
>>
>>
>>
>> -Original Message-
>> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
>> Sent: 27 March 2018 10:03
>> To: Satoru Matsushima <satoru.matsush...@gmail.com>
>> Cc: dmm@ietf.org
>> Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1
>>
>> On Mon, Mar 26, 2018 at 11:57 PM, Satoru Matsushima 
>> <satoru.matsush...@gmail.com> wrote:
>>> Thank you Tom,
>>>
>>> Unfortunately I couldn’t find clear advantage of GUE against GTP-U.
>>> (No offensive, please don’t get me wrong.)
>>>
>>> I couldn’t see GUE in NVO WG doc list. But I can see much more foo-over-UDP 
>>> type encapsulation in IETF.
>>
>> It's not in nvo3, it's now WGLC in intarea. See draft-ietf-intarea-gue and 
>> draft-ietf-intarea-gue-extensions.
>>
>>> IMO Unified concept in that encapsulation doesn’t seem to work i.n that 
>>> circumstance. When it comes to WiFi case, IETF has CAPWAP as the user plane 
>>> protocol which is also a foo-over-UDP variation.
>>>
>> Rigtht so if a WiFi network needs to talk to 3GPP network for a roaming 
>> device, what protocol are they going to use?
>>
>>> Nevertheless I think that that aspect would be a criteria for user plane 
>>> protocols comparison provided to 3GPP. But I don’t think it is good idea 
>>> that we provides 3GPP all kind of foo-over-UDP encapsulation protocols in 
>>> IETF. It would be better to pick SRv6 and some generic foo-over-UDP 
>>> protocol to be compared with GTP-U supported functionalities.
>>>
>> GUE is the generic foo-over-UDP protocol for that purpose.
>>
>>> Basic functionalities of GTP-U is that sequence number option, 
>>> extension-headers, and multicast and those should be the part of criteria. 
>>> IMO as you suggested, overhead size, performance, TE, extensibility and 
>>> encryption would be good idea for the criteria in addition to the above 
>>> fundamental ones.
>>>
>>> Best regards,
>>> --satoru
>>>
>>>
>>>
>>>> 2018/03/27 11:51、Tom Herbert <t...@quantonium.net>のメール:
>>>>
>>>> On Mon, Mar 26, 2018 at 6:30 PM, Satoru Matsushima 
>>>> <satoru.matsush...@gmail.com> wrote:
>>>>> Thank you Tom for your suggestion.
>>>>>
>>>>> Do you think that GUE has some advantages against GTP-U?
>>>>
>>>> I believe so. GUE is designed to be a general pu

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Arashmid Akhavain]

Hi Tom,
I totally understand your point.  But RFC8200 doesn't single out the source as 
the only node that can do this type of manipulation. "Any node along a packet's 
delivery path" is rather open to interpretation.

Arashmid

-Original Message-
From: Tom Herbert [mailto:t...@quantonium.net] 
Sent: 27 March 2018 15:50
To: Arashmid Akhavain <arashmid.akhav...@huawei.com>
Cc: Sri Gundavelli (sgundave) <sgund...@cisco.com>; dmm@ietf.org
Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1

On Tue, Mar 27, 2018 at 11:37 AM, Arashmid Akhavain 
<arashmid.akhav...@huawei.com> wrote:
> Although segment end points are nodes along packets' delivery path, they are 
> terminating a segment.
> So why is it considered a RFC8200 violation if SRH manipulation is restricted 
> to those nodes.
>
Hi Arashmid,

Because only the source of a packet is allowed to create extension headers. The 
source is identified by the source address, and we know that intermediate nodes 
in segment routing are not the source since they don't change to the source 
address to be their own. Creating extension headers when encapsulating is okay 
since the encapsulator is the source of the outer packet. The problems with EH 
insertion were enumerated in the discussion on 6man list.

Tom

> Arashmid
>
>
>
>
>
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
> Sent: 27 March 2018 11:05
> To: Sri Gundavelli (sgundave) <sgund...@cisco.com>
> Cc: dmm@ietf.org
> Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1
>
> On Tue, Mar 27, 2018 at 7:17 AM, Sri Gundavelli (sgundave) 
> <sgund...@cisco.com> wrote:
>>
>>
>> On 3/26/18, 5:16 PM, "Tom Herbert" <t...@quantonium.net> wrote:
>>
>>>> With regards to SR encapsulation: "this is using IP-in-IP as default.
>>>> Why not using UDP encapsulation?"
>>>
>>
>> I am really hoping we will be able to apply SRH insertion without the 
>> need for IP encapsulation. At least for mobile environments within a 
>> closed administrative domains, there should be exceptions for 
>> allowing insertion of SRH by a on-path node. I realize there are 
>> issues with ICMP error messages hitting the source etc, but we should 
>> be able to document those issues and specify work arounds. I 
>> understand there have been discussions on this topic before, but I 
>> hope authors will find some agreements for the same.
>>
> Sri,
>
> There's been quite a bit of discussion on this on 6man list with reference to 
> draft-voyer-6man-extension-header-insertion. The problem is that extension 
> header insertion would violate RFC8200: "Extension headers (except for the 
> Hop-by-Hop Options header) are not processed, inserted, or deleted by any 
> node along a packet's delivery path".
>
> In addition to the the protocol ramifications of doing this (dealing with 
> MTU, ICMP error, etc.) there were questions as to whether the benefit is 
> significant enough to justify the cost, as well as what does it mean to 
> define Internet protocols that only work in a "controlled domain".
>
> I believe 6man is the right place for further discussions on this.
>
> Tom
>
>
>
>
>>
>> Sri
>> 
>>
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Arashmid Akhavain]

Hi Charlie,

Mobile IPV6 can be among the alternatives. But mobility is just one the 
important features in 3GPP.
There are several aspects such as impact on CP, support for service chaining, 
traffic engineering, QoS and BW reservation, etc. that perhaps require further 
investigation.

Best regards,
Arashmid




-Original Message-
From: Charlie Perkins [mailto:charles.perk...@earthlink.net] 
Sent: 27 March 2018 15:02
To: Arashmid Akhavain <arashmid.akhav...@huawei.com>
Cc: dmm@ietf.org
Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1

Hello Arashmid,

> if a WiFi network needs to talk to 3GPP network for a roaming device, what 
> protocol are they going to use?

They could use Mobile IPv6, which was designed for exactly this purpose.

Do you think that would work?

Regards,
Charlie P.



On 3/27/2018 11:08 AM, Arashmid Akhavain wrote:
> Tom,
> Are you referring to a use case where the UE moves between different access 
> technologies?
>
> Arashmid
>
>> IMO Unified concept in that encapsulation doesn’t seem to work i.n that 
>> circumstance. When it comes to WiFi case, IETF has CAPWAP as the user plane 
>> protocol which is also a foo-over-UDP variation.
>>
> Rigtht so if a WiFi network needs to talk to 3GPP network for a roaming 
> device, what protocol are they going to use?
>
>
>
>
>
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
> Sent: 27 March 2018 10:03
> To: Satoru Matsushima <satoru.matsush...@gmail.com>
> Cc: dmm@ietf.org
> Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1
>
> On Mon, Mar 26, 2018 at 11:57 PM, Satoru Matsushima 
> <satoru.matsush...@gmail.com> wrote:
>> Thank you Tom,
>>
>> Unfortunately I couldn’t find clear advantage of GUE against GTP-U.
>> (No offensive, please don’t get me wrong.)
>>
>> I couldn’t see GUE in NVO WG doc list. But I can see much more foo-over-UDP 
>> type encapsulation in IETF.
> It's not in nvo3, it's now WGLC in intarea. See draft-ietf-intarea-gue and 
> draft-ietf-intarea-gue-extensions.
>
>> IMO Unified concept in that encapsulation doesn’t seem to work i.n that 
>> circumstance. When it comes to WiFi case, IETF has CAPWAP as the user plane 
>> protocol which is also a foo-over-UDP variation.
>>
> Rigtht so if a WiFi network needs to talk to 3GPP network for a roaming 
> device, what protocol are they going to use?
>
>> Nevertheless I think that that aspect would be a criteria for user plane 
>> protocols comparison provided to 3GPP. But I don’t think it is good idea 
>> that we provides 3GPP all kind of foo-over-UDP encapsulation protocols in 
>> IETF. It would be better to pick SRv6 and some generic foo-over-UDP protocol 
>> to be compared with GTP-U supported functionalities.
>>
> GUE is the generic foo-over-UDP protocol for that purpose.
>
>> Basic functionalities of GTP-U is that sequence number option, 
>> extension-headers, and multicast and those should be the part of criteria. 
>> IMO as you suggested, overhead size, performance, TE, extensibility and 
>> encryption would be good idea for the criteria in addition to the above 
>> fundamental ones.
>>
>> Best regards,
>> --satoru
>>
>>
>>
>>> 2018/03/27 11:51、Tom Herbert <t...@quantonium.net>のメール:
>>>
>>> On Mon, Mar 26, 2018 at 6:30 PM, Satoru Matsushima 
>>> <satoru.matsush...@gmail.com> wrote:
>>>> Thank you Tom for your suggestion.
>>>>
>>>> Do you think that GUE has some advantages against GTP-U?
>>> I believe so. GUE is designed to be a general purposed multi use 
>>> case encapsulation. The defined GUE extensions deal with problems 
>>> and provide features of encapsulation (header security, 
>>> fragmentation, payload security, checksum handling etc.). This is 
>>> done without resorting to expensive TLV processing. GUE also allows 
>>> "private data"
>>> that could be used for use case specific info-- so TLVs or GTP 
>>> extensions could be encoded so in that sense it's a superset of GTP 
>>> functionality. As I mentioned, GUE has a mode for encapsulating IP 
>>> in UDP with minimal overhead (direct IP over UDP).
>>>
>>>> When it comes to foo over UDP capsulation, does GUE benefit user plane 
>>>> beyond GTP-U?
>>>>
>>> I think so. Perhaps the biggest advantage is the GUE can be used 
>>> accross different use cases and technologies. It's generic protocol 
>>> so it could be used for multiple use cases in a mobile network. For 
>>> instance, a UE might talk to a a

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Arashmid Akhavain]

ID-LOC (SRV6, ILA, LISP, ILNP) would cover these use cases easily since UE ID 
remains the same no matter what access 
technology we use.
Without ID-LOC, there is always going to be a need for all sort of complicated 
control plane hand over procedures.
Also, we end up with n2 interworking issue as we add more access technologies 
to the mix.

Arashmid

-Original Message-
From: Tom Herbert [mailto:t...@quantonium.net] 
Sent: 27 March 2018 14:25
To: Arashmid Akhavain <arashmid.akhav...@huawei.com>
Cc: Satoru Matsushima <satoru.matsush...@gmail.com>; dmm@ietf.org
Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1

On Tue, Mar 27, 2018 at 11:08 AM, Arashmid Akhavain 
<arashmid.akhav...@huawei.com> wrote:
> Tom,
> Are you referring to a use case where the UE moves between different access 
> technologies?
>
I think it's possible and should be a consideration. Countless devices are 
already regularly multihomed between WiFi and mobile.

Tom


> Arashmid
>
>> IMO Unified concept in that encapsulation doesn’t seem to work i.n that 
>> circumstance. When it comes to WiFi case, IETF has CAPWAP as the user plane 
>> protocol which is also a foo-over-UDP variation.
>>
> Rigtht so if a WiFi network needs to talk to 3GPP network for a roaming 
> device, what protocol are they going to use?
>
>
>
>
>
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
> Sent: 27 March 2018 10:03
> To: Satoru Matsushima <satoru.matsush...@gmail.com>
> Cc: dmm@ietf.org
> Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1
>
> On Mon, Mar 26, 2018 at 11:57 PM, Satoru Matsushima 
> <satoru.matsush...@gmail.com> wrote:
>> Thank you Tom,
>>
>> Unfortunately I couldn’t find clear advantage of GUE against GTP-U.
>> (No offensive, please don’t get me wrong.)
>>
>> I couldn’t see GUE in NVO WG doc list. But I can see much more foo-over-UDP 
>> type encapsulation in IETF.
>
> It's not in nvo3, it's now WGLC in intarea. See draft-ietf-intarea-gue and 
> draft-ietf-intarea-gue-extensions.
>
>> IMO Unified concept in that encapsulation doesn’t seem to work i.n that 
>> circumstance. When it comes to WiFi case, IETF has CAPWAP as the user plane 
>> protocol which is also a foo-over-UDP variation.
>>
> Rigtht so if a WiFi network needs to talk to 3GPP network for a roaming 
> device, what protocol are they going to use?
>
>> Nevertheless I think that that aspect would be a criteria for user plane 
>> protocols comparison provided to 3GPP. But I don’t think it is good idea 
>> that we provides 3GPP all kind of foo-over-UDP encapsulation protocols in 
>> IETF. It would be better to pick SRv6 and some generic foo-over-UDP protocol 
>> to be compared with GTP-U supported functionalities.
>>
> GUE is the generic foo-over-UDP protocol for that purpose.
>
>> Basic functionalities of GTP-U is that sequence number option, 
>> extension-headers, and multicast and those should be the part of criteria. 
>> IMO as you suggested, overhead size, performance, TE, extensibility and 
>> encryption would be good idea for the criteria in addition to the above 
>> fundamental ones.
>>
>> Best regards,
>> --satoru
>>
>>
>>
>>> 2018/03/27 11:51、Tom Herbert <t...@quantonium.net>のメール:
>>>
>>> On Mon, Mar 26, 2018 at 6:30 PM, Satoru Matsushima 
>>> <satoru.matsush...@gmail.com> wrote:
>>>> Thank you Tom for your suggestion.
>>>>
>>>> Do you think that GUE has some advantages against GTP-U?
>>>
>>> I believe so. GUE is designed to be a general purposed multi use 
>>> case encapsulation. The defined GUE extensions deal with problems 
>>> and provide features of encapsulation (header security, 
>>> fragmentation, payload security, checksum handling etc.). This is 
>>> done without resorting to expensive TLV processing. GUE also allows 
>>> "private data"
>>> that could be used for use case specific info-- so TLVs or GTP 
>>> extensions could be encoded so in that sense it's a superset of GTP 
>>> functionality. As I mentioned, GUE has a mode for encapsulating IP 
>>> in UDP with minimal overhead (direct IP over UDP).
>>>
>>>> When it comes to foo over UDP capsulation, does GUE benefit user plane 
>>>> beyond GTP-U?
>>>>
>>> I think so. Perhaps the biggest advantage is the GUE can be used 
>>> accross different use cases and technologies. It's generic protocol 
>>> so it could be used for multiple use cases in a mobile network. For 
>>> instance, a UE

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Arashmid Akhavain]

Although segment end points are nodes along packets' delivery path, they are 
terminating a segment.
So why is it considered a RFC8200 violation if SRH manipulation is restricted 
to those nodes.

Arashmid





-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
Sent: 27 March 2018 11:05
To: Sri Gundavelli (sgundave) 
Cc: dmm@ietf.org
Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1

On Tue, Mar 27, 2018 at 7:17 AM, Sri Gundavelli (sgundave)  
wrote:
>
>
> On 3/26/18, 5:16 PM, "Tom Herbert"  wrote:
>
>>> With regards to SR encapsulation: "this is using IP-in-IP as default.
>>> Why not using UDP encapsulation?"
>>
>
> I am really hoping we will be able to apply SRH insertion without the 
> need for IP encapsulation. At least for mobile environments within a 
> closed administrative domains, there should be exceptions for allowing 
> insertion of SRH by a on-path node. I realize there are issues with 
> ICMP error messages hitting the source etc, but we should be able to 
> document those issues and specify work arounds. I understand there 
> have been discussions on this topic before, but I hope authors will 
> find some agreements for the same.
>
Sri,

There's been quite a bit of discussion on this on 6man list with reference to 
draft-voyer-6man-extension-header-insertion. The problem is that extension 
header insertion would violate RFC8200: "Extension headers (except for the 
Hop-by-Hop Options header) are not processed, inserted, or deleted by any node 
along a packet's delivery path".

In addition to the the protocol ramifications of doing this (dealing with MTU, 
ICMP error, etc.) there were questions as to whether the benefit is significant 
enough to justify the cost, as well as what does it mean to define Internet 
protocols that only work in a "controlled domain".

I believe 6man is the right place for further discussions on this.

Tom




>
> Sri
> 
>

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

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

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Arashmid Akhavain]

Tom,
Are you referring to a use case where the UE moves between different access 
technologies?

Arashmid

> IMO Unified concept in that encapsulation doesn’t seem to work i.n that 
> circumstance. When it comes to WiFi case, IETF has CAPWAP as the user plane 
> protocol which is also a foo-over-UDP variation.
>
Rigtht so if a WiFi network needs to talk to 3GPP network for a roaming device, 
what protocol are they going to use?





-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
Sent: 27 March 2018 10:03
To: Satoru Matsushima 
Cc: dmm@ietf.org
Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1

On Mon, Mar 26, 2018 at 11:57 PM, Satoru Matsushima 
 wrote:
> Thank you Tom,
>
> Unfortunately I couldn’t find clear advantage of GUE against GTP-U. 
> (No offensive, please don’t get me wrong.)
>
> I couldn’t see GUE in NVO WG doc list. But I can see much more foo-over-UDP 
> type encapsulation in IETF.

It's not in nvo3, it's now WGLC in intarea. See draft-ietf-intarea-gue and 
draft-ietf-intarea-gue-extensions.

> IMO Unified concept in that encapsulation doesn’t seem to work i.n that 
> circumstance. When it comes to WiFi case, IETF has CAPWAP as the user plane 
> protocol which is also a foo-over-UDP variation.
>
Rigtht so if a WiFi network needs to talk to 3GPP network for a roaming device, 
what protocol are they going to use?

> Nevertheless I think that that aspect would be a criteria for user plane 
> protocols comparison provided to 3GPP. But I don’t think it is good idea that 
> we provides 3GPP all kind of foo-over-UDP encapsulation protocols in IETF. It 
> would be better to pick SRv6 and some generic foo-over-UDP protocol to be 
> compared with GTP-U supported functionalities.
>
GUE is the generic foo-over-UDP protocol for that purpose.

> Basic functionalities of GTP-U is that sequence number option, 
> extension-headers, and multicast and those should be the part of criteria. 
> IMO as you suggested, overhead size, performance, TE, extensibility and 
> encryption would be good idea for the criteria in addition to the above 
> fundamental ones.
>
> Best regards,
> --satoru
>
>
>
>> 2018/03/27 11:51、Tom Herbert のメール:
>>
>> On Mon, Mar 26, 2018 at 6:30 PM, Satoru Matsushima 
>>  wrote:
>>> Thank you Tom for your suggestion.
>>>
>>> Do you think that GUE has some advantages against GTP-U?
>>
>> I believe so. GUE is designed to be a general purposed multi use case 
>> encapsulation. The defined GUE extensions deal with problems and 
>> provide features of encapsulation (header security, fragmentation, 
>> payload security, checksum handling etc.). This is done without 
>> resorting to expensive TLV processing. GUE also allows "private data"
>> that could be used for use case specific info-- so TLVs or GTP 
>> extensions could be encoded so in that sense it's a superset of GTP 
>> functionality. As I mentioned, GUE has a mode for encapsulating IP in 
>> UDP with minimal overhead (direct IP over UDP).
>>
>>> When it comes to foo over UDP capsulation, does GUE benefit user plane 
>>> beyond GTP-U?
>>>
>> I think so. Perhaps the biggest advantage is the GUE can be used 
>> accross different use cases and technologies. It's generic protocol 
>> so it could be used for multiple use cases in a mobile network. For 
>> instance, a UE might talk to a a low latency service application via 
>> GUE. To the server this looks much more like simple virtualization or 
>> encapsulation and GUE includes potential optimizations. Similarly, 
>> GUE also could be use to connect across different access technologies 
>> that might not be 3GPP (like roaming between WIFI and a mobile network).
>> Conceptually, other IETF defined encapsulations could also be used 
>> for this (e.g. IPIP, LISP, GRE, VXLAN), but GUE is specifically 
>> designed to be multi use case, low overhead, but still extensible.
>>
>> We intend to use ILA in a similar multi-use case fashion, however 
>> when encapsulation is required (like SR TE is needed, or we need an 
>> encrypted tunnel) then I believe GUE is a good alternative for that 
>> case to provide necessary functionality and extensibility.
>>
>> Tom
>>
 2018/03/27 9:16、Tom Herbert のメール:

 On Wed, Mar 21, 2018 at 9:27 AM, Sri Gundavelli (sgundave) 
  wrote:
> FYI. This is the notes that Carlos captured. Thank you Carlos!!
>
> We are also waiting for Lyle to share his notes. Please review and 
> comment, if you see any mistakes.
>

 With regards to SR encapsulation: "this is using IP-in-IP as default.
 Why not using UDP encapsulation?"

 There is some rationale for UDP encapsulation here to maximize 
 compatibility with the network and potentially intermediate nodes 
 like firewalls. For example, in the performance numbers that 
 Kalyani 

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

[Arashmid Akhavain]

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

Arashmid

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

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

Sri


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



On Tue, Mar 20, 2018 at 11:28 AM, Sri Gundavelli (sgundave) 
> wrote:
>  [KB] I will let Sri answer this.

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



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

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


Right.

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

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

My three cents :-)

Regards,
Behcet
Sri


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

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



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

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

Re: [DMM] Mapping System scalability

[Arashmid Akhavain]

Alberto,

Our tests showed  very promising results for public cloud Pub/Sub (DHT based). 
We got about 120ms performance out of these systems.
Given that these systems are designed to mover large chunk of data, it is very 
reasonable to assume that the performance for these DHT based mapping systems 
can be further improved for 5G.

Arashmid

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alberto Rodriguez-Natal
Sent: Friday, March 16, 2018 4:20 AM
To: dmm@ietf.org
Cc: l...@ietf.org list 
Subject: [DMM] Mapping System scalability

Hi all,

In the DMM call this week, some people asked about the scalability of the 
Mapping System. The LISP community has delivered different solutions to address 
that challenge over the years. Here are some pointers to different Mapping 
System implementations, I'm sure that the folks at the LISP WG list can provide 
even more references.

LISP Delegated Database Tree (LISP DDT) [1] follows a DNS-like structure and 
it's designed to be deployed at Internet scale. For an academic work on a 
DNS-based Mapping System take a look at [2].

Designs leveraging DHTs have also been considered to enable high scalabilty, 
see for instance [3][4]. For a survey on different Mapping System options see 
[5] (I wasn't able to find an open version of this article unfortunately).

For those interested in current research efforts, recent works include 
decentralized designs [6] or even Blockchain-based approaches [7].

Hope this helps,
Alberto

[1] https://tools.ietf.org/html/rfc8111
[2] http://people.ac.upc.edu/ljakab/2010-jakab-jsac-lisp-tree.pdf
[3] https://tools.ietf.org/html/draft-cheng-lisp-shdht-04
[4] 
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.139.735=rep1=pdf
[5] http://ieeexplore.ieee.org/document/6422285/
[6] https://tools.ietf.org/html/draft-farinacci-lisp-decent-00
[7] 
https://datatracker.ietf.org/meeting/97/materials/slides-97-lisp-blockchain-based-mapping-system/
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] SRv6 for 5G Mobile [was Re: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt]

[Arashmid Akhavain]

Great work Satoru-san,
The paper certainly strengthens the case for the user of SRV6 in the back-haul.

Arashmid

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima
Sent: 07 March 2018 18:34
To: dmm 
Subject: [DMM] SRv6 for 5G Mobile [was Re: I-D Action: 
draft-ietf-dmm-srv6-mobile-uplane-01.txt]

FYI. A blog entry posted to APNIC:

"Reducing the complexity of 5G networks using Segment Routing IPv6"
https://blog.apnic.net/2018/03/07/reducing-complexity-5g-networks-using-segment-routing-ipv6/

Please take a look.

Cheers,
--satoru


> 2018/03/06 9:34、Satoru Matsushima のメール:
> 
> Dear folks,
> 
> A new revision of SRv6 Mobile User Plane draft has been submitted to IETF.
> 
> I’d present brief summary of the updates, but the agenda seems already full 
> so that it is uncertain I can do that.
> 
> So let me share the summary of update on the -01 version here.
> 
> A Big progress is that the draft supports interworking with GTP over IPv6 in 
> addition to GTP over IPv4.
> And we have made change SRv6 function to IPv6 encapsulation with SRH instead 
> of SRH insertion by default. 
> 
> Another changes have been made. 5G architecture in 3GPP is shown as a 
> reference architecture, as the discussion on the list many people ask SRv6 
> applicability for 5G. As the result, many terminologies are aligned based on 
> the reference.
> 
> You can see many improvements in terms of readability, especially on packet 
> flow explanations. I hope that many of us understand how SRv6 works for the 
> deployment cases described in the draft. 
> 
> Pablo has contributed those significant part of progresses and improvements. 
> He's now onboard as a co-author of the draft.
> 
> Best regards,
> --satoru
> 
>> 転送されたメッセージ:
>> 
>> 差出人: internet-dra...@ietf.org
>> 件名: [DMM] I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt
>> 日付: 2018年3月6日 7:42:01 JST
>> 宛先: 
>> CC: dmm@ietf.org
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Distributed Mobility Management WG of the 
>> IETF.
>> 
>>Title   : Segment Routing IPv6 for Mobile User Plane
>>Authors : Satoru Matsushima
>>  Clarence Filsfils
>>  Miya Kohno
>>  Pablo Camarillo
>>  Daniel Voyer
>>  Charles E. Perkins
>>  Filename: draft-ietf-dmm-srv6-mobile-uplane-01.txt
>>  Pages   : 23
>>  Date: 2018-03-05
>> 
>> Abstract:
>>   This document discusses the applicability of SRv6 (Segment Routing
>>   IPv6) to user-plane of mobile networks.  The source routing
>>   capability and the network programming nature of SRv6, accomplish
>>   mobile user-plane functions in a simple manner.  The statelessness
>>   and the ability to control underlying layer will be even more
>>   beneficial to the mobile user-plane, in terms of providing
>>   flexibility and SLA control for various applications.  It also
>>   simplifies the network architecture by eliminating the necessity of
>>   tunnels, such as GTP-U [TS.29281], PMIP [RFC5213], Mac-in-Mac, MPLS,
>>   and so on.  In addition, Segment Routing provides an enhanced method
>>   for network slicing, which is briefly introduced by this document.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dmm-srv6-mobile-uplane/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-01
>> https://datatracker.ietf.org/doc/html/draft-ietf-dmm-srv6-mobile-upla
>> ne-01
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-srv6-mobile-uplane-0
>> 1
>> 
>> 
>> Please note that it may take a couple of minutes from the time of 
>> submission until the htmlized version and diff are available at 
>> tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
> 

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

Re: [DMM] RE : [5gangip] 3GPP Liaison Statement on user plane protocol study

[Arashmid Akhavain]

Hi Lionel,
Thank you for your email and the link to CT4's LS .
Peter Ashwood-Smith and I met with Satoru-san yesterday in Montreal to discuss 
some of the requirements and explore a few options.

Also, a few of us in dmm including myself are writing a draft that we hope will 
be useful as a response. In this draft, we are considering a few technologies 
and  intend to provide a comprehensive analysis that might prove to be helpful 
in selecting a new data plane for N9.

We will sent out new version of our proposed draft as they become available. 
Your comments and feedbacks will certainly be greatly appreciated.

Best regards,
Arashmid Akhavain

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of lionel.mor...@orange.com
Sent: 01 March 2018 14:21
To: 5gan...@ietf.org; dmm@ietf.org
Cc: Georg Mayer <georg.mayer.hua...@gmx.com>; Gonzalo Camarillo 
<gonzalo.camari...@ericsson.com>; Matsushima Satoru 
<satoru.matsush...@g.softbank.co.jp>
Subject: [DMM] RE : [5gangip] 3GPP Liaison Statement on user plane protocol 
study


Correcting dmm address
Le 1 mars 2018 14:02, lionel.mor...@orange.com<mailto:lionel.mor...@orange.com> 
a écrit :
Hi,

I would like to inform IETF folks that a study item on user plane protocol in 
5GC for Release-16 (5G phase 2) has been initiated in the 3GPP CT4 WG 
(responsible for core network protocol aspects in mobile networks).

An official LS has been sent to IETF and the content of this LS as well as 
other related information can be found into:
http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_82_Gothenburg/Docs/C4-181380.zip

Please do not hesitate to contact Satoru and/or myself for further information 
if required.

Best Regards

[http://www.orange.com/sirius/logos_mail/orange_logo.gif]
Lionel Morand
Chair of 3GPP CT4 WG
Chair of IETF Dime and Radext WGs
Core Network Senior Architect and Diameter expert
Cell. +33 6 07 75 89 36 
<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootService%3DSIGNATURE%26to%3D0607758936>
Off.  +33 1 57 39 62 57 
<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootService%3DSIGNATURE%26to%3D0145296257>
lionel.mor...@orange.com <mailto:lionel.mor...@orange.com>


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.

_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.
___
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

[Arashmid Akhavain]

+1

These are more or less different implementations of the same data path 
architecture/design.
The mandate from 3GPP however is to investigate new data path options (emphasis 
on the "S") for N9, not to study SRV6 for N9.

Arashmid


From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: 07 February 2018 12:50
To: sarik...@ieee.org
Cc: dmm ; i...@ietf.org
Subject: Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

They all look the same, Behcet :-)

You tunnel, it becomes LISP; when you translate it becomes ILA;  When you call 
that mapping table a binding table, and keep it one place, it becomes Mobile 
IPv6.

When you move that table to some cloud and push it/fetch/flood it, they all 
converge :-)

Sri





From: Behcet Sarikaya >
Reply-To: "sarik...@ieee.org" 
>
Date: Wednesday, February 7, 2018 at 9:44 AM
To: Sri Gundavelli >
Cc: "Bogineni, Kalyani" 
>,
 Marco Liebsch >, Dino 
Farinacci >, 
"i...@ietf.org" >, 
dmm >
Subject: Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

Hi Sri,


On Wed, Feb 7, 2018 at 11:23 AM, Sri Gundavelli (sgundave) 
> wrote:
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.



I find it a bit too simplistic to put these two words
translation / tunneling

in a sort of unifying manner.

I don't think the reality is that simple, especially when you talk to 3GPP 
people.

In fact the translation or Id/Loc separation systems offer completely different 
and whole new view of how the data plane will work than tunneling which is the 
legacy technology.

On the other hand, draft-ietf-dmm-srv6-mobile-uplane-00 which was previously

draft-matsushima-spring-dmm-srv6-mobile-uplane-03

proposes a more efficient way of tunneling.
I don't see any discussion on the main subject, i.e. SRv6 mobile user plane so 
far on this list and I am puzzled by that.

So my humble suggestion is to concentrate on the advantages and disadvantages 
of SRv6 mobile user plane draft to 3GPP 4G (if there is time maybe a bit of 
5G). I assure you there is a lot of meat there which should keep you busy for a 
long time.

Regards,
Behcet

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" 
>
Date: Tuesday, February 6, 2018 at 1:23 PM
To: Marco Liebsch >, 
Sri Gundavelli >, Dino Farinacci 
>
Cc: "i...@ietf.org" 
>, dmm >
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@01D3A015.392834D0]



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@01D3A015.392834D0]



Option 2: Here 

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

[Arashmid Akhavain]

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


Arashmid



From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Bogineni, Kalyani
Sent: 07 February 2018 08:20
To: Marco Liebsch 
Cc: i...@ietf.org; dmm 
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 
>
Cc: i...@ietf.org; dmm 
>; Dino Farinacci 
>; Sri Gundavelli (sgundave) 
>
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; 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 
>
Cc: Sri Gundavelli (sgundave) >; 
Dino Farinacci >; 
i...@ietf.org; dmm >
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 
>
 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) >; 
Dino Farinacci >
Cc: i...@ietf.org; dmm >
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 

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

[Arashmid Akhavain]

Hi Tom and Sri,

One of the possible options is perhaps to use something along the line of what 
public clouds or OTT folks provide/use.
A form of DHT (with some wild carding capability) can perhaps fit the bill. We 
ran some tests with Google and Azure Pub/Sub and got about 120ms response time. 
These public cloud services though and as such are designed for moving large 
amount of data around and therefore need to do some buffering to be efficient. 
A custom version of these types of database and messaging for ID-LOC mapping 
distribution could perhaps be much faster.

Arashmid


From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: 29 January 2018 10:26
To: dmm@ietf.org
Subject: Re: [DMM] Questions about SRv6 mobile user-plane

HI Tom,

Thanks for your response. Please see inline.



---

https://tools.ietf.org/html/draft-herbert-ila-motivation-00 provides some 
comparisons between ILA and ILNP, encapsulations, SR, and transport layer 
mechanisms that can achieve some effects in mobility.

The choice of mapping system is critical. The mapping of identifier, or 
equivalently virtual to physical address mapping, seems to be a common problem 
in mobility and networking virtualization. As you mentioned, LISP defines a 
query method to populate a mapping cache. I assume this problem needs to be 
tackled in SR for mobile user-plane but I'm not sure what solution is preferred 
after reading the draft.

[Sri] There are multiple approaches on how we manage this mapping state. 
Obviously, ILA is one approach, but there are few other approaches as well that 
we need to review.



ILA partitions the problem into a two level hierarchy: ILA routers and IL 
forwarding nodes. This is somewhat analogous to core IP routers and nodes 
running neighbor discovery.  ILA routers contain all the (possibly sharded) 
mappings. They are authoritative. Forwarding nodes are located close to user 
devices and maintain a working set  cache of entries driven by user activity. 
If a packet doesn't hit the cache it's forwarded to a router that will do the 
ILA transformation. If the cache is hit, the packet can be transformed at the 
forwarding node to eliminate triangular routing. Caches can be populated by 
pull or push models. ILAMP (the ILA mapping protocol) supports both of these, 
but my current preference for scalability and mitigating DOS attacks on the 
cache is to use secure redirects sent by ILA routers  (analogous to ICMP 
redirects).


[Sri] When I last reviewed the ILA I-D, I do not seem to remember reading about 
the cache state, ILMP. or about how the mapping gets to the ILA routers. Looks 
like the spec is evolving as we speak. With ILAMP type control protocol for 
cache management, I see more similarities to LISP.




On a different note, just curious if SID prefix can ever have topological 
relevance and can be used for routing. In other words, can you ever route a 
packet without translating  the SIR prefix of the destination address with the 
locator? Can SID prefix be used as a locator in some special cases?

Yes, the SIR prefix is routable to forward to an ILA router. This is necessary 
for the redirect mechanism I describe above. I suppose this could be contorted 
to make the SIR address be a home address like in MobileIP and locators are 
COAs (if my use of MobileIP terminology is correct). There also might be nodes 
in the network, as well as external nodes that don't do go through a cache to 
their packets need to hit an ILA router to get forwarded to the location of 
mobile nodes. An upshot of that is that edge routers might need to perform 
transformations (SIR to ILA) at high rates so the mechanism needs to be very 
efficient and amenable to HW implementation.


[Sri] This is precisely what I was thinking.

I get that SIR prefix takes the packet awards the ILA domain and some ILA 
router in the path can apply the mapping. I was thinking there may not be a 
good reason to have more than one or two SIR prefixes for each ILA domain. As 
long as the SIR prefix can take the packet from a non-ILA domain (internet) to 
ILA domain, then the edge router can apply the mapping. But, that also implies 
the edge routers will have to have too much of mapping state. Now, if we have 
many SIR prefixes and associate a SIR prefix for each PGW/UPF, that state can 
be distributed and keep the edge routers stateless, but it also brings 
anchoring back into the picture. In one simplest mode, as you say, HNP (home 
network prefix) can be a SIR and the PGW/SGW or  (LMA/MAG) can do the 
translation of SIR - ILA, without the need for tunneling.

So, in your mind how many SIR prefixes will be used in a typical T1 operator 
domain? Also, how can we quantify the state that ILA introduces in different 
parts of the network?


Regards
Sri







From: dmm > on behalf of Tom 
Herbert >
Date: Friday, January 26, 

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

[Arashmid Akhavain]

Hi Kalyani,

I like your practical approach. In addition to the vendors though, I think It 
will help if we could get people from the service providers to
present their point of view as well.  It might take some time though before we 
get more clarifications from the vendors or carriers.
In the meantime, let's keep going forward with your plan and make modifications 
as we receive feedback.

Arashmid

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

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<mailto:kalyani.bogin...@verizonwireless.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>>
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.ashwoo

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

[Arashmid Akhavain]

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>; Arashmid Akhavain 
<arashmid.akhav...@huawei.com>; dmm@ietf.org
Cc: AshwoodsmithPeter <peter.ashwoodsm...@huawei.com>; TongWen 
<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 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 d

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

[Arashmid Akhavain]

Hi Kalyani,
Please add me to the list.

Thanks,
Arashmid

From: Bogineni, Kalyani [mailto:kalyani.bogin...@verizonwireless.com]
Sent: 25 January 2018 12:04
To: Sri Gundavelli (sgundave) <sgund...@cisco.com>; Arashmid Akhavain 
<arashmid.akhav...@huawei.com>; dmm@ietf.org
Cc: AshwoodsmithPeter <peter.ashwoodsm...@huawei.com>; TongWen 
<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 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. 

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

[Arashmid Akhavain]

HI Kalyani,
Yes, a call to better understand the requirement will be great. I asked for 
some clarifications from CT4 Chair and copied 
dmm@ietf.org<mailto:dmm@ietf.org>. But didn't get a reply so far. So, a call 
would definitely help.

I am on Canada East Coast. 10am East Coast usually works for Europe, but might 
not work for folks in China, Japan, or people on the West Coast.

If people have presentations, I can arrange a WebEx meeting as well. Either 
way, a call will be very helpful.

Arashmid


From: Bogineni, Kalyani [mailto:kalyani.bogin...@verizonwireless.com]
Sent: 25 January 2018 07:46
To: Arashmid Akhavain <arashmid.akhav...@huawei.com>; Sri Gundavelli (sgundave) 
<sgund...@cisco.com>; dmm@ietf.org
Cc: AshwoodsmithPeter <peter.ashwoodsm...@huawei.com>; TongWen 
<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...@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 sol

[DMM] IPv6 GTP-C/GTP-U

[Arashmid Akhavain]

As I am sure you all know, recently 3GPP CT4 approved a Study Item asking 
IETF’s DMM to investigate alternative data paths for N9?
Given that big mobile operators have already selected IPV6 as their choice of 
data path, is it the GTP that 3GPP is interested in finding alternatives for?

Lionel, your insight is greatly appreciated.

Terry, any thoughts on this?

Note: I have copied dmm@ietf.org since they are the WG 
with 3GPP mandate and it would be perhaps better to try to use that mailing 
list to continue our discussions.

Arashmid



From: 5gangip [mailto:5gangip-boun...@ietf.org] On Behalf Of FIGURELLE, TERRY F
Sent: 24 January 2018 11:58
To: Ca By ; d.l...@surrey.ac.uk
Cc: 5gan...@ietf.org; alexandre.petre...@gmail.com; nick.heat...@bt.com
Subject: Re: [5gangip] IPv6 GTP-C/GTP-U

We have deployed more than 20k eNB’s that use IPv6 only transport for S1-U and 
all of our SGW’s and PGW’s support IPv6 transport for GTP-U and GTP-C. We 
actually are working with Syniverse for IPv6 IPX for S8. We already have inter 
lab over production Syniverse IPX between AT and six other major telecoms 
(Bell Canada, Rogers, DoCoMo, etc.).

We are running  production VoLTE (ims APN) using IPv6 GTP-U|GTP-C with UE IPv6 
only and the common general purpose APN (nxtgenphone) supports IPv4 only, IPv6 
only and currently IPv4v6 (deprecated by 3GPP). This includes two UE operating 
systems which cover 97% of the market share. Only handful of devices where 
certified for IPv4v6. All devices AT has certified since the launch or UMS 
support IPv4 only, IPv6 only and “IPv4 or IPv6”. AT’s device requirements are 
considered the gold standard in the mobile industry. All of the major vendors 
for EPC support IPv6 GTP transport and we have 42 million active subscribers 
running on a virtualize EPC (Intel COTS hardware, hypervisor, etc.) that 
supports IPv6 GTP. Verizon, T-Mobile (USA) and Sprint also use IPv6.

GM’s OnStar uses IPv6 only VoLTE over IPv6 GTP-U in North America they use UE 
IPv4 only for the other APN’s but those still use IPv6 GTP-U in North America. 
BMW and other auto companies also support IPv6 GTP-U in North America. AT was 
the first to support LTE roaming and we helped Bell Canada and Rogers support 
it. We can use direct connections (IPX bypass) or Syniverse IPX for LTE 
roaming. There are a number of country specific IPX but Syniverse now supports 
interop with a large number of telecoms via their IPX or in conjunction with 
country specific IPX.

Ericson, Huawei, Samsung and Nokia all support IPv6 GTP-U eNB’s. Spirent, 
Tektronix and other test tool vendors all support IPv6 GTP-C|GTP-U. IPv6 GTP 
has been supported for several years in production networks. It’s very common 
in Asian countries too.

Hopefully this ends the IPv6 GTP thread!!!

Terry Figurelle
Lead Member of Technical Staff
Wireless Network Arch. & Design
Mobility Core
AT Services
tf2...@att.com
cell - (206)601-5157
___
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

[Arashmid Akhavain]

Hi Kalyani,

I was thinking something along this:

A section on each competing architecture where we first provide a description 
of each architecture.
A section on the list and set of features that 3GPP requires and must be 
supported.

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.

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.

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?
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>; Sri Gundavelli (sgundave) 
<sgund...@cisco.com>; dmm@ietf.org
Cc: AshwoodsmithPeter <peter.ashwoodsm...@huawei.com>; TongWen 
<tong...@huawei.com>; Bogineni, Kalyani <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 
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 regula

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

[Arashmid Akhavain]

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
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
Cc: Bogineni, Kalyani 
>
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