Juniper Networks Explains the Key Success Factors of Autonomous Transport Networking

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