Subject: Re: [5gangip] 5G & IP Task Force - was: FW: Re: MINUTES of side meeting in Singapore

From: <[email-masked]>
Date: Thu, 14 Dec 2017 17:12:04 +0000

Dear all
Following the extensive discussions on this list in the last weeks we propose to set up a task force group to work on:

1.	White paper on id-loc protocol concept evaluation for 5G as planned by 3GPP similar to the one mentioned by Arash in the mail some days ago (https://mailarchive.ietf.org/arch/msg/5gangip/TVjXrlW5tbNsJ4ZLJfUPVemIYcA) but on different other id-loc separation protocol proposals as e.g. ILNP and ILA (in case of approval to be submitted to 3GPP e.g. as Temp.Doc. on solution proposal or somewhere else). 
More details to follow soon ...

2.	Work on an IETF draft describing how id-loc systems can be applied to the upcoming 5G architectures. This document could be based on (1) above (or identical) or it could be different.

Here are the list of people who agreed to serve and contribute in general: Dino Farinacci, Peter Ashwood (with Arash),  Saleem, Tom, and Alex.
This is gratefully acknowledged!
Further volunteers' effort is more than welcome!

The work will consist possibly of bi-weekly conference calls starting in the week of January 7, 2018. Webex calls will be announced on the list so that other list members will also be able to attend the calls if they wish to do so.

Thanks!
Best Regards
Dirk

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 14 Dec 2017 18:04:11 +0000

Hi Dirk,

As a contributor to the LISP mobile networks document,   I would be happy to contribute to this document. Please add me to the list.

Is this the same document what Kalyani was trying to put it together?

BR,
--
Uma C.

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, December 14, 2017 9:12 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [5gangip] 5G & IP Task Force - was: FW: Re: MINUTES of side meeting in Singapore

Dear all

Thanks!
Best Regards
Dirk 

_______________________________________________
5gangip mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/5gangip

---

From: AshwoodsmithPeter <[email-masked]>
Date: Thu, 14 Dec 2017 18:25:14 +0000

I wonder if a consolidated email list might be useful?

I'm happy to offer up our webex for use and working storage.

Peter

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, December 14, 2017 12:12 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [5gangip] 5G & IP Task Force - was: FW: Re: MINUTES of side meeting in Singapore

Dear all

Thanks!
Best Regards
Dirk

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 14 Dec 2017 10:29:43 -0800

Others can decide but I am fine if [email-masked] is added to [email-masked]. But I am not sure if the members of 5ger want the 5gangip activity. We can wait one week for objections. And if there are few to none, we can make the call.

Dino

> On Dec 14, 2017, at 10:25 AM, AshwoodsmithPeter <[email-masked]> wrote:
>

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Thu, 14 Dec 2017 19:43:41 +0000

Uma - as mentioned in my email yesterday, the white paper I was proposing will be
developed in DMM WG.

Kalyani

> From: 5gangip [mailto:[email-masked]] On Behalf Of Uma
> Chunduri
> Sent: Thursday, December 14, 2017 1:04 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: [E] Re: [5gangip] 5G & IP Task Force - was: FW: Re: MINUTES of side
> meeting in Singapore
> 
> Hi Dirk,
> 
> As a contributor to the LISP mobile networks document,   I would be happy
> to contribute to this document. Please add me to the list.
> 
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> 1.	White paper on id-loc protocol concept evaluation for 5G as planned
> by 3GPP similar to the one mentioned by Arash in the mail some days ago
> (https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__mailarchive.ietf.org_arch_msg_5gangip_TVjXrlW5tbNsJ4ZLJfUPVemIYc
> A&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=I
> diSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT
> &m=-Tb7KEdKx1PmJPa7Vgq5wLnvFGmna3mNYsf2KwXh-
> VI&s=onavqTS2wnS5HpK-kfRa2piAmqalnxVUVD6yEGpjASY&e=) but on
> different other id-loc separation protocol proposals as e.g. ILNP and ILA (in
> case of approval to be submitted to 3GPP e.g. as Temp.Doc. on solution
> proposal or somewhere else).
> 2.	Work on an IETF draft describing how id-loc systems can be applied to
> the upcoming 5G architectures. This document could be based on (1) above
> (or identical) or it could be different.
> 
> Here are the list of people who agreed to serve and contribute in general:
> Dino Farinacci, Peter Ashwood (with Arash),  Saleem, Tom, and Alex.
> The work will consist possibly of bi-weekly conference calls starting in the
> week of January 7, 2018. Webex calls will be announced on the list so that
> other list members will also be able to attend the calls if they wish to do so.
> 
> Thanks!
> Best Regards
> Dirk
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_5gangip&d=DwICAg&c=udBTRvFvXC5D
> hqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMY
> KgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=-
> Tb7KEdKx1PmJPa7Vgq5wLnvFGmna3mNYsf2KwXh-VI&s=nTjX-
> CvwVxYLPIPXw0eYpjmNkB64wCB5tkF9TFXyCeQ&e=
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_5gangip&d=DwICAg&c=udBTRvFvXC5D
> hqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMY
> KgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=-
> Tb7KEdKx1PmJPa7Vgq5wLnvFGmna3mNYsf2KwXh-VI&s=nTjX-
> CvwVxYLPIPXw0eYpjmNkB64wCB5tkF9TFXyCeQ&e=

---

From: "Schumacher L." <[email-masked]>
Date: Fri, 15 Dec 2017 08:19:31 +0100

Dear Dirk,

With all due respect, and fully acknowledging my newbie status here, I 
must confess I am surprised that (i) 5Gangip focuses so much on 
ID/Locator separation and that (ii) this focus is hardly supported by 
convincing Business Cases likely to trigger large scale deployments.

Assuming the majority of 5G traffic would be (i) Best-Effort and (ii) 
pull-oriented (VOD, non critical IoT), the only expectation for this 
kind of traffic, AFAICT, is to catch routable IP addresses on the fly, 
enabling to open and exploit TCP connections, until the content has been 
fully retrieved. Whenever a given network attachment is no longer 
operating (due to movement, changing PHY conditions, etc), the 
corresponding IP address is dropped and the relevant TCP connections are 
closed.

For the rest of the traffic (non-VOD, as mentionned by Mikael 
Abrahamsson), low latency scenarii come to mind. However, due to the 
stringent 1ms E2E time budget, and considering most of this time budget 
is likely to be spent in PHY and Layer 2, Local Breakouts are a relevant 
option. In such a case, mobility could/would be handled within/between 
these Local Breakouts, turning into Virtual Machine Mobility (VMM).

So, what are the remaining Use Cases for which Layer 3 mobility should 
be improved?

On the other hand, one premise of the whole discussion was a desire to 
get rid of GTP, regarded as a protocol supporting terminal mobility and 
(many) additional (painly documented) features. Are we giving up on that 
account?

Finally, David Lake raised an issue which I regard very relevant, i.e. 
the energy efficiency of the data communication, e.g. how many Joules 
are spent per useful transferred bit (goodput), considering the (many) 
encapsulation(s) of this useful bit (throughput). Are we disregarding 
that question as well? Is Robust Header Compression (ROHC) like in 
NB-IoT the way forward?

Best regards,
LS

-- 

Laurent SCHUMACHER
Professeur
Faculté d'Informatique

T. +32 (0)81 724 980
F. +32 (0)81 724 967
[email-masked] <mailto:[email-masked]>
http://www.unamur.be/universite/personnes/page_view/01005249/
http://be.linkedin.com/pub/laurent-schumacher/0/32b/7b7

Université de Namur ASBL
Rue de Bruxelles 61 - 5000 Namur

Let’s respect the environment together.
Only print this message if necessary!

---

From: <[email-masked]>
Date: Fri, 15 Dec 2017 08:40:00 +0000

Laurent

Totally agree with you.  The title of this proto WG is:

“5G Aspects of Next Generation Internet Protocols”

For me, that is as much about architectures and use-cases as about the protocol.  Use cases for 5G all seem to mention aspects of enhanced mobility at higher speeds delivery against SLAs.

TR 138 913 makes for interesting and relevant reading in this respect – UE speeds of up to 500km/h are envisaged with consistent data-rate during handover.  Current cellular technology struggles to deliver a good mobility experience at relatively low-speed as anyone who has tried to use their mobile on a train will tell you.   Even on my local, low-speed line at 160km/h there are issues with handovers.

Other aspects of a cellular system must also be taken into consideration – Massive MIMO, C-RAN (which distorts/changes the overall architecture in terms of traffic placement), CoMP, neutral host, spectrum management, LI, etc.

We have to see 3GPP as an end-user and design to their needs – the opportunity to do that, frankly, was missed in the early stages of 5G standardisation which is why we have N3 and N6 fixed.

However, we have an opportunity to work with 3GPP around N9.  But N9 is as-much about how to interconnect elements in a Slice (another very poorly defined term at the moment) to deliver against an outcome.

I’m not sure what we are trying to achieve here at the moment but I don’t think we’re anywhere near ready to be proposing new protocols yet?

I also think as IETF we need to be a LOT more co-ordinated across the various groups looking at “5G.”

David

From: 5gangip [mailto:[email-masked]] On Behalf Of Schumacher L.
Sent: 15 December 2017 07:20
To: [email-masked]
Subject: Re: [5gangip] 5Gangip larger than ID/Loc? - Was: 5G & IP Task Force

Dear Dirk,

With all due respect, and fully acknowledging my newbie status here, I must confess I am surprised that (i) 5Gangip focuses so much on ID/Locator separation and that (ii) this focus is hardly supported by convincing Business Cases likely to trigger large scale deployments.

Assuming the majority of 5G traffic would be (i) Best-Effort and (ii) pull-oriented (VOD, non critical IoT), the only expectation for this kind of traffic, AFAICT, is to catch routable IP addresses on the fly, enabling to open and exploit TCP connections, until the content has been fully retrieved. Whenever a given network attachment is no longer operating (due to movement, changing PHY conditions, etc), the corresponding IP address is dropped and the relevant TCP connections are closed.

For the rest of the traffic (non-VOD, as mentionned by Mikael Abrahamsson), low latency scenarii come to mind. However, due to the stringent 1ms E2E time budget, and considering most of this time budget is likely to be spent in PHY and Layer 2, Local Breakouts are a relevant option. In such a case, mobility could/would be handled within/between these Local Breakouts, turning into Virtual Machine Mobility (VMM).

So, what are the remaining Use Cases for which Layer 3 mobility should be improved?

On the other hand, one premise of the whole discussion was a desire to get rid of GTP, regarded as a protocol supporting terminal mobility and (many) additional (painly documented) features. Are we giving up on that account?

Finally, David Lake raised an issue which I regard very relevant, i.e. the energy efficiency of the data communication, e.g. how many Joules are spent per useful transferred bit (goodput), considering the (many) encapsulation(s) of this useful bit (throughput). Are we disregarding that question as well? Is Robust Header Compression (ROHC) like in NB-IoT the way forward?

Best regards,
LS

Le 14/12/17 à 18:12, [email-masked]<mailto:[email-masked]> a écrit :

Dear all

Thanks!

Best Regards

Dirk

5gangip mailing list

[email-masked]<mailto:[email-masked]>

--

Laurent SCHUMACHER
Professeur
Faculté d'Informatique

T. +32 (0)81 724 980
F. +32 (0)81 724 967
[email-masked]<mailto:[email-masked]>
http://www.unamur.be/universite/personnes/page_view/01005249/
http://be.linkedin.com/pub/laurent-schumacher/0/32b/7b7

Université de Namur ASBL

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 15 Dec 2017 10:59:49 +0100

Le 15/12/2017 à 08:19, Schumacher L. a écrit :
[...]
> (many) additional (painly documented) features. Are we giving up on that 

There are more things about GTP:

GTP-on-IPv6, instead the current GTP-on-IPv4.

Internet Draft titled "GTP", as low-hanging fruit.

Replacing GTP with IP routing headers.

Replacing GTP with Mobile IP Route Optimisation.

Probably more.

Alex

[...]

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 15 Dec 2017 12:32:24 +0100

> Totally agree with you.  The title of this proto WG is:

Let us just briefly clarify there is no WG, but otherwise I agree with you.

> For me, that is as much about architectures and use-cases as about the 
> protocol.  Use cases for 5G all seem to mention aspects of enhanced 
> mobility at higher speeds delivery against SLAs.
> 
> TR 138 913 makes for interesting and relevant reading in this respect – 
> UE speeds of up to 500km/h are envisaged with consistent data-rate 
> during handover.  Current cellular technology struggles to deliver a 
> good mobility experience at relatively low-speed as anyone who has tried 
> to use their mobile on a train will tell you.   Even on my local, 
> low-speed line at 160km/h there are issues with handovers.
> 
> Other aspects of a cellular system must also be taken into consideration 
> – Massive MIMO, C-RAN (which distorts/changes the overall architecture 
> in terms of traffic placement), CoMP, neutral host, spectrum management, 
> LI, etc.
> 
> We have to see 3GPP as an end-user and design to their needs – the 
> opportunity to do that, frankly, was missed in the early stages of 5G 
> standardisation which is why we have N3 and N6 fixed.
> 
> However, we have an opportunity to work with 3GPP around N9.  But N9 is 
> as-much about how to interconnect elements in a Slice (another very 
> poorly defined term at the moment) to deliver against an outcome.
> 
> I’m not sure what we are trying to achieve here at the moment but I 
> don’t think we’re anywhere near ready to be proposing new protocols yet?
> 
> *From:*5gangip [mailto:[email-masked]] *On Behalf Of 
> *Schumacher L.
> *Sent:* 15 December 2017 07:20
> *To:* [email-masked]
> *Subject:* Re: [5gangip] 5Gangip larger than ID/Loc? - Was: 5G & IP Task 
> Force
> 
> Dear Dirk,
> 
> Le 14/12/17 à 18:12, [email-masked] 
> <mailto:[email-masked]> a écrit :
> 
>     Dear all
> 
>     [email-masked] <mailto:[email-masked]>
> 
> *Laurent SCHUMACHER*
> *T.*+32 (0)81 724 980
> *F.* +32 (0)81 724 967
> *Université de Namur ASBL*
> *Only print this message if necessary!*
> 
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 15 Dec 2017 12:37:06 +0100

> low-speed line at 160km/h there are issues with handovers.

I wonder whether this speed range is considered with mobile devices 
accessing 3.5GHz LTE (in France: "BLR LTE, Boucle Locale Radio LTE 
3500")?  Or is it access on 2.6GHz only?

For the 500km/h: one may wonder who needs that fast.  But in case of 
vehicle-to-vehicle communication on Germany freeway that number could be 
reached.

Alex
[...]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 15 Dec 2017 12:40:43 +0100 (CET)

> vehicle-to-vehicle communication on Germany freeway that number could be 

Trains.

https://www.cnbc.com/2016/09/25/china-developing-500kmh-trains-to-lead-export-of-high-speed-rail-technology.html

In France, TGV does 320km/h in regular production, so not far off.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 15 Dec 2017 14:00:16 +0100

Le 15/12/2017 à 12:40, Mikael Abrahamsson a écrit :
>> vehicle-to-vehicle communication on Germany freeway that number could 
>> be reached.
> 
> Trains.
> 

I agree trains could be a need.

One also thinks about current connected trains like Thalys is on 
satellite, not on cellular.

Alex

---

From: AshwoodsmithPeter <[email-masked]>
Date: Fri, 15 Dec 2017 14:56:27 +0000

It's for high speed trains and it's not just frequency of handoffs the air interface has to be more tolerant of Doppler.

Peter

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Friday, December 15, 2017 6:37 AM
To: [email-masked]
Subject: Re: [5gangip] 5Gangip larger than ID/Loc? - Was: 5G & IP Task Force

> TR 138 913 makes for interesting and relevant reading in this respect 
> – UE speeds of up to 500km/h are envisaged with consistent data-rate 
> good mobility experience at relatively low-speed as anyone who has 
> tried to use their mobile on a train will tell you.   Even on my 
> local, low-speed line at 160km/h there are issues with handovers.

I wonder whether this speed range is considered with mobile devices accessing 3.5GHz LTE (in France: "BLR LTE, Boucle Locale Radio LTE 3500")?  Or is it access on 2.6GHz only?

For the 500km/h: one may wonder who needs that fast.  But in case of vehicle-to-vehicle communication on Germany freeway that number could be reached.

Alex
[...]

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 15 Dec 2017 16:04:16 +0100

Le 15/12/2017 à 15:56, AshwoodsmithPeter a écrit :
> It's for high speed trains and it's not just frequency of handoffs
> the air interface has to be more tolerant of Doppler.

Which encoder is going to be used for NR?

SC-FDM?

Alex

> 
> Peter
> 
> -----Original Message----- From: 5gangip
> [mailto:[email-masked]] On Behalf Of Alexandre Petrescu 
> Sent: Friday, December 15, 2017 6:37 AM To: [email-masked] Subject:
> Re: [5gangip] 5Gangip larger than ID/Loc? - Was: 5G & IP Task Force
> 
> 
> 
> Le 15/12/2017 à 09:40, [email-masked] a écrit : [...]
>> TR 138 913 makes for interesting and relevant reading in this
>> respect – UE speeds of up to 500km/h are envisaged with consistent
>> data-rate during handover.  Current cellular technology struggles
>> to deliver a good mobility experience at relatively low-speed as
>> anyone who has tried to use their mobile on a train will tell you.
>> Even on my local, low-speed line at 160km/h there are issues with
>> handovers.
> 
> Alex [...]
> _______________________________________________ 5gangip mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/5gangip
>

---

From: AshwoodsmithPeter <[email-masked]>
Date: Fri, 15 Dec 2017 15:11:09 +0000

Last I heard it was Filtered OFDM , over TDD and FDD with flexible FFT sizes, flexible sub-carrier spacing, flexible frame sizes and polar codes.  Each slice specifies specific attributes of the above to provide various delay/throughput etc. properties with more slice behaviors possible in the future.

Things may have changed in the last 6 months so take the above with a grain of salt.

Peter

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Friday, December 15, 2017 10:04 AM
To: AshwoodsmithPeter <[email-masked]>; [email-masked]
Subject: Re: [5gangip] 5Gangip larger than ID/Loc? - Was: 5G & IP Task Force

Le 15/12/2017 à 15:56, AshwoodsmithPeter a écrit :
> It's for high speed trains and it's not just frequency of handoffs the 
> air interface has to be more tolerant of Doppler.

SC-FDM?

Alex

>> tried to use their mobile on a train will tell you.

---

From: AshwoodsmithPeter <[email-masked]>
Date: Fri, 15 Dec 2017 15:12:01 +0000

And at those speeds you'd be handing off every minute or so. I.e. without mobility you'd get a new address every minute.

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Friday, December 15, 2017 9:56 AM
To: Alexandre Petrescu <[email-masked]>; [email-masked]
Subject: Re: [5gangip] 5Gangip larger than ID/Loc? - Was: 5G & IP Task Force

Peter

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Friday, December 15, 2017 6:37 AM
To: [email-masked]
Subject: Re: [5gangip] 5Gangip larger than ID/Loc? - Was: 5G & IP Task Force

Alex
[...]

---

From: <[email-masked]>
Date: Fri, 15 Dec 2017 16:41:23 +0000

SC-FDMA can be used in the Macro uplink direction in specific RF scenarios.   But otherwise my understanding is the same as Peter's.

LTE and 5GNR OFDM look very similar except the shoulders on 5GNR are much steeper so more spectrally efficient.

Sub carrier spacing is variable in 5GNR as well rather than the 15kHz fixed in LTE and therefore spectrum can be matched with the application.  The term "RAN Slicing" is being bandied about quite a lot and I think this is what people mean....

More details that you could even wish to know (including a comparison with LTE) here http://www.sharetechnote.com/html/5G/5G_FrameStructure.html

D

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: 15 December 2017 15:11
To: Alexandre Petrescu <[email-masked]>; [email-masked]
Subject: Re: [5gangip] 5Gangip larger than ID/Loc? - Was: 5G & IP Task Force

Peter

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Friday, December 15, 2017 10:04 AM
To: AshwoodsmithPeter <[email-masked]>; [email-masked]
Subject: Re: [5gangip] 5Gangip larger than ID/Loc? - Was: 5G & IP Task Force

SC-FDM?

Alex

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 15 Dec 2017 19:28:43 +0000

+1 for on multiple things David said below.

Quick comments [Uma]:

--
Uma C.

From: 5gangip [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, December 15, 2017 12:40 AM
To: [email-masked]; [email-masked]
Subject: Re: [5gangip] 5Gangip larger than ID/Loc? - Was: 5G & IP Task Force

Laurent

We have to see 3GPP as an end-user and design to their needs – the opportunity to do that, frankly, was missed in the early stages of 5G standardisation which is why we have N3 and N6 fixed.
[Uma]: Especially on N3, removing GTP is extremely involved. This is not simply removing the TEID of GTP and putting into some other form. This is what I saw in some solutions (may be practical). What is removal means actually? Completely anchorless,
                then almost all existing 3GPP procedures (current eNB mobility – all variants of the same, mobile terminated data, new mobility cases and impact of initial slicing solutions planned for deployment next year  etc..) need a re-write.

However, we have an opportunity to work with 3GPP around N9.  But N9 is as-much about how to interconnect elements in a Slice (another very poorly defined term at the moment) to deliver against an outcome.
[Uma]: Slicing aspect is one definite item on N9.  But this is more than that, it has branch point (BP) UPF solution in 3 SSC modes.
 Some of these modes don’t have session continuity, might be ok for the offload traffic discussed – however this assumes UE changes and potentially server changes in the internet (not fully discussed at all in the solutions). Not sure if this is  done deal there..

I’m not sure what we are trying to achieve here at the moment but I don’t think we’re anywhere near ready to be proposing new protocols yet?
[Uma]: Great question. I struggled to answer this myself, the best (at this point) we can do is writing the white paper with potential ID/LOC solutions, close to the reality of 3GPP. Perhaps then we can nail down few problems with more clarity and come up with some independent charter.

[Uma]: +1.

1.       Most of the ID/LOC solution needs mapping server in 3GPP control plane. This could have optional AUTH procedures (some of it are needed for FMC cases).
           We didn’t progress this in another similar mailing list (IDEAS) because of privacy issues as it was presented to handle multiple enterprise and IOT uses cases not specific to 3GPP.
            Those privacy issues are completely irrelevant in 3GPP domain, where subscriber/IMSI knowledge is central to everything.
           But unfortunately 3GPP was not the only focus in that list.

2.       IETF netslices mailing list. Extremely relevant for 3GPP, but also apparently focus has been shifted there and it doesn’t fully focus on the transport network slicing aspects (more on controller and yang models).

3.       This list, with the focus on GTP removal, but lot of solution aspects overlaps with the core of 3GPP procedures. May be can be done without touching anything and with ILA data plane solution.

4.       Transport stack reduction – I see only GTP, PW + LSP path from eNB to PGW and an additional layer for shared transport network scenarios. All are needed, I see SRv6 solution by Satoru

(now DMM WG document) tried this but given the RFC8200 fact that every time extension header is introduced you have to encapsulate with one more IPv6 layer *and* all SIDs are IPv6 addresses (used for intermediate nodes and services),

this would rather potentially  increase the total size than the currently deployed solutions (may be this would be addressed with draft-voyer-6man-extension-header-insertion-02.txt, let’s see).

So I can only agree with David’s point; some form of co-ordination is required, but that won’t happen until we have a concrete charter..

David

From: 5gangip [mailto:[email-masked]] On Behalf Of Schumacher L.
Sent: 15 December 2017 07:20
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [5gangip] 5Gangip larger than ID/Loc? - Was: 5G & IP Task Force

Dear Dirk,

Best regards,
LS

Dear all

Thanks!

Best Regards

Dirk

5gangip mailing list

--

Laurent SCHUMACHER
Professeur
Faculté d'Informatique

T. +32 (0)81 724 980
F. +32 (0)81 724 967

Université de Namur ASBL

---

From: "Schumacher L." <[email-masked]>
Date: Sun, 17 Dec 2017 10:02:24 +0100

Dear Uma,

Le 15/12/17 à 20:28, Uma Chunduri a écrit :
> (...)
> [Uma]: Especially on N3, removing GTP is extremely involved. This is 
> not simply removing the TEID of GTP and putting into some other form. 
> This is what I saw in some solutions (may be practical). What is 
> removal means actually? Completely anchorless,
>
>                 then almost all existing 3GPP procedures (current eNB 
> mobility – all variants of the same, mobile terminated data, new 
> mobility cases and impact of initial slicing solutions planned for 
> deployment next year  etc..) need a re-write.
>

How do you foresee combining this Layer 3 anchorlessness with the need 
of stateful network functions?

Best regards,
LS
-- 

Laurent SCHUMACHER
Professeur
Faculté d'Informatique

T. +32 (0)81 724 980
F. +32 (0)81 724 967

Université de Namur ASBL

---

From: <[email-masked]>
Date: Mon, 18 Dec 2017 14:53:49 +0000

Dear Uma, David, all,

thank you for the discussion and proposals - I agree that we should carefully first consider maybe a plethora of issues we see so far (however writing new protocols was not thought as in scope) and then try to concentrate on issues we can handle in due time.
For what we had in mind a presentation to 3GPP is not the main goal, rather becoming clear what problems remain to be solved (for the sake of defining a framework or a charter) - compared to what shall be studied within WG DMM now as input to 3GPP CT4 study item.
Sorry for any misunderstanding I may have caused by misleading wording!
Rather than mobility the predominant issue could be connectivity and session continuity in general.
I also will have a deeper look at the draft and RFC mentioned to see what prior and parallel work should be considered in order to achieve thorough coordination and correlation within IETF. This may already result in a better focus for our paper …

Thanks again!
Best Regards
Dirk

From: 5gangip [mailto:[email-masked]] On Behalf Of Uma Chunduri
Sent: Freitag, 15. Dezember 2017 20:29
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [5gangip] 5Gangip larger than ID/Loc? - Was: 5G & IP Task Force

Quick comments [Uma]:

--
Uma C.

From: 5gangip [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, December 15, 2017 12:40 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [5gangip] 5Gangip larger than ID/Loc? - Was: 5G & IP Task Force

Laurent

[Uma]: +1.

David

Dear Dirk,

Best regards,
LS

Dear all

Thanks!

Best Regards

Dirk

5gangip mailing list

--

Laurent SCHUMACHER
Professeur
Faculté d'Informatique

T. +32 (0)81 724 980
F. +32 (0)81 724 967

Université de Namur ASBL

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 18 Dec 2017 18:23:24 +0000

>How do you foresee combining this Layer 3 anchorlessness with the need of stateful network functions?

Hi Laurent,

Great question.
I am not sure complete anchorless is what we need. LISP solution doesn’t propose that. It uses dynamic encapsulation (and can be used both with GTP and LISP data plane) at the XTRs  (eNB/gNB & PGW/UPF),
thus reducing lot of complexity and tight control plane signaling on what is out there.

With 5G CUPS model as there is lot of flexibility instantiate control plane more dynamically and stateful network functions can be applied there.
While ID/LOCs have much more potential overall; usage in few/limited key use cases within the framework of 3GPP architecture would yield greater acceptance to start with.

BR,
--
Uma C.