sonata-nfv / son-hsp-pilot

SONATA's Hierarchical Service Providers Pilot
http://www.sonata-nfv.eu
Apache License 2.0
0 stars 2 forks source link

NSD creation/sync in lower level Service Platform #2

Open DarioValocchi opened 7 years ago

DarioValocchi commented 7 years ago

How does Lower SP SLM get a NSD which contains the VNF?

DarioValocchi commented 7 years ago

The problem rises after the deployment and configuration after the placement decision has been made and it boils down to "how do we pass the NSD or just the FG to the lower SP when we instantiate a VNF on lower level SP" @jbonnet proposes these solutions:

here's my opinion on the implication of these three solutions

PhilipEardley commented 7 years ago

I'm not sure if this is solution 4... maybe a combination of solution 1 & 2? My take is that: the lower (red) SP publishes the NSDs for the NSs it can offer. This is effectively a public catalogue that upper (green) SPs can view. the service lifecycle manager is something separate. Each SP runs its own SLMs for the NSs it operates. knowing uuids - I think this is getting into addressing issues? we should involve Andy who's thought about addressing issues.

PhilipEardley commented 7 years ago

(after discussion with Andy) Solution 1 - if this means identical NSDs in the two platforms, then this isn't really two SPs. Solution 3 - "red SLM acts just like the green one" - great, this is recursion Solution 2 - "generated on the fly". yes - or yes to some extent:- The catalogue will have [1] NSD templates (which are relatively static), [2] info for each instantiation of the NS (about resource usage, and addressing/port - so VNF1 (in the upper-SP) can forward packets to VNF2 (in lower-SP). The lower-SP needs to understand what constraints there (for instance, there's no point it suggesting one of its private addresses - which might be what it does by default). Typically the upper-SP also needs a management address, so it can configure VNF2 (in lower-SP), eg set details of the firewall's rules.