Semantic overload on residual_bandwidth link property

[italovalcy]

According to the Topology Data Model spec, the residual_bandwidth is defined as:

The residual_bandwidth attribute describes the average bandwidth available for the Link object. The representation of the residual_bandwidth must be provided in percentage from 0 to 100 of the bandwidth attribute. For instance, if bandwidth is 40Gbps and the Link average utilization is 25Gbps (or 62.5%), the residual_bandwidth must have value 37.5, meaning 37.5%. The OXP operator is responsible for defining the time interval to be based, for instance, the last 30 days, the last day, or the last 12 hours. This specification suggests that residual_bandwidth to be based on the last 7 to 14 days for better accuracy and decision making.

This means that the residual_bandwidth will be updated by OXP according to their local policy and based on measured bandwidth utilization of the link.

On the other hand, PCE is using residual_bandwidth property with a "semantic overload" to also store information about "residual reserved bandwidth".

With this scenario, we may ended up in situations where:

0. Execution starts with Link.residual_bandwidth = 100%
1. A L2VPN request is made to use 90% of the link. Then PCE updates Link.residual_bandwidth = 10%
2. A Topology update from OXP is received, and the OXP sets the residual_bandwith to 100% (because, for instance, at that point the link bandwidth was reserved but it is not being used -- or another scenario where OXP is not really monitoring bandwidth utilization at that point)
3. Upon receiving the topology update of step 2, PCE updates (replace=True) the Link.residual_bandwidth = 100%
4. A DELETE L2VPN request is received for the L2VPN created on step 1 (min_bw = 90%). Then PCE updates Link.residual_bandwidth = 190% (!)

Even though we can discuss establishing a ceil function to Link, there are corner cases where this won't be valid.

We need to remove this semantic overload and store information about link bandwidth reservation in another attribute

[YufengXin]

This was well understood. (1) The question was if OXP actually updates this attribute accurately. My understanding was that it didn't, just like the case of available range. (2) Architecturally speaking, the QOS metrics update from OXPs should go through the BAPM channel.

For now just let sdx-controller/pce does this job.