Showing posts with label Self Driving Networks. Show all posts
Showing posts with label Self Driving Networks. Show all posts

Monday, April 10, 2023

The Mother of All Network Architecture Frameworks - MONAF

 


In case You have been into the IP Networking Industry for long enough, You would have probably come across:

  1. The Holy "OSI Model"
  2. ISO Model
  3. TCP/IP Model
  4. RINA Model by John Day
  5. Hour Glass Model by Micah Beck
  6. SOS Model
  7. OODA Loop for Security

While all of these models are helpful in some form and shape, They often help us answer some of the very few questions we generally have as Network Architects, Designers & Engineers but often lacks:

- A bird eye view of Network Architecture as a whole

- A layered approach to go deeper into details & nuts and bolts while still allowing abstractions to work to meet requirements of different audience

- Fill the gap between understanding of Network among - Business, Architects, Designers, Engineers

- Address both functional & Non-Functional requirements

- Work as a guiding compass to address - "Known Knowns", "Known Unknowns", "Unknown Unknowns"

- Stitching together all of the information in a more tangible & informed way

- Last but not least, helps understand your specific constraints beside looking at everything across its life cycle

If you have been there and often relying on your head to hold so much of information but yet unable to put it into a structural frame, You might just want to give this a try.

In the subsequent posts we will uncover different layers and that too 5 layers down in terms of details (From 10,000 feet to 100 feet journey)

HTH...

A Tech Artist ðŸŽ¨

Monday, October 18, 2021

Facebook Down Event - The dilemma of a CTO, Black Swans & Fallacies of IBN


While Facebook just seem to have published somewhat a lengthysh version of root cause analysis (https://lnkd.in/guptSB3u) for public about their recent worldwide network outage that made - Facebook, WhatsApp & Instagram completely cut out from internet, it must have raised some concerns in the worldwide CTO and CIO community.


Since historically they have been told that and what pretty much every vendor in networking industry is preaching about in terms of different ways & methods (Systems, People & Processes) to avoid such circumstances are bright & magical ideas such as:

- Automation & Orchestration
- Intent Based Networking (IBN)
- Software Defined Networking (SDN)
- Centralized Controllers
- Data Models
- Automated Test & Deployment Pipeline with Unit Tests (aka CICD)
- Reliability & Resiliency Engineering
- AI/ML OPS
- Network Design Principles (Hierarchy, Swim Lanes, Segmentation etc.)
- Streaming Telemetry
- Observability Tools
- Bright Engineers
- Testbed Equipment
- Network Modelling & Simulation Tools with Formal Verification
- Rigorous platforms testing (HW/SW)
- Single Source of Truth
- Chaos Engineering
- BCP Plan
- Correlation Tools & what not

But assuming if you go via this checklist, Facebook would probably have all checks against all these items and so would be any of the FAANG company at this stage.

" So assuming you are a CTO or CIO, what would you suggest as possible next steps to your CEO & board if you have been called up this week for a meeting to discuss about how do we ensure such events don't happen in our network ? "

So lets park the above question for a while and move to what reactions we have seen so far.

1. The usual suspect is, bad things happens and everything breaks at some point, focus on RCA...move on and ensure it doesn't happen again

2. Network Architects favorite answer.... " it depends "

3. Was it a People or Process issue ?

4. The conspiracy theory that FB was under a Cyber attack which they don't want to disclose

5. Blame BGP (the easy suspect) … interestingly we got 10000+ new BGP experts on twitter and LinkedIn overnight :) beside the fact that 99% of them hardly understand the BGP details since none of them looked at the problem from perspectives of "unintended consequences", "ripple effect", "interaction surfaces", "failure domains", " & so forth beside all the pointers list I shared above. So let's say blaming BGP was an easy pick for the "ghost" network engineers. Beside the fact that RCA published by Facebook doesn't cover any technical details either.

6. "The Black Swans" - This is an interesting one and less talked about fact in case of this outage. While some may claim this was just one of those black swan events, I personally seriously doubt that and more so in the absence of a detailed RCA.

The answers lies in Systems thinking, Anti fragile networks, deep expertise, people's attitude towards excellence, and willingness to collaborate under uncertainty.

Further Readings:
















HTH...

A Network Artist ðŸŽ¨

Saturday, March 27, 2021

Are Networks Really Complex ?

A recent short article from an IBN Evangelist brought up an interesting point about how complex modern networks really are and how IBN (Intent Based Networking), assuming SDN is dead, would potentially transform your network and equip you with enough insight by virtue of using AI & ML in such a way that overall network will be much more predictive in nature & AI/ML magic will take care of all complexity.

Wow...by now if You are not sold to this such a great marketing sales pitch....I'll be disappointed 😈

But as an Individual Network Consultant & as a Network Architecture practitioner, I often help my Clients to look deeper under the hood and uncover insights which helps them transform their networks in such a way that's much more realistic and much more practical in nature.

So let's start uncovering some details around " What makes our Networks really Complex? " to understand the problem space at its core and not just at its surface and bring this idea to " How to go about this idea and bring it to reality".

Business Layer
+++++++++++

Often business people based on tons of marketing from vendor believe that the technology is and was the way to transform their businesses. And don't get me wrong but that's true for most part at it's surface. But on the flip side what they don't get it is that the Technology is part of solution and not heart of solution. At it's core you still got to get it right from People & Process perspective. That's one of the reason why over 80% of Digital Transformation projects which are technology centric often gets failed and they get failed miserably from ROI perspective.

To simplify this I often quote this to my friends and colleagues " In theory your Smart phone has more computing power than Apollo 11 which took men to moon, but doesn't that mean you know completely how to harness this power still today to it's potential"

So why most technology driven Digital Transformation Projects really fail today ?

1. Short Term Thinking 

2. The Technology Fallacy - At its core in any business its the People make the difference not tech

3. Absence of Collaboration Culture - Start building trust at its core

4. Imposed Fake " Innovation " Culture - It's a big one in big Orgs.

5. Vendor driven Tech & Innovation - Vendor religions are still ruling the world

6. Most Valuable yet underrated skills:

    A. Common Sense
    B. Listening
    C. Hard Work
    D. Framing the Problem correctly and map it to its roots 
    E. Hypothesis Testing of your ideas, thoughts and frameworks 

7. Fake Data Analytics - People using biased data & statistical models to prove their point and sound intelligent

8. The Generation Gap - This is actually a very big one

9. Absence of a comprehensive & mature "OEM/Partner/Solution benchmarking & onboarding process"

10. Moving away from Vendor A to Vendor B to save cost - If it's just CAPEX, just don't do that

11. OPs & Engineering are usually not invited in Business reviews as they seem irrelevant to many business folks still today

12. Most cross skill programs are fake and misleading

13. Too much of belief in - Cloud, SDN, IBN, Automation and the saga continues...

14. Believing that it's eventually the APP that matters and not the underlying tech...remember it's still Information Technology (IT) and not App Technology (AppT)

15. The urgent culture - Remember that most urgent things are unimportant 

16. Let's not focus too much on those MBAs and CAs running companies at this point 😇


Technology
++++++++

1. The fake Application Aware Networking notion - It doesn't exist...Period ! 

2. Most Networking Managers & CTOs are still not investing into Core Network Architecture & Design skills and keep believing in OEM's Voodoo magic

3. Lack of Test bed environment -  Over 90% of organizations still don't own dedicated Test bed environment that can validate those fresh configuration & configuration changes by replicating your production network at scale

4. The fake Architectural Skills - Just because someone owns an Expert Level networking certification or tons of experience on resume doesn't mean they own strong architectural & design skills

5. The old school & immature Interview Process

6. Common misunderstanding that if someone is working on new cool shiny tech, they are innovative

7. Tech people still believing understanding "How business really works" is boring & unimportant since that's why they chose to become Engineer 

8. Vendor & Technology/Solution religions 

9. All you need to pick on a new vendor and it's solution is that 3-5 days of training - Really ?

10. Tech folks still thinking in SLAs which BTW is a business metric and not a technology metric to begin with while still keep ignoring SLOs and SLIs

11. Tech Folks not being able to articulate changes they would need around People & Processes when introducing new shiny Tech, So how you handle change management in your SDN solution world and most importantly how different it is compare the what it was before introducing SDN ?

12. Outdated and non-standardized network documentation 

13. The One Book Mentality - Not sure how many times and how often I came across his mentality. Usually the moment you ask a regular network engineer for example "How should we go about implementing IPv6 in our network ? ", the common set of responses you will hear back would be:

 A. Let me read a good book on this and come back
 B. Tell me what you want me to implement
 C. Let me find the IPv6 deployment best practices document

But often they miss the point of first get a full understanding of following to fully understand the problem statement:

 A. Why we are doing it in first place ?
 B. What problem we are trying to solve ?
 C. What changes we would need to make across Tech, People & Processes ?
 D. What are my alternatives to meet same goal ?
 E. How we would measure our success and more importantly our Business will measure it for us ?

14. Most Networking tech folks are still madly in love with Vendor stories & narratives when it comes to learning

15. Learning a product doesn't make You an Engineer, understanding how tech works behind the scene does

16. No tight & close feedback loop between Design & OPs team

Standard Bodies Failures 
++++++++++++++++++

Like every other Industry, we got IEEE, IETF, MEF & ONUG and bunch of other standard governance bodies in Networking. But how robust their process are at their core ?

1. In most standardization documents, its not mandatory for You as author to talk through entire life cycle bits of your proposed protocol or solution. Always remember that building something new is perhaps always the easier part compare to operating it for next 5 years or so on daily basis. Under the hood the problem is very similar to " Why most hackathons are useless " for most part despite being chosen as one of popular tools to drive innovation. 

2. Most RFCs are just boring lengthy texts...Not saying all of them since I am in love with RFC 1925 and RFCs do add lot more details in the equation, but why can't those be written in more interactive manner in a modern world where people predict that visual and AR/VR based learning is going to be the future despite we ignore based on evidences that people retain visual memories for longer. Perhaps they put on a dedicated track around this lead by Dan Roam at some point understanding its importance.

3. Networking & even Expert Level certifications only focus on Tech aspect and are still far from reality you have to face in real world...ping me to discuss those numerous examples 😇

4. Security aspects of  any new protocol or solution is still an after thought in most cases

5. Lack of metrics defined to measure the quality of any protocol, solution & tech

Let's keep Complexity Theory & " Complex vs. Complicated " for some other time 👽

So what do you think now about " Are Networks really Complex ? "

Further Readings:






HTH...
A Network Artist

Thursday, November 23, 2017

Few Questions You Should Ask Your fav Self-Driving Networks Vendor



Since everyone is talking about Intent Based or Data Driven Networks for a while, I spent some time recently going through work done by Cisco, Juniper, Apstra, Veriflow & Forward Networks in the Area of Intent Based Networking AKA Data Driven Network AKA Self Driving Networks.

So far seems like everyone is trying to solve the different sets of problems with some overlap. Also mostly they use ML/AI in some form or shape. But my assumption is Algorithms under ML/AI umbrella are proprietary (Secret Sauce) for most part with little details available publicly.

Also the common buzzword " Automation " would mean totally different set of things in such world IMHO. So In the mean while below are quick questions you can ask to your fav. OEM vendor guys next time you go for a product/training session around same :) to get more clarity.

> What they really mean by Intent Based Networking ? (Everyone has some different definition for this)

> How do they describe the Intent to the system ?


> How do they map Business Intent & Technology intent and describe it to system ?


> Does the system translate the intent into configurations/policies on it's own or they use some sort of policy language for admin to be used to describe Business and Technical intents to system ?


> What sort of checks that system has to verify described intent and returns feedback to admin ?


> Are there any dry run capabilities into the system ?


> How they maintain the consistency for the intent throughout the life-cycle - Plan, Design, Deploy, Verify, Operate & Optimize ?


> How Intent gets documented and updated over time ?


> How do you describe intent for things like Backup path etc. ?


> How do they create visualization for Intent to present to management & Network Architects ?


> How to modify Intent over the period and what would be the touch points ?

> How their Intent Based Networking is different from policy based network (Remember Promise Theory that ACI Works on) ?


> OEMs AI/ML/DL & Algorithm Details (I doubt they would be willing though) ?


> How do they control AI and ML since they can create their own algorithms and break this closed loop over time ? (Remember what happened with Facebook's AI attempt)


> How do they track changes in such networks such as created by AI/ML dynamically ?


> How does AI/ML understand if it's actual pattern change in network during attack or just traffic pattern change driven by an special event such as heavy load on billing systems during financial year end for example ?


> Do they use graph approach (By building Network Graph such as Link State Protocol Does) or they use relation approach (Such as describing links with properties ) across network components to describe intent ?


> Which Data model they follow to describe intent and push/change configurations ? (Also understanding Data Normalization Techniques & Data Model details will be key to understand support across multiple vendors )


> Do they support APIs to describe intent and to work with other systems as part of larger eco-system ?


> How do they deal with scale ? (Everyone has different sets of limitations here)


> How do they deal with mix of legacy networks & Cloud Networks in hybrid environment ?


> How do they handle Leaky abstraction & Grey failures ?


> How do they operate across multi OEM platforms with different HW/SW capabilities ? (Which essentially means they must form a eco system with selective set of partners as it's going to be an ongoing effort)


> Does the intent description part only takes care of configuration side of things or they even go further with Network Design as part of another abstraction layer ?


Let's park Telemetry related stuff of solution for a while which is another area to dig into in order to fit all pieces together.  :) (Maybe another follow up post)

HTH...
Deepak Arora
Evil CCIE