Correlation between network complexity and troubleshooting time (and resources)...
Dear BCOP community, While traveling the world and speaking with different operators - what I hear is some sort of need to have a document or "study" of ways to simplify your network in order to cut down costs of owning, running and mainly troubleshooting it. We can hear lot's of presentations (mainly from vendors and also young enthusiastic admins that sees complexity as a challenge) how to introduce new shiny features X that would do Y to your network, but also make it more complex to maintain and troubleshoot, specially makes troubleshooting longer when disaster happens. Operators started to understand that "less is more", but have troubles escaping the influences from the past, that are keeping them tied in complexity business, so the need emerged to put together some content that would explain pros and cons of complexity, how to weight and balance complexity vs. needed features and functionality and also the correlation of increased complexity on longer and harder troubleshooting. I had a quick word with some "usual suspects", but I would like to ask BCOP community if there's any interest in working together to pull this through and shed some light for new (and old operators) that making your network as complex as possible is not necessarily the best idea. If there is some interest - any volunteers to work on this subject/topic? See you all at BCOP TF meeting in London on Monday at 18:00, the first day of RIPE69 meeting ;) Cheers, Jan
Hi Jan, I have seen papers from vendors before on this, such as http://www-05.ibm.com/uk/juniper/pdf/200249.pdf I am keep on this ideaology of keeping things simple as possible to reduce the surface area of potential human error. This is of course caveated against (i) unavoidable complexity because that's the service we've sold to a customer or just simply the service the customer requires and (ii) more densely interconnected networks can't avoid a minimum level of complexity. We can catch up at RIPE if you'd like? Kind regards, James.
On 21/10/14 13:46, James Bensley wrote:
Hi Jan,
Hi,
I have seen papers from vendors before on this, such as http://www-05.ibm.com/uk/juniper/pdf/200249.pdf
I am keep on this ideaology of keeping things simple as possible to reduce the surface area of potential human error. This is of course caveated against (i) unavoidable complexity because that's the service we've sold to a customer or just simply the service the customer requires and (ii) more densely interconnected networks can't avoid a minimum level of complexity.
Would you like to discuss this at BCOP meeting? We could spend few minutes on this topic as apparently it's a interesting one for wider audience. The best possible outcome of BCOP TF meeting would be if we could get a small group of co-authors that would start documenting this topic... I learned that you start with a title and table of content and then everything is much easier :)
We can catch up at RIPE if you'd like?
Sure, see you in London ;) Cheers, Jan
On 21 October 2014 14:18, Jan Zorz @ go6.si <jan@go6.si> wrote:
Would you like to discuss this at BCOP meeting? We could spend few minutes on this topic as apparently it's a interesting one for wider audience.
The best possible outcome of BCOP TF meeting would be if we could get a small group of co-authors that would start documenting this topic... I learned that you start with a title and table of content and then everything is much easier :)
Well I don't want to get up on stage and talk about it if that's why you mean :) I swear alot and don't really hold it back very well. Happy to talk in person though and/or a beer of course!
We can catch up at RIPE if you'd like?
Sure, see you in London ;)
Cheers, Jan
Sure, see you there! Cheers, James.
participants (2)
-
James Bensley
-
Jan Zorz @ go6.si