Instantiation network information

[santiagordguez]

At instantiation time, network information will be required to the user:

• Ingress/Egress
• Location
• Network Attachment Points (network segments)

[santiagordguez]

Done: https://github.com/sonata-nfv/son-bss/pull/83

Pending: adapt the code to retrieve the list of locations from GK API.

[jbonnet]

Hi, @srodriguezOPT Can you please paste here an example of the JSON provided to the GK? Thanks,

[santiagordguez]

Hi @jbonnet

I included an example in http://wiki.sonata-nfv.eu/index.php/D43_BSS_Module#Location_Info

[jbonnet]

Ha, great, @srodriguezOPT, thanks, I'm reproducing it here, for completeness:

{
  "service_uuid": "8c58b169-7c38-4bcd-9421-a91bd786f1fa",
  "egress": [
    {     
    }
  ],
  "ingress": [
    {
      "location": "Aveiro",
      "nap": "10.0.0.1/32"
    },
    {
      "location": "London",
      "nap": "20.10.0.2/24"
    }
  ]
}

[jbonnet]

@srodriguezOPT Some doubts:

1. can both egress and ingress be empty?
2. when empty, can they be like "egress":[] (i.e., without the {} inside)?
3. when not empty, both location and nap must be present, right?
4. do we need to store this in the DB, together with the service_uuid (for instance, will the BSS want to search by 'which service instantiation requests were made with ingress location == 'Aveiro')?

[santiagordguez]

@jbonnet:

1. Yes, they can be empty.
2. Ok, no problem.
3. Exactly; when not empty, both fields are mandatory
4. BSS will not filter by location/nap information. We can include it as part of the requests info, (detailed info) but it's not mandatory. BSS won't use this information

[jbonnet]

Great, @srodriguezOPT, thanks!

[santiagordguez]

Closed by https://github.com/sonata-nfv/son-bss/pull/83