cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

127
Views
0
Helpful
1
Replies
khgrant
Cisco Employee

NSO and WAE Integration for Service Activation

 

All-

 

Is there a NED for pulling topology information from WAE?  If so, what are the capabilities with it, i.e. what information can it pull?  With all the integration that is going between WAE and NSO, my thought is possibly using WAE to help make service activation more dynamic, instead of statically needing to select which nodes stitched PWs need to go to.

 

Riggs Goodman III

 

1 ACCEPTED SOLUTION

Accepted Solutions
khgrant
Cisco Employee

 

Hi Riggs,

 

If you’re just chasing topology information from a single IGP AREA, then BGP-LS & ODL/OSC is an option for that.

 

If you chasing multi area IGP topology information, then WAE is suited for this, as the plan files contain single AS model.

 

Inter-AS models are not supported in WAE by default, but can be built, with some assistance from the WANO team or an experienced field engineer.

 

As for talking to WAE from NSO, and getting service information relating to existing L2TPv3 and LSP’s you can get most of this from NSO just as easily using things like XPATH etc.

 

WAE adds a lot more value when you start talking about path computation or dependency/risk analysis.

 

Understanding connectivity between nodes, their neighbours etc.

 

The interface at the moment is REST API Based.

 

In theory you could save the plan file in the file system and use mate_sql binaries to perform the same action on a WAE server as an alternative as well.

 

There are a couple of AS engineers in APJ that have built JAR files that parse the WADL XML for WAE REST API convert them to classes in a Java JAR.

 

These JAR are then accessed as a Data Providers in NSO, allowing your service models to talk to WAE API’s directly.

 

The WADL needs to be parsed and compiled per WAE / NSO version pair as the WADL & API’s change in each WAE release.

 

This is not a NED in that sense.

 

The WANO BU is looking at producing a Netconf interface for WAE API for this reason, this is separate to NSO BU responsibilities.

 

That Netconf interface would effectively provide a compiled NED, which is what most AS teams are chasing.

 

The output data from that NED would effectively be operational data as I understand it, and this becomes a separate issue when dealing with parsing that operational data.

 

The return path hops for an LSP optimization as an example would be an XML/JSON string, that you need to parse yourself in NSO and then insert into a LSP explicit path Service Model.

 

If you want the contact details of those AS engineers that have done this please message me offline.

 

Those people are rather busy so will likely only be able to provide you guidance and some examples of what they have done.

 

If you want to understand what you can pull from WAE, you should look at the DEVNET site and review the API sets that are available from WAE:

 

These are the SDN API’s, for path computation/optimisation and demand calendaring etc.

 

https://developer.cisco.com/site/wae/documentation/api-release-6-2/platform-rest-api/

 

These are the Plan file API’s for element, service and plan file manipulation

 

https://developer.cisco.com/site/wae/documentation/api-release-6-2/design-rest-api/

 

These ate the WAE Live statistics, reporting and trends data API’s

 

https://developer.cisco.com/site/wae/documentation/api-release-6-2/live-rest-api/

 

 

 

- Regards Martin

 

Martin Thygesen

 

View solution in original post

1 REPLY 1
khgrant
Cisco Employee

 

Hi Riggs,

 

If you’re just chasing topology information from a single IGP AREA, then BGP-LS & ODL/OSC is an option for that.

 

If you chasing multi area IGP topology information, then WAE is suited for this, as the plan files contain single AS model.

 

Inter-AS models are not supported in WAE by default, but can be built, with some assistance from the WANO team or an experienced field engineer.

 

As for talking to WAE from NSO, and getting service information relating to existing L2TPv3 and LSP’s you can get most of this from NSO just as easily using things like XPATH etc.

 

WAE adds a lot more value when you start talking about path computation or dependency/risk analysis.

 

Understanding connectivity between nodes, their neighbours etc.

 

The interface at the moment is REST API Based.

 

In theory you could save the plan file in the file system and use mate_sql binaries to perform the same action on a WAE server as an alternative as well.

 

There are a couple of AS engineers in APJ that have built JAR files that parse the WADL XML for WAE REST API convert them to classes in a Java JAR.

 

These JAR are then accessed as a Data Providers in NSO, allowing your service models to talk to WAE API’s directly.

 

The WADL needs to be parsed and compiled per WAE / NSO version pair as the WADL & API’s change in each WAE release.

 

This is not a NED in that sense.

 

The WANO BU is looking at producing a Netconf interface for WAE API for this reason, this is separate to NSO BU responsibilities.

 

That Netconf interface would effectively provide a compiled NED, which is what most AS teams are chasing.

 

The output data from that NED would effectively be operational data as I understand it, and this becomes a separate issue when dealing with parsing that operational data.

 

The return path hops for an LSP optimization as an example would be an XML/JSON string, that you need to parse yourself in NSO and then insert into a LSP explicit path Service Model.

 

If you want the contact details of those AS engineers that have done this please message me offline.

 

Those people are rather busy so will likely only be able to provide you guidance and some examples of what they have done.

 

If you want to understand what you can pull from WAE, you should look at the DEVNET site and review the API sets that are available from WAE:

 

These are the SDN API’s, for path computation/optimisation and demand calendaring etc.

 

https://developer.cisco.com/site/wae/documentation/api-release-6-2/platform-rest-api/

 

These are the Plan file API’s for element, service and plan file manipulation

 

https://developer.cisco.com/site/wae/documentation/api-release-6-2/design-rest-api/

 

These ate the WAE Live statistics, reporting and trends data API’s

 

https://developer.cisco.com/site/wae/documentation/api-release-6-2/live-rest-api/

 

 

 

- Regards Martin

 

Martin Thygesen

 

Create
Recognize Your Peers
Content for Community-Ad