Subject: Re: [Netslices] Open Issue I: SouthBound/Mapping Interface

From: Lei Wang <[email-masked]>
Date: Thu, 4 Jan 2018 07:11:45 +0000

Hi Cristina,

I agree with the Option 1. Maybe it is not the proper time to do  SBI standardization work in COMS now, not matter in terms of opportunity or technology.

About the Option 3,  do you mean we can discuss different situations of SBI according to respenctive technologies in information model that can be delivered to multi-domains ( e.g. ACTN, Detnet...) ? Or what you want to say is the classification of technology domains?

Kind Regards

Lei Wang

________________________________
[email-masked]

From: qiangli (D)<mailto:[email-masked]>
Date: 2017-12-21 17:02
To: Flinck, Hannu (Nokia - FI/Espoo)<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netslices] Open Issue I: SouthBound/Mapping Interface
Hi Hannu and  others,

Thank you for your comments. As you and Diego mentioned, the standardization of southbound interface is a sensitive matter, we’d better avoid infringing other WGs/RGs.

To solve this issue, maybe we should figure out “Is it possible to have a uniform/standard mapping interface to adapt to a variety of implementation technologies?” first. If Pedro is right, such uniform interface does exist, then it’s not a big deal to standardize it IMHO. Otherwise, I think we may need to consider which option listed below will be better:
Option 1: No standardization work on southbound interface, at least before IETF 101
Option 2: Separately analyze all specific technologies as you have done -- ACTN [un-checked], NFV [checked], then how about SFC, VPN…?
Option 3: Classify technologies (e.g., providing connectivity, provide VNF….) , then discuss for each classification.

I personally prefer 1 or 3, what’s your opinion?

Best regards,

Cristina QIANG

From: Flinck, Hannu (Nokia - FI/Espoo) [mailto:[email-masked]]
Sent: Wednesday, December 20, 2017 10:33 PM
To: qiangli (D) <[email-masked]>; [email-masked]
Subject: RE: [Netslices] Open Issue I: SouthBound/Mapping Interface

Hello Cristina and others,

I would suggest that  COMS/ATCN interface mapping would be developed in the TEAS WG since that is an IETF WG, is also alluding to slicing topics, has related specifications and the expertise of the transport networks.

However, NFVO related work is currently within NVFRG where the slicing work is a minor subset of much larger territory of what the RG is discussing.  Therefore, it would be better to do such focused work in COMS when and if it becomes an IETF WG.

Best regards
Hannu

From: Netslices [mailto:[email-masked]] On Behalf Of qiangli (D)
Sent: Wednesday, December 13, 2017 10:41 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Netslices] Open Issue I: SouthBound/Mapping Interface

Hi All,

This email is want to collect your opinion on the following issue:

Do we need to standardize the Southbound/Mapping interface of a network slice aware system in COMS? Or do you think this work should be carried out in existing WGs/RGs? (e.g., mapping interface between COMS and ACTN, mapping interface between COMS and NFVO)

Best regards,

Cristina QIANG

---

From: "qiangli (D)" <[email-masked]>
Date: Thu, 4 Jan 2018 09:11:29 +0000

Hi Lei Wang,

Thank you for your comments. I think an example given by Hannu could be used to explain option 3

“Probably what you want is to have a set of reference or example mappings for few representative technologies? Such as

-          A slice over the WAN/transport network for a given technology,

-          A slice over VNF infrastructure (SFCs and nvo3),

-          A slice that is a concatenation of the two across different domains (this we know is missing).”

Best regards,

Cristina QIANG

From: Netslices [mailto:[email-masked]] On Behalf Of Lei Wang
Sent: Thursday, January 04, 2018 3:12 PM
To: qiangli (D) <[email-masked]>; NetSlices <[email-masked]>
Subject: Re: [Netslices] Open Issue I: SouthBound/Mapping Interface

Hi Cristina,

Kind Regards

Lei Wang

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

Best regards,

Cristina QIANG

From: Flinck, Hannu (Nokia - FI/Espoo) [mailto:[email-masked]]
Sent: Wednesday, December 20, 2017 10:33 PM
To: qiangli (D) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Netslices] Open Issue I: SouthBound/Mapping Interface

Best regards
Hannu

Hi All,

Best regards,

Cristina QIANG

---

From: Liang GENG <[email-masked]>
Date: Tue, 9 Jan 2018 15:31:09 +0000

Hi Hannu

Thanks for your email.

Please find my comments in line.

>HFl: Monitoring and ensuring the SLA end to end of a slice is an important aspect. Note that when the slice is crossing a (technology) domain, we might need to stich the end to end slice OAM from different pieces of segments. Can we have such a “technology agnostic” OAM? Is that feasible? Or should we do something what SFC WG is doing?

>>[LG] I was discussing this with Cristina the other day. What you said about e2e OAM is an extremely important concern for COMS. In a cross-technology scenarios,  on one hand, COMS may send OAM requests to different domain controllers. It is distributing and collecting OAM requests and responses rather than directly executing OAM functions. At this level, I think the OAM model can be technology agnostic because the OAM parameters COMS would like to collect from different domains need to be aligned. However, the actual OAM functions each domain is based on may be different. On the other hand, COMS may need to execute OAM functions directly if there are generic resource elements that are directly under COMS control. Also I am not very familiar with SFC OAM, could you share more informaiton on

I personally think COMS itself should not include the southbound mapping because there was an assumption that anything below COMS is not aware of "slice" (although in management perspective, COMS may see some of them "Subnets"). Existing WG/technologies may refer to/map with COMS models if they would like to be part of the managed network slice instance. Eventually, it may be us - the people from COMS community, who will be actively progressing these southbound interfaces in various IETF WGs.

>HFl: What you say above would be an ideal situation, but I am afraid that in practice the situation is such that also other WGs are working on slicing. See https://www.ietf.org/id/draft-ietf-teas-actn-framework-11.txt

>>[LG] Yes, you are absolutely correct! What I mean is that whether or not a specific technology domain is working on slice, COMS does not need to know. The SBI of COMS delivers configuration models - the domain control apply this configuration based on their own technology choices.

In principle, COMS itself provides the capability of inter-operation between different domains. This capability is enabled by common information model/service model and related OAM models/mechanisms. The southbound mapping is implementation-specific in the view of COMS and may be more suitable to be carried out in various technology-specific WGs. A good example would be that for a link from node A to node B requiring 100Mbit/s peak bandwidth and maximum of 5ms latency, one can map this using various type of SD-WAN(VPN) controllers with different underlay data planes. COMS sees them as the same.

>HFl:  ok.

And also in terms of the working load of WG, the southbound mapping could be endless, it may not be feasible for COMS WG to deliver a sensible charter on this matter concerning southbound interfaces.

>HFl: right.

Meanwhile, I think it would be good if we can first of all deliver a/several information models so that the southbound technology domain can chose the materials they need to map with. We can do this by categorizing the resources as Cristina suggested as "classifications" - which may make the model more systematic. However, it is not necessary to limit the southbound to one category - it should be able to pick parameters/components whatever are needed.

>HFl: this a bit unclear to me. Maybe you can elaborate your thoughts further.

>>[LG] Here I mean if the information model which defines the template of parameters of various type of resource tends to be to complex, we could split it into several information models based on the categories of resources. A specific technology domain may define their own network configuration model (specific SBI of COMS) based on those information models. Of course, the information model could also be just one as we did now. The other thing I would like to point out for discussion is that we may need to define a generic SBI or network configuration model in cases where resources are directly managed/control by COMS. What do yo think?

Best wishes

Liang

From: Netslices <[email-masked]<mailto:[email-masked]>> on behalf of Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]<mailto:[email-masked]>>
Sent: 22 December 2017 22:02:46
To: qiangli (D); [email-masked]<mailto:[email-masked]>
Subject: Re: [Netslices] Open Issue I: SouthBound/Mapping Interface

Ok. Think I what you might be after. Probably what you want is to have a set of reference or example mappings for few representative technologies? Such as

-          A slice that is a concatenation of the two across different domains (this we know is missing).

Is this what you would like to see? If so, it sounds to me reasonable and motivating work and would be  useful to identify possible gaps and needed additions.

Best regards

Hannu

From: qiangli (D) [mailto:[email-masked]]
Sent: Friday, December 22, 2017 3:09 PM
To: Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Netslices] Open Issue I: SouthBound/Mapping Interface

Hi Hannu,

You’re right. Still that question, If there does not exist a uniform mapping interface between COMS and various implementation technologies, I am afraid we are unable to analyze all possibilities.  That’s why I suggested option 3 even I’m also not sure whether we can find out an appropriate classification method.

Best regards,

Cristina QIANG

From: Flinck, Hannu (Nokia - FI/Espoo) [mailto:[email-masked]]
Sent: Thursday, December 21, 2017 9:43 PM
To: qiangli (D) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Netslices] Open Issue I: SouthBound/Mapping Interface

Hello Cristina

I am not sure I understand the option 3 sufficiently. What would be the use of the classification? Should we identify classes of technologies that can be served by same/similar mapping based on the classification?

Best regards

Hannu

From: Netslices [mailto:[email-masked]] On Behalf Of qiangli (D)
Sent: Thursday, December 21, 2017 11:02 AM
To: Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netslices] Open Issue I: SouthBound/Mapping Interface

Hi Hannu and  others,

Best regards,

Cristina QIANG

Best regards

Hannu

Hi All,

Best regards,

Cristina QIANG

---

From: Liang GENG <[email-masked]>
Date: Tue, 9 Jan 2018 15:42:58 +0000

Hi Cristina, Hannu and Lei,

I would like to think it in this way. Please see if this make sense to you.

-It is preferred in COMS NOT to define network configuration model (SBI) for each technology domains.

-It may be preferred in COMS to do some sort of categorization based on the type of resources at the level of information model. This makes it easier for different domain controllers to define specific network configuration models (SBI of COMS, or "mappings" in previous discussion in this tread )

-It may be preferred in COMS to define a generic network configuration model that is used for SBI with resources directly managed by COMS.

What do you think?

________________________________
From: Netslices <[email-masked]> on behalf of qiangli (D) <[email-masked]>
Sent: 04 January 2018 17:11:29
To: Lei Wang; NetSlices
Subject: Re: [Netslices] Open Issue I: SouthBound/Mapping Interface

Hi Lei Wang,

Best regards,

Cristina QIANG

Hi Cristina,

Kind Regards

Lei Wang

Date: 2017-12-21 17:02

Hi Hannu and  others,

Best regards,

Cristina QIANG

Best regards

Hannu

Hi All,

Best regards,

Cristina QIANG

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 9 Jan 2018 17:28:19 +0000

Hi Lei Wang, Cristina, all,

i think it is important, first of all, to decide which type of model you want to address. The drawing from Cristina (from https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/)   is an excellent starting point.
In my opinion you should not try to map "more or less" what you have with one of the models below, but on the other side discuss which one you want to address (e.g. Service Delivery Model) and then proceed on that path.
That said, if I correctly understood you don't want to address the models on the SBI of the network orchestrator (i.e. Network configuration model or device model), hence you need to decide if you want to build a service delivery model or a service model (to start with).
BR
Daniele

From: Netslices [mailto:[email-masked]] On Behalf Of Liang GENG
Sent: martedì 9 gennaio 2018 16:43
To: qiangli (D) <[email-masked]>; Lei Wang <[email-masked]>; NetSlices <[email-masked]>
Subject: Re: [Netslices] Open Issue I: SouthBound/Mapping Interface

What do you think?

________________________________
From: Netslices <[email-masked]<mailto:[email-masked]>> on behalf of qiangli (D) <[email-masked]<mailto:[email-masked]>>
Sent: 04 January 2018 17:11:29
To: Lei Wang; NetSlices
Subject: Re: [Netslices] Open Issue I: SouthBound/Mapping Interface

Hi Lei Wang,

"Probably what you want is to have a set of reference or example mappings for few representative technologies? Such as

-          A slice that is a concatenation of the two across different domains (this we know is missing)."

Best regards,

Cristina QIANG

From: Netslices [mailto:[email-masked]] On Behalf Of Lei Wang
Sent: Thursday, January 04, 2018 3:12 PM
To: qiangli (D) <[email-masked]<mailto:[email-masked]>>; NetSlices <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netslices] Open Issue I: SouthBound/Mapping Interface

Hi Cristina,

Kind Regards

Lei Wang

Date: 2017-12-21 17:02

Hi Hannu and  others,

Thank you for your comments. As you and Diego mentioned, the standardization of southbound interface is a sensitive matter, we'd better avoid infringing other WGs/RGs.

To solve this issue, maybe we should figure out "Is it possible to have a uniform/standard mapping interface to adapt to a variety of implementation technologies?" first. If Pedro is right, such uniform interface does exist, then it's not a big deal to standardize it IMHO. Otherwise, I think we may need to consider which option listed below will be better:

Option 2: Separately analyze all specific technologies as you have done -- ACTN [un-checked], NFV [checked], then how about SFC, VPN...?

Option 3: Classify technologies (e.g., providing connectivity, provide VNF....) , then discuss for each classification.

I personally prefer 1 or 3, what's your opinion?

Best regards,

Cristina QIANG

Best regards

Hannu

Hi All,

Best regards,

Cristina QIANG

---

From: Liang GENG <[email-masked]>
Date: Tue, 9 Jan 2018 17:54:44 +0000

Hi Daniele and all,

This graph is a perfect reference. Thanks for this!

COMS system is at the same level as  "network orchestrator" in this graph. I believe COMS will need to have a information model(s) as templates of a "network slice". It should also address NBI service delivery model.

For Service Model, I am not sure - how much difference is there as to Service Delivery Model. Might they be converged to one level in some cases?

As to the SBI, a generic network configuration model may be useful while other specific ones may be more feasible to be addressed by different technology domains respectively according to COMS information model(s).

We started from COMS information model - trying to confine the scope of resource elements that can be used for network slice. This should provide a general reference to both NBI and SBI.

Best wishes

Liang

________________________________
From: Daniele Ceccarelli <[email-masked]>
Sent: 10 January 2018 01:28:19
To: Liang GENG; qiangli (D); Lei Wang; NetSlices
Subject: RE: Re: [Netslices] Open Issue I: SouthBound/Mapping Interface

In my opinion you should not try to map “more or less” what you have with one of the models below, but on the other side discuss which one you want to address (e.g. Service Delivery Model) and then proceed on that path.

That said, if I correctly understood you don’t want to address the models on the SBI of the network orchestrator (i.e. Network configuration model or device model), hence you need to decide if you want to build a service delivery model or a service model (to start with).

BR
Daniele

What do you think?

Hi Lei Wang,

Best regards,

Cristina QIANG

Hi Cristina,

Kind Regards

Lei Wang

Date: 2017-12-21 17:02

Hi Hannu and  others,

Best regards,

Cristina QIANG

Best regards

Hannu

Hi All,

Best regards,

Cristina QIANG

---

From: Leeyoung <[email-masked]>
Date: Tue, 9 Jan 2018 20:20:35 +0000

Hi Liang,

As you pointed out there is little difference between service delivery model and service model. Service delivery model can be a subset of service model.

In effect, the NBI of COMS system (network orchestrator level) would be much the same as service model. In ACTN, we have defined this interface as CMI (Cutomer-MDSC interface). There is already an information model (https://datatracker.ietf.org/doc/draft-ietf-teas-actn-info-model/) as well as many YANG models on CMI (which corresponds to your NBI) and MPI (which corresponds to your SBI/Network Configuration model) that have been addressed by ACTN effort in TEAS.

Please see the following draft that maps different models to different interfaces: https://tools.ietf.org/html/draft-ietf-teas-actn-yang-00  In Section 4.1 and 4.3, we have elaborated numerous functions and its correspond YANG models on both CMI and MPI (which is your NBI and SBI). It will be good to know what "additional" work COMS will bring to the table beyond what is already covered by this draft.

In addition, there has been a new work started that enhances basic TE to SF-aware TE topology: https://datatracker.ietf.org/doc/draft-bryskin-teas-use-cases-sf-aware-topo-model/  and  https://datatracker.ietf.org/doc/draft-bryskin-teas-use-cases-sf-aware-topo-model/  This new work covers how topology can support not just TE but SF/NF/VNF based on ETSI GS NFV-MAN 001 V1.1.1.

It might be a reasonable thing to begin with these models and identify what needs to be augmented to meet the COMS requirements rather than starting a new model from stretch.

Thanks.
Young

From: Netslices [mailto:[email-masked]] On Behalf Of Liang GENG
Sent: Tuesday, January 09, 2018 11:55 AM
To: Daniele Ceccarelli <[email-masked]>; qiangli (D) <[email-masked]>; Lei Wang <[email-masked]>; NetSlices <[email-masked]>
Subject: Re: [Netslices] Open Issue I: SouthBound/Mapping Interface

Hi Daniele and all,

Best wishes

Liang

From: Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>

BR
Daniele

From: Netslices [mailto:[email-masked]] On Behalf Of Liang GENG
Sent: martedì 9 gennaio 2018 16:43
To: qiangli (D) <[email-masked]<mailto:[email-masked]>>; Lei Wang <[email-masked]<mailto:[email-masked]>>; NetSlices <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netslices] Open Issue I: SouthBound/Mapping Interface

What do you think?

Hi Lei Wang,

Best regards,

Cristina QIANG

Hi Cristina,

Kind Regards

Lei Wang

Date: 2017-12-21 17:02

Hi Hannu and  others,

Best regards,

Cristina QIANG

Best regards

Hannu

Hi All,

Best regards,

Cristina QIANG

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 9 Jan 2018 21:29:10 -0000

Sorry to jump in as a lurker, but co-author of
draft-ietf-opsawg-service-model-explained that is about to be published as RFC
8309 I needed to comment.

Liang said:

> For Service Model, I am not sure - how much difference is there as to Service
Delivery Model. Might they be converged to one level in some cases?

You may converge components. For example, you could decide to build one
component that provides the function of Service Orchestrator and Network
Orchestrator. This a functional architecture, and no one is obliged to implement
it as drawn.

When you converge components, the external interface between those components is
no longer visible and so (of course?) does not need to be implemented. You
*could* continue to use the interface internal to your implementation but you
might replace it with a function call, or not have it at all. It's a private
implementation issue.

BUT, the conflation of Service Model and Service Delivery Model is, in general,
an unwise thing to do. Of course, it may depend on the nature of the service
being discussed. Some services could be so very, very simple that the two models
are nested as Young suggests: "Service delivery model can be a subset of service
model". For example, the customer details might be left out of the Service
Delivery Model, and the service expectations in the Service Model might be
narrowed down to explicit requirements present in the Service Delivery Model.

But for other services, it is quite likely that the Service Delivery Model
contains more detail and specifics based on knowledge of the capabilities of the
underlying network (without specifying the device configuration).

I think you would be wise to keep the distinction in terminology, and if it is
valuable, you can inherit or share common YANG definitions.

Cheers,
Adrian

PS Cristina's figure shows "information model" in two places. In my opinion, an
information model exists only on paper. It may be used to inform the design of a
data model (for use on an external interface). And some implementations might
choose to construct their internal data structures to follow the information
model (or at least make sure that all of the information is present), but this
is an implementation option- in practice (with a functional architecture, you
can explain what the interfaces look like, but you do not need to (should not!)
attempt to specify how the inside of one of your boxes behaves.

---

From: "qiangli (D)" <[email-masked]>
Date: Wed, 10 Jan 2018 04:51:38 +0000

Hi Adrian,

Thanks a lot for your explanation, it's very useful to us. 

As you suggested, we regard the information model as an internal data structure which could be used to describe what a network slice looks like, of course also could be used to inform the design of data models on external interfaces. And what we really want to do is the resource-centric common management plane of network slices, include OAM, data models of interfaces, etc. 

Speaking of data models, I have some confusions about the NBI of Network Orchestrator and the Service (delivery) model. I understand their relation as during the ns requirement initialization phase, NBI data model and service (delivery) model are the same/similar thing. NBI data models has broader meaning in other phases, such as capacity exposure, monitored result report, etc. I am not sure if my understanding is correct or not.

Best regards,

Cristina QIANG

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Wednesday, January 10, 2018 5:29 AM
To: 'Liang GENG' <[email-masked]>; 'Daniele Ceccarelli' <[email-masked]>; qiangli (D) <[email-masked]>; 'Lei Wang' <[email-masked]>; 'NetSlices' <[email-masked]>
Subject: RE: [Netslices] Open Issue I: SouthBound/Mapping Interface

Sorry to jump in as a lurker, but co-author of draft-ietf-opsawg-service-model-explained that is about to be published as RFC
8309 I needed to comment.

Liang said:

> For Service Model, I am not sure - how much difference is there as to 
> Servic

You may converge components. For example, you could decide to build one component that provides the function of Service Orchestrator and Network Orchestrator. This a functional architecture, and no one is obliged to implement it as drawn.

When you converge components, the external interface between those components is no longer visible and so (of course?) does not need to be implemented. You
*could* continue to use the interface internal to your implementation but you might replace it with a function call, or not have it at all. It's a private implementation issue.

BUT, the conflation of Service Model and Service Delivery Model is, in general, an unwise thing to do. Of course, it may depend on the nature of the service being discussed. Some services could be so very, very simple that the two models are nested as Young suggests: "Service delivery model can be a subset of service model". For example, the customer details might be left out of the Service Delivery Model, and the service expectations in the Service Model might be narrowed down to explicit requirements present in the Service Delivery Model.

But for other services, it is quite likely that the Service Delivery Model contains more detail and specifics based on knowledge of the capabilities of the underlying network (without specifying the device configuration).

I think you would be wise to keep the distinction in terminology, and if it is valuable, you can inherit or share common YANG definitions.

Cheers,
Adrian

PS Cristina's figure shows "information model" in two places. In my opinion, an information model exists only on paper. It may be used to inform the design of a data model (for use on an external interface). And some implementations might choose to construct their internal data structures to follow the information model (or at least make sure that all of the information is present), but this is an implementation option- in practice (with a functional architecture, you can explain what the interfaces look like, but you do not need to (should not!) attempt to specify how the inside of one of your boxes behaves.