“For every complex problem there is an answer that is clear, simple, and wrong..”
H. L. Mencken.
In yesterday’s blog, we discussed the law of cascading problems where if we have data accuracy levels as follows:
- Locations are 90%
- Pits are 95%
- Ducts are 90%
- Cables are 90%
- Joints are 85%
- Patch panels are 85%
- Active devices are 95%
- Cards are 95%
- Ports are 90%
- Bearer circuits are 85%
then the success rate of end-to-end circuits through all of these objects is less than 30% (ie multiply all these percentages together).
One of the simplest ways to build a higher level of resiliency via imperfect data is to reduce the amount of cascading (ie simplify the data by reducing the number of relationships).
In the example above, it’s fantastic to know all the outside plant relationships (ie pits, ducts, cables, joints, patch-panels) for fault-finding purposes but outside plant data is notoriously difficult to maintain (it generally has no programmatic interface to facilitate electronic audits so manual audits are required).
So the challenge for the OSS experts dealing with this scenario is:
- Do I model outside plant as a dotted-line to increase E2E circuit success rates and reduce the effort in manicuring the data; or
- Do the fault-identification benefits of outweigh the effort of maintaining the data and coping with the E2E circuit fall-outs
Furthermore, the larger the data volumes, the bigger the remediation task. For example, it might be easy to choose option 2 if you have a local network and infrequent customer network change but rely heavily on your outside plant (eg utilities). It becomes much harder to accommodate option 2 if you have global infrastructure and large amounts of change in your customer data sets (ie E2E circuits) (eg tier-1 CSPs).Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email