NSD creation/sync in lower level Service Platform about son-hsp-pilot

[DarioValocchi]

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:

• Solution 1: The NSD/VNFDs are the same in both platforms (hence the Catalogue sharing), and the red SLM knows that only the VNF-2 is to be deployed here;
• Solution 2: The NSD with only the red VNFD (VNF-2) is generated on the fly (so there are no Catalogue sharing), so the red SLM acts just like the green one;
• Solution 3: The NSD with only the red VNFD (VNF-2) is separately on-boarded by the developer (so there are no Catalogue sharing), so the red SLM acts just like the green one;

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

• Solution 1: implies more work on GK and MANO, maybe higher flexibilities, because of the dedicated API on lower SP=>different flow in MANO from standard service instantiation.
• Solution 2: implies more work on IA, maybe lower flexibility, but very smaller impact on lower level SP because of API/flow reuse on lower API
• Solution 3: I don't think it is feasible, cause the higher SP won't know the UUID of the NSD on-boarded in the lower-SP

[PhilipEardley]

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]

(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.