Cyril Doussau, Product Strategy & Marketing, Juniper Networks

Juniper Networks Explains the Key Success Factors of Autonomous Transport Networking

Network AutomationWAN
Still image shows a box with a headshot with the name Kevin Landry across the top, on the left hand side and his title underneath but it is too blurry to read.  In the middle of the screen there is a TechField Day logo with these words underneath “SHOWCASE Presented by: Juniper Networks, The Autonomous Transport Network Key Success Factors.”  On the right hand side is a box with a headshot with the name Cyril Doussau on the top and his title below his image but it is too blurry to read.

Network automation has a critical role to play in the future of industries.

In this Tech Field Day Showcase, Cyril Doussau and Kevin Landry discuss Juniper® Paragon Automation. Paragon Automation is Juniper Networks’ suite of cloud-native software applications that is designed to eliminate repeatable tasks by putting them on auto-pilot, saving time and cost. Hear the presenters talk about the three success factors of building an autonomous transport network.  

Show more

You’ll learn

  • How Paragon Automation ensures optimum operational efficiency and high levels of service experience

  • The key requirements addressed for communications service providers

  • How Paragon Automation helps automate tasks through the stages of planning, orchestration, assurance and optimization

Who is this for?

Network Professionals Security Professionals


Cyril Doussau Headshot
Cyril Doussau
Product Strategy & Marketing, Juniper Networks
Kevin Landry headshot
Kevin Landry
Sr. Product Marketing Manager, Juniper Networks

Guest speakers

Peter Welcher Headshot
Peter Welcher
Architect and Tech Advisor, NetCraftsmen
Nick Buraglio
Network Architect, ESnet
David Penaloza Seijas Headshot
David Penaloza Seijas
Principal Engineer, Verizon Business
Steve Puluka Headshot
Steve Puluka
Principal Engineer, Verizon Business


0:09 everyone my name is Sheldon I'm

0:11 responsible for evangelizing the

0:13 benefits of Park on automation from

0:15 Juniper Networks so in today's showcase

0:17 we are to review how to build the one

0:21 automation of the future or the

0:23 automated one of the future

0:25 so we the need for alteration is really

0:27 no longer a secret but let me quickly

0:30 review why automation is becoming more

0:32 critical every day

0:34 We are continuing to see a massive

0:36 growth in our Network

0:38 by the end of the decade we will have an

0:41 impressive 20 times more connected

0:43 device

0:44 Network Architects have become more

0:46 efficient and more complex Network

0:48 outage are still very expensive and

0:50 making the news every day and we we all

0:53 know that most outage are due to manual

0:55 changes and today it has become

0:58 impossible to manage change at scale

1:01 by delivering the quality and the speed

1:03 that a CSP customers are requiring so

1:06 something must change and like many in

1:10 the market today are many other network

1:12 leaders we believe that automation has a

1:15 critical world to play and luckily for

1:17 us and locally for the industry

1:19 things can improve 75 percent of all

1:23 networking activity are still manual

1:25 today

1:26 even more we have 63 percent of csps

1:29 that are using manual processes to

1:30 manage their service life cycle and we

1:33 learn from csps and from the analytics

1:35 community that actually when they try to

1:38 do it themselves 70 of their projects

1:40 fail and it's really due to the

1:43 complexity of building an automated one

1:45 so another issue that we see is the fact

1:49 that 60 percent of network problems are

1:53 still not discovered by netapps and so

1:56 when we want to automatically

1:57 automatically improve networks or

2:01 um automate Networks

2:03 we need to understand where the problems

2:06 come from and it cannot happen if the

2:08 problems are not visible

2:10 so this is why at Juniper Networks we

2:14 did launch Pagan Automation and pagon is

2:17 really a suite of applications products

2:21 that have been designed to automate the

2:23 the planning the orchestration the

2:25 assurance and the optimization of modern

2:28 networks so with spark on automation you

2:31 can provision devices with your touch

2:33 you can automate service activation and

2:36 testing you can leverage AI to

2:38 accelerate food cause analysis You can

2:41 predict issues and resolve them faster

2:44 and optimize Network automatically

2:48 so what what our customers are starting

2:50 with simple use case they can leverage

2:52 the same technology to deliver on a

2:55 short experience with closed loop

2:56 automation

2:58 and you know everyone here if you a

3:02 fixed language provider if you if you're

3:05 a mobile provider if you have a business

3:07 service provider and even a large

3:09 Enterprise a significant Party part of

3:12 the traffic the application critical

3:14 traffic is going to go through through

3:16 the the one the transport Networks and

3:19 so when we talk about building an

3:22 autonomous one also we need to think

3:25 about managing multiple Network domains

3:29 so you will have to automate an Access

3:31 Network such as a Metro or Cloud Network

3:33 an aggregation Network The Edge and the

3:36 core and so all those Network domains

3:39 and various layers from Optical layer to

3:42 layer 3 will need to be fully automatic

3:45 automated and in order to deliver that

3:49 that Antoine Automotive one

3:52 so while many have invested in a service

3:56 orchestrator here

3:57 some of the service fulfillment and

3:59 service Assurance function would need to

4:01 be leveraged in order to achieve this

4:05 um and so the networks become truly

4:07 programmable and driven through apis

4:12 as the automation is quite of a wide

4:15 topic and so we decided to focus that

4:18 attack field day on traffic engineering

4:20 and closed group remediation and this is

4:23 simply because when we inquiry with the

4:25 market when we look at our customers and

4:27 as well the large Enterprise and the CSP

4:30 out there they are telling us that

4:32 traffic engineering and close-up

4:33 remediation are the two main use case

4:36 that they are focusing on right now and

4:39 and planning to invest in technology to

4:42 to solve those problems so here we're

4:45 going to talk to the today about past

4:47 diversity latency based footing

4:49 autonomous capacity optimization and

4:52 closed loop remediation and I will pass

4:54 to Kevin who will talk about those

4:56 critical success factors

4:59 my name is Kevin Landry and I work with

5:01 Cyril here on evangelizing our Network

5:04 automation solution for the when at

5:06 Juniper Networks and today I'm going to

5:09 be covering key success factors that are

5:11 critical to moving towards an autonomous

5:14 transport Network

5:17 so moving uh to the first success factor

5:21 it's actually one of uh The Usual

5:24 Suspects for intent-based Automation and

5:27 it's model based service orchestration

5:29 which accelerates provisioning and

5:32 orchestration of the stateful VPN

5:33 Services you're going to see on the

5:35 right of the slide and really what this

5:38 does is it reduces configuration

5:39 complexity and the need for heavy manual

5:43 provisioning efforts what's important is

5:46 that the service modeling will abstract

5:48 complexity and with this standards based

5:51 approach the network data is normalized

5:54 and correlated to services in a way that

5:56 provides a service-centric visibility

6:01 the the next key success factor

6:06 um our second one is actually one that

6:08 is surprisingly overlooked uh by many

6:10 network network vendor automation

6:12 Solutions today yet we feel it's so

6:15 important uh it's called active data

6:18 plane measurements and that's where you

6:20 have test agents deployed in the network

6:22 to inject synthetic traffic that appears

6:25 just like an end user and it's important

6:27 because you really can't improve what

6:29 you don't measure so what this does is

6:33 it allows you to measure the actual

6:35 service experience during monitoring or

6:38 it's able to load tests to measure slays

6:41 before you even activate this service

6:43 and the beauty of that is that with this

6:47 service-centric approach uh it's able to

6:50 test on the data plane so you can

6:52 inherently test across any domain

6:55 whatever infrastructure technology

6:56 you're using whether it's across the

6:59 when whether across Cloud Server service

7:01 chains and the data centers or even over

7:04 sd-wan or even across partner partner

7:07 domains or the internet where you might

7:10 not have control of these networks so

7:13 you really get a really specific

7:15 visibility end to end

7:17 you know as a service provider obviously

7:19 the new turnip testing is is

7:22 straightforward and you know happens

7:24 when you turn on the circuit but one of

7:26 the things we've struggled with

7:28 as a service provider is how to provide

7:31 this at scale across the the whole

7:34 network because as soon as you have

7:36 hundreds or thousands of services across

7:39 hundreds or thousands of devices you

7:42 know running this level of of testing to

7:45 verify the service starts to become

7:48 problematic so what are your responses

7:51 to to deal with that situation I'm

7:53 really happy you asked that question

7:55 because in the past with passive DPI

7:58 type Solutions there was a lot of uh I

8:00 guess cost and effort to deploy

8:02 expensive probes in the network and that

8:04 was very uh it wasn't very timely

8:07 because you know it wasn't easy to roll

8:09 those out in a very quick way so you

8:11 have immediate kpis and you know that

8:13 service level quality visibility so the

8:18 solution that we have at Juniper

8:20 Networks which is called Paragon active

8:23 Assurance what it's able to do is it's

8:26 able to be very lightweight so that you

8:29 could deploy it in terms of the test

8:31 agents as either a virtual Network

8:34 function

8:35 um on a hypervisor or if you're using

8:38 cloud cloud native approach and you're

8:42 able to deploy it as a container as well

8:44 or you know a software on a server so

8:47 the idea is you're able to deploy these

8:49 in a way that you could hit any part of

8:52 the network and strategically place them

8:54 and it's very quick to be able to do

8:57 this customers are able to basically do

9:01 this within hours kind of thing and get

9:03 their Network up uh with with testing

9:05 it's very easy and something else we

9:08 actually launched this year was within

9:11 our devices itself for our Cloud Metro

9:13 we actually have embedded natively the

9:17 test agents within the router software

9:19 for ACX family and what that gives you

9:23 is the ability ability to turn that on

9:25 on the routers itself from day one so

9:28 that you have immediate access to

9:30 testing so it's really going Beyond you

9:33 know the reflection based testing that a

9:34 lot of the vendors were using like

9:36 t-womp and and that kind of mechanism to

9:40 something that's really testing service

9:42 quality end to end and in a way that is

9:47 um service Centric so you actually know

9:49 that what you're testing is like end

9:51 user traffic because you're actually

9:53 injecting end user traffic or synthetic

9:55 traffic

9:56 so yeah and then as a follow-up if

9:59 you're not using the standard reflection

10:01 RFC methods uh how do you present that

10:05 to a client that it's they're okay with

10:08 you using their service for this for

10:11 this testing thing for you know adding

10:14 traffic to the service they're paying

10:16 for

10:17 so a lot of times what happens is if you

10:21 have a self-service portal as a service

10:24 provider and you offer that to your

10:26 customers we're able to offer a solution

10:30 that allows you to do HTTP uh yes speed

10:34 testing so you could actually as a

10:37 customer test the connectivity of your

10:39 application and validate that SLA

10:41 performance so that's one way as a

10:44 customer that they see this but many

10:46 times

10:47 um I guess the notion of being able to

10:50 be able to be proactive and be able to

10:53 prevent these uh kind of issues before

10:55 customers even see them happening is

10:58 really what's key for the solution we

11:00 want to be able to give and enable this

11:03 providers A solution that's able to keep

11:06 them ahead of problems so that they're

11:08 able to address them so they could

11:09 really eliminate all the the customer

11:12 dissatisfaction from poor quality and

11:16 the customer churn that's associated it

11:18 with that so when you're dealing with

11:19 customers like health care and finance

11:22 they're comfortable with the carrier

11:24 injecting traffic into their private

11:26 service the amount of traffic that we

11:28 inject is very very small

11:30 yeah very tiny doesn't damage the series

11:33 yeah like we're talking about a very

11:36 small amount of traffic that there's

11:38 really no performance concerns when uh

11:41 you inject this level of traffic and now

11:44 of course we can scale up and do load

11:46 testing as well if we want to test you

11:48 know some kind of data center backup and

11:50 that we could actually reach that you

11:52 know level of bandwidth we could do that

11:55 too but you would also have the RFC

11:58 options available if people weren't

12:00 comfortable with non-standard things

12:02 being done it definitely I mean we are

12:04 testing from Layer Two all the way to

12:08 layer seven so you know all the

12:10 different standards in terms of like the

12:12 IP and ethernet layer we're doing all

12:15 the the bread and butter cases that you

12:17 would be able to do on the devices

12:18 themselves but we go beyond that to do

12:21 you know all the way up to layer of

12:23 seven as well

12:24 I think uh having this built in is a

12:27 real great uh competitive feature

12:29 because what we're seeing with some of

12:30 the Enterprise uh based testing products

12:34 is they're still in the costly onesie

12:36 choosy hundreds range and what I'm

12:40 anticipating is scaling this up but if

12:42 you can get your provider to do a lot of

12:44 it for you that really simplifies the

12:47 Enterprise customer side for the service

12:50 provider I would think

12:51 definitely this data that gets um you

12:56 know this testing data you obviously are

12:58 going to have a whole wealth of

12:59 information potentially over time is

13:02 that trackable anywhere long term can

13:04 you set up regular testing that just I

13:06 mean obviously it's active so that you

13:09 know presumably these are ongoing things

13:11 is it is it recorded anywhere that can

13:13 be referenced as a baseline yeah

13:15 definitely uh basically there's the

13:18 approach where we're doing monitoring

13:20 and you're able to feed that data even

13:22 into other performance systems in fact

13:24 we do that where we feed this kind of

13:26 data say we're doing some kind of

13:28 latency testing for instance we might

13:30 feed that data into what we have in

13:33 terms of our AI engine which is in

13:37 another product called Paragon insights

13:39 so with that you're able to get not only

13:41 the service level visibility but go

13:43 deeper into you know other types of

13:45 telemetry and actually that's what I'm

13:47 going to talk about on the next slide we

13:49 believe that it's a marriage of both

13:51 Telemetry approaches with the passive

13:54 data with the active data that's the

13:56 best choice

13:57 so I guess moving on then um to the

14:00 third success factor and that's really

14:02 you know to extend the conversation that

14:04 we were just having having a

14:06 comprehensive Network observability

14:08 stack is key because your automation

14:11 that you have is really only as good as

14:13 the insights that drive it so this is

14:16 very important for both improving

14:18 operational efficiency but also to

14:20 enable that automation so yeah having

14:23 that breadth of telemetry data is so

14:25 useful

14:26 um you know it gives you that visibility

14:28 into Network performance but it's also

14:30 able to mount that to services so that

14:33 you could understand their health as

14:35 well

14:35 and really as I was talking about in the

14:39 questions the data could be it's very

14:41 versatile we could actually you know

14:43 export it to you know different systems

14:45 but we could ingest it from whatever

14:47 data source uh and that we think is a

14:49 best practice you really need to be

14:51 flexible on that uh whether it's a data

14:54 lake or a third-party system whatever

14:56 infrastructure domain whatever vendor

14:58 you have to be able to normalize it and

15:01 make it meaningful by deriving specific

15:03 kpis

15:05 uh but the problem is the Telemetry can

15:08 only get you so far so that's why we

15:10 really advocate for the active data

15:12 plane measurements that really should be

15:14 a part of that observability stack

15:16 because as mentioned you're not going to

15:18 be able to improve it if you can't

15:20 measure it but in addition that I'll

15:22 just extend it even further you can't

15:24 React to what you don't know about so

15:26 what we're finding in a lot of customers

15:28 uh and why they they buy into this is

15:31 that the measurements often help them to

15:33 detect detect silent issues that have

15:36 been creeping up in them or they didn't

15:38 even know existed and those are the ones

15:40 that would eventually disrupt services

15:42 so that's why this is so powerful

15:45 you mentioned earlier about the

15:48 Telemetry and you can only have both the

15:51 Telemetry information on all the

15:52 visibility based on the data you get

15:54 into the box so then my question goes on

15:57 the lines of what does happen or or how

16:01 do you get information into the tool

16:04 that is not necessarily driven or

16:06 derived from your measurements assumed

16:09 you have a service provider that of

16:12 course lives in the future and uses net

16:15 box to have a single source of Truth and

16:18 reporting that has a list of prefixes or

16:21 links or any other type of information

16:23 are you able to ingest all that because

16:26 there is a limit to what you can measure

16:28 with the with the agents and this also

16:30 goes hand in hand with multi-vendor

16:33 environments definitely and so the way

16:35 junipers approach that is we don't do it

16:37 within our active Assurance product we

16:40 do this when we marry it with our

16:42 Paragon insights that you're able to

16:44 have an approach where you know we do

16:46 all the the base like Kafka bus type

16:49 things and rest API ingest and you know

16:53 through netconf and and like you know

16:55 any kind of telemetry right grpc you

16:58 know all the all of that's done for

17:00 streaming Telemetry but

17:03 um where we go beyond is we have

17:05 something called bring your own ingest

17:07 so that allows you to basically write

17:10 rules where you could ingest from any

17:12 data source

17:13 um so I hope that answers your question

17:16 okay so for instance because is earlier

17:19 than we were talking about then a

17:22 service being then turned up and doing

17:24 testing but what if for instance you

17:26 deployed and there's a there's a brown

17:29 uh Brownfield deployment and then oh

17:33 there is a service that we just have to

17:35 turn out we just put a p in this

17:37 particular section of the network yeah

17:39 the rest is irrelevant but then you get

17:42 into the tool you simply add a new node

17:44 or do you have to pull the new node from

17:47 another different tool because again

17:50 there will be many things that are

17:52 driven by automation but there are

17:54 always these special cases that are not

17:56 covered by some automation then which

17:58 are the other ways in which you can add

18:00 this can you get into the tool and put

18:01 another node and things like that

18:03 exactly you could do that

18:05 um so you know you could add a device

18:07 into monitoring and it's important to

18:10 note that we support Legacy types of

18:12 collection like SNMP and even CLI right

18:16 so

18:17 um it's really uh I guess we're trying

18:20 to focus on the flexibility to be able

18:22 to really include any data source and

18:25 it's important I think it's a best

18:26 practice that you're able to have that I

18:29 guess programmability uh we go and

18:32 extend that further we have the ability

18:34 to even take that data and automate it

18:37 with what we call playbooks so you're

18:39 basically using the data to trigger

18:42 actions and we could integrate with sdn

18:45 the solutions like our Paragon

18:47 Pathfinder to you know trigger

18:48 optimization or even orchestration

18:51 systems where we're gonna you know

18:53 provision as well based on you know if

18:55 there's a change needed that we need to

18:57 react to in the network I guess at the

18:59 heart of what we're going to be talking

19:01 to today is our fourth success factor

19:03 and it's the one that we're actually

19:06 going to be focusing on demoing today in

19:08 our second video recording and it's all

19:11 about AI driven multi-vendor sdn control

19:13 which really is the foundation to moving

19:16 towards that autonomous self driving

19:19 Network and some of the use cases we're

19:22 going to talk to you about today include

19:24 path diversity latency based routing

19:27 autonomous capacity optimization and

19:31 closed-loop

19:32 Remediation and again that's going to be

19:35 in the demos so I won't talk too much

19:36 because we're going to hear a lot about

19:37 that from Julian

19:40 um

19:41 and then I'll move on to the final and

19:44 fifth success factor which is related to

19:49 sdn control as well and it's

19:52 multi-vendor interoperability so you

19:55 know a lot of vendors claim multi-vendor

19:58 interoperability multi multi-vendor

20:00 support but we feel that it's really

20:01 important as a best practice to get

20:04 involved in testing that and actually

20:06 you know kind of not just talking the

20:10 talk but walking the walk so to speak

20:12 you know we want to make all this

20:15 automation work in today's modern

20:17 networks no matter what vendor that's

20:19 being used and it's really important in

20:22 order to do that and get the best

20:25 results that you prove it out with you

20:27 know some kind of organization such as

20:29 the eantc

20:31 um where we were able to do

20:32 interoperability testing with other

20:35 vendors that are the the key ones that

20:37 they're in the industry anyways and also

20:40 to be able to you know have experience

20:43 with our product managing multi-vendor

20:46 devices and real customer deployments

20:50 um so what we do is all the leading

20:53 vendors in when sdn control we get

20:55 together annually for this

20:57 interoperability testing at the entc and

21:00 this year we were able to validate our

21:02 sdn controller which we call Paragon

21:04 Pathfinder with Cisco Nokia and Huawei

21:08 and another thing we've done is we have

21:11 tier one and tier two service provider

21:14 customers where we actually had no

21:16 Juniper install base for our Network

21:18 equipment and those customers deployed

21:22 our Paragon automation to manage those

21:24 other networks based on our competitors

21:26 equipment

21:27 so you know it just goes to show that

21:30 when you uh you know you you go beyond

21:33 just the the normal talk of multi-vendor

21:36 and prove it out great things could

21:38 happen you see that customers will you

21:40 know embrace your equipment because when

21:42 they test it out they know it's working

21:43 right in in talking about that I the

21:46 first of all I think the multi-vendor

21:47 strategy is great I think that's you

21:49 know in service provider it's you know

21:51 pretty much the way it's been for a long

21:52 time so that's great looking at the

21:54 protocol stack here um in the transport

21:56 options that you have I see all The

21:57 Usual Suspects of SRM PLS srv6 bgplu I

22:03 spent a lot of time Consulting for tier

22:04 two and tier three isps typically last

22:06 Mile isps and one of the things we're

22:08 seeing is is that mpls and L3 is getting

22:11 pushed out way far into the last mile

22:13 whereas traditionally it's been you know

22:16 Metro ethernet based and as such we have

22:19 a mix of data planes that are out there

22:20 in a lot of networks where we have ldp

22:22 traditionally and then we're mixing an

22:24 srmpls what does this look like if

22:27 you're a service writer that's in the

22:28 middle of transition from ldp to srmpls

22:32 okay I mean yeah it's the kind of thing

22:36 where

22:37 um well from my past experience I know

22:39 that we support both right so if you're

22:41 using rsvpte you're able to deploy this

22:45 and be able to get that visibility right

22:47 away and start to automate with a little

22:49 bit of control in terms of all these use

22:51 cases that we're going to talk about but

22:53 I think what I'll do is I'm going to

22:56 leave this question and introduce Julian

22:58 because I know that we also do the

23:01 segment routing a lot of times you know

23:03 there's kind of an evolution where they

23:05 start up segment routing in a separate

23:07 negative segment to be able to as a

23:10 green field to start that up so they're

23:12 kind of managing both but they would in

23:14 most my experience they're using two

23:16 different two controllers for that even

23:19 though you could support both in one but

23:21 it's just because of you know scaling to

23:23 different domains uh you know you you

23:26 you mentioned the the mpls side and

23:29 obviously you know psep and and segment

23:32 routing or a big part of making you know

23:34 the multi-vendor on the path side of of

23:37 things work

23:38 and you know with the experience that

23:41 I've had with North Star now Paragon

23:43 Pathfinder you know that you know those

23:46 standards are incredibly important to

23:50 that kind of system working and then in

23:53 the service provider because you know as

23:55 Kevin mentioned there isn't a service

23:56 provider in the world that's a 100

23:59 any vendor so aside from the

24:03 From the Path side of things what are

24:06 the other standards you're working with

24:08 uh to to ensure this end to end working

24:12 thing uh certainly bgp like you know

24:15 protocols like bgpls are helping us gain

24:18 visibility of the topology it's really

24:21 important that we support peace up

24:23 because that's giving us ability to work

24:25 on a multi-vendor basis you know there's

24:28 uh standards for Segment routing uh

24:31 ultimately I think maybe Julian could

24:33 he's more the expert in this domain I

24:35 would say I mean the other sets of

24:39 um standards

24:40 um if you like are related to

24:44 um Telemetry so open config is becoming

24:47 increasingly of interest

24:49 um as a means of you know standardizing

24:51 the way that Telemetry is sensed by the

24:53 network devices to the automation

24:56 systems so certainly we support

24:59 um you know open config as uh um

25:02 Telemetry in ingest mechanisms that's

25:05 another good example of standards-based

25:08 approach

Show more