Define infrabstract - MANO Framework APIs for initial implmentaion of year 1 #1 about son-sp-infrabstract

[DarioValocchi]

First 2 questions, we briefly discusse off-line with @mpeuster.

Question1: The service offered by the adaptor would be relatively slow: e.g. download and push VM into VIM image repo, deploy and configire a VM or a whole NS, trigger configuration changes...
Therefore the need of an async, RPC like procedure. I have two protocols in mind:

1. Sip-like ringing to acknowledge the request to the SLM
   SLM -> Request ->Adapt
   SLM<-RinginLikeAck<-Adapt
   ...
   SLM<-Response<-Adapt
2. No ringing, SLM trusts the broker 100% and implements internal timouts to handle errors
   SLM->Request->Adapt
   ...
   SLM<-Response<-Adapt

Question 2: Sholud the Adaptor behave like a plugin and register to the plugin manager, providing also its own hearthbeat mechanism, practically extending Manuel plugin interface?

[tsoenen]

@DarioValocchi @mpeuster @adrian-rosello : Hi all! As suggested by Dario on gitter, lets sync up on the SLM <--> IA interaction.

At this point, the SLM sends a request to the IA in the following way (yaml):

forwarding_graph:
        ...
vnf_images:
        - vnf_id:
          url:
        - vnf_id:
          url:
        - ...

The info behind forwarding_graph explains how the vnfs should be connected, and is a copy from https://github.com/sonata-nfv/son-schema/blob/master/service-descriptor/examples/sonata-demo.yml. @DarioValocchi: Is this enough information for deployment, or do you need more?

The SLM expects the following response from the IA(yaml):

request_status: ...
nsr:
        ...
vnfr1:
        ...
vnfr2:
        ...

The status can be RUNNING/FAILED/... the content of nsr, vnfr1, vnfr2, ... is still undefined. I think we should start with the basics (things like name, id, ip, ...) and add additional fields later when someone needs them.

Any thoughts? (I'm out of the office this afternoon, so I won't be able to respond before this evening/tomorrow morning)

[adrian-rosello]

Hi Thomas!

I totally agree with you. Taking a look at ETSI standard, at least the ip and the vnf_address (described as a network address configured for the management access) are required. We can include the status of the VNF as well. This will make the VNFR part look like:

vnfr1:
    id: xxxxx
    vnf_address: x.x.x.x
    status: x

[DarioValocchi]

Thank you for the good work.
One think we agreed on during the IA meeting two weeks ago was to send to the IA the whole SD+the VNFD. This will allow different wrapper for different VIM to behave differently, and have a complete picture of the service to deploy. As far as I understood, It will also be simpler to translate it the VIM specific format. Is this a problem?
As for the response, I think the format you propose is fine. I will look into it today, as I develop the API endpoint for this call.

@tsoenen @adrian-rosello: a quick question that has came to my mind just now: Do we have a formalization of the message sent through the message broker? Topic, content, format, etc...? Is the payload sent over the msgbus in yaml or json?

[DarioValocchi]

I'm going through the SD and I have another question: I would like also @smendel @mbredel and @jbonnet opinions' on this. Is the NS forwarding graph something to be parsed and "enforced" by the IA?
Because I can see how the IA can parse and enforce the "virtual_links" section of the SD, but maybe the configuration of the VNF-to-VNF forwarding rules could be something to send through the VNF adaptor? What do you think?

[mbredel]

@DarioValocchi Very good question. In general (not for Y1), the forwarding graph could span multiple different VIMs. Therefore, the parsing of the forwarding graph (FG) should be done in the VNF adapter (or at least outside the IA). However, the IA has to offer an API such that the VNF adapter can talk to it. The VNF addapter could send parts of the FG to the IA, which means the IA has to be able to parse it as well ...

[jbonnet]

@mbredel @DarioValocchi
The VNFFG describes the connections between different VNFs. The VNF Adaptor just deals with one VNF at a time, for example when there's a parameter of a VNF that needs to be changed. In that sense, the VNF Adaptor may receive some network/inter-VNF connection information that needs to be changed in a given VNF, but definitely not the whole VNFGG(D).

@DarioValocchi What do you mean by 'enforcing'? Checking if data is coherent? If so, yes, the IA may do something about validating semantically what is being asked...

[DarioValocchi]

@jbonnet @mbredel about the VNFFG role in the SD : isn't the connection between VNF described in the "connection_points" and "virtual_links" sections of the descriptor?
That is the core of my question, a little example:
The IA parses the SD connection_points list and this is used to configure the interfaces of each VM/container in the VIM.
The IA parses the SD virtual_links and this is used to configure the connection between interfaces in the VIM NaaS.
The IA parses the "forwarding_graphs" section and what? ssh into the VM to set iptable rules? I hope this also clarifies what I ment for "enforcing" 😄

[tsoenen]

@DarioValocchi : Sending the entire NSD and VNFD's is not a problem. I propose the following format for that

NSD:
        ...
VNFD1:
        ...
VNFD2:
        ...
...

It is send on the topic 'infrastructure.service.deploy', encrypted as a yaml message. Each packet has a correlation_id property in its header. The response should have the same correlation_id.

[jbonnet]

@DarioValocchi
Connection points and virtual links are the 'possible' paths you may have. The VNFFG is a specific path for that specific service, that of course has to use one of the paths defined by connection points and virtual links.

[DarioValocchi]

@jbonnet I think I see. The FG is configured in the VIM+WIM through the Networking facilities, and this is moslty kept outside of the VNFs.

[DarioValocchi]

@tsoenen 👍 for the format.
I get the info on the topic and the use of the correlation_id from the source code and implemented yesterday the api endpoint for the service deploy call. 😃
I also implemented a Mock Wrapper, as we discussed yesterday morning, and I'm currently working on parsing the service descriptor to generate the response the SLM expects.

[mbredel]

@jbonnet Oh - yes you are right regarding the VNF Adaptor and the VNFFG.

@DarioValocchi You can have Virtual Links in a VNF descriptor that describes a VNF which is composed of several (>1) VDUs, where each VDU is a VM (or Docker). The NS descriptor again can have Virtual Links between multiple VNFs ....

[DarioValocchi]

@mbredel Yes, I was talking about the links in the NS. Now I think I see what José mean. That is something not going through the VNF adaptor, as it acts per VNF.

[DarioValocchi]

@tsoenen as for the message the SLM sends: Would it be nicer to have something like:

NSD:
        ...
VNFDs:
      - VNFD1
      - VNFD2

I am not an expert with YAML, so maybe is a stupid question. Seems to me it would be mush easyer to parse.

[tsoenen]

@DarioValocchi : If you prefer this format, we can do it that way. From the SLM point of view, I think both are fairly equal when it comes to parsing.

In your example, does VNFDs contain a list of dictionaries (where each vnfd is a dictionary) or a dictionary of dictionaries (where each dictionary is a vnfd, and vnfd1, vnfd2 are the keys)?

[DarioValocchi]

@tsoenen I think is a List of dictionaries, speaking python. So to allow variable number of VNFD.
Using Java I have VNFDescriptor and the ServiceDescriptor.
What I had in mind was modeling the message like this:

  private ServiceDescriptor NSD;
  private ArrayList<VNFDescriptor> VNFDs;

[DarioValocchi]

Other issue that came up now I'm implementing the mock response generation. Any policy for the Instances ID? What information is expected in the Service Record? Id and status, again?

[jbonnet]

@DarioValochi
... and IP address of the instance, and... 

jb

Enviado de Samsung Mobile

-------- Mensagem original --------
De : Dario Valocchi [email protected]
Data:08/04/2016 17:00 (GMT+00:00)
Para: sonata-nfv/son-sp-infrabstract [email protected]
Cc: José Bonnet [email protected]
Assunto: Re: [sonata-nfv/son-sp-infrabstract] Define infrabstract - MANO
Framework APIs for initial implmentaion of year 1 #1 (#2)

Other issue that came up now I'm implementing the mock response generation. Any policy for the Instances ID? What information is expected in the Service Record? Id and status, again?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[DarioValocchi]

Ok, I feel stupid now. 😄
I totally missed the NSR and NVFR schemas in the son-schema repo. I'll stick to them. Is it right? @mbredel

[DarioValocchi]

@tsoenen , The mock's almost ready. Just one more question.
Following the MSC illustred here, the creation of the NSR is something made by the SLM once it receives the runtime information from the adaptor. This runtime information includes the information @adrian-rosello mentioned for each VNF. But I'm still not sure, what to include as runtime information for the whole service. The NSR schema is quite big and contains a lot of fields, coming both from the NSD and from the instance. Which field are originated by the IA and included in the IA response to the SLM?

[tsoenen]

@DarioValocchi : It's a lot of fields indeed:) It's the first time I see it, so right now I don't now which originate where. But I think that for now, it is ok if the NSRs are not complete. As long as their is a NSR and it has some fields, we can continu. So I would suggest that you include a (small) subset of te fields that originate in the IA, and we can add fields later when needed.
If you think the NSR does not contain any instance information, except maybe references to the VNFRs, then maybe the SLM should be making the NSR.

[DarioValocchi]

@tsoenen, just pushed a new commit on the DV-branch of the adapter with the promised MockWrapper.
If you look at the tests I've defined a unit test where the sonata-demo.yml is sent to the IA along with the associated VNFDs (NSD and VNFD examples in son-schema). The MockWrapper fakes the instantiation and generates this response:

request_status: "normal_operation"
nsr:
  id: "6c70e65d-f8be-4853-a487-d947ad3986ae"
  status: "normal_operation"
vnfrs:
- descriptor_version: "vnfr-schema-01"
  id: "5d241bc4-b94a-4d7b-a18c-c534ecccfe20"
  status: "normal_operation"
  vnf_address: "0.0.0.0"
  virtual_deployment_units:
  - id: "e50cbaf4-adc4-4898-aa4e-63b2e161aeb1"
    vm_image: "file:///docker_files/iperf/Dockerfile"
    vdu_reference: "iperf-vnf:vdu01:e50cbaf4-adc4-4898-aa4e-63b2e161aeb1"
    number_of_instances: 1
- descriptor_version: "vnfr-schema-01"
  id: "b52163e2-d7b3-4456-bd79-54ce2bd86c9b"
  status: "normal_operation"
  vnf_address: "0.0.0.0"
  virtual_deployment_units:
  - id: "b31658dd-6e6c-47f2-8102-a92c1bee65fe"
    vm_image: "file:///docker_files/firewall/Dockerfile"
    vdu_reference: "firewall-vnf:vdu01:b31658dd-6e6c-47f2-8102-a92c1bee65fe"
    number_of_instances: 1
- descriptor_version: "vnfr-schema-01"
  id: "f2a98e32-3a9f-46e4-8194-093f70bfe8c9"
  status: "normal_operation"
  vnf_address: "0.0.0.0"
  virtual_deployment_units:
  - id: "025de910-3aae-4f57-a59a-7f99fac8c955"
    vm_image: "file:///docker_files/tcpdump/Dockerfile"
    vdu_reference: "tcpdump-vnf:vdu01:025de910-3aae-4f57-a59a-7f99fac8c955"
    number_of_instances: 1

that is basically a copy of the required fields of the VNFR from the relevant VNFD. The NSR now contains just a status and an ID of the instance. There's room, of course, for other fields, if they are originated in the IA.
@mbredel on the vdu_reference field I followed the semantic in the comment of VNFR schema. I hope I did it as it was meant to be.