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

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 23 Feb 2017 13:52:47 -0600

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

---

From: AshwoodsmithPeter <[email-masked]>
Date: Mon, 27 Feb 2017 19:49:42 +0000

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,

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.

converged networks (5G) from an IP point of view Document date:  2017-02-23

Abstract:

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

---

From: AshwoodsmithPeter <[email-masked]>
Date: Mon, 27 Feb 2017 20:55:54 +0000

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,

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: Jon Crowcroft <[email-masked]>
Date: Tue, 28 Feb 2017 09:18:14 +0000

the idea of using BGP for a network of a trillion devices is
truly scary. please think again - the number of ASs will be
in the millions - BGP is the wrong paradigm. the level of
resource sharing ("peering") and rate of change of
customer/provider relationships would simply not work with a)
path vector or b) the BGP policy expression mechanisms...

something new is needed. and fast.
> 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.
> 
> Htmlized:       
> https://tools.ietf.org/html/draft-vonhugo-5gangip-ip-issues-02
> Diff:
> 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: AshwoodsmithPeter <[email-masked]>
Date: Tue, 28 Feb 2017 14:50:35 +0000

Thanks John,

I was not advocating a specific solution but pointing out that something  " BGP like ", i.e. a distributed protocol between islands of 5G would be required rather than another level of hierarchy. My point was that there was no discussion of this item in the document and that since the IETF is pretty good at this sort of thing it would seem that perhaps a discussion of this issue should be in the document. My guess is that the IETF leadership is looking to understand what issues will require new work and then which groups are best suited to deal with them so if you agree that the problem is real and needs addressing then a section on this with some guidance would likely be very useful. 

One quibble, while there may be 100's of billions of 5G devices it is expected that most of them won't require mobility but I agree it's still a daunting problem.

Peter

-----Original Message-----
From: Jon Crowcroft [mailto:[email-masked]] 
Sent: Tuesday, February 28, 2017 4:18 AM
To: AshwoodsmithPeter <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Jon Crowcroft <[email-masked]>
Subject: Re: [5gangip] New Version Notification for draft-vonhugo-5gangip-ip-issues-02.txt

the idea of using BGP for a network of a trillion devices is truly scary. please think again - the number of ASs will be in the millions - BGP is the wrong paradigm. the level of resource sharing ("peering") and rate of change of customer/provider relationships would simply not work with a) path vector or b) the BGP policy expression mechanisms...

> 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.
> 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.
>

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 28 Feb 2017 15:49:39 +0000

understood - didn't mean to imply you were positing bgp, per
se 

we need something that comprehends slices (and anti-slices:)
too and is cross layer - as well as scaling!
> Thanks John,
> 
> I was not advocating a specific solution but pointing out that something  
> " BGP like ", i.e. a distributed protocol between islands of 5G would be 
> required rather than another level of hierarchy. My point was that there 
> was no discussion of this item in the document and that since the IETF is 
> pretty good at this sort of thing it would seem that perhaps a discussion 
> of this issue should be in the document. My guess is that the IETF 
> leadership is looking to understand what issues will require new work and 
> then which groups are best suited to deal with them so if you agree that 
> the problem is real and needs addressing then a section on this with some 
> guidance would likely be very useful.
> 
> One quibble, while there may be 100's of billions of 5G devices it is 
> expected that most of them won't require mobility but I agree it's still 
> a daunting problem.
> 
> Peter
> 
> the idea of using BGP for a network of a trillion devices is truly scary. 
> please think again - the number of ASs will be in the millions - BGP is 
> the wrong paradigm. the level of resource sharing ("peering") and rate of 
> change of customer/provider relationships would simply not work with a)

---

From: AshwoodsmithPeter <[email-masked]>
Date: Tue, 28 Feb 2017 16:36:52 +0000

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

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: Behcet Sarikaya <[email-masked]>
Date: Tue, 28 Feb 2017 11:00:39 -0600

Hi Satish, all,

When you post mails on 5G IP list, please, please do not use long cc
lists! We said this before, now repeating again.
Most of those people in your cc list are already on the list, the
mailer automatically distributes the mails to everybody.
If you think someone is not subscribed, please let me and Dirk, we can
subscribe those people.

If you use long cc lists, the reflector starts to malfunction, so your
mail may not get delivered at all.

Regards,

Behcet