Project proposal technical feedback SDN-O, GS-O (part 3)


Olga Havel
 

Hi,

 

Attached is the updated Proposal, added to wiki as well.

 

Thanks,

Olga

 

 

From: Olga Havel
Sent: 28 June 2016 14:50
To: 'Elzur, Uri'; 'openo-tsc@...'
Subject: RE: [openo-tsc] Project proposal technical feedback SDN-O, GS-O (part 3)

 

Hi Uri,

 

Thanks for further clarifications. I tried to address your clarifications and comments, I updated the wiki as well as the proposal with the additional info. Please see my comments with [OH] Comment

Talk to you later today.

 

Thanks,

Olga

 

 

From: Elzur, Uri [mailto:uri.elzur@...]
Sent: 25 June 2016 03:56
To: Olga Havel; 'openo-tsc@...'
Subject: RE: [openo-tsc] Project proposal technical feedback SDN-O, GS-O (part 3)

 

Hi Olga

 

Thanks for your care! Doing better and was able to travel and join the team in Berlin. We did miss you, hope you had a good vacation

 

One procedural comment:

Noting China Telecom potential contribution to SDN-O. it is clear to me that China Telecom folks can be “contributors” and their participation is welcome. Note that section 4.a.d in the participation agreement suggests a non-member can also be a “committers”. This may potentially in the future, for a case where a non member may  have a seat on the TSC,  in the steady state. We may want to discuss it. 

Separately, we also need to ask the LF to open the TSC mailing list to anyone who expresses interest. It will be cool to have reference on the website to organizations who are “contributors” even if not members!

[OH] Agree

 

Pls see below relies to some of your replies [UE]

 

Thx

 

Uri (“Oo-Ree”)

C: 949-378-7568

 

From: Olga Havel [mailto:olga.havel@...]
Sent: Thursday, June 23, 2016 8:38 AM
To: Elzur, Uri <uri.elzur@...>; 'openo-tsc@...' <openo-tsc@...>
Subject: RE: [openo-tsc] Project proposal technical feedback SDN-O, GS-O (part 3)

 

Thanks Uri for the notes and comments. I hope you are feeling better and that you back is healing well.

 

I updated the Proposal (attaches is version 0.9), please see my notes below (with [Olga]). I also added notes and the proposal to wiki.

 

Please note that I still kept the proposal as Draft 0.9, as I will need to do updates after the OPEN-O Use Case is finalized. that I will do when the Board/TSC agree the Use Case.

 

Hope the meeting in Berlin went well.

 

Best Regards,

Olga

 

 

From: openo-tsc-bounces@... [mailto:openo-tsc-bounces@...] On Behalf Of Elzur, Uri
Sent: 17 June 2016 15:21
To: 'openo-tsc@...'
Subject: [openo-tsc] Project proposal technical feedback SDN-O, GS-O (part 3)

 

4) GS-O – Brendan Hassett

General comments:

 

Another instance of the same code for the GUI portal for rel1. Long term, look at ways to integrate

Enables 3rd party orchestrator too, if such exists

(MEF as an option)

4 – use the ETSI interface

Can have in theory another orchestrator or 3rd party OSS on top, but not in scope for rel1

GUI – can we use one code (i.e. CMCC GUI for NFV-O) and disable some functionality vs separate code

Catalog is an open

No intelligence e.g. pick best placement target

 

Slide #5, #7:

Based on slide #6, assume that the Service Parser, Decomposer and Workflow Engine are ARIA based from Common TOSCA project.

O.100 BH, AB: comment “Parser decomposer and workflow not aligned” ??? Does ARIAN expose specific APIs for these functions?

O.101 BH: Does GS-O NBI use TOSCA YAML as an input? Interact with the Model Designer? Pls provide pointer to API

O.102 BH: does the Service Decomposer take NSD+VNFFG as an input? Will it split the VNFFG?

O.103 BH: who develops the Catalog project? No commit for rel1???

Slide #6:

O.104 BH: describe the proposed NB API and its potential of integration with any existing BSS. Any DM exposed north bound? How will the proposed API interact with SID?

O.105 BH: is Os-Ma-Nfvo not the proposed interface for 1? Vs. the interface 4 towards the NFVO? It assumes that ETSI model has NO information for the physical network!

O.106 BH, AB: relies on Common – TOSCA catalog? CSAR is only API requirement for integration? What protocol?

O.107 BH: what is the semantics of interface 3 to the SDN-O component – just E2E connectivity request? Need additional parameters…

Slide #8:

O.108 BH: define “Service”

 

6/9/16 Shenzen

6) SDN-O Olga Havel

Some general comments:

<Olga> Version 0.9 added with subset of comments addressed, others will be addressed during the next 2 milestones of the project, at architecture meetings or post Release 1

<Olga> Major Risk - OPEN-O Use Case not agreed yet, waiting for the Board and TSC to agree the OPEN-O Use Case, new SDN-O Proposal version will be needed afterwards. Therefore, network diagrams have not been changed yet, until the Use Case is agreed.

<Olga> Some comments here are really not open issues for the proposal, but items to be specified during the project, either Release 1 or post Release 1.

<Olga> Some comments here are more general OPEN-O items, outside of the SDN-O scope

 

·         Do not use “Network Services” to avoid confusion w ETSI NSD (but would like to)

<Olga> DONE. Change to network connectivity service everywhere – Slide 2 Project Description was the reason for the comment.

·         China Telecom code for Network SA – will that not be avail now? Slide #13 suggests committers from China Telecom

<Olga> My latest info is that China Telecom will be involved, we are in contact with them and discussing use cases. I have China Telecom as committers.

[UE] comment above.

Other plans for Service Assurance? Seems like Huawei MAY add post rel1 per slide #12?

<Olga> We are currently defining the use case with China Telecom for Release 1 (Stretch Goal for fully integrated and functional for November). Additional Functionality is proposed post-release 1, not Huawei but OPEN-O roadmap. Please see both Post Release 1 Roadmap (Slide 15) and Post release 1 Lifecycle extensions(Slide 12). I used the same diagram as GS-O initially, to make it consistent. The note only says that the diagram on Slide 12 will be enhanced going forward.

[UE] slide 13 now, I guess

[OH] Changed all slide numbers in the wiki

 

 

O.200 UE: Intel to explore adding a committer to the ODL driver project, working w ZTE

<Olga> Waiting for Intel to come back to me.

 [UE] WIP

[OH] Any progress?

 

 

O.201 LD: clarify comment on Overlay/underlay – CMCC wants Enterprise/. No one has key different requirements at this point

<Olga> I changed Slide 9 to “E2E Overlay Network Connectivity Service over Underlay Connectivity”. Currently Use Case being discussed - Enterprise and residential.

[UE] assume this means E2E within the SDN-O control! i.e. it is not planned to have the same overlay running between SDN-O and NFV-O. so pls clarify the term “E2E” somewhere in your deck

[OH] Updated to “E2E Overlay Network Connectivity Service within the SDN-O Control ...” everywhere

 

Slide #3

GS-O will not have ability to access to configure the micro services. Will only have one item it can drive: an e2e connectivity request.

 

<Olga> That is correct for Release 1. We can discuss if more is needed post Release 1.

 

O.202 OH, ARC: should SDN-O be a standalone entity exposing its own NB and SB APIs (GUI, Catalog, Data Model) or what is the right level of integration with rest of Open-O for rel1 and long term? Current proposal has no way for GSO to orchestrate any SDN-O internal micro services but the E2E connectivity service

<Olga> Release 1 Proposal states that GS-O orchestrates only the e2e network connectivity service. We are discussing if there is need for any retrieval for release 1, latest info from GS-O is that no get will be required for Release 1. We will need to expand it for post Release 1. Currently requirement is to abstract the network connectivity and provide abstracted API that does not mandate the GS-O to understand the network topology, layering and different technologies. The solution post release 1 may be general enough that any properties defined by business in the catalogue to be configurable and visible at GS-O layer should be supported, including selecting technologies and viewing the details of network if needed.

[UE] as we have one use case for rel1, the GS-O request will be for “e2e network connect”. So will SDN-O simply pick one of its 3 micro services? Based on what criteria?

[OH] Updated with saying hard-coded for Release 1, with catalogue driven for release 2.

 

O.203 OH, ARC: provide the NB Rest API. Referring to ETSI MANO spec fig 5.2 what is the difference between the WAN Infrastructure Manager and SDN-O? What is the pro/cons of using Or-Vi and Nf-Vi as a starting point for NB and SB API? If MEF Legato is proposed, provide a write up of its pro/cons and industry support. What is the flexibility to change it?

<Olga> Removed the MEF Presto Reference, we can discuss at the Architecture Committee. Changed it to more generic statement on Slide 10, although we believe MEF is requirement for SDN-O, and we should substantiate it further at the architecture meetings for Release 2 strategy.

MEF / TMF / ETSI may be useful as reference for abstract NBI (post Release 1)

MEF / ONF / TMF/ ETSI may be useful as reference for abstract SBI (post Release 1).

 

O.204 ARC: assume a connectivity type can be requested from GS-O? Or else what is the meaning of asking for an E2E connectivity from GS-O?

<Olga> Connectivity type may be asked from GS-O or may be automatically assigned, depending on the business policy. Release 1 plan is to initially support the use case where SDN-O automatically selects the underlaying technologies. Going forward (Post release 1) it will may also be in the catalogue as part of the network connectivity service template.

[UE] pls see comment above related to O202

[OH] Updated with saying automatically selects the underlaying technologies, hardcoded in the overlay e2e service.

 

O.205 ARC: is Open-O to be architected presented as Hierarchy of orchestrators or provide also a top seeing all physical and logical infrastructure and exposing based on RBAC

<Olga> I think we agreed that it is up to the business to decide what is exposed to the top level and what is abstracted by the SDN-O, based on its business policies, requirements and organization. Release 1 Use Case is the simple one without need to expose all infrastructure, currently discussing with GS-O if anything needs to be exposed. Latest info from GS-O is that get will not be required in Release 1.

[UE] I think this is an OPEN for the Arch team

[OH] Yes

 

O.206 ARC: assume that some VNFs will be on boarded based on their YANG model, so TOSCA Common and the associated Designer have to support YANG and conversion to TOSCA (of relevant parts). Should the Designer for the physical network and SDN-O be integrated too – i.e. related also to TOSCA/YANG interaction/ integration

 

<Olga> We may discuss more at the Architecture Meetings and TSC. Our current agreed architecture is defined to abstract physical network and specific vendors and their models by providing a common SBI and capability to add drivers to map from vendor APIs to common API.

[UE] pls note, I don’t think we have discussed / agreed on this before

[OH] My understanding is that the architecture figure specifies having common SBI and different drivers external from SDN-O. Does that mandate some generic orchestration based on common APIs and models and drivers handling specifics of the specific vendor YANG models?

 

O.207 OH: document operator’s requirements for Roles and responsibilities (e.g. separate operator for NFV and SDN. Top level operator should not have double click access to the physical network). Addressing different personalities, diff scenarios

<Olga> Is this SDN-O Open Issue? We discussed the roles and responsibilities during the overall User Case? Should this be OPEN-O or even GS-O and not SDN-O issue., where we have those roles documented as discussed in Beijing.

[UE] agree!

 

O.208 OH: as code for GUI is not yet avail (per slide #11) – why not use GS-O?

<Olga> SDN-O will reuse the Portal code from NFV-O, same as GS-O.  Slide does not say that the code is not shared, just that it is a different project and different module. The GS-O will have different GUi and have different requirements. Longer term, the best approach would be to have common Portal Framework that could be reused between modules. Currently, out of 44 use cases we have for SDN-O, only 2 are exposed to GS-O.

 

O.209 OH: provide a description of proposed interaction with GS-O and Common TOSCA (slide #9 suggests NO interaction, while Slide #10, #11 shows some)

<Olga> Slide 9 used the existing Architecture slide and specifies what is in the scope of SDN-O in the Release 1 and what external modules the SDN-O will depend on or will use. It does not specify who would be using SDN-O over API. Slide 10 specifies that GS-O will communicate with SDN-O via REST interface. How this SDN-O REST interface is called from GS-O (via TOSCA template or some other way) should probably be described in GS-O, as SDN-O provides REST interface and the rest is external to SDN-O.

[UE] looking for a short paragraph that describes the functional interaction. Will attempt to do it but will be best if you can help. Not sure we know what you think s the interaction supported w GS-O

[OH] I added more info on Slide 6.

 

O.210 OH: provide the “common SBI” API.

<Olga> I added the Common SBI slide 5. Please review.

[UE] will provide technical feedback on the proposed SBI  API ASAP

Is anyone else looking into it?

[OH] We will distribute the new version by 30th. Nobody is reviewing it yet, we will do it during milestones M1 and M2.

 

O.211 OH: how will the “common SBI” be defined? Is he API for Rel1 proprietary with a future option to move to MEF Presto? How wide is its industry support? What devices support is today? Standardization goals? How to drive broad industry adoption?

<Olga> I added the Common SBI slide 5. Please review.

[UE] process understood. My concern is more on the SBI technical aspects

[OH] We will review it and update based on the review comments for Milestone 2. If we cannot deliver, will identify the gaps and requirements for post Release 1.

 

Slide #4:

O.212 OH: What technologies/protocols will be used by ODL to drive its respective devices? Just VLAN/VxLAN?

<Olga> This will be based on the OPEN-O Use Case. Currently VLAN/VxLAN, as mentioned on the slide, but the new Use Case is being discussed (Board/TSC). May be more if agreed.

 

O.213 OH: What technologies/protocols will be used by ONOS to drive its respective devices? Is the L3VPN configured into physical devices using OpenFlow? Other? What IPsec options?

ODL driver from ZTE

<Olga> This will be based on the OPEN-O Use Case. Currently L3VPN/IPSec, as mentioned on the slide, but the new Use Case is being discussed (Board/TSC). May be more if agreed. The controller itself and how it communicates with devices is outside of the SDN-O project, will be defined in the Lab/Test project

 

O.214 ZTE: what NBI of ODL will the ZTE driver support? E.g. NetVirt to OvS on the server?

 <Olga> More details about what exact Controller APIs will be supported will be specified before milestone M1 Feature/Functionality Freeze or M2 API freeze.

 

Agreement that SDN Controller under VIM or directly from the NFV-O is out of context. However it is assumed that for rel1, the SDN-O will manipulate Neutron to connect the Physical network to the tenant specific logical network inside the VIM.

<Olga> Correct

 

 

O.215 OH: Describe VIM Neutron driver functionality? What is the solution approach? Supports connectivity only or isolation, QoS and security too? What neutron API and OpenStack versions are supported? (criteria to select the OpenStack distro – RHT mentioned on slide #14)

Neutron API is referred to and used herewith for SDN-O connectivity only.

<Olga> We will specify all this before M1 Feature/Functionality Freeze or M2 API freeze.

 

O.216 OH: does it present a multi writer issue?

<Olga> Currently, the team is aware of the potential issue raised by Uri and will analyze the problem and propose the solution.

 

O.217 OH: describe the low level semantics of the proposed connectivity model. It seems to add a router in the path. Implications?

<Olga> Is this something we want in the proposal or are we going to work on it in the first milestones of the project. In regards to adding a router on a path – depends where the router is (PE, P1, in access, etc). In some cases, SDN-O may not even be aware of it (inside the controller domain) and in some cases SDN-O will need to support it, but the use case for this is outside of the scope of Release 1.

[UE] this is about how we connect E2E when we have some part in SDN-O and another inside NFV-O. we  do need to discuss it

[OH] Can we do it during the Mileastone 1 (features and functionality) or Milestone 2 (API)??

 

O.218 ARC: What is the preferred long term approach for SDN to VIM network connection – direct? By SDN-O? Through GS-O? Who owns the global VNFFG?

<Olga> Topic for all the partners, including TSC and architecture committee.

 

DENG Huis comment – would like to see super controller as part rel 1

Super SDNC: CMCC has a developer assigned to the ODL SPTN project

 

<Olga> Will update the slides when the new Use Case proposed by CMCC is agreed and the final agreed slide distributed to all.

 

O.219 OH: provide description of SPTN. Is this a CMCC code contribution? How does it add value to agreed Rel1 Use case?

<Olga> SPTN is requested by CMCC. I will add it to the diagram later, when I receive the latest agreed use case diagram. Currently, will leave the Use Case diagram unchanged. Please ask the Board/TSC about the value of SPTN, China Mobile is requesting it based on their business needs.

 

O.220 DH: clarify - no need for L2 micro service in support of SPTN L3 is all we need

<Olga> L2VPN service removed based on the comments from Shenzhen, but the new Use Case proposed by CMCC now has L2VPN as underlay inside the Access. Will not change the diagrams until the Use Case is agreed (Board/TSC).

 

O.221 OH: Stretch goal includes network monitoring using PCEP. Is technology for BGP peering contributed? Included in rel1 but not fully tested? Can be contributed?

<Olga> Currently started the process of discussing the use cases and functionality with China Telecom. All info will be added to the wiki as agreed before M1 for use cases & features/functionality and before M2 for APIs.

 

O.222 OH: is there a list of supported physical network devices e.g. Switches, Routers? How can the list be extended?

<Olga> Will be added during milestone M1 and then M2. The full list of controllers, devices that these controllers support and API versions. Also, the lab project should specify all the versions that we will demo and test with.

 

Slide #5:

“Basic network connectivity service inventory”

<Olga> We need to design how and if we will support basic service inventory and topology for Release 1 - it is currently the stretch goal. Will be fully specified inside the M1 and M2 phases. We can have each technology microservice having its own inventory or we can have SDN-O basic service inventory  micro service.

 

O.223 OH, ARC: specific network connectivity using specific technologies is proposed as the SDN-O “micro-services”. Is it scalable and comprehensive? Is the E2E Network connectivity another such “micro service” does it provide the physical network topology (connectivity, QoS, Security, HA, utilization level etc.) as well?

<Olga> The current design is based on the existing code, OPEN-O Use Case and Release 1 delivery. The initial focus is on the initial network connectivity service provision & activate integration and demo. The design will need to evolve to take into account service catalogue, model driven and full service lifecycle, including (network discovery, synch, monitoring, assurance, closed loop, etc). Please see roadmap items. The physical network topology will be simulated for Release 1 inside BRS service. Some items in the brackets are not physical network topology.

[UE]  “The physical network topology will be simulated for Release 1 inside BRS service” so no real physical network will be supported?

[OH] We are proposing to integrate only provisioning with the real network for Release 1, we propose to simulate and do not do the full discovery from the network, and deliver discovery for Release 2. But that may change if RedHat may want to join and use their discovery – still did not get reply.

 

O.224 OH: is IPsec a stand alone micro service provided for any L3 network connectivity?

 

<Olga> YES, it is currently a separate micro service.

 [UE] not clear to me how it is not related to the underlying technology. E. g. no IPSec on L2???

[OH] It may be only supported on top of L3VPN underlay, but it is still a separate microservice as it has separate lifecycle management from L3VPN. And there is reuse of L3VPN between multiple IPSec services.

 

Slide #9:

O.225 OH: Mark the diagram with the number of SDN  used (1 – under VIM, 2 – NFVO to VIM direct, 3- under SDN-O for physical network control, 4 – Super SDN Controller)

There are 4 types of SDN Controller and this projects addresses/interacts with 3 and 4 only

<Olga> I believe we agreed that if we need numbering it should be added in the overall Use Case and then referred to in SDN-O. Please do the numbering the OPEN-O Use Case, I will change the SDN-O proposal afterwards, based on that.

 

O.226 OH: SBI API – distinguish between private and public. Can it be ONF CI or MEF?

D.7: Agree that long term drivers are outside the project under the public API

AV: same API style should be used throughout the project

<Olga> Updated the slide

 

O.227 OH, ARC: Use TOSCA as the API style vs CMCC request for separation of roles and ability to see the scope of the infrastructure

On-boarding a service – no catalog. API and some micro services.

<Olga> SDN-O will provide REST API in Release 1. The API would be provided by the SDN-O team and defined in the GS-O Catalogue.

 

O.228 OH, ARC: define desired approach for Network Service on-boarding – interaction with GS-O, global inventory, separate in SDN-O? How automated is it vs desired automation goals?

Will have micro service catalog internal only??? Per above comment assume that GSO will be able to orchestrate any micro services!

<Olga> Proposal States in several places that catalogue for SDN-O is post Release 1. As agreed, GS-O will orchestrate e2e network connectivity service only in Release 1. Changed NBI description to -  NBI for orchestration of e2e network connectivity service only

[UE] so no real on boarding, I take it?

[OH] Not in Release 1, but I believe we must put t as the highest priority for post Release 1.

 

O.229 OH: Catalog plans for Rel1? Post rel 1?

<Olga> Proposal States in several places that catalogue for SDN-O is post Release 1.

 

O.230 OH: when network topology changes – how does it affect running micro services? Is the change applied to each of them individually? Some global considerations (related to question about global topology micro service)

<Olga> No discovery & monitoring & synch & closed loop support in Release 1 – just initial provisioning on the static network. Controllers will handle changes inside their clouds.

 

O.231 OH: any OAM scheme support?

<Olga> Not in Release 1

O.232 OH: Use of micro services bus. Micro service on the use case slide e.g. IPSec, MPLS l# VPN

 <Olga> There will be one microservice per service type, currently listed for the Use Case agreed in Beijing, may need to change for the new use case when agreed with Board/TSC

 

Slide #12:

O.233 OH, ARC: what is the long term approach to design and on-boarding environment? Does it make sense to use the Common TOSCA designer?

<Olga> To be analyzed later, to be discussed at Architecture Meetings and planned for post Release 1.

 

O.234 OH: no resource reservation is part of rel1? Any measures to monitor/control network load/congestion, traffic engineering?

<Olga> Post Release 1.

 

Slide #16:

O.235 OH: define “Meta Model driven dynamic programmable orchestration”

 <Olga> Capability to support orchestration of the new service type out of the box via configuration only, without need to do any code changes and new software releases

 

O.236 ARC: IM/DM an API alignment with external SDO and open source

 <Olga> To be discussed at the Architecture Meetings, need strategy and agreement not only for SDN-O, but OPEN-O

 

Thx

 

Uri (“Oo-Ree”)

C: 949-378-7568

 


Olga Havel
 

Hi Uri,

 

Thanks for further clarifications. I tried to address your clarifications and comments, I updated the wiki as well as the proposal with the additional info. Please see my comments with [OH] Comment

Talk to you later today.

 

Thanks,

Olga

 

 

From: Elzur, Uri [mailto:uri.elzur@...]
Sent: 25 June 2016 03:56
To: Olga Havel; 'openo-tsc@...'
Subject: RE: [openo-tsc] Project proposal technical feedback SDN-O, GS-O (part 3)

 

Hi Olga

 

Thanks for your care! Doing better and was able to travel and join the team in Berlin. We did miss you, hope you had a good vacation

 

One procedural comment:

Noting China Telecom potential contribution to SDN-O. it is clear to me that China Telecom folks can be “contributors” and their participation is welcome. Note that section 4.a.d in the participation agreement suggests a non-member can also be a “committers”. This may potentially in the future, for a case where a non member may  have a seat on the TSC,  in the steady state. We may want to discuss it. 

Separately, we also need to ask the LF to open the TSC mailing list to anyone who expresses interest. It will be cool to have reference on the website to organizations who are “contributors” even if not members!

[OH] Agree

 

Pls see below relies to some of your replies [UE]

 

Thx

 

Uri (“Oo-Ree”)

C: 949-378-7568

 

From: Olga Havel [mailto:olga.havel@...]
Sent: Thursday, June 23, 2016 8:38 AM
To: Elzur, Uri <uri.elzur@...>; 'openo-tsc@...' <openo-tsc@...>
Subject: RE: [openo-tsc] Project proposal technical feedback SDN-O, GS-O (part 3)

 

Thanks Uri for the notes and comments. I hope you are feeling better and that you back is healing well.

 

I updated the Proposal (attaches is version 0.9), please see my notes below (with [Olga]). I also added notes and the proposal to wiki.

 

Please note that I still kept the proposal as Draft 0.9, as I will need to do updates after the OPEN-O Use Case is finalized. that I will do when the Board/TSC agree the Use Case.

 

Hope the meeting in Berlin went well.

 

Best Regards,

Olga

 

 

From: openo-tsc-bounces@... [mailto:openo-tsc-bounces@...] On Behalf Of Elzur, Uri
Sent: 17 June 2016 15:21
To: 'openo-tsc@...'
Subject: [openo-tsc] Project proposal technical feedback SDN-O, GS-O (part 3)

 

4) GS-O – Brendan Hassett

General comments:

 

Another instance of the same code for the GUI portal for rel1. Long term, look at ways to integrate

Enables 3rd party orchestrator too, if such exists

(MEF as an option)

4 – use the ETSI interface

Can have in theory another orchestrator or 3rd party OSS on top, but not in scope for rel1

GUI – can we use one code (i.e. CMCC GUI for NFV-O) and disable some functionality vs separate code

Catalog is an open

No intelligence e.g. pick best placement target

 

Slide #5, #7:

Based on slide #6, assume that the Service Parser, Decomposer and Workflow Engine are ARIA based from Common TOSCA project.

O.100 BH, AB: comment “Parser decomposer and workflow not aligned” ??? Does ARIAN expose specific APIs for these functions?

O.101 BH: Does GS-O NBI use TOSCA YAML as an input? Interact with the Model Designer? Pls provide pointer to API

O.102 BH: does the Service Decomposer take NSD+VNFFG as an input? Will it split the VNFFG?

O.103 BH: who develops the Catalog project? No commit for rel1???

Slide #6:

O.104 BH: describe the proposed NB API and its potential of integration with any existing BSS. Any DM exposed north bound? How will the proposed API interact with SID?

O.105 BH: is Os-Ma-Nfvo not the proposed interface for 1? Vs. the interface 4 towards the NFVO? It assumes that ETSI model has NO information for the physical network!

O.106 BH, AB: relies on Common – TOSCA catalog? CSAR is only API requirement for integration? What protocol?

O.107 BH: what is the semantics of interface 3 to the SDN-O component – just E2E connectivity request? Need additional parameters…

Slide #8:

O.108 BH: define “Service”

 

6/9/16 Shenzen

6) SDN-O Olga Havel

Some general comments:

<Olga> Version 0.9 added with subset of comments addressed, others will be addressed during the next 2 milestones of the project, at architecture meetings or post Release 1

<Olga> Major Risk - OPEN-O Use Case not agreed yet, waiting for the Board and TSC to agree the OPEN-O Use Case, new SDN-O Proposal version will be needed afterwards. Therefore, network diagrams have not been changed yet, until the Use Case is agreed.

<Olga> Some comments here are really not open issues for the proposal, but items to be specified during the project, either Release 1 or post Release 1.

<Olga> Some comments here are more general OPEN-O items, outside of the SDN-O scope

 

·         Do not use “Network Services” to avoid confusion w ETSI NSD (but would like to)

<Olga> DONE. Change to network connectivity service everywhere – Slide 2 Project Description was the reason for the comment.

·         China Telecom code for Network SA – will that not be avail now? Slide #13 suggests committers from China Telecom

<Olga> My latest info is that China Telecom will be involved, we are in contact with them and discussing use cases. I have China Telecom as committers.

[UE] comment above.

Other plans for Service Assurance? Seems like Huawei MAY add post rel1 per slide #12?

<Olga> We are currently defining the use case with China Telecom for Release 1 (Stretch Goal for fully integrated and functional for November). Additional Functionality is proposed post-release 1, not Huawei but OPEN-O roadmap. Please see both Post Release 1 Roadmap (Slide 15) and Post release 1 Lifecycle extensions(Slide 12). I used the same diagram as GS-O initially, to make it consistent. The note only says that the diagram on Slide 12 will be enhanced going forward.

[UE] slide 13 now, I guess

[OH] Changed all slide numbers in the wiki

 

 

O.200 UE: Intel to explore adding a committer to the ODL driver project, working w ZTE

<Olga> Waiting for Intel to come back to me.

 [UE] WIP

[OH] Any progress?

 

 

O.201 LD: clarify comment on Overlay/underlay – CMCC wants Enterprise/. No one has key different requirements at this point

<Olga> I changed Slide 9 to “E2E Overlay Network Connectivity Service over Underlay Connectivity”. Currently Use Case being discussed - Enterprise and residential.

[UE] assume this means E2E within the SDN-O control! i.e. it is not planned to have the same overlay running between SDN-O and NFV-O. so pls clarify the term “E2E” somewhere in your deck

[OH] Updated to “E2E Overlay Network Connectivity Service within the SDN-O Control ...” everywhere

 

Slide #3

GS-O will not have ability to access to configure the micro services. Will only have one item it can drive: an e2e connectivity request.

 

<Olga> That is correct for Release 1. We can discuss if more is needed post Release 1.

 

O.202 OH, ARC: should SDN-O be a standalone entity exposing its own NB and SB APIs (GUI, Catalog, Data Model) or what is the right level of integration with rest of Open-O for rel1 and long term? Current proposal has no way for GSO to orchestrate any SDN-O internal micro services but the E2E connectivity service

<Olga> Release 1 Proposal states that GS-O orchestrates only the e2e network connectivity service. We are discussing if there is need for any retrieval for release 1, latest info from GS-O is that no get will be required for Release 1. We will need to expand it for post Release 1. Currently requirement is to abstract the network connectivity and provide abstracted API that does not mandate the GS-O to understand the network topology, layering and different technologies. The solution post release 1 may be general enough that any properties defined by business in the catalogue to be configurable and visible at GS-O layer should be supported, including selecting technologies and viewing the details of network if needed.

[UE] as we have one use case for rel1, the GS-O request will be for “e2e network connect”. So will SDN-O simply pick one of its 3 micro services? Based on what criteria?

[OH] Updated with saying hard-coded for Release 1, with catalogue driven for release 2.

 

O.203 OH, ARC: provide the NB Rest API. Referring to ETSI MANO spec fig 5.2 what is the difference between the WAN Infrastructure Manager and SDN-O? What is the pro/cons of using Or-Vi and Nf-Vi as a starting point for NB and SB API? If MEF Legato is proposed, provide a write up of its pro/cons and industry support. What is the flexibility to change it?

<Olga> Removed the MEF Presto Reference, we can discuss at the Architecture Committee. Changed it to more generic statement on Slide 10, although we believe MEF is requirement for SDN-O, and we should substantiate it further at the architecture meetings for Release 2 strategy.

MEF / TMF / ETSI may be useful as reference for abstract NBI (post Release 1)

MEF / ONF / TMF/ ETSI may be useful as reference for abstract SBI (post Release 1).

 

O.204 ARC: assume a connectivity type can be requested from GS-O? Or else what is the meaning of asking for an E2E connectivity from GS-O?

<Olga> Connectivity type may be asked from GS-O or may be automatically assigned, depending on the business policy. Release 1 plan is to initially support the use case where SDN-O automatically selects the underlaying technologies. Going forward (Post release 1) it will may also be in the catalogue as part of the network connectivity service template.

[UE] pls see comment above related to O202

[OH] Updated with saying automatically selects the underlaying technologies, hardcoded in the overlay e2e service.

 

O.205 ARC: is Open-O to be architected presented as Hierarchy of orchestrators or provide also a top seeing all physical and logical infrastructure and exposing based on RBAC

<Olga> I think we agreed that it is up to the business to decide what is exposed to the top level and what is abstracted by the SDN-O, based on its business policies, requirements and organization. Release 1 Use Case is the simple one without need to expose all infrastructure, currently discussing with GS-O if anything needs to be exposed. Latest info from GS-O is that get will not be required in Release 1.

[UE] I think this is an OPEN for the Arch team

[OH] Yes

 

O.206 ARC: assume that some VNFs will be on boarded based on their YANG model, so TOSCA Common and the associated Designer have to support YANG and conversion to TOSCA (of relevant parts). Should the Designer for the physical network and SDN-O be integrated too – i.e. related also to TOSCA/YANG interaction/ integration

 

<Olga> We may discuss more at the Architecture Meetings and TSC. Our current agreed architecture is defined to abstract physical network and specific vendors and their models by providing a common SBI and capability to add drivers to map from vendor APIs to common API.

[UE] pls note, I don’t think we have discussed / agreed on this before

[OH] My understanding is that the architecture figure specifies having common SBI and different drivers external from SDN-O. Does that mandate some generic orchestration based on common APIs and models and drivers handling specifics of the specific vendor YANG models?

 

O.207 OH: document operator’s requirements for Roles and responsibilities (e.g. separate operator for NFV and SDN. Top level operator should not have double click access to the physical network). Addressing different personalities, diff scenarios

<Olga> Is this SDN-O Open Issue? We discussed the roles and responsibilities during the overall User Case? Should this be OPEN-O or even GS-O and not SDN-O issue., where we have those roles documented as discussed in Beijing.

[UE] agree!

 

O.208 OH: as code for GUI is not yet avail (per slide #11) – why not use GS-O?

<Olga> SDN-O will reuse the Portal code from NFV-O, same as GS-O.  Slide does not say that the code is not shared, just that it is a different project and different module. The GS-O will have different GUi and have different requirements. Longer term, the best approach would be to have common Portal Framework that could be reused between modules. Currently, out of 44 use cases we have for SDN-O, only 2 are exposed to GS-O.

 

O.209 OH: provide a description of proposed interaction with GS-O and Common TOSCA (slide #9 suggests NO interaction, while Slide #10, #11 shows some)

<Olga> Slide 9 used the existing Architecture slide and specifies what is in the scope of SDN-O in the Release 1 and what external modules the SDN-O will depend on or will use. It does not specify who would be using SDN-O over API. Slide 10 specifies that GS-O will communicate with SDN-O via REST interface. How this SDN-O REST interface is called from GS-O (via TOSCA template or some other way) should probably be described in GS-O, as SDN-O provides REST interface and the rest is external to SDN-O.

[UE] looking for a short paragraph that describes the functional interaction. Will attempt to do it but will be best if you can help. Not sure we know what you think s the interaction supported w GS-O

[OH] I added more info on Slide 6.

 

O.210 OH: provide the “common SBI” API.

<Olga> I added the Common SBI slide 5. Please review.

[UE] will provide technical feedback on the proposed SBI  API ASAP

Is anyone else looking into it?

[OH] We will distribute the new version by 30th. Nobody is reviewing it yet, we will do it during milestones M1 and M2.

 

O.211 OH: how will the “common SBI” be defined? Is he API for Rel1 proprietary with a future option to move to MEF Presto? How wide is its industry support? What devices support is today? Standardization goals? How to drive broad industry adoption?

<Olga> I added the Common SBI slide 5. Please review.

[UE] process understood. My concern is more on the SBI technical aspects

[OH] We will review it and update based on the review comments for Milestone 2. If we cannot deliver, will identify the gaps and requirements for post Release 1.

 

Slide #4:

O.212 OH: What technologies/protocols will be used by ODL to drive its respective devices? Just VLAN/VxLAN?

<Olga> This will be based on the OPEN-O Use Case. Currently VLAN/VxLAN, as mentioned on the slide, but the new Use Case is being discussed (Board/TSC). May be more if agreed.

 

O.213 OH: What technologies/protocols will be used by ONOS to drive its respective devices? Is the L3VPN configured into physical devices using OpenFlow? Other? What IPsec options?

ODL driver from ZTE

<Olga> This will be based on the OPEN-O Use Case. Currently L3VPN/IPSec, as mentioned on the slide, but the new Use Case is being discussed (Board/TSC). May be more if agreed. The controller itself and how it communicates with devices is outside of the SDN-O project, will be defined in the Lab/Test project

 

O.214 ZTE: what NBI of ODL will the ZTE driver support? E.g. NetVirt to OvS on the server?

 <Olga> More details about what exact Controller APIs will be supported will be specified before milestone M1 Feature/Functionality Freeze or M2 API freeze.

 

Agreement that SDN Controller under VIM or directly from the NFV-O is out of context. However it is assumed that for rel1, the SDN-O will manipulate Neutron to connect the Physical network to the tenant specific logical network inside the VIM.

<Olga> Correct

 

 

O.215 OH: Describe VIM Neutron driver functionality? What is the solution approach? Supports connectivity only or isolation, QoS and security too? What neutron API and OpenStack versions are supported? (criteria to select the OpenStack distro – RHT mentioned on slide #14)

Neutron API is referred to and used herewith for SDN-O connectivity only.

<Olga> We will specify all this before M1 Feature/Functionality Freeze or M2 API freeze.

 

O.216 OH: does it present a multi writer issue?

<Olga> Currently, the team is aware of the potential issue raised by Uri and will analyze the problem and propose the solution.

 

O.217 OH: describe the low level semantics of the proposed connectivity model. It seems to add a router in the path. Implications?

<Olga> Is this something we want in the proposal or are we going to work on it in the first milestones of the project. In regards to adding a router on a path – depends where the router is (PE, P1, in access, etc). In some cases, SDN-O may not even be aware of it (inside the controller domain) and in some cases SDN-O will need to support it, but the use case for this is outside of the scope of Release 1.

[UE] this is about how we connect E2E when we have some part in SDN-O and another inside NFV-O. we  do need to discuss it

[OH] Can we do it during the Mileastone 1 (features and functionality) or Milestone 2 (API)??

 

O.218 ARC: What is the preferred long term approach for SDN to VIM network connection – direct? By SDN-O? Through GS-O? Who owns the global VNFFG?

<Olga> Topic for all the partners, including TSC and architecture committee.

 

DENG Huis comment – would like to see super controller as part rel 1

Super SDNC: CMCC has a developer assigned to the ODL SPTN project

 

<Olga> Will update the slides when the new Use Case proposed by CMCC is agreed and the final agreed slide distributed to all.

 

O.219 OH: provide description of SPTN. Is this a CMCC code contribution? How does it add value to agreed Rel1 Use case?

<Olga> SPTN is requested by CMCC. I will add it to the diagram later, when I receive the latest agreed use case diagram. Currently, will leave the Use Case diagram unchanged. Please ask the Board/TSC about the value of SPTN, China Mobile is requesting it based on their business needs.

 

O.220 DH: clarify - no need for L2 micro service in support of SPTN L3 is all we need

<Olga> L2VPN service removed based on the comments from Shenzhen, but the new Use Case proposed by CMCC now has L2VPN as underlay inside the Access. Will not change the diagrams until the Use Case is agreed (Board/TSC).

 

O.221 OH: Stretch goal includes network monitoring using PCEP. Is technology for BGP peering contributed? Included in rel1 but not fully tested? Can be contributed?

<Olga> Currently started the process of discussing the use cases and functionality with China Telecom. All info will be added to the wiki as agreed before M1 for use cases & features/functionality and before M2 for APIs.

 

O.222 OH: is there a list of supported physical network devices e.g. Switches, Routers? How can the list be extended?

<Olga> Will be added during milestone M1 and then M2. The full list of controllers, devices that these controllers support and API versions. Also, the lab project should specify all the versions that we will demo and test with.

 

Slide #5:

“Basic network connectivity service inventory”

<Olga> We need to design how and if we will support basic service inventory and topology for Release 1 - it is currently the stretch goal. Will be fully specified inside the M1 and M2 phases. We can have each technology microservice having its own inventory or we can have SDN-O basic service inventory  micro service.

 

O.223 OH, ARC: specific network connectivity using specific technologies is proposed as the SDN-O “micro-services”. Is it scalable and comprehensive? Is the E2E Network connectivity another such “micro service” does it provide the physical network topology (connectivity, QoS, Security, HA, utilization level etc.) as well?

<Olga> The current design is based on the existing code, OPEN-O Use Case and Release 1 delivery. The initial focus is on the initial network connectivity service provision & activate integration and demo. The design will need to evolve to take into account service catalogue, model driven and full service lifecycle, including (network discovery, synch, monitoring, assurance, closed loop, etc). Please see roadmap items. The physical network topology will be simulated for Release 1 inside BRS service. Some items in the brackets are not physical network topology.

[UE]  “The physical network topology will be simulated for Release 1 inside BRS service” so no real physical network will be supported?

[OH] We are proposing to integrate only provisioning with the real network for Release 1, we propose to simulate and do not do the full discovery from the network, and deliver discovery for Release 2. But that may change if RedHat may want to join and use their discovery – still did not get reply.

 

O.224 OH: is IPsec a stand alone micro service provided for any L3 network connectivity?

 

<Olga> YES, it is currently a separate micro service.

 [UE] not clear to me how it is not related to the underlying technology. E. g. no IPSec on L2???

[OH] It may be only supported on top of L3VPN underlay, but it is still a separate microservice as it has separate lifecycle management from L3VPN. And there is reuse of L3VPN between multiple IPSec services.

 

Slide #9:

O.225 OH: Mark the diagram with the number of SDN  used (1 – under VIM, 2 – NFVO to VIM direct, 3- under SDN-O for physical network control, 4 – Super SDN Controller)

There are 4 types of SDN Controller and this projects addresses/interacts with 3 and 4 only

<Olga> I believe we agreed that if we need numbering it should be added in the overall Use Case and then referred to in SDN-O. Please do the numbering the OPEN-O Use Case, I will change the SDN-O proposal afterwards, based on that.

 

O.226 OH: SBI API – distinguish between private and public. Can it be ONF CI or MEF?

D.7: Agree that long term drivers are outside the project under the public API

AV: same API style should be used throughout the project

<Olga> Updated the slide

 

O.227 OH, ARC: Use TOSCA as the API style vs CMCC request for separation of roles and ability to see the scope of the infrastructure

On-boarding a service – no catalog. API and some micro services.

<Olga> SDN-O will provide REST API in Release 1. The API would be provided by the SDN-O team and defined in the GS-O Catalogue.

 

O.228 OH, ARC: define desired approach for Network Service on-boarding – interaction with GS-O, global inventory, separate in SDN-O? How automated is it vs desired automation goals?

Will have micro service catalog internal only??? Per above comment assume that GSO will be able to orchestrate any micro services!

<Olga> Proposal States in several places that catalogue for SDN-O is post Release 1. As agreed, GS-O will orchestrate e2e network connectivity service only in Release 1. Changed NBI description to -  NBI for orchestration of e2e network connectivity service only

[UE] so no real on boarding, I take it?

[OH] Not in Release 1, but I believe we must put t as the highest priority for post Release 1.

 

O.229 OH: Catalog plans for Rel1? Post rel 1?

<Olga> Proposal States in several places that catalogue for SDN-O is post Release 1.

 

O.230 OH: when network topology changes – how does it affect running micro services? Is the change applied to each of them individually? Some global considerations (related to question about global topology micro service)

<Olga> No discovery & monitoring & synch & closed loop support in Release 1 – just initial provisioning on the static network. Controllers will handle changes inside their clouds.

 

O.231 OH: any OAM scheme support?

<Olga> Not in Release 1

O.232 OH: Use of micro services bus. Micro service on the use case slide e.g. IPSec, MPLS l# VPN

 <Olga> There will be one microservice per service type, currently listed for the Use Case agreed in Beijing, may need to change for the new use case when agreed with Board/TSC

 

Slide #12:

O.233 OH, ARC: what is the long term approach to design and on-boarding environment? Does it make sense to use the Common TOSCA designer?

<Olga> To be analyzed later, to be discussed at Architecture Meetings and planned for post Release 1.

 

O.234 OH: no resource reservation is part of rel1? Any measures to monitor/control network load/congestion, traffic engineering?

<Olga> Post Release 1.

 

Slide #16:

O.235 OH: define “Meta Model driven dynamic programmable orchestration”

 <Olga> Capability to support orchestration of the new service type out of the box via configuration only, without need to do any code changes and new software releases

 

O.236 ARC: IM/DM an API alignment with external SDO and open source

 <Olga> To be discussed at the Architecture Meetings, need strategy and agreement not only for SDN-O, but OPEN-O

 

Thx

 

Uri (“Oo-Ree”)

C: 949-378-7568

 


Elzur, Uri <uri.elzur@...>
 

Hi Olga

 

Thanks for your care! Doing better and was able to travel and join the team in Berlin. We did miss you, hope you had a good vacation

 

One procedural comment:

Noting China Telecom potential contribution to SDN-O. it is clear to me that China Telecom folks can be “contributors” and their participation is welcome. Note that section 4.a.d in the participation agreement suggests a non-member can also be a “committers”. This may potentially in the future, for a case where a non member may  have a seat on the TSC,  in the steady state. We may want to discuss it. 

Separately, we also need to ask the LF to open the TSC mailing list to anyone who expresses interest. It will be cool to have reference on the website to organizations who are “contributors” even if not members!

 

Pls see below relies to some of your replies [UE]

 

Thx

 

Uri (“Oo-Ree”)

C: 949-378-7568

 

From: Olga Havel [mailto:olga.havel@...]
Sent: Thursday, June 23, 2016 8:38 AM
To: Elzur, Uri <uri.elzur@...>; 'openo-tsc@...' <openo-tsc@...>
Subject: RE: [openo-tsc] Project proposal technical feedback SDN-O, GS-O (part 3)

 

Thanks Uri for the notes and comments. I hope you are feeling better and that you back is healing well.

 

I updated the Proposal (attaches is version 0.9), please see my notes below (with [Olga]). I also added notes and the proposal to wiki.

 

Please note that I still kept the proposal as Draft 0.9, as I will need to do updates after the OPEN-O Use Case is finalized. that I will do when the Board/TSC agree the Use Case.

 

Hope the meeting in Berlin went well.

 

Best Regards,

Olga

 

 

From: openo-tsc-bounces@... [mailto:openo-tsc-bounces@...] On Behalf Of Elzur, Uri
Sent: 17 June 2016 15:21
To: 'openo-tsc@...'
Subject: [openo-tsc] Project proposal technical feedback SDN-O, GS-O (part 3)

 

4) GS-O – Brendan Hassett

General comments:

 

Another instance of the same code for the GUI portal for rel1. Long term, look at ways to integrate

Enables 3rd party orchestrator too, if such exists

(MEF as an option)

4 – use the ETSI interface

Can have in theory another orchestrator or 3rd party OSS on top, but not in scope for rel1

GUI – can we use one code (i.e. CMCC GUI for NFV-O) and disable some functionality vs separate code

Catalog is an open

No intelligence e.g. pick best placement target

 

Slide #5, #7:

Based on slide #6, assume that the Service Parser, Decomposer and Workflow Engine are ARIA based from Common TOSCA project.

O.100 BH, AB: comment “Parser decomposer and workflow not aligned” ??? Does ARIAN expose specific APIs for these functions?

O.101 BH: Does GS-O NBI use TOSCA YAML as an input? Interact with the Model Designer? Pls provide pointer to API

O.102 BH: does the Service Decomposer take NSD+VNFFG as an input? Will it split the VNFFG?

O.103 BH: who develops the Catalog project? No commit for rel1???

Slide #6:

O.104 BH: describe the proposed NB API and its potential of integration with any existing BSS. Any DM exposed north bound? How will the proposed API interact with SID?

O.105 BH: is Os-Ma-Nfvo not the proposed interface for 1? Vs. the interface 4 towards the NFVO? It assumes that ETSI model has NO information for the physical network!

O.106 BH, AB: relies on Common – TOSCA catalog? CSAR is only API requirement for integration? What protocol?

O.107 BH: what is the semantics of interface 3 to the SDN-O component – just E2E connectivity request? Need additional parameters…

Slide #8:

O.108 BH: define “Service”

 

6/9/16 Shenzen

6) SDN-O Olga Havel

Some general comments:

<Olga> Version 0.9 added with subset of comments addressed, others will be addressed during the next 2 milestones of the project, at architecture meetings or post Release 1

<Olga> Major Risk - OPEN-O Use Case not agreed yet, waiting for the Board and TSC to agree the OPEN-O Use Case, new SDN-O Proposal version will be needed afterwards. Therefore, network diagrams have not been changed yet, until the Use Case is agreed.

<Olga> Some comments here are really not open issues for the proposal, but items to be specified during the project, either Release 1 or post Release 1.

<Olga> Some comments here are more general OPEN-O items, outside of the SDN-O scope

 

·         Do not use “Network Services” to avoid confusion w ETSI NSD (but would like to)

<Olga> DONE. Change to network connectivity service everywhere – Slide 2 Project Description was the reason for the comment.

·         China Telecom code for Network SA – will that not be avail now? Slide #13 suggests committers from China Telecom

<Olga> My latest info is that China Telecom will be involved, we are in contact with them and discussing use cases. I have China Telecom as committers.

[UE] comment above.

Other plans for Service Assurance? Seems like Huawei MAY add post rel1 per slide #12?

<Olga> We are currently defining the use case with China Telecom for Release 1 (Stretch Goal for fully integrated and functional for November). Additional Functionality is proposed post-release 1, not Huawei but OPEN-O roadmap. Please see both Post Release 1 Roadmap (Slide 15) and Post release 1 Lifecycle extensions(Slide 12). I used the same diagram as GS-O initially, to make it consistent. The note only says that the diagram on Slide 12 will be enhanced going forward.

[UE] slide 13 now, I guess

 

O.200 UE: Intel to explore adding a committer to the ODL driver project, working w ZTE

<Olga> Waiting for Intel to come back to me.

 [UE] WIP

 

O.201 LD: clarify comment on Overlay/underlay – CMCC wants Enterprise/. No one has key different requirements at this point

<Olga> I changed Slide 9 to “E2E Overlay Network Connectivity Service over Underlay Connectivity”. Currently Use Case being discussed - Enterprise and residential.

[UE] assume this means E2E within the SDN-O control! i.e. it is not planned to have the same overlay running between SDN-O and NFV-O. so pls clarify the term “E2E” somewhere in your deck

 

Slide #3

GS-O will not have ability to access to configure the micro services. Will only have one item it can drive: an e2e connectivity request.

 

<Olga> That is correct for Release 1. We can discuss if more is needed post Release 1.

 

O.202 OH, ARC: should SDN-O be a standalone entity exposing its own NB and SB APIs (GUI, Catalog, Data Model) or what is the right level of integration with rest of Open-O for rel1 and long term? Current proposal has no way for GSO to orchestrate any SDN-O internal micro services but the E2E connectivity service

<Olga> Release 1 Proposal states that GS-O orchestrates only the e2e network connectivity service. We are discussing if there is need for any retrieval for release 1, latest info from GS-O is that no get will be required for Release 1. We will need to expand it for post Release 1. Currently requirement is to abstract the network connectivity and provide abstracted API that does not mandate the GS-O to understand the network topology, layering and different technologies. The solution post release 1 may be general enough that any properties defined by business in the catalogue to be configurable and visible at GS-O layer should be supported, including selecting technologies and viewing the details of network if needed.

[UE] as we have one use case for rel1, the GS-O request will be for “e2e network connect”. So will SDN-O simply pick one of its 3 micro services? Based on what criteria?

O.203 OH, ARC: provide the NB Rest API. Referring to ETSI MANO spec fig 5.2 what is the difference between the WAN Infrastructure Manager and SDN-O? What is the pro/cons of using Or-Vi and Nf-Vi as a starting point for NB and SB API? If MEF Legato is proposed, provide a write up of its pro/cons and industry support. What is the flexibility to change it?

<Olga> Removed the MEF Presto Reference, we can discuss at the Architecture Committee. Changed it to more generic statement on Slide 10, although we believe MEF is requirement for SDN-O, and we should substantiate it further at the architecture meetings for Release 2 strategy.

MEF / TMF / ETSI may be useful as reference for abstract NBI (post Release 1)

MEF / ONF / TMF/ ETSI may be useful as reference for abstract SBI (post Release 1).

 

O.204 ARC: assume a connectivity type can be requested from GS-O? Or else what is the meaning of asking for an E2E connectivity from GS-O?

<Olga> Connectivity type may be asked from GS-O or may be automatically assigned, depending on the business policy. Release 1 plan is to initially support the use case where SDN-O automatically selects the underlaying technologies. Going forward (Post release 1) it will may also be in the catalogue as part of the network connectivity service template.

[UE] pls see comment above related to O202

 

O.205 ARC: is Open-O to be architected presented as Hierarchy of orchestrators or provide also a top seeing all physical and logical infrastructure and exposing based on RBAC

<Olga> I think we agreed that it is up to the business to decide what is exposed to the top level and what is abstracted by the SDN-O, based on its business policies, requirements and organization. Release 1 Use Case is the simple one without need to expose all infrastructure, currently discussing with GS-O if anything needs to be exposed. Latest info from GS-O is that get will not be required in Release 1.

[UE] I think this is an OPEN for the Arch team

 

O.206 ARC: assume that some VNFs will be on boarded based on their YANG model, so TOSCA Common and the associated Designer have to support YANG and conversion to TOSCA (of relevant parts). Should the Designer for the physical network and SDN-O be integrated too – i.e. related also to TOSCA/YANG interaction/ integration

 

<Olga> We may discuss more at the Architecture Meetings and TSC. Our current agreed architecture is defined to abstract physical network and specific vendors and their models by providing a common SBI and capability to add drivers to map from vendor APIs to common API.

[UE] pls note, I don’t think we have discussed / agreed on this before

 

O.207 OH: document operator’s requirements for Roles and responsibilities (e.g. separate operator for NFV and SDN. Top level operator should not have double click access to the physical network). Addressing different personalities, diff scenarios

<Olga> Is this SDN-O Open Issue? We discussed the roles and responsibilities during the overall User Case? Should this be OPEN-O or even GS-O and not SDN-O issue., where we have those roles documented as discussed in Beijing.

[UE] agree!

 

O.208 OH: as code for GUI is not yet avail (per slide #11) – why not use GS-O?

<Olga> SDN-O will reuse the Portal code from NFV-O, same as GS-O.  Slide does not say that the code is not shared, just that it is a different project and different module. The GS-O will have different GUi and have different requirements. Longer term, the best approach would be to have common Portal Framework that could be reused between modules. Currently, out of 44 use cases we have for SDN-O, only 2 are exposed to GS-O.

 

O.209 OH: provide a description of proposed interaction with GS-O and Common TOSCA (slide #9 suggests NO interaction, while Slide #10, #11 shows some)

<Olga> Slide 9 used the existing Architecture slide and specifies what is in the scope of SDN-O in the Release 1 and what external modules the SDN-O will depend on or will use. It does not specify who would be using SDN-O over API. Slide 10 specifies that GS-O will communicate with SDN-O via REST interface. How this SDN-O REST interface is called from GS-O (via TOSCA template or some other way) should probably be described in GS-O, as SDN-O provides REST interface and the rest is external to SDN-O.

[UE] looking for a short paragraph that describes the functional interaction. Will attempt to do it but will be best if you can help. Not sure we know what you think s the interaction supported w GS-O

 

O.210 OH: provide the “common SBI” API.

<Olga> I added the Common SBI slide 5. Please review.

[UE] will provide technical feedback on the proposed SBI  API ASAP

Is anyone else looking into it?

 

O.211 OH: how will the “common SBI” be defined? Is he API for Rel1 proprietary with a future option to move to MEF Presto? How wide is its industry support? What devices support is today? Standardization goals? How to drive broad industry adoption?

<Olga> I added the Common SBI slide 5. Please review.

[UE] process understood. My concern is more on the SBI technical aspects

 

Slide #4:

O.212 OH: What technologies/protocols will be used by ODL to drive its respective devices? Just VLAN/VxLAN?

<Olga> This will be based on the OPEN-O Use Case. Currently VLAN/VxLAN, as mentioned on the slide, but the new Use Case is being discussed (Board/TSC). May be more if agreed.

 

O.213 OH: What technologies/protocols will be used by ONOS to drive its respective devices? Is the L3VPN configured into physical devices using OpenFlow? Other? What IPsec options?

ODL driver from ZTE

<Olga> This will be based on the OPEN-O Use Case. Currently L3VPN/IPSec, as mentioned on the slide, but the new Use Case is being discussed (Board/TSC). May be more if agreed. The controller itself and how it communicates with devices is outside of the SDN-O project, will be defined in the Lab/Test project

 

O.214 ZTE: what NBI of ODL will the ZTE driver support? E.g. NetVirt to OvS on the server?

 <Olga> More details about what exact Controller APIs will be supported will be specified before milestone M1 Feature/Functionality Freeze or M2 API freeze.

 

Agreement that SDN Controller under VIM or directly from the NFV-O is out of context. However it is assumed that for rel1, the SDN-O will manipulate Neutron to connect the Physical network to the tenant specific logical network inside the VIM.

<Olga> Correct

 

 

O.215 OH: Describe VIM Neutron driver functionality? What is the solution approach? Supports connectivity only or isolation, QoS and security too? What neutron API and OpenStack versions are supported? (criteria to select the OpenStack distro – RHT mentioned on slide #14)

Neutron API is referred to and used herewith for SDN-O connectivity only.

<Olga> We will specify all this before M1 Feature/Functionality Freeze or M2 API freeze.

 

O.216 OH: does it present a multi writer issue?

<Olga> Currently, the team is aware of the potential issue raised by Uri and will analyze the problem and propose the solution.

 

O.217 OH: describe the low level semantics of the proposed connectivity model. It seems to add a router in the path. Implications?

<Olga> Is this something we want in the proposal or are we going to work on it in the first milestones of the project. In regards to adding a router on a path – depends where the router is (PE, P1, in access, etc). In some cases, SDN-O may not even be aware of it (inside the controller domain) and in some cases SDN-O will need to support it, but the use case for this is outside of the scope of Release 1.

[UE] this is about how we connect E2E when we have some part in SDN-O and another inside NFV-O. we  do need to discuss it

 

O.218 ARC: What is the preferred long term approach for SDN to VIM network connection – direct? By SDN-O? Through GS-O? Who owns the global VNFFG?

<Olga> Topic for all the partners, including TSC and architecture committee.

 

DENG Huis comment – would like to see super controller as part rel 1

Super SDNC: CMCC has a developer assigned to the ODL SPTN project

 

<Olga> Will update the slides when the new Use Case proposed by CMCC is agreed and the final agreed slide distributed to all.

 

O.219 OH: provide description of SPTN. Is this a CMCC code contribution? How does it add value to agreed Rel1 Use case?

<Olga> SPTN is requested by CMCC. I will add it to the diagram later, when I receive the latest agreed use case diagram. Currently, will leave the Use Case diagram unchanged. Please ask the Board/TSC about the value of SPTN, China Mobile is requesting it based on their business needs.

 

O.220 DH: clarify - no need for L2 micro service in support of SPTN L3 is all we need

<Olga> L2VPN service removed based on the comments from Shenzhen, but the new Use Case proposed by CMCC now has L2VPN as underlay inside the Access. Will not change the diagrams until the Use Case is agreed (Board/TSC).

 

O.221 OH: Stretch goal includes network monitoring using PCEP. Is technology for BGP peering contributed? Included in rel1 but not fully tested? Can be contributed?

<Olga> Currently started the process of discussing the use cases and functionality with China Telecom. All info will be added to the wiki as agreed before M1 for use cases & features/functionality and before M2 for APIs.

 

O.222 OH: is there a list of supported physical network devices e.g. Switches, Routers? How can the list be extended?

<Olga> Will be added during milestone M1 and then M2. The full list of controllers, devices that these controllers support and API versions. Also, the lab project should specify all the versions that we will demo and test with.

 

Slide #5:

“Basic network connectivity service inventory”

<Olga> We need to design how and if we will support basic service inventory and topology for Release 1 - it is currently the stretch goal. Will be fully specified inside the M1 and M2 phases. We can have each technology microservice having its own inventory or we can have SDN-O basic service inventory  micro service.

 

O.223 OH, ARC: specific network connectivity using specific technologies is proposed as the SDN-O “micro-services”. Is it scalable and comprehensive? Is the E2E Network connectivity another such “micro service” does it provide the physical network topology (connectivity, QoS, Security, HA, utilization level etc.) as well?

<Olga> The current design is based on the existing code, OPEN-O Use Case and Release 1 delivery. The initial focus is on the initial network connectivity service provision & activate integration and demo. The design will need to evolve to take into account service catalogue, model driven and full service lifecycle, including (network discovery, synch, monitoring, assurance, closed loop, etc). Please see roadmap items. The physical network topology will be simulated for Release 1 inside BRS service. Some items in the brackets are not physical network topology.

[UE]  “The physical network topology will be simulated for Release 1 inside BRS service” so no real physical network will be supported?

 

O.224 OH: is IPsec a stand alone micro service provided for any L3 network connectivity?

 

<Olga> YES, it is currently a separate micro service.

 [UE] not clear to me how it is not related to the underlying technology. E. g. no IPSec on L2???

 

Slide #9:

O.225 OH: Mark the diagram with the number of SDN  used (1 – under VIM, 2 – NFVO to VIM direct, 3- under SDN-O for physical network control, 4 – Super SDN Controller)

There are 4 types of SDN Controller and this projects addresses/interacts with 3 and 4 only

<Olga> I believe we agreed that if we need numbering it should be added in the overall Use Case and then referred to in SDN-O. Please do the numbering the OPEN-O Use Case, I will change the SDN-O proposal afterwards, based on that.

 

O.226 OH: SBI API – distinguish between private and public. Can it be ONF CI or MEF?

D.7: Agree that long term drivers are outside the project under the public API

AV: same API style should be used throughout the project

<Olga> Updated the slide

 

O.227 OH, ARC: Use TOSCA as the API style vs CMCC request for separation of roles and ability to see the scope of the infrastructure

On-boarding a service – no catalog. API and some micro services.

<Olga> SDN-O will provide REST API in Release 1. The API would be provided by the SDN-O team and defined in the GS-O Catalogue.

 

O.228 OH, ARC: define desired approach for Network Service on-boarding – interaction with GS-O, global inventory, separate in SDN-O? How automated is it vs desired automation goals?

Will have micro service catalog internal only??? Per above comment assume that GSO will be able to orchestrate any micro services!

<Olga> Proposal States in several places that catalogue for SDN-O is post Release 1. As agreed, GS-O will orchestrate e2e network connectivity service only in Release 1. Changed NBI description to -  NBI for orchestration of e2e network connectivity service only

[UE] so no real on boarding, I take it?

 

O.229 OH: Catalog plans for Rel1? Post rel 1?

<Olga> Proposal States in several places that catalogue for SDN-O is post Release 1.

 

O.230 OH: when network topology changes – how does it affect running micro services? Is the change applied to each of them individually? Some global considerations (related to question about global topology micro service)

<Olga> No discovery & monitoring & synch & closed loop support in Release 1 – just initial provisioning on the static network. Controllers will handle changes inside their clouds.

 

O.231 OH: any OAM scheme support?

<Olga> Not in Release 1

O.232 OH: Use of micro services bus. Micro service on the use case slide e.g. IPSec, MPLS l# VPN

 <Olga> There will be one microservice per service type, currently listed for the Use Case agreed in Beijing, may need to change for the new use case when agreed with Board/TSC

 

Slide #12:

O.233 OH, ARC: what is the long term approach to design and on-boarding environment? Does it make sense to use the Common TOSCA designer?

<Olga> To be analyzed later, to be discussed at Architecture Meetings and planned for post Release 1.

 

O.234 OH: no resource reservation is part of rel1? Any measures to monitor/control network load/congestion, traffic engineering?

<Olga> Post Release 1.

 

Slide #16:

O.235 OH: define “Meta Model driven dynamic programmable orchestration”

 <Olga> Capability to support orchestration of the new service type out of the box via configuration only, without need to do any code changes and new software releases

 

O.236 ARC: IM/DM an API alignment with external SDO and open source

 <Olga> To be discussed at the Architecture Meetings, need strategy and agreement not only for SDN-O, but OPEN-O

 

Thx

 

Uri (“Oo-Ree”)

C: 949-378-7568

 


Olga Havel
 

Thanks Uri for the notes and comments. I hope you are feeling better and that you back is healing well.

 

I updated the Proposal (attaches is version 0.9), please see my notes below (with [Olga]). I also added notes and the proposal to wiki.

 

Please note that I still kept the proposal as Draft 0.9, as I will need to do updates after the OPEN-O Use Case is finalized. that I will do when the Board/TSC agree the Use Case.

 

Hope the meeting in Berlin went well.

 

Best Regards,

Olga

 

 

From: openo-tsc-bounces@... [mailto:openo-tsc-bounces@...] On Behalf Of Elzur, Uri
Sent: 17 June 2016 15:21
To: 'openo-tsc@...'
Subject: [openo-tsc] Project proposal technical feedback SDN-O, GS-O (part 3)

 

4) GS-O – Brendan Hassett

General comments:

 

Another instance of the same code for the GUI portal for rel1. Long term, look at ways to integrate

Enables 3rd party orchestrator too, if such exists

(MEF as an option)

4 – use the ETSI interface

Can have in theory another orchestrator or 3rd party OSS on top, but not in scope for rel1

GUI – can we use one code (i.e. CMCC GUI for NFV-O) and disable some functionality vs separate code

Catalog is an open

No intelligence e.g. pick best placement target

 

Slide #5, #7:

Based on slide #6, assume that the Service Parser, Decomposer and Workflow Engine are ARIA based from Common TOSCA project.

O.100 BH, AB: comment “Parser decomposer and workflow not aligned” ??? Does ARIAN expose specific APIs for these functions?

O.101 BH: Does GS-O NBI use TOSCA YAML as an input? Interact with the Model Designer? Pls provide pointer to API

O.102 BH: does the Service Decomposer take NSD+VNFFG as an input? Will it split the VNFFG?

O.103 BH: who develops the Catalog project? No commit for rel1???

Slide #6:

O.104 BH: describe the proposed NB API and its potential of integration with any existing BSS. Any DM exposed north bound? How will the proposed API interact with SID?

O.105 BH: is Os-Ma-Nfvo not the proposed interface for 1? Vs. the interface 4 towards the NFVO? It assumes that ETSI model has NO information for the physical network!

O.106 BH, AB: relies on Common – TOSCA catalog? CSAR is only API requirement for integration? What protocol?

O.107 BH: what is the semantics of interface 3 to the SDN-O component – just E2E connectivity request? Need additional parameters…

Slide #8:

O.108 BH: define “Service”

 

6/9/16 Shenzen

6) SDN-O Olga Havel

Some general comments:

<Olga> Version 0.9 added with subset of comments addressed, others will be addressed during the next 2 milestones of the project, at architecture meetings or post Release 1

<Olga> Major Risk - OPEN-O Use Case not agreed yet, waiting for the Board and TSC to agree the OPEN-O Use Case, new SDN-O Proposal version will be needed afterwards. Therefore, network diagrams have not been changed yet, until the Use Case is agreed.

<Olga> Some comments here are really not open issues for the proposal, but items to be specified during the project, either Release 1 or post Release 1.

<Olga> Some comments here are more general OPEN-O items, outside of the SDN-O scope

 

·         Do not use “Network Services” to avoid confusion w ETSI NSD (but would like to)

<Olga> DONE. Change to network connectivity service everywhere – Slide 2 Project Description was the reason for the comment.

·         China Telecom code for Network SA – will that not be avail now? Slide #13 suggests committers from China Telecom

<Olga> My latest info is that China Telecom will be involved, we are in contact with them and discussing use cases. I have China Telecom as committers.

·         Other plans for Service Assurance? Seems like Huawei MAY add post rel1 per slide #12?

<Olga> We are currently defining the use case with China Telecom for Release 1 (Stretch Goal for fully integrated and functional for November). Additional Functionality is proposed post-release 1, not Huawei but OPEN-O roadmap. Please see both Post Release 1 Roadmap (Slide 15) and Post release 1 Lifecycle extensions(Slide 12). I used the same diagram as GS-O initially, to make it consistent. The note only says that the diagram on Slide 12 will be enhanced going forward.

 

O.200 UE: Intel to explore adding a committer to the ODL driver project, working w ZTE

<Olga> Waiting for Intel to come back to me.

 

O.201 LD: clarify comment on Overlay/underlay – CMCC wants Enterprise/. No one has key different requirements at this point

<Olga> I changed Slide 9 to “E2E Overlay Network Connectivity Service over Underlay Connectivity”. Currently Use Case being discussed - Enterprise and residential.

 

Slide #3

GS-O will not have ability to access to configure the micro services. Will only have one item it can drive: an e2e connectivity request.

 

<Olga> That is correct for Release 1. We can discuss if more is needed post Release 1.

 

O.202 OH, ARC: should SDN-O be a standalone entity exposing its own NB and SB APIs (GUI, Catalog, Data Model) or what is the right level of integration with rest of Open-O for rel1 and long term? Current proposal has no way for GSO to orchestrate any SDN-O internal micro services but the E2E connectivity service

<Olga> Release 1 Proposal states that GS-O orchestrates only the e2e network connectivity service. We are discussing if there is need for any retrieval for release 1, latest info from GS-O is that no get will be required for Release 1. We will need to expand it for post Release 1. Currently requirement is to abstract the network connectivity and provide abstracted API that does not mandate the GS-O to understand the network topology, layering and different technologies. The solution post release 1 may be general enough that any properties defined by business in the catalogue to be configurable and visible at GS-O layer should be supported, including selecting technologies and viewing the details of network if needed.

 

O.203 OH, ARC: provide the NB Rest API. Referring to ETSI MANO spec fig 5.2 what is the difference between the WAN Infrastructure Manager and SDN-O? What is the pro/cons of using Or-Vi and Nf-Vi as a starting point for NB and SB API? If MEF Legato is proposed, provide a write up of its pro/cons and industry support. What is the flexibility to change it?

<Olga> Removed the MEF Presto Reference, we can discuss at the Architecture Committee. Changed it to more generic statement on Slide 10, although we believe MEF is requirement for SDN-O, and we should substantiate it further at the architecture meetings for Release 2 strategy.

MEF / TMF / ETSI may be useful as reference for abstract NBI (post Release 1)

MEF / ONF / TMF/ ETSI may be useful as reference for abstract SBI (post Release 1).

 

O.204 ARC: assume a connectivity type can be requested from GS-O? Or else what is the meaning of asking for an E2E connectivity from GS-O?

<Olga> Connectivity type may be asked from GS-O or may be automatically assigned, depending on the business policy. Release 1 plan is to initially support the use case where SDN-O automatically selects the underlaying technologies. Going forward (Post release 1) it will may also be in the catalogue as part of the network connectivity service template.

 

O.205 ARC: is Open-O to be architected presented as Hierarchy of orchestrators or provide also a top seeing all physical and logical infrastructure and exposing based on RBAC

<Olga> I think we agreed that it is up to the business to decide what is exposed to the top level and what is abstracted by the SDN-O, based on its business policies, requirements and organization. Release 1 Use Case is the simple one without need to expose all infrastructure, currently discussing with GS-O if anything needs to be exposed. Latest info from GS-O is that get will not be required in Release 1.

 

O.206 ARC: assume that some VNFs will be on boarded based on their YANG model, so TOSCA Common and the associated Designer have to support YANG and conversion to TOSCA (of relevant parts). Should the Designer for the physical network and SDN-O be integrated too – i.e. related also to TOSCA/YANG interaction/ integration

 

<Olga> We may discuss more at the Architecture Meetings and TSC. Our current agreed architecture is defined to abstract physical network and specific vendors and their models by providing a common SBI and capability to add drivers to map from vendor APIs to common API.

 

O.207 OH: document operator’s requirements for Roles and responsibilities (e.g. separate operator for NFV and SDN. Top level operator should not have double click access to the physical network). Addressing different personalities, diff scenarios

<Olga> Is this SDN-O Open Issue? We discussed the roles and responsibilities during the overall User Case? Should this be OPEN-O or even GS-O and not SDN-O issue., where we have those roles documented as discussed in Beijing.

 

O.208 OH: as code for GUI is not yet avail (per slide #11) – why not use GS-O?

<Olga> SDN-O will reuse the Portal code from NFV-O, same as GS-O.  Slide does not say that the code is not shared, just that it is a different project and different module. The GS-O will have different GUi and have different requirements. Longer term, the best approach would be to have common Portal Framework that could be reused between modules. Currently, out of 44 use cases we have for SDN-O, only 2 are exposed to GS-O.

 

O.209 OH: provide a description of proposed interaction with GS-O and Common TOSCA (slide #9 suggests NO interaction, while Slide #10, #11 shows some)

<Olga> Slide 9 used the existing Architecture slide and specifies what is in the scope of SDN-O in the Release 1 and what external modules the SDN-O will depend on or will use. It does not specify who would be using SDN-O over API. Slide 10 specifies that GS-O will communicate with SDN-O via REST interface. How this SDN-O REST interface is called from GS-O (via TOSCA template or some other way) should probably be described in GS-O, as SDN-O provides REST interface and the rest is external to SDN-O.

 

O.210 OH: provide the “common SBI” API.

<Olga> I added the Common SBI slide 5. Please review.

 

O.211 OH: how will the “common SBI” be defined? Is he API for Rel1 proprietary with a future option to move to MEF Presto? How wide is its industry support? What devices support is today? Standardization goals? How to drive broad industry adoption?

<Olga> I added the Common SBI slide 5. Please review.

 

Slide #4:

O.212 OH: What technologies/protocols will be used by ODL to drive its respective devices? Just VLAN/VxLAN?

<Olga> This will be based on the OPEN-O Use Case. Currently VLAN/VxLAN, as mentioned on the slide, but the new Use Case is being discussed (Board/TSC). May be more if agreed.

 

O.213 OH: What technologies/protocols will be used by ONOS to drive its respective devices? Is the L3VPN configured into physical devices using OpenFlow? Other? What IPsec options?

ODL driver from ZTE

<Olga> This will be based on the OPEN-O Use Case. Currently L3VPN/IPSec, as mentioned on the slide, but the new Use Case is being discussed (Board/TSC). May be more if agreed. The controller itself and how it communicates with devices is outside of the SDN-O project, will be defined in the Lab/Test project

 

O.214 ZTE: what NBI of ODL will the ZTE driver support? E.g. NetVirt to OvS on the server?

 <Olga> More details about what exact Controller APIs will be supported will be specified before milestone M1 Feature/Functionality Freeze or M2 API freeze.

 

Agreement that SDN Controller under VIM or directly from the NFV-O is out of context. However it is assumed that for rel1, the SDN-O will manipulate Neutron to connect the Physical network to the tenant specific logical network inside the VIM.

<Olga> Correct

 

 

O.215 OH: Describe VIM Neutron driver functionality? What is the solution approach? Supports connectivity only or isolation, QoS and security too? What neutron API and OpenStack versions are supported? (criteria to select the OpenStack distro – RHT mentioned on slide #14)

Neutron API is referred to and used herewith for SDN-O connectivity only.

<Olga> We will specify all this before M1 Feature/Functionality Freeze or M2 API freeze.

 

O.216 OH: does it present a multi writer issue?

<Olga> Currently, the team is aware of the potential issue raised by Uri and will analyze the problem and propose the solution.

 

O.217 OH: describe the low level semantics of the proposed connectivity model. It seems to add a router in the path. Implications?

<Olga> Is this something we want in the proposal or are we going to work on it in the first milestones of the project. In regards to adding a router on a path – depends where the router is (PE, P1, in access, etc). In some cases, SDN-O may not even be aware of it (inside the controller domain) and in some cases SDN-O will need to support it, but the use case for this is outside of the scope of Release 1.

 

O.218 ARC: What is the preferred long term approach for SDN to VIM network connection – direct? By SDN-O? Through GS-O? Who owns the global VNFFG?

<Olga> Topic for all the partners, including TSC and architecture committee.

 

DENG Huis comment – would like to see super controller as part rel 1

Super SDNC: CMCC has a developer assigned to the ODL SPTN project

 

<Olga> Will update the slides when the new Use Case proposed by CMCC is agreed and the final agreed slide distributed to all.

 

O.219 OH: provide description of SPTN. Is this a CMCC code contribution? How does it add value to agreed Rel1 Use case?

<Olga> SPTN is requested by CMCC. I will add it to the diagram later, when I receive the latest agreed use case diagram. Currently, will leave the Use Case diagram unchanged. Please ask the Board/TSC about the value of SPTN, China Mobile is requesting it based on their business needs.

 

O.220 DH: clarify - no need for L2 micro service in support of SPTN L3 is all we need

<Olga> L2VPN service removed based on the comments from Shenzhen, but the new Use Case proposed by CMCC now has L2VPN as underlay inside the Access. Will not change the diagrams until the Use Case is agreed (Board/TSC).

 

O.221 OH: Stretch goal includes network monitoring using PCEP. Is technology for BGP peering contributed? Included in rel1 but not fully tested? Can be contributed?

<Olga> Currently started the process of discussing the use cases and functionality with China Telecom. All info will be added to the wiki as agreed before M1 for use cases & features/functionality and before M2 for APIs.

 

O.222 OH: is there a list of supported physical network devices e.g. Switches, Routers? How can the list be extended?

<Olga> Will be added during milestone M1 and then M2. The full list of controllers, devices that these controllers support and API versions. Also, the lab project should specify all the versions that we will demo and test with.

 

Slide #5:

“Basic network connectivity service inventory”

<Olga> We need to design how and if we will support basic service inventory and topology for Release 1 - it is currently the stretch goal. Will be fully specified inside the M1 and M2 phases. We can have each technology microservice having its own inventory or we can have SDN-O basic service inventory  micro service.

 

O.223 OH, ARC: specific network connectivity using specific technologies is proposed as the SDN-O “micro-services”. Is it scalable and comprehensive? Is the E2E Network connectivity another such “micro service” does it provide the physical network topology (connectivity, QoS, Security, HA, utilization level etc.) as well?

<Olga> The current design is based on the existing code, OPEN-O Use Case and Release 1 delivery. The initial focus is on the initial network connectivity service provision & activate integration and demo. The design will need to evolve to take into account service catalogue, model driven and full service lifecycle, including (network discovery, synch, monitoring, assurance, closed loop, etc). Please see roadmap items. The physical network topology will be simulated for Release 1 inside BRS service. Some items in the brackets are not physical network topology.

 

O.224 OH: is IPsec a stand alone micro service provided for any L3 network connectivity?

 

<Olga> YES, it is currently a separate micro service.

 

Slide #9:

O.225 OH: Mark the diagram with the number of SDN  used (1 – under VIM, 2 – NFVO to VIM direct, 3- under SDN-O for physical network control, 4 – Super SDN Controller)

There are 4 types of SDN Controller and this projects addresses/interacts with 3 and 4 only

<Olga> I believe we agreed that if we need numbering it should be added in the overall Use Case and then referred to in SDN-O. Please do the numbering the OPEN-O Use Case, I will change the SDN-O proposal afterwards, based on that.

 

O.226 OH: SBI API – distinguish between private and public. Can it be ONF CI or MEF?

D.7: Agree that long term drivers are outside the project under the public API

AV: same API style should be used throughout the project

<Olga> Updated the slide

 

O.227 OH, ARC: Use TOSCA as the API style vs CMCC request for separation of roles and ability to see the scope of the infrastructure

On-boarding a service – no catalog. API and some micro services.

<Olga> SDN-O will provide REST API in Release 1. The API would be provided by the SDN-O team and defined in the GS-O Catalogue.

 

O.228 OH, ARC: define desired approach for Network Service on-boarding – interaction with GS-O, global inventory, separate in SDN-O? How automated is it vs desired automation goals?

Will have micro service catalog internal only??? Per above comment assume that GSO will be able to orchestrate any micro services!

<Olga> Proposal States in several places that catalogue for SDN-O is post Release 1. As agreed, GS-O will orchestrate e2e network connectivity service only in Release 1. Changed NBI description to -  NBI for orchestration of e2e network connectivity service only

 

O.229 OH: Catalog plans for Rel1? Post rel 1?

<Olga> Proposal States in several places that catalogue for SDN-O is post Release 1.

 

O.230 OH: when network topology changes – how does it affect running micro services? Is the change applied to each of them individually? Some global considerations (related to question about global topology micro service)

<Olga> No discovery & monitoring & synch & closed loop support in Release 1 – just initial provisioning on the static network. Controllers will handle changes inside their clouds.

 

O.231 OH: any OAM scheme support?

<Olga> Not in Release 1

O.232 OH: Use of micro services bus. Micro service on the use case slide e.g. IPSec, MPLS l# VPN

 <Olga> There will be one microservice per service type, currently listed for the Use Case agreed in Beijing, may need to change for the new use case when agreed with Board/TSC

 

Slide #12:

O.233 OH, ARC: what is the long term approach to design and on-boarding environment? Does it make sense to use the Common TOSCA designer?

<Olga> To be analyzed later, to be discussed at Architecture Meetings and planned for post Release 1.

 

O.234 OH: no resource reservation is part of rel1? Any measures to monitor/control network load/congestion, traffic engineering?

<Olga> Post Release 1.

 

Slide #16:

O.235 OH: define “Meta Model driven dynamic programmable orchestration”

 <Olga> Capability to support orchestration of the new service type out of the box via configuration only, without need to do any code changes and new software releases

 

O.236 ARC: IM/DM an API alignment with external SDO and open source

 <Olga> To be discussed at the Architecture Meetings, need strategy and agreement not only for SDN-O, but OPEN-O

 

Thx

 

Uri (“Oo-Ree”)

C: 949-378-7568

 


Brendan Hassett <brendan.hassett@...>
 

Hello all,

 

See below for some quick answers. We can discuss in more detail in Berlin.

 

Regards,

Brendan

 

 

From: openo-tsc-bounces@... [mailto:openo-tsc-bounces@...] On Behalf Of Elzur, Uri
Sent: Friday, June 17, 2016 3:21 PM
To: 'openo-tsc@...' <openo-tsc@...>
Subject: [openo-tsc] Project proposal technical feedback SDN-O, GS-O (part 3)

 

4) GS-O – Brendan Hassett

General comments:

 

Another instance of the same code for the GUI portal for rel1. Long term, look at ways to integrate

Enables 3rd party orchestrator too, if such exists

(MEF as an option)

4 – use the ETSI interface

Can have in theory another orchestrator or 3rd party OSS on top, but not in scope for rel1

GUI – can we use one code (i.e. CMCC GUI for NFV-O) and disable some functionality vs separate code

Catalog is an open

No intelligence e.g. pick best placement target

 

Slide #5, #7:

Based on slide #6, assume that the Service Parser, Decomposer and Workflow Engine are ARIA based from Common TOSCA project.

O.100 BH, AB: comment “Parser decomposer and workflow not aligned” ??? Does ARIAN expose specific APIs for these functions?

[BH] Discussions are ongoing with Gigaspaces to define the ARIA APIs.

O.101 BH: Does GS-O NBI use TOSCA YAML as an input? Interact with the Model Designer? Pls provide pointer to API

[BH] Model Designer writes the Service Description (YAML in CSAR) to the Catalog. GS-O GUI allows user to select a service from the catalog. GS-O GUI sends the catalog reference to GS-O through the NBI. GS-O (actually Lifecycle Manager) reads the Service Description from the Catalog using the reference received over the NBI.

O.102 BH: does the Service Decomposer take NSD+VNFFG as an input? Will it split the VNFFG?

[BH] We are working with Gigaspaces on the capabilities of the parser. The current plan is that the TOSCA Simple Profile for NFV will be supported. In Release 1, there will be no functionality in GS-O to split the forwarding graph.

O.103 BH: who develops the Catalog project? No commit for rel1???

[BH] ZTE will develop the Catalog in the O-Common project.

Slide #6:

O.104 BH: describe the proposed NB API and its potential of integration with any existing BSS. Any DM exposed north bound? How will the proposed API interact with SID?

[BH] We are working with Gigaspaces on this issue. In Release 1, the GS-O NBI model will be just a concatenation of the models from SDN-O and NFV-O.

O.105 BH: is Os-Ma-Nfvo not the proposed interface for 1? Vs. the interface 4 towards the NFVO? It assumes that ETSI model has NO information for the physical network!

[BH] In Release 1, the GS-O NBI will be just a concatenation of the NBIs from SDN-O and NFV-O.

O.106 BH, AB: relies on Common – TOSCA catalog? CSAR is only API requirement for integration? What protocol?

[BH] Waiting for APIs from the Catalog.

O.107 BH: what is the semantics of interface 3 to the SDN-O component – just E2E connectivity request? Need additional parameters…

[BH] Waiting for NBI and model from the SDN-O project.

Slide #8:

O.108 BH: define “Service”

[BH] In this context, the Service is an Global End-To-End Service.

 

6/9/16 Shenzen

6) SDN-O Olga Havel

Some general comments:

·         Do not use “Network Services” to avoid confusion w ETSI NSD (but would like to)

·         China Telecom code for Network SA – will that not be avail now? Slide #13 suggests committers from China Telecom

·         Other plans for Service Assurance? Seems like Huawei MAY add post rel1 per slide #12?

 

O.200 UE: Intel to explore adding a committer to the ODL driver project, working w ZTE

 

O.201 LD: clarify comment on Overlay/underlay – CMCC wants Enterprise/. No one has key different requirements at this point

Slide #3

GS-O will not have ability to access to configure the micro services. Will only have one item it can drive: an e2e connectivity request.

O.202 OH, ARC: should SDN-O be a standalone entity exposing its own NB and SB APIs (GUI, Catalog, Data Model) or what is the right level of integration with rest of Open-O for rel1 and long term? Current proposal has no way for GSO to orchestrate any SDN-O internal micro services but the E2E connectivity service

O.203 OH, ARC: provide the NB Rest API. Referring to ETSI MANO spec fig 5.2 what is the difference between the WAN Infrastructure Manager and SDN-O? What is the pro/cons of using Or-Vi and Nf-Vi as a starting point for NB and SB API? If MEF Legato is proposed, provide a write up of its pro/cons and industry support. What is the flexibility to change it?

O.204 ARC: assume a connectivity type can be requested from GS-O? Or else what is the meaning of asking for an E2E connectivity from GS-O?

O.205 ARC: is Open-O to be architected presented as Hierarchy of orchestrators or provide also a top seeing all physical and logical infrastructure and exposing based on RBAC

O.206 ARC: assume that some VNFs will be on boarded based on their YANG model, so TOSCA Common and the associated Designer have to support YANG and conversion to TOSCA (of relevant parts). Should the Designer for the physical network and SDN-O be integrated too – i.e. related also to TOSCA/YANG interaction/ integration

 

O.207 OH: document operator’s requirements for Roles and responsibilities (e.g. separate operator for NFV and SDN. Top level operator should not have double click access to the physical network). Addressing different personalities, diff scenarios

O.208 OH: as code for GUI is not yet avail (per slide #11) – why not use GS-O?

O.209 OH: provide a description of proposed interaction with GS-O and Common TOSCA (slide #9 suggests NO interaction, while Slide #10, #11 shows some)

O.210 OH: provide the “common SBI” API.

O.211 OH: how will the “common SBI” be defined? Is he API for Rel1 proprietary with a future option to move to MEF Presto? How wide is its industry support? What devices support is today? Standardization goals? How to drive broad industry adoption?

Slide #4:

O.212 OH: What technologies/protocols will be used by ODL to drive its respective devices? Just VLAN/VxLAN?

O.213 OH: What technologies/protocols will be used by ONOS to drive its respective devices? Is the L3VPN configured into physical devices using OpenFlow? Other? What IPsec options?

ODL driver from ZTE

O.214 ZTE: what NBI of ODL will the ZTE driver support? E.g. NetVirt to OvS on the server?

 

Agreement that SDN Controller under VIM or directly from the NFV-O is out of context. However it is assumed that for rel1, the SDN-O will manipulate Neutron to connect the Physical network to the tenant specific logical network inside the VIM.

O.215 OH: Describe VIM Neutron driver functionality? What is the solution approach? Supports connectivity only or isolation, QoS and security too? What neutron API and OpenStack versions are supported? (criteria to select the OpenStack distro – RHT mentioned on slide #14)

Neutron API is referred to and used herewith for SDN-O connectivity only.

O.216 OH: does it present a multi writer issue?

O.217 OH: describe the low level semantics of the proposed connectivity model. It seems to add a router in the path. Implications?

O.218 ARC: What is the preferred long term approach for SDN to VIM network connection – direct? By SDN-O? Through GS-O? Who owns the global VNFFG?

DENG Huis comment – would like to see super controller as part rel 1

Super SDNC: CMCC has a developer assigned to the ODL SPTN project

O.219 OH: provide description of SPTN. Is this a CMCC code contribution? How does it add value to agreed Rel1 Use case?

O.220 DH: clarify - no need for L2 micro service in support of SPTN L3 is all we need

O.221 OH: Stretch goal includes network monitoring using PCEP. Is technology for BGP peering contributed? Included in rel1 but not fully tested? Can be contributed?

O.222 OH: is there a list of supported physical network devices e.g. Switches, Routers? How can the list be extended?

Slide #5:

“Basic network connectivity service inventory”

O.223 OH, ARC: specific network connectivity using specific technologies is proposed as the SDN-O “micro-services”. Is it scalable and comprehensive? Is the E2E Network connectivity another such “micro service” does it provide the physical network topology (connectivity, QoS, Security, HA, utilization level etc.) as well?

O.224 OH: is IPsec a stand alone micro service provided for any L3 network connectivity?

 

Slide #9:

O.225 OH: Mark the diagram with the number of SDN  used (1 – under VIM, 2 – NFVO to VIM direct, 3- under SDN-O for physical network control, 4 – Super SDN Controller)

There are 4 types of SDN Controller and this projects addresses/interacts with 3 and 4 only

 

O.226 OH: SBI API – distinguish between private and public. Can it be ONF CI or MEF?

D.7: Agree that long term drivers are outside the project under the public API

AV: same API style should be used throughout the project

O.227 OH, ARC: Use TOSCA as the API style vs CMCC request for separation of roles and ability to see the scope of the infrastructure

On-boarding a service – no catalog. API and some micro services.

O.228 OH, ARC: define desired approach for Network Service on-boarding – interaction with GS-O, global inventory, separate in SDN-O? How automated is it vs desired automation goals?

Will have micro service catalog internal only??? Per above comment assume that GSO will be able to orchestrate any micro services!

O.229 OH: Catalog plans for Rel1? Post rel 1?

O.230 OH: when network topology changes – how does it affect running micro services? Is the change applied to each of them individually? Some global considerations (related to question about global topology micro service)

O.231 OH: any OAM scheme support?

O.232 OH: Use of micro services bus. Micro service on the use case slide e.g. IPSec, MPLS l# VPN

 

Slide #12:

O.233 OH, ARC: what is the long term approach to design and on-boarding environment? Does it make sense to use the Common TOSCA designer?

O.234 OH: no resource reservation is part of rel1? Any measures to monitor/control network load/congestion, traffic engineering?

Slide #16:

O.235 OH: define “Meta Model driven dynamic programmable orchestration”

O.236 ARC: IM/DM an API alignment with external SDO and open source

 

 

Thx

 

Uri (“Oo-Ree”)

C: 949-378-7568

 


Elzur, Uri <uri.elzur@...>
 

4) GS-O – Brendan Hassett
General comments:
 
Another instance of the same code for the GUI portal for rel1. Long term, look at ways to integrate
Enables 3rd party orchestrator too, if such exists
(MEF as an option)
4 – use the ETSI interface
Can have in theory another orchestrator or 3rd party OSS on top, but not in scope for rel1
GUI – can we use one code (i.e. CMCC GUI for NFV-O) and disable some functionality vs separate code
Catalog is an open
No intelligence e.g. pick best placement target
 
Slide #5, #7:
Based on slide #6, assume that the Service Parser, Decomposer and Workflow Engine are ARIA based from Common TOSCA project.
O.100 BH, AB: comment “Parser decomposer and workflow not aligned” ??? Does ARIAN expose specific APIs for these functions?
O.101 BH: Does GS-O NBI use TOSCA YAML as an input? Interact with the Model Designer? Pls provide pointer to API
O.102 BH: does the Service Decomposer take NSD+VNFFG as an input? Will it split the VNFFG?
O.103 BH: who develops the Catalog project? No commit for rel1???
Slide #6:
O.104 BH: describe the proposed NB API and its potential of integration with any existing BSS. Any DM exposed north bound? How will the proposed API interact with SID?
O.105 BH: is Os-Ma-Nfvo not the proposed interface for 1? Vs. the interface 4 towards the NFVO? It assumes that ETSI model has NO information for the physical network!
O.106 BH, AB: relies on Common – TOSCA catalog? CSAR is only API requirement for integration? What protocol?
O.107 BH: what is the semantics of interface 3 to the SDN-O component – just E2E connectivity request? Need additional parameters…
Slide #8:
O.108 BH: define “Service”
 
6/9/16 Shenzen
6) SDN-O Olga Havel
Some general comments:
  • Do not use “Network Services” to avoid confusion w ETSI NSD (but would like to)
  • China Telecom code for Network SA – will that not be avail now? Slide #13 suggests committers from China Telecom
  • Other plans for Service Assurance? Seems like Huawei MAY add post rel1 per slide #12?
 
O.200 UE: Intel to explore adding a committer to the ODL driver project, working w ZTE
 
O.201 LD: clarify comment on Overlay/underlay – CMCC wants Enterprise/. No one has key different requirements at this point
Slide #3
GS-O will not have ability to access to configure the micro services. Will only have one item it can drive: an e2e connectivity request.
O.202 OH, ARC: should SDN-O be a standalone entity exposing its own NB and SB APIs (GUI, Catalog, Data Model) or what is the right level of integration with rest of Open-O for rel1 and long term? Current proposal has no way for GSO to orchestrate any SDN-O internal micro services but the E2E connectivity service
O.203 OH, ARC: provide the NB Rest API. Referring to ETSI MANO spec fig 5.2 what is the difference between the WAN Infrastructure Manager and SDN-O? What is the pro/cons of using Or-Vi and Nf-Vi as a starting point for NB and SB API? If MEF Legato is proposed, provide a write up of its pro/cons and industry support. What is the flexibility to change it?
O.204 ARC: assume a connectivity type can be requested from GS-O? Or else what is the meaning of asking for an E2E connectivity from GS-O?
O.205 ARC: is Open-O to be architected presented as Hierarchy of orchestrators or provide also a top seeing all physical and logical infrastructure and exposing based on RBAC
O.206 ARC: assume that some VNFs will be on boarded based on their YANG model, so TOSCA Common and the associated Designer have to support YANG and conversion to TOSCA (of relevant parts). Should the Designer for the physical network and SDN-O be integrated too – i.e. related also to TOSCA/YANG interaction/ integration
 
O.207 OH: document operator’s requirements for Roles and responsibilities (e.g. separate operator for NFV and SDN. Top level operator should not have double click access to the physical network). Addressing different personalities, diff scenarios
O.208 OH: as code for GUI is not yet avail (per slide #11) – why not use GS-O?
O.209 OH: provide a description of proposed interaction with GS-O and Common TOSCA (slide #9 suggests NO interaction, while Slide #10, #11 shows some)
O.210 OH: provide the “common SBI” API.
O.211 OH: how will the “common SBI” be defined? Is he API for Rel1 proprietary with a future option to move to MEF Presto? How wide is its industry support? What devices support is today? Standardization goals? How to drive broad industry adoption?
Slide #4:
O.212 OH: What technologies/protocols will be used by ODL to drive its respective devices? Just VLAN/VxLAN?
O.213 OH: What technologies/protocols will be used by ONOS to drive its respective devices? Is the L3VPN configured into physical devices using OpenFlow? Other? What IPsec options?
ODL driver from ZTE
O.214 ZTE: what NBI of ODL will the ZTE driver support? E.g. NetVirt to OvS on the server?
 
Agreement that SDN Controller under VIM or directly from the NFV-O is out of context. However it is assumed that for rel1, the SDN-O will manipulate Neutron to connect the Physical network to the tenant specific logical network inside the VIM.
O.215 OH: Describe VIM Neutron driver functionality? What is the solution approach? Supports connectivity only or isolation, QoS and security too? What neutron API and OpenStack versions are supported? (criteria to select the OpenStack distro – RHT mentioned on slide #14)
Neutron API is referred to and used herewith for SDN-O connectivity only.
O.216 OH: does it present a multi writer issue?
O.217 OH: describe the low level semantics of the proposed connectivity model. It seems to add a router in the path. Implications?
O.218 ARC: What is the preferred long term approach for SDN to VIM network connection – direct? By SDN-O? Through GS-O? Who owns the global VNFFG?
DENG Huis comment – would like to see super controller as part rel 1
Super SDNC: CMCC has a developer assigned to the ODL SPTN project
O.219 OH: provide description of SPTN. Is this a CMCC code contribution? How does it add value to agreed Rel1 Use case?
O.220 DH: clarify - no need for L2 micro service in support of SPTN L3 is all we need
O.221 OH: Stretch goal includes network monitoring using PCEP. Is technology for BGP peering contributed? Included in rel1 but not fully tested? Can be contributed?
O.222 OH: is there a list of supported physical network devices e.g. Switches, Routers? How can the list be extended?
Slide #5:
“Basic network connectivity service inventory”
O.223 OH, ARC: specific network connectivity using specific technologies is proposed as the SDN-O “micro-services”. Is it scalable and comprehensive? Is the E2E Network connectivity another such “micro service” does it provide the physical network topology (connectivity, QoS, Security, HA, utilization level etc.) as well?
O.224 OH: is IPsec a stand alone micro service provided for any L3 network connectivity?
 
Slide #9:
O.225 OH: Mark the diagram with the number of SDN  used (1 – under VIM, 2 – NFVO to VIM direct, 3- under SDN-O for physical network control, 4 – Super SDN Controller)
There are 4 types of SDN Controller and this projects addresses/interacts with 3 and 4 only
 
O.226 OH: SBI API – distinguish between private and public. Can it be ONF CI or MEF?
D.7: Agree that long term drivers are outside the project under the public API
AV: same API style should be used throughout the project
O.227 OH, ARC: Use TOSCA as the API style vs CMCC request for separation of roles and ability to see the scope of the infrastructure
On-boarding a service – no catalog. API and some micro services.
O.228 OH, ARC: define desired approach for Network Service on-boarding – interaction with GS-O, global inventory, separate in SDN-O? How automated is it vs desired automation goals?
Will have micro service catalog internal only??? Per above comment assume that GSO will be able to orchestrate any micro services!
O.229 OH: Catalog plans for Rel1? Post rel 1?
O.230 OH: when network topology changes – how does it affect running micro services? Is the change applied to each of them individually? Some global considerations (related to question about global topology micro service)
O.231 OH: any OAM scheme support?
O.232 OH: Use of micro services bus. Micro service on the use case slide e.g. IPSec, MPLS l# VPN
 
Slide #12:
O.233 OH, ARC: what is the long term approach to design and on-boarding environment? Does it make sense to use the Common TOSCA designer?
O.234 OH: no resource reservation is part of rel1? Any measures to monitor/control network load/congestion, traffic engineering?
Slide #16:
O.235 OH: define “Meta Model driven dynamic programmable orchestration”
O.236 ARC: IM/DM an API alignment with external SDO and open source
 
 
Thx
 
Uri (“Oo-Ree”)
C: 949-378-7568