Awww "Tell me what you want, what you really, really want from SD-WAN"

I like your topic--specific enough to draw some hope, broad enough to be attractive to many folks.  What I want/need in monitoring SD-WAN includes, but isn't limited to:

• SD-Monitoring.  If I'm going to do anything "SD-WAN-ish", I don't want to do physical hardware setups, spending time doing physical changes in my environment to monitor new SD-WAN flows, manually building new views for it, resulting in many one-offs that only I can recall or support.  Nope, I want something that will:
  • Detect new flows for me without any action on my part, and display them.
  • Automatically discover:
    • New devices and their ports
    • New pseudo wires and new virtual flows
    • New circuit ID's, service providers' names, and rated speeds
    • New virtual and physical end addresses
• It will automatically add those new circuits & flows to a page dedicated for SD-WAN, using the data about circuit ID's and service provider names, street addresses, even telephone numbers to call when a site or service is experiencing problems or needs more resources to accommodate growth.  Without my manually building the page.  And it can't just display every discovered interface when I only want to see WAN throughput; it has to be smart enough to only show WAN services.   Sure, let me edit it and move things around to make sense, but let's have this automated 100%.

SD-WAN frequently uses equipment built for Zero-Touch-Provisioning--it can even be synonymous with ZTP on occasion, and that means monitoring must mature to detect and display useful information without intervention or touch by a Network Analyst.

I want to save my organization serious dollars (50%?  80%?) in annual WAN and Internet fees, while simultaneously increasing reliability and up time for my customers' network needs.  We're doing this today as part of COVID-19 resource recovery, and it's having great results, but it requires too many man-hours.  The future of SD-WAN funding and success means using an NMS to automatically accomplish what we have to do manually today.  Things like:

• Automatically providing charts or tables that display SD-WAN WAN and Internet peak, average, and 95th percentile utilization, by week, month, and year, with only a few clicks.  This info needs to be available in Reports that are automated or easily adjusted for time periods & sites. And it can't have LAN port data--only SD-WAN interfaces need to be reported (but LAN ports still need to be monitored and to have alerts show up in case they have issues).
• Trending analysis that goes back three years.  That's going to mean a database warehouse that can be mined instead of us limiting data to the last 6-weeks to one year to save database size and to keep the NMS from becoming much slower.  
• Filtering out unnecessary interfaces intuitively, automatically showing only useful information.  (Do you get the idea this is a big deal to me?  I want to monitor all ports, but I want a great NMS Report or Widget or Page to be populated automatically only with WAN ports and their stats.)
• Displaying data for pseudo wires that automatically adjusts as routing paths change based on availability, path cost, latency, etc.
• Quickly building automated views that show which circuits are underutilized or saturated, based on average, peak, and 95th percentile charts or tables.  We'll use that to justify downsizing underutilized services, or buying bigger pipes.  The latter is something we've always done, but the former is new to us.  Showing us where we've bought more circuit than we need lets us downsize it or require the provider reduce their bills for it.
• Letting us easily see where expensive (business class) synchronous circuits can be replaced with home-class asynchronous Internet connections that allow us to leverage costs by dropping a WAN service and replacing it with a broadband circuit with a ZTP solution like a Meraki VPN appliance.

Today I look at a dedicated site-to-site services between my remote offices and see we're spending millions of dollars annually on WAN services.  Tomorrow I want to see those services' costs closer to a few hundred thousand dollars.  It's being accomplished by shopping for broadband services local to the remote sites, dropping in a Meraki, setting it as the primary path for traffic back to the main office, and leaving the legacy WAN link and hardware in place until that circuit's service contract expires.  During that period we have the benefit of a dual-path / dual-provider resilience, and we benefit by having potentially MUCH greater download speeds for the site, at a fraction of the cost of the synchronous business-class WAN service.  When contract renewal time arrives, we'll be able to require the business-class service provider lower prices and increase throughput.  If they don't, we discontinue that circuit by removing it from the contract, and simply use the broadband.  An example:

A remote business office X has a 20Mb xb20Mb business class WAN service to connect to the home office.  The service costs $1500/month, or $18,000/year.

I reached out to a local broadband provider in that city and learned they have fiber WAN service already in the building hosting our office X.  The provider offered to give us 1G synchronous service for $200/month, or $2,400/year.  

I had them set up the new service, I installed a Meraki that sends that traffic to the Internet and to our home office via a VPN tunnel instead of a dedicated path.

Latency increased from 12 milliseconds to 25 millseconds--that's a down side, but we can live with it.  WAN costs decreased by 87%.  Throughput capability increased by 5000%, enabling them to provide new, more bandwidth-intensive services to their local customers, resulting in greater revenues through gaining more work.  The fact that employees stopped complaining about slow file transfers and corporate WAN-based apps was icing on the cake.

Multiply this by 100 sites, or even by 1000 since many of our circuits are much more expensive than this small example site.

We'll be doing more of this cost savings because SD-WAN was designed for it, and because COVID-19 has reduced revenues so dramatically.  

As we expand this philosophy and technology at these hundred different sites, we'll combine multiple technologies to enable more resilience and reduce costs while providing improved service to our remote offices and their customers.  Maybe we'll use bundled T1's for voice resilience in case of WAN failure. Maybe we'll have G3/G4 cellular services going in the background for remote environmental monitoring.  Maybe dedicated Ethernet will remain in play, but will only support corporate apps and large file transfers, with broadband backup solutions ready and waiting for when backhoe fade takes out the fiber (this has been a particularly bad spring for backhoes cutting fiber in my states).

Monitoring of the multiple combinations of WAN service available via SD-WAN should not be a complex and manual process.  It shouldn't be expensive in terms of NMS products or licensing or support.  It should be SD-NMS.  Automated, flexible, intuitive, easy, and it should happen in the background, out of sight.  

But monitoring SD-WAN, even deploying it, won't happen if we can't look at trends from recent years and extrapolate them into the future.  With solid data, funding can be made available.  Or, with solid data, funding can be reduced.  Meaning Service Providers must provide more with less, the same way we do more with less today.

That's what I really-really want.  Improved throughput and resilience, lower network costs, and an SD-WAN NMS that does it for us without having to devote more Network Analyst hours to set it up the first time, and to keep it running smoothly indefinitely.

This is exactly the type of conversation I wanted to start!  I'm pulling in other PM's to review also.  Thank you for starting this off, the spice pic is EPIC btw  

~Dez~

How about asking internal ?

https://packetpushers.net/podcast/tech-bytes-solarwinds-boosts-voip-performance-development-productivity-with-silver-peak-sd-wan-sponsored/

I like your topic--specific enough to draw some hope, broad enough to be attractive to many folks.  What I want/need in monitoring SD-WAN includes, but isn't limited to:

• SD-Monitoring.  If I'm going to do anything "SD-WAN-ish", I don't want to do physical hardware setups and spend time doing physical changes in my environment to monitor new SD-WAN flows, manually building new views for it, resulting in many one-offs that only I can recall or support.  Nope, I want something that will:
  • Detect new flows for me without any action on my part, and display them.
  • Automatically discover:
    • New devices and their ports
    • New virtual wires and new virtual flows
    • New circuit ID's, service providers' names, and rated speeds
    • New virtual and physical end addresses
• It will automatically add those new circuits & flows to a page dedicated for SD-WAN, using the data about circuit ID's and service provider names, street addresses, even telephone numbers to call when a site or service is experiencing problems or needs more resources to accommodate growth.  Without my manually building the page.  Sure, let me edit it and move things around to make sense, but let's have this automated 100%.

SD-WAN frequently uses equipment built for Zero-Touch-Provisioning--it can even be synonymous with ZTP on occasion, and that means monitoring must mature to detect and display useful information also without intervention or touch by a Network Analyst.

I want to save my organization serious dollars (50%?  80%?) in annual WAN and Internet fees, while simultaneously increasing reliability and up time for my customers' network needs.  We're doing this today as part of COVID-19 resource recovery, and it's having great results, but it requires too many man-hours.  The future of SD-WAN means an NMS automatically accomplishing what we have to do manually today.  It includes:

• Automatically providing charts or tables that display WAN and Internet peak, average, and 95th percentile utilization, by week, month, and year, with only a few clicks.  This info needs to be available in Reports that are automated or easily adjusted for time periods & sites. 
• Trending analysis that goes back three years.  That's going to mean a database warehouse that can be mined instead of us limiting data to the last 6-weeks to one year to save database size and keep the NMS from becoming much slower.  
• Filtering out unnecessary interfaces intuitively, automatically showing only useful information.
• Displaying data for virtual wires that automatically adjusts as routing paths change based on availability, path cost, latency, etc.
• Quickly building automated views that show which circuits are underutilized or saturated, based on average, peak, and 95th percentile charts or tables.
• Letting us easily see where expensive (business class) synchronous circuits can be replaced with home-class asynchronous Internet connections that allow us to leverage costs by dropping a WAN service and replacing it with a broadband circuit with a ZTP solution like a Meraki VPN appliance.

Today I look at a dedicated site-to-site service between my remote offices and see we're spending millions of dollars annually on WAN services.  Tomorrow I want to see those services' costs closer to a few hundred thousand dollars.  It's being accomplished by shopping for broadband services local to the remote sites, dropping in a Meraki, setting it as the primary path for traffic back to the main office, and leaving the legacy WAN link and hardware in place until that circuit's service contract expires.  During that period we have the benefit of a dual-path / dual-provider resilience, and we benefit by having potentially MUCH greater download speeds for the site, at a fraction of the cost of the synchronous business-class WAN service.  When contract renewal time arrives, we'll be able to require the business-class service provider lower prices and increase throughput.  If they don't, we discontinue that circuit by removing it from the contract, and simply use the broadband.  An example:

A remote business office X has a 20Mb xb20Mb business class WAN service to connect to the home office.  The service costs $1500/month, or $18,000/year.

I reached out to a local broadband provider in that city and learned they have fiber WAN service already in the building hosting our office X.  The provider offered to give us 1G synchronous service for $200/month, or $2,400/year.  

I had them set up the new service, I installed a Meraki that sends that traffic to the Internet and to our home office via a VPN tunnel instead of a dedicated path.

Latency increased from 12 milliseconds to 25 millseconds.  WAN costs decreased by 87%.  Throughput capability increased by 5000%, enabling them to provide new, more bandwidth-intensive services to their local customers, resulting in greater revenues through gaining more work.  The fact that employees stopped complaining about slow file transfers and corporate WAN-based apps was icing on the cake.

Multiply this by 100, or even 1000, since many of our circuits are much more expensive than this small example site.

We'll be doing more of this cost savings because SD-WAN was designed for it, and because COVID-19 has reduced revenues so dramatically.  

As we expand this philosophy and technology at these hundred different sites, we'll combine multiple technologies to enable more resilience and reduce costs while providing improved service to our remote offices and their customers.  Maybe we'll use bundled T1's for voice resilience in case of WAN failure. Maybe we'll have G3/G4 cellular services going in the background for remove environmental monitoring.  Maybe dedicated Ethernet will remain in play, but will only support corporate apps and large file transfers, with broadband backup solutions ready and waiting for when backhoe fade takes out the fiber (this has been a particularly bad spring for backhoes cutting fiber in my states).

Monitoring of the multiple combinations of WAN service available via SD-WAN should not be a complex and manual process.  It shouldn't be expensive in terms of NMS products or licensing or support.  It should be SD-NMS.  Automated, flexible, intuitive, easy, and it should happen in the background, out of sight.  

But monitoring SD-WAN, even deploying it, won't happen if we can't look at trends from recent years and extrapolate them into the future.  With solid data, funding can be made available.  Or, with solid data, funding can be reduced.  Meaning Service Providers must provide more with less, the same way we do more with less today.

That's what I really-really want.  Improved throughput and resilience, lower network costs, and an SD-WAN NMS that does it for us without having to devote more Network Analyst hours to set it up the first time, and to keep it running smoothly indefinitely.