NSO configuring peer routers

[franjorge]

Hello,

This is more a best practice or architectural question. I have seen several services that configure a PE and their corresponding CEs. In those scenarios, you have one instance of the service associated to each of the PEs. In each of those instances you have the information of the CEs associated to the corresponding PE and the instance of the service may configure the PE and the CEs connected to it.

However, I am wondering what would be the best approach to build services that involve routers in the same hierarchical level.

For example, let's say you want to create a service that automatically configures the interfaces between the routers in the core of your network, the P routers. Imagine the core of your network is built up of three P routers (P1, P2 and P3) and they are all connected to each other.

First you create an instance of the service for P1, where you state that it has an interface to P2 and another interface to P3. That instance of the service configures the corresponding interfaces in P1, P2 and P3. However, when you create the instance of the service for P2, the interface between P2 and P1 should not be configured again, neither in P1 nor in P2, since it has already been configured by the first instance.

You could just decide to not add P1 to the neighbors of P2 in the P2 instance, but this approach would be a bit messy. You would never know where the information about a connection is stored (in the example, it could be in the P1 instance or in the P2 instance).

How would you deal with such cases?

Thanks.

Fran

[lightfep1]

You could make it so that each interface is a different instance in you service model with a couple of extra fields to identify the remove device/interface so you know when you are working on the interface where it goes to. 

I did a project for managing our service policies across our core node and made it where the key was the device-name interface type (TE,GIG) and the interface ID, then some options for the engineering teams to pick to apply the correct profile. This made it so each interface is an independent instance and can be adjusted individually of each other, this included updates to the policy-map.

As I see it, you really got two main choices, one that controls both ends as one service or each interface as an independent service. If there is not a lot of variation, you can do it so that each service instance controls both endpoints, but if your network engineers are like mine, they want options and lots of them, with constant changes and updates. So by making each interface a different instance of the service it made making updates and changes more controlled.