cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
135
Views
1
Helpful
5
Replies
khgrant
Cisco Employee

NSO to work with openstack GBP

Hi team,

 

   GBP is getting popular in openstack deployment, actually it’s the most popular way when integrate with ACI, however we check ESC 2.1,it doesn’t  support GBP model, so we can’t use NSO to call ESC and call openstack eventually,do we have a solution for NSO to work with openstack GBP? Or is there an openstack NED supporting GBP?

 

   Thanks!

 

1 ACCEPTED SOLUTION

Accepted Solutions
khgrant
Cisco Employee

I think we need to think about the architecture here a little.

 

 

  1. Generally, with NSO, we follow ETSI NFV reference. So we have Higher-Order-Service (outcome) à NSO à ESC à VIM. From a service layer perspective, the service consumer doesn’t really care exactly how the service gets implemented in the network.

    I think the flow that you referring to is: 

  1. OpenStack (GBP) à NSO à Some DC Controller (APIC/VTS/3rd Party)

 

 

Following from what we did for the Neutron ML2 plugin mechanism, currently we have a “service-package” called “openstack” that is bundled with the NSO installation. Here OpenStack neutron plug-in will call API (exposed by the openstack service-package) and then in NSO we map that to whatever we have in the network-layer (APIC etc.). This “openstack” service-package can easily be extended to support GBP models. Then this can be mapped to lower layer network constructs of choice.

 

View solution in original post

5 REPLIES 5
khgrant
Cisco Employee

I think we need to think about the architecture here a little.

 

 

  1. Generally, with NSO, we follow ETSI NFV reference. So we have Higher-Order-Service (outcome) à NSO à ESC à VIM. From a service layer perspective, the service consumer doesn’t really care exactly how the service gets implemented in the network.

    I think the flow that you referring to is: 

  1. OpenStack (GBP) à NSO à Some DC Controller (APIC/VTS/3rd Party)

 

 

Following from what we did for the Neutron ML2 plugin mechanism, currently we have a “service-package” called “openstack” that is bundled with the NSO installation. Here OpenStack neutron plug-in will call API (exposed by the openstack service-package) and then in NSO we map that to whatever we have in the network-layer (APIC etc.). This “openstack” service-package can easily be extended to support GBP models. Then this can be mapped to lower layer network constructs of choice.

 

View solution in original post

 

   Basically we want to keep this architecture 'Higher-Order-Service (outcome) à NSO à ESC à VIM’ when it comes to GBP,because our case is a NFV case.That’s to say:

 

   Higher-Order-Service (outcome) à NSO à ESC à Openstack(GBP)->ACI

 

   Is it doable?

 

   Thanks.

khgrant
Cisco Employee

BTW,we have openstack(GBP) integrated with ACI already,it’s up and run.

khgrant
Cisco Employee

You will have to check with the ESC folks (copied) to see if they expose some “normalised” version of GBP to the North. Note that ESC is VIM agnostic, so they will have to normalise GBP in some way.

 

 

Or at least they can tell you if it is on their roadmap.

 

 

The other option is to go directly to OpenStack (check OpenStack NED) and configure the relevant GBP constructs.

 

khgrant
Cisco Employee

Hi,

 

 

Do we think GBP will be more popular that Heat API? I saw requests on Heat in a number of RFI/RFP but never about GBP.

 

 

To be fair with the ESC team, we cannot ask them to support and maintain every API OpenStack will come-up with. In the NFV world, we need an API that will help us track and understand which resources we are allocating. IF we use a very obscure API in OS, we loose visibility and then monitoring becomes an issue. Enterprise (main ACI focus) is different.

 

Create
Recognize Your Peers
Content for Community-Ad