search

anuket-project / anuket-specifications

Anuket specifications
https://docs.anuket.io
123 stars 117 forks source link

[RA1] SFC - req.inf.ntw.04 - Traceability #1080

Closed ASawwaf closed 4 years ago

ASawwaf commented 4 years ago

req.inf.ntw.04 : The Architecture should support service function chaining. Traceability : Is this VNFM/NFVO requirement?

it should be SDN requirements, the NFVO will onboard Network Service that be implemented by SDN/Neutron @pgoyal01 can we change ?

collivier commented 4 years ago

I'm not clear if we all agree the support of SFC and I would rather consider a networking requirement here. If true, the API has to be added in RA1 chapter 5 accordingly (whatever should or must) as the other services or the other capabilities/extensions. It's worth mentioning that it's also listed as gap (falsy linked to an SDN Controller). If the current Neutron API is not suitable, we do define a plan to propose the new neutral API in Neutron as a first step.

pgoyal01 commented 4 years ago

@ASawwaf @collivier ONAP experts should chime in here.

My understanding is that ONAP supports SFC including its modeling in SDC (Service Design & Creation) component. ONAP performs the orchestration of the SFC utilising SDN capabilities.

collivier commented 4 years ago

Even if ONAP supports SFC, it cannot be translated into an infra requirement as is. In any case, it would be great to confirm the SFC API supported by ONAP. If it's one offered by networking_sfc, we should no longer list the current SFC API as gap.

ASawwaf commented 4 years ago

@collivier @pgoyal01 , So let's put in this way , SFC it is networking task that the traffic, Service will be chained across multiple VNF, which it is consider as a Network services which onboarded in NS Catelouge and as NS Descprtator from NFVO Side if we open the NS descriptor we will find the definition of this services using VDU , I-VL nad E-VL and endpoints,

after that, this will be translated through Or-VI interface API ( Openstack APIs ) to implement this request but due to the fact that neutron can some limitation to achieve this, so it will be communicated ( NFVO ) to SDN-C to implement

How SDN-C will implement it we have several ways , in a nutshell

So to close API , either Openstack API , Or SDN ( Neutron Delegate ) API that is consumed by NFVO ( ONAP)

For ONAP , as far as i know they working to have some components from ODL ( Netconf, Daexim....) based on Karaf distribution , So may support SFC

@rabi-abdel @sukhdevkapur @oyayan any call here ?

pgoyal01 commented 4 years ago

@ASawwaf since this is not a mandatory requirement can we choose not to address in Baldy release?

ASawwaf commented 4 years ago

@pgoyal01 sure

sukhdevkapur commented 4 years ago

@pgoyal01 - While I agree that this is not must for Baldy, it should be brought in as requirement for the Architecture @collivier - networking-sfc is not sufficient to support this. My understanding is that most (if not all) production deployments use this feature and is generally supported by SDN controllers - hence, SDN is MUST requirement for RM, RA, RI, and RC @rabi-abdel - Note that SDN is brought up and then dropped. We are not doing proper justification for RM, RA, RI, RC. IN Antwerp F2F meeting, it was decided that SDN will be included in next release (Please check the notes that you wrote on the board during the meeting). During Prague meeting, it was noted that it was not included and was brought up again. The folks in RI team agreed to include SDN on their test pod. When I brought it up in OPNFV meeting to include SDN in their test pods, I was punted back to CNTT TSC. @rabi-abdel - it is shame that because of timing constraints, I can not attend CNTT TSC, but, please represent me in TSC and bring it up. Perhaps @ASawwaf, @pgoyal01 or you can represent me in TSC and bring this and get a closure on this.

pgoyal01 commented 4 years ago

Closing #1080 -- all SFC related work will be followed in #1019