cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
39
Views
1
Helpful
2
Replies
Highlighted
Cisco Employee

Device Models/Service Models for Cross Domain Orchestration

All-

Are there any white papers or documentation on how the device models and services modules for cross domain orchestration work (or will work).  I understand how devices models work when you are connecting to a network device (router, switch, etc) and it stores model of the configuration in the DB.  However, how exactly does/will this work with platforms like ACI, WAE, etc?  I highly doubt we would store the entire “configuration” of these platforms, and it would be more of mapping of REST commands between one system an the other.

Any help would be appreciated.

Riggs Goodman III

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Cisco Employee

 

Riggs,

Are there any white papers or documentation on how the device models and services modules for cross domain orchestration work (or will work).  I understand how devices models work when you are connecting to a network device (router, switch, etc) and it stores model of the configuration in the DB.  However, how exactly does/will this work with platforms like ACI, WAE, etc?

 

Currently they are treated just like a new kind of "device", with a device model, NED, etc. This is not the only option, but it seems to make sense here.
 

I highly doubt we would store the entire “configuration” of these platforms, and it would be more of mapping of REST commands between one system an the other.

 

What is the reason you think so? There could be issues with this approach, and if have some specific insights to share, I'd be interested to understand more.

 

There are alternative approaches possible, e.g. continuous east-west syncing, or treating the WAE/ACI/... as an external database. This would have certain benefits, but would require full transactional semantics to be implemented on WAE and would have HA implications.

 

Best Regards,

 

/jan

 

View solution in original post

2 REPLIES 2
Highlighted
Cisco Employee

 

Riggs,

Are there any white papers or documentation on how the device models and services modules for cross domain orchestration work (or will work).  I understand how devices models work when you are connecting to a network device (router, switch, etc) and it stores model of the configuration in the DB.  However, how exactly does/will this work with platforms like ACI, WAE, etc?

 

Currently they are treated just like a new kind of "device", with a device model, NED, etc. This is not the only option, but it seems to make sense here.
 

I highly doubt we would store the entire “configuration” of these platforms, and it would be more of mapping of REST commands between one system an the other.

 

What is the reason you think so? There could be issues with this approach, and if have some specific insights to share, I'd be interested to understand more.

 

There are alternative approaches possible, e.g. continuous east-west syncing, or treating the WAE/ACI/... as an external database. This would have certain benefits, but would require full transactional semantics to be implemented on WAE and would have HA implications.

 

Best Regards,

 

/jan

 

View solution in original post

Highlighted
Cisco Employee

-----Original Message-----
From: Carl Moberg (camoberg)
Sent: Friday, September 25, 2015 8:41 AM
To: Riggs Goodman (rigoodma)
Cc: Jan Lindblad (jlindbla); service_orchestration(mailer list)
Subject: Re: Device Models/Service Models for Cross Domain Orchestration

Riggs,

> On Sep 25, 2015, at 2:28 PM, Riggs Goodman (rigoodma) <rigoodma@cisco.com> wrote:
>
> Jan-
>
> Thanks for the response.  I was thinking more along the line of east/west sharing of information.  But, I’m curious if we would have too much of that or rely on the application or OSS/BSS sitting on top of NSO to share that data with each platform that might need it.
>
> I guess that’s for CDO and some of the BUs to tell me what the plan is
> ;-)

My experience is that its first and foremost up to the customers and their challenges to guide us. The original location of, and sharing policies around any type of data is largely driven by the use case and customer expectations.

The somewhat new approach that NSO brings to the CVG portfolio is that it is an open platform. A set of tools if you like. And the field drives the direction on how to apply it (including service application development) per customer engagement together with an appropriate mix of customer developers, AS and third-part SIs. CDO and CVG concerns themselves with building a solid and easy to use platform including components and tools to support it. But the actual development of end-user solutions happen outside of CVG.

> If we are sharing information between platforms via NSO, it then comes down to what information needs to be shared.  If it is, as an example, topology information in WAE, that’s minimal of what needs to be modeled in NSO, compared to all the other information available in WAE.

As long as it solves the customers needs and use cases, that sounds good.

> Would like to get the BUs thoughts on whether you are building NEDs to
> support some of this east/west communication or is more north/south

We are both improving APIs and tooling for east-west integration (in the way I interpret the term) and NEDs for the types of integration that can benefit from the model-driven, transactional nature of the NEDs.

Content for Community-Ad
Cisco Community August2020 Spotlight Award Winners
This widget could not be displayed.