Subject: Re: [5gangip] New Version Notification for draft-vonhugo-5gangip-ip-issues-02.txt

From: "K, Satish (Nokia - IN)" <[email-masked]>
Date: Thu, 2 Mar 2017 06:47:15 +0000

Hi Peter:

I guess you are referring to the following excerpt from the MAMS draft.
" .... NCM and CCM also negotiate application level policies for categorizing applications, e.g.  based on DSCP, Destination IP address, and determining which of the available network paths, needs to be used for transporting data of that category of applications.."

This statement implies the following:
- NCM and CCM negotiate the combination of network paths, e.g. which combination of access links, and which core (IP address) to reach the application.. 
say, use LTE in the Uplink and Wi-fi in the Downlink for accessing an Application Server via the Wi-Fi core (i.e App server would see it as device accessing via regular Wi-Fi network).
- NCM and CCM agree on either an encapsulation protocol/location-ID separation protocol to help the network user plane entity (N-MADP) identify the packets received on the LTE uplink to be routed via the Wi-Fi core
Therefore, the MAMS scheme can co-exist and is in alignment with the location/IP separation concept.

On the aspect of Source IP: 
The source IP is the IP address assigned by the core network, that is chosen to be used to reach the Application Server/End-point. 
When the packets are transported over alternate access, techniques like encapsulation/mapping can be used at the network (say, N-MADP instantiated at the MEC in the example mentioned in the previous email) to route the packets to the appropriate core.

BR
Satish

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Tuesday, February 28, 2017 10:07 PM
To: [email-masked]; [email-masked]; K, Satish (Nokia - IN) <[email-masked]>
Subject: Re: [5gangip] New Version Notification for draft-vonhugo-5gangip-ip-issues-02.txt

Thanks, just read it over.

Clearly multiple access is part of the fixed mobile convergence problem and this document talks about the same challenge of multiple access networks but this document appears to assume that applications pick the interface most appropriate for their packets, i.e. no separation of ID and location. 

" determining which of the available network paths, needs to be used for transporting data of that category of applications"

What happens when I wish to inverse multiplex over the set of available interfaces? I.e. what's my source IP?

Anyway as you point out it's an important topic that is not included in the ip-issues draft but I think it needs to be considered in parallel with over the top (encapsulation)  v.s. interworking discussions.

Peter

-----Original Message-----
From: K, Satish (Nokia - IN) [mailto:[email-masked]]
Sent: Tuesday, February 28, 2017 6:01 AM
To: AshwoodsmithPeter <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]; Sprecher, Nurit (Nokia - IL/Hod HaSharon) <[email-masked]>; Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]>; Kuure, Pekka (Nokia - FI/Espoo) <[email-masked]>; Vasudevan, Vasu (Nokia - US) <[email-masked]>; Zhu, Jing Z <[email-masked]>; Florin Baboescu <[email-masked]>; pengshuping <[email-masked]>
Subject: RE: [5gangip] New Version Notification for draft-vonhugo-5gangip-ip-issues-02.txt

Hi Peter:

Thanks for the good discussion points.

In this context, just want to point to the ongoing work on MAMS (Multi Access Management Services - https://tools.ietf.org/html/draft-kanugovi-intarea-mams-protocol-02) as it does addresses some of these points.  It provides an over-the-top interworking framework that provides a single/unified framework for managing interworking between multiple different fixed, and multiple different mobile networks. 

The network side functions can be flexibly instantiated either at the core or at the access edge. 
As an example of MAMS instantiation at the access edge, MEC can host (e.g. as apps) the network selection control functions (referred as NCM and N-MADP). MAMS functions, hosted on the MEC, also provide the location mapping functions, i.e., selection of core network path for upstream data, and selection appropriate access links for delivering the downstream data, which is in alignment with schemes for separation of location and ID .

BR
Satish

Satish Kanugovi ([email-masked]), DMTS, :Core Networks Evolution Group:
Core, Cloud & Software Innovation Planning  @ Mobile Networks CTO
Call/Text: +91 98861 24678 (cell), https://www.linkedin.com/in/satishkanugovi

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Tuesday, February 28, 2017 2:26 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [5gangip] New Version Notification for draft-vonhugo-5gangip-ip-issues-02.txt

Oh, on the discussions of LISP (and I use LISP as a generic term for separation of location and ID and not to refer to a specific format):

The discussion of LISP could be framed in the context of Fixed Mobile Convergence where it offers some interesting advantages as follows:

Fixed Mobile Convergence or FMC could better be described as (F)+(M)+C .. i.e. there are multiple fixed and multiple mobile networks that need to be converged, not just one of each.

If there were just one fixed network and one mobile network then an interworking solution to FMC requires a single protocol to hand off between the two. The problem of course is that there are multiple different fixed and multiple different mobile networks that ideally should be converged. An interworking solution therefore results in O(N^2) protocols while an over the top solution just adds one.

Hmm .. then again for standards folks interworking would be lots of new work ;)

Peter

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Monday, February 27, 2017 2:50 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [5gangip] New Version Notification for draft-vonhugo-5gangip-ip-issues-02.txt

Hey guys,

Starting to read this over in a bit more depth and had a couple of quick general comments before I dig deeper.

1 - The introduction implies that the infrastructure has to be ready to meet 5G needs. This is too late. The 4.5G architecture for things like NB-IOT and highly virtualized cores for EPC will require very similar architectures and one can think of NB-IOT and 4G as slices implemented in the supporting infrastructure.  So we can imagine operators deploying an architecture now that will allow 4G and 5G to co-exist and for resources to be adjusted as required between them as 5G penetrates more and more. While I have no idea what will happen with 5G , for 3G to 4G there are radios that do both to ease migration so perhaps the same will happen with 5G?

2- There is a conspicuous lack of discussion of front haul and its role. Detnet and its relationship to eCPRI and ROE/1904.3 should be explored. There may well also be ACTN related issues for the analog FH, at a minimum there are auto discovery issues on every fiber and wire irrespective of what they ultimately carry. 

3- The control hierarchy/orchestration and its interworking when you cease to continue moving up a hierarchy needs to be addressed, I suppose a form of BGP or other peering between autonomous 5G systems would be required because we can't have a master controller for the 5G world.

Anyway just a few early thoughts.

Peter

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: Thursday, February 23, 2017 2:53 PM
To: [email-masked]
Cc: [email-masked]
Subject: [5gangip] New Version Notification for draft-vonhugo-5gangip-ip-issues-02.txt

Hi all,

Dirk and I submitted Rev. 02 of 5G IP issues draft.
Your comments will be appreciated.

Regards,

Dirk& Behcet

A new version of I-D, draft-vonhugo-5gangip-ip-issues-02.txt
has been successfully submitted by Behcet Sarikaya and posted to the IETF repository.

Name:           draft-vonhugo-5gangip-ip-issues
Revision:       02
Title:          Review on issues in discussion of next generation
converged networks (5G) from an IP point of view Document date:  2017-02-23
Group:          Individual Submission
Pages:          18
URL:
https://www.ietf.org/internet-drafts/draft-vonhugo-5gangip-ip-issues-02.txt
Status:
https://datatracker.ietf.org/doc/draft-vonhugo-5gangip-ip-issues/
Htmlized:       https://tools.ietf.org/html/draft-vonhugo-5gangip-ip-issues-02
Diff:
https://www.ietf.org/rfcdiff?url2=draft-vonhugo-5gangip-ip-issues-02

Abstract:
   This document presents considerations related to open and upcoming
   issues with upcoming new communication systems denoted as 5G aiming
   to set a basis for documenting problem space, use-cases, and
   potential solutions related to next-generation network
   infrastructure.  The draft reviews currently investigated topics,
   including both inputs from IETF and from other SDOs as well as
   research activities.  Further the outcome of recent discussions at
   side sessions during IETF meetings are recaptured to help identifying
   a starting point for future thoughts.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

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

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

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

---

From: János Farkas <[email-masked]>
Date: Thu, 2 Mar 2017 11:28:57 +0100

Hi,

Just to add to Peter's comment #2:
In addition to DetNet Pointed out by Peter already (e.g., 
https://tools.ietf.org/html/draft-ietf-detnet-use-cases-11#section-6), 
IEEE P802.1CM TSN for Fronthaul is very relevant to 5G 
(http://www.ieee802.org/1/pages/802.1cm.html, e.g., 
https://mentor.ieee.org/802-ec/dcn/16/ec-16-0038-01-5GSG-802-1cm-for-5g.pdf).

Note also the DetNet Charter 
(https://datatracker.ietf.org/wg/detnet/charter/, e.g., "The Working 
Group collaborates with IEEE802.1 Time Sensitive Networking (TSN), which 
is responsible for Layer 2 operations, to define a common architecture 
for both Layer 2 and Layer 3").

Best regards,
Janos

---

From: AshwoodsmithPeter <[email-masked]>
Date: Thu, 2 Mar 2017 14:44:10 +0000

Hey Janos, long time no chat!

Yes thanks for pointing out the Detnet references.

This reminds me that PTP and 1588 etc. is also highly relevant, especially for a highly compressed packet based fronthaul and there is no discussion of this in the document either.

There are lots of interesting traffic engineering issues around fronthaul/backhaul and packet if we are to avoid having multiple networks.

Peter

-----Original Message-----
From: János Farkas [mailto:[email-masked]] 
Sent: Thursday, March 02, 2017 5:29 AM
To: AshwoodsmithPeter <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [5gangip] New Version Notification for draft-vonhugo-5gangip-ip-issues-02.txt

Hi,

Just to add to Peter's comment #2:
In addition to DetNet Pointed out by Peter already (e.g., https://tools.ietf.org/html/draft-ietf-detnet-use-cases-11#section-6),
IEEE P802.1CM TSN for Fronthaul is very relevant to 5G (http://www.ieee802.org/1/pages/802.1cm.html, e.g., https://mentor.ieee.org/802-ec/dcn/16/ec-16-0038-01-5GSG-802-1cm-for-5g.pdf).

Note also the DetNet Charter
(https://datatracker.ietf.org/wg/detnet/charter/, e.g., "The Working Group collaborates with IEEE802.1 Time Sensitive Networking (TSN), which is responsible for Layer 2 operations, to define a common architecture for both Layer 2 and Layer 3").

Best regards,
Janos

---

From: AshwoodsmithPeter <[email-masked]>
Date: Thu, 2 Mar 2017 15:00:50 +0000

Oh, Another point concerning security related to LISP.

There is an interesting issue with anchor-less mobility. Obviously anchor points perform policy accounting lawful intercept etc. duties that cannot be ignored.
The absolute best place to perform these functions (if its not at an anchor point in the network) is actually in the terminal/UE itself. 

And therein lies the security/trust issue. How can you remove anchors points in the network and instead use the UE/terminal as the only remaining single anchor point to perform its own accounting and policy? 

There are secure execution environments/processors in terminals/UE's these days, where all the finger print recognition, password encryption etc. is done and perhaps it's possible to extend these to run secure network functions on behalf of the slices. i.e. the NFV cloud extends into the terminal's secure execution engine.

Peter

-----Original Message-----
From: K, Satish (Nokia - IN) [mailto:[email-masked]] 
Sent: Thursday, March 02, 2017 1:47 AM
To: AshwoodsmithPeter <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [5gangip] New Version Notification for draft-vonhugo-5gangip-ip-issues-02.txt

Hi Peter:

This statement implies the following:
- NCM and CCM negotiate the combination of network paths, e.g. which combination of access links, and which core (IP address) to reach the application.. 
say, use LTE in the Uplink and Wi-fi in the Downlink for accessing an Application Server via the Wi-Fi core (i.e App server would see it as device accessing via regular Wi-Fi network).
- NCM and CCM agree on either an encapsulation protocol/location-ID separation protocol to help the network user plane entity (N-MADP) identify the packets received on the LTE uplink to be routed via the Wi-Fi core Therefore, the MAMS scheme can co-exist and is in alignment with the location/IP separation concept.

BR
Satish

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Tuesday, February 28, 2017 10:07 PM
To: [email-masked]; [email-masked]; K, Satish (Nokia - IN) <[email-masked]>
Subject: Re: [5gangip] New Version Notification for draft-vonhugo-5gangip-ip-issues-02.txt

Peter

-----Original Message-----
From: K, Satish (Nokia - IN) [mailto:[email-masked]]
Sent: Tuesday, February 28, 2017 6:01 AM
To: AshwoodsmithPeter <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]; Sprecher, Nurit (Nokia - IL/Hod HaSharon) <[email-masked]>; Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]>; Kuure, Pekka (Nokia - FI/Espoo) <[email-masked]>; Vasudevan, Vasu (Nokia - US) <[email-masked]>; Zhu, Jing Z <[email-masked]>; Florin Baboescu <[email-masked]>; pengshuping <[email-masked]>
Subject: RE: [5gangip] New Version Notification for draft-vonhugo-5gangip-ip-issues-02.txt

Hi Peter:

BR
Satish

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Tuesday, February 28, 2017 2:26 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [5gangip] New Version Notification for draft-vonhugo-5gangip-ip-issues-02.txt

Peter

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Monday, February 27, 2017 2:50 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [5gangip] New Version Notification for draft-vonhugo-5gangip-ip-issues-02.txt

Hey guys,

Peter

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: Thursday, February 23, 2017 2:53 PM
To: [email-masked]
Cc: [email-masked]
Subject: [5gangip] New Version Notification for draft-vonhugo-5gangip-ip-issues-02.txt

Hi all,

Regards,

Dirk& Behcet

Abstract:

The IETF Secretariat

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 2 Mar 2017 12:22:30 -0800

> And therein lies the security/trust issue. How can you remove anchors points in the network and instead use the UE/terminal as the only remaining single anchor point to perform its own accounting a…

Multicast and you distrust everyone. You make it best effort. You multicast RLOC changes when it happens and its up to the receivers to decide if they want to use your new RLOC. And it needs to be done in limited scope so it can scale with authentication.

Dino

---

From: AshwoodsmithPeter <[email-masked]>
Date: Thu, 2 Mar 2017 21:05:21 +0000

Thanks Dino,

My first point was more related to trusting accounting information and trusting that policy was being enforced. 
My second point was that there are new trusted environments in the UE's which effectively mean that you could trust certain things from the UE.

I suppose in the operators network it's possible to trust mappings coming from the NB's and other first hop access points.

Peter

-----Original Message-----
From: Dino Farinacci [mailto:[email-masked]] 
Sent: Thursday, March 02, 2017 3:23 PM
To: AshwoodsmithPeter <[email-masked]>
Cc: K, Satish (Nokia - IN) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [5gangip] New Version Notification for draft-vonhugo-5gangip-ip-issues-02.txt

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 2 Mar 2017 13:47:54 -0800

> I suppose in the operators network it's possible to trust mappings coming from the NB's and other first hop access points.

Yes, just like wifi (non WiFi-Direct), where you have some policy you can play with in a centralized spot.

Dino

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 2 Mar 2017 16:23:05 -0600

An important point we made in ip-issues draft in Section 9 second
paragraph was about the session management function (SMF) defined by
3GPP SA2 decomposition or subdivision to NCM and MADP.
So far no comments on that?
I think that SA2 views SMF as being purely control plane entity. Any
data plane or user plane components are placed in the user plane
function or UPF.
So we need to justify why something like MADP is not part of UPF?

Behcet

---

From: Tom Herbert <[email-masked]>
Date: Thu, 2 Mar 2017 14:25:42 -0800

Behcet, Dirk,

Thanks for the draft. A few comments below...

First sentence: "upcoming" used twice seems redundant

Section 1:

Probably don't need to mention 2020 here, it is sufficient to say "upcoming"

"potentially heterogenous technologies in concurrence" should be
separate data point. Not sure potential is needed, seems like this is
going ot be a core requirement.

Section 2.1

s/These group/This group/

"moving devices" or "mobile devices"?

Section 2.2

Isn't MTM (machine to machine) common acronym for this type of
communication. Also, maybe this whole use case is just IoT?

Use case 2.3 and 2.2 have a significant degree of overlap and maybe
should be merged. There might just be two use cases indicated by H2M
and M2M communication. The first has minimal latency requirements, the
second much more likely to be latency (an reliability) critical. The
first class clearly has high bandwidth requirements (e.g. people
watching videos), but the second may very well have high bandwidth
requirements also (e.g. remote cameras sending data for video
analytics).

Section 3:

Is there any way to quantify "high availability and reliability". This
is going to be important with competing technology such as V2X.

Section 5:

s/Currently/Currently,/

"multiple checksums" meaning Internet checksum or more generally
integrity checks such as CRC?

-1 on designing a new type of protocol :-)

A little confusing mentioning 5G, 802.11, Wi-Fi as layer below. That
is completely correct layering, but seems orthogonal to just 5G.

"there are even much more we need to consider" - bad wording

moving things->mobile nodes

Section 6:

I like the "no gateways would be needed" :-) In fact I think that a
first order goal of this work should be to flatten and simplify the
network.

Section 8:

We need to align this whole discussion with the V2X WAVE work. They
are currently planning on using a variant of IP mobility. Honestly, I
am very worried that the complexity and requirements of the mobile
architecture will be an impediment to unifying the architecture with
vehicular networks. Honestly, if I was building these networks from
scratch I'd be more inclined to got with a more canonical (and
simpler) IP network architecture.

Consider the alphabet soup of section 9 with regards to complexity!

Section 10: ILNP is a nonstarter. It has no deployment and no
implementation. Maybe just say ILA is based on ILNP. To data, LISP and
ILA are the only proposed and practical protocols for 5G mobility.

The changes required by ILNP are not at all minimal. It is invasive in
the transport layer which is exactly what makes it a nonstarter. The
whole discussion here about ILNP is baseless.

"As non of the mentioned existing protocols fully covers the 5G
requirements consistently"-- this needs to be quantified, especially
if the conclusion is that we need yet another identifier/locator
protocol as the document insinuates then that is going to need a real
justification. IIRC there was even early on the 5G list about coming
up with a new IP protocol because IP wasn't good enough. These serve
to do nothing more than make 5G somehow special and prevent
unification. IMO, the emphasis here should be on simplification and
leveraging existing Internet protocols.

Security/privacy:

End-to-end encryption should be supported and encouraged. In
particular, we (content providers) want to hide as much of the packet
from the network as possible which includes transport layer headers.
Mobile networks, including 5G, must start to assume they won't have
access to L4 headers any more (such as TCP). This is a big issue in
the battle against protocol ossification!

Tom

On Thu, Feb 23, 2017 at 11:52 AM, Behcet Sarikaya
<[email-masked]> wrote:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>

---

From: János Farkas <[email-masked]>
Date: Fri, 3 Mar 2017 08:40:44 +0100

Hi Peter,

Yes, it's been ages, unfortunately. It'd be great to chat f2f.

I fully agree with all your recent points as well.

Cheers,
Janos

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 3 Mar 2017 14:57:29 -0600

Hi Tom,

On Thu, Mar 2, 2017 at 4:25 PM, Tom Herbert <[email-masked]> wrote:
> are currently planning on using a variant of IP mobility.

Do you mean ipwave WG? They are currently charted to develop IPv6 over
802.11-OCB with OCB being Communicating Outside the Context
so where is the overlap?

> Honestly, I

Welcome to the architecture discussion. As we mentioned in the draft,
such a discussion should consider the current 5G Architecture as we
have it in Figure 1.

> Consider the alphabet soup of section 9 with regards to complexity!

This comment seems to be related to Peter's comment on the
relationship of session management with identifier locator separation
issue.
We thought that by including it maybe we get some requirements on
multihomed nodes when used simultaneously such as fragmentation,
reordering etc.

> whole discussion here about ILNP is baseless.

No need to rehash ILNP discussions we already had on the list.

> leveraging existing Internet protocols.

I hope that you don't mean here that an existing protocol as is  what we need.
Otherwise we are in agreement.

> the battle against protocol ossification!

We don't want to get into this discussion which seems to be related to quic.

BTW, I did the editorial changes you suggested above, hopefully to be
reflected in Rev. 03.

Regards,

Behcet