Subject: [Netslices] Another approach to the problem

From: Stewart Bryant <[email-masked]>
Date: Thu, 16 Mar 2017 11:34:30 +0000

I have been thinking quite hard about the ongoing debate between those 
looking to design and deploy NS, and those with experience in deploying 
orchestrated networks.

I wonder if we need to address this from a different angle.

Fundamentally this is about a customer buying a service from a provider, 
and the provider spinning up all the components of that service, and the 
question being asked is whether this is a new business model supported 
by new technology of an existing business model for which we have 
deployed technology.

I wonder whether we might make more progress by starting with the 
business architecture?

I think that this means building a model with provisioning requests 
flowing in one direction and invoices flowing in the other.

I know that this is unusual in the IETF but I wonder if it would enable 
us to shed more light on the problem.

- Stewart

---

From: <[email-masked]>
Date: Thu, 16 Mar 2017 11:50:55 +0000

Stewart

Interesting - I had EXACTLY the same thought.

There IS a business issue here which is hurting the SPs who, in-turn, are being asked to invest in order to support more consumption from the OTTs.

My thought is that IETF (note - E) is the wrong place to be addressing this for the <very good> reasons Anton has been succinctly addressing.

Other "network" industries also struggle with this same revenue settlement/investment/OTT problem to different extents (the two which come to mind immediately are rail and electricity supply).

Could this be an IAB study group of some sort?

David

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: 16 March 2017 11:35
To: Network Slices <[email-masked]>
Subject: [Netslices] Another approach to the problem

I have been thinking quite hard about the ongoing debate between those looking to design and deploy NS, and those with experience in deploying orchestrated networks.

Fundamentally this is about a customer buying a service from a provider, and the provider spinning up all the components of that service, and the question being asked is whether this is a new business model supported by new technology of an existing business model for which we have deployed technology.

I wonder whether we might make more progress by starting with the business architecture?

I think that this means building a model with provisioning requests flowing in one direction and invoices flowing in the other.

I know that this is unusual in the IETF but I wonder if it would enable us to shed more light on the problem.

- Stewart

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

---

From: Anton Ivanov <[email-masked]>
Date: Thu, 16 Mar 2017 12:00:54 +0000

On 16/03/17 11:34, Stewart Bryant wrote:
> looking to design and deploy NS, and those with experience in 
> deploying orchestrated networks.
>
> Fundamentally this is about a customer buying a service from a 
> provider, and the provider spinning up all the components of that 
> service, and the question being asked is whether this is a new 
> business model supported by new technology of an existing business 
> model for which we have deployed technology.

Existing business model - inter-provider OSS interworking + activation 
to match. Some of us have been there and written it before including 
QoS/Guarantee interworking at the border between providers. I count at 
least 2 people I know who have built this on this list (I am sure there 
are more).

> I wonder whether we might make more progress by starting with the 

If it is an existing business model which some of us have built and 
deplotyed as far back as 2007 (at least myself) and 3GPP has just awoken 
to it - why should we redo it?

I said in one of my first emails that 3GPP has a phenomenal talent for 
digging out archaeological artefacts and presenting them like the newest 
thing around, so we can suffer from them for decades. This is just one 
more example.

There is definitely work needed to improve it and in all my comments I 
am looking at it strictly from the perspective of:

1. What work needs to be done at OSS/BSS/NMS level for making the 
existing model work easier and more "out of the box" - models, interop, etc.

2. What network bits and pieces are missing - IMHO we are missing 
boundary interop here and there.

A.

> I know that this is unusual in the IETF but I wonder if it would 
> enable us to shed more light on the problem.
>
> - Stewart
>
>

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 16 Mar 2017 12:05:40 +0000

David

An interesting idea, regardless of how this discussion turn out.

The IETF, in the broad meaning of the term, tends to regard this sort of 
problem as out of scope, but there are some existential questions that 
lie at the root of this, and they have technical implications, so maybe 
it does  need to take a closer look.

- Stewart

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 16 Mar 2017 08:32:13 -0400

> On Mar 16, 2017:8:00 AM, at 8:00 AM, Anton Ivanov <[email-masked]> wrote:
> 
> Existing business model - inter-provider OSS interworking + activation to match. Some of us have been there and written it before including QoS/Guarantee interworking at the border between providers. I count at least 2 people I know who have built this on this list (I am sure there are more).
> If it is an existing business model which some of us have built and deplotyed as far back as 2007 (at least myself) and 3GPP has just awoken to it - why should we redo it?
> 
> I said in one of my first emails that 3GPP has a phenomenal talent for digging out archaeological artefacts and presenting them like the newest thing around, so we can suffer from them for decades. This is just one more example.
> 
> There is definitely work needed to improve it and in all my comments I am looking at it strictly from the perspective of:
> 
> 1. What work needs to be done at OSS/BSS/NMS level for making the existing model work easier and more "out of the box" - models, interop, etc.
> 
> 2. What network bits and pieces are missing - IMHO we are missing boundary interop here and there.

	Yes, this is basically back to the same approach we took with inter-AS TE.  I suggest people look back at
the pros and cons of that, and how those problems were solved (or not solved) before attempting to 
create new technologies to solve what appear to be very similar situations albeit with different names. 

	—Tom

---

From: <[email-masked]>
Date: Thu, 16 Mar 2017 13:15:57 +0000

Anton

"If it is an existing business model which some of us have built and deplotyed as far back as 2007 (at least myself) and 3GPP has just awoken to it - why should we redo it?"

I'm not convinced that 3GPP HAS awoken to the business model.  In terms of the item you state - "QoS/Guarantee interworking" - there are technical limitations to that in 3GPP architecture (which we can overcome, exactly as you say, with existing, standardised protocols) but there have (AFAIK) been no proposals to 3GPP to radically overhaul the packet-core. To-date, "5G" will be built on the same architecture (just moved around a bit a la network slicing) as 4G/LTE.

I think the reason that this is so is because no-one has stated the business problem other than standing and shouting "Mr OTT - stop taking all my revenue" on one side or "Mr SP - give me infinite capacity for free" on the other.

Boundary interop is an omission but we have to sort-out the settlement problem first.   Right now, the OTTs are doing just fine, thank you, and would like to carry on NOT having to settle (much).  We have to work out what would be in-it for them.

When we've done that, we can take a look at where there may be need for new/improved protocols which we can poke through IETF.

David

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Anton Ivanov
Sent: 16 March 2017 12:01
To: [email-masked]
Subject: Re: [Netslices] Another approach to the problem

A.

---

From: Anton Ivanov <[email-masked]>
Date: Thu, 16 Mar 2017 13:53:41 +0000

On 16/03/17 13:15, [email-masked] wrote:
> I'm not convinced that 3GPP HAS awoken to the business model.

Well, there as signs of that. They seem to have come across some of the 
archaeological artefacts from our ancient travails in their efforts to 
build a "modern network" (quotes intended and needed). LONG after we 
have moved on to do something more interesting.

>    In terms of the item you state - "QoS/Guarantee interworking" - there are technical limitations to that in 3GPP architecture (which we can overcome, exactly as you say, with existing, standardised protocols) but there have (AFAIK) been no proposals to 3GPP to radically overhaul the packet-core.

Unfortunately - yes.

>   To-date, "5G" will be built on the same architecture (just moved around a bit a la network slicing) as 4G/LTE.

Unfortunately - yes ^2.

> Boundary interop is an omission but we have to sort-out the settlement problem first.   Right now, the OTTs are doing just fine, thank you, and would like to carry on NOT having to settle (much).…

Here is where being able to take a resource on let's say homenet, 
6LoPaN, etc, assign it to a "slice" and connect it to the datacenter is 
interesting on many levels to the SP - it can start doing things which 
the OTT are doing now. It can presently only look with envy at what they 
are doing.

If you do it to ALL of the traffic it equates to a virtual CPE.

If you do it to part of the traffic it equates to a virtual service.

It has additional interesting use cases and implications - security 
isolation, etc.

LOTS of interesting stuff to do and to address. Very relevant too. Mirai 
and similar incidents finally showed some of the "benefits" of "Wild 
West" OTT in this space. It is way more interesting than 3GPP attempts 
at amateur archaeology though (they just happen to have logical and 
terminological overlap with it).

> When we've done that, we can take a look at where there may be need for new/improved protocols which we can poke through IETF.

That as well as models to represent the actual boundary interaction so 
it can be controlled by systems which are outside our work scope.

A.