Demystified SD WAN, SDN, NFV, and VNF

hello and welcome we continue our sd1 architecture matters series and in today's session Steve will demystify the differences between sd1 Sdn NFV and DNS Steve who is the vp of product and co-founder here at belleau cloud before we start a couple of housekeeping items this webinar has been recorded and you will get a link to the recording shortly after the session the presentation slides as well as other resources can be found by clicking the attachments button in your interface we hope to have time at the end for Q&A although this presentation is very technical and quite involved so we have reserved some time but please send your questions in as early as possible and now welcome Steve thanks Sasha and welcome to another in our architecture matters series sound like a mouthful of acronyms so we'll try to dig through that today I am presenting live from Orlando is just following the Gartner symposium where this was a dressing topic so the goal today is we'll take a broader look and how Sdn simulates to the principles of both Sdn and NFV as well software-defined networking and network function virtualization first out first I'll start off by looking at how the Sdn architectural principles really more importantly the market goals that drove those have been applied taking it from a more data centric application to appliance to the when and implementations for next generation LAN in terms of SD okay on this slide the let me start first was what is FD n and so the they all in F for the Open Networking foundation been really the the forearm of the leader in defining the Sdn architecture and a key principle in this architecture was the separation of the control plane from the forwarding plane really the goal it was more important was to increase program ability and also to allow the abstraction those application flows and network services and the the underlying infrastructure so through the course of this webinar we'll see how that actually can be a flyer to transform to the the problem we're trying to solve in the land side but really the direct program ability was to enable this abstraction as well as whatever wants to do is increase the agility and to really adjust network wide traffic flow to meet the changing needs the goal of central management is key to really get a global view on the network and to simplify configuration changes programmatic interface or configuration of the goal matters to let Network managers more easily configure manage and optimize and network resources and also particularly for service providers to do this via automated software programs as well now see the as a different market segments mature to move these towards open standards and both for simplifying design in terms of putting different pieces together and also allowing interoperability between between vendors so see how Sdn or the principles of varisty and architecture be applied to an SDN implementations are really going from data center to the land and going from an architecture principle to an actual actual implementation so before I actually launch into the table I think as this has evolved the our level goals and customer expectations are really for number one simplified and centralized management so the central management put in control into software so part of this but on the control overstated plan which put controlling the software that software can be rapidly innovated and with an API that allows programmatic inputs and then ultimately with the software hardware split or the control playing data plane split to enable the use of more cost-effective commodity hardware and also have more interchangeability between the the hardware components quickly touching on the the highlights of this of this table so well off the end decouples very strictly decouples control and forwarding elements the Sdn really takes a more hybrid approach approach to this so local decisions will be made with local context but based on centralized control policies see the importance of that later and why this applies to the Internet and the lan as opposed to more of a data center centric deployment the goal of agility is achieved based on adjusting the forwarding to meet policy as well as and this is a key new requirement for SD LAN as well as real-time transport or link conditions and so this enables application flows independent of the underlying infrastructure I use the transport and then the most part most sqn implications are software based and some are even network as a service which is what's offered by Vela cloud and our provider partners so that that also allows for rapid innovation then obviously Central Management is available via central policy and orchestration I can all be programmed via a REST API so in the when world's not yet standardized as it is in for open flow but there's work underway in multiple forms including Oneg which is actually meeting next week and mes coming up shortly in November as well to start to talk about the Sdn interoperability but already the software approach of f2n has already allowed the use of off-the-shelf x86 based hardware actually the next slide let's look at the evolving real world expectations of Sdn and this is captured by one leading analyst group Gartner so they basically defined FDA and as having four I guess critical components the one is that it's a lightweight and key keywords the lightweight replacement for traditional complex routers obviously goal is to simplify the branch line edge it will be the land edge device particularly at the branch not necessarily at the data center the critical new functionality is ability to leverage multiple LAN connections and do this under unified policy and also bring this or abstract this up to an application level and make that independent of the underlying transport and then overall it's discussed with Sdn simplify the complexity of traditional lands as it goes hand-in-hand with the goal of increasing agility and then finally the they do expect the secure care activity and additional network services so this is where we'll later see that NFB should be a more flexible and powerful way to deliver these additional network services as opposed to a more traditional way to do that so we're on to the next slide let's expend actually beyond the goals I've got in our set for us to an but first let's recap what a nasty LAN solution is so in this diagram it's not not just a CPE replacement there really is an end-to-end solution at the logical overlay network as we mentioned the key is it can encompass any land transport so a mix of private MPLS public internet broadband even II could be independent of the service provider or accomplish multiple providers it works between any two sty nodes in this diagram the nodes Lloyd are branches and data centers called edges and key to the Sdn approach these edges can be software the cloud delivered implementation would also extend this overlay to any cloud pop or data center with the use of what we call multi-tenant cloud gateways so really the key additional benefits on the bottom the first benefit god I mentioned is simplifying the management of lands and this is especially important as Enterprise IT wants to use multiple circuits instead of a single circuit or multiple of multiple providers we also want to keep the simplification as we insert additional services and that's where the nfe plague comes in next benefit take it further than the Gartner definition is really to assure the performance of critical applications really focus on performance not just using multiple types of links to assure the performance of the app even as you add different links and more advanced solutions can can achieve this even if they're using Internet only links and finally I think the extended or stretch goal is that some more advanced solutions should should support the enterprise migration of their apps and data and services to the cloud so the goal of a cloud delivered solution would provide all the same benefits that you have within an enterprise all the way to any cloud destination as well so in this next slide I won't touch in too much detail I'll just expand a bit on the architecture for an SEO and solution in addition to the edges for the on-premise deployment in the gateways for the cloud access deployment I mentioned in the previous slide I just want to highlight there are also at the top of the slide tributed redundant policy controllers we'll get into the function of that further as well as the the management interface or operator for viewing and configuring policies or a cloud delivered service or over managed su and services can all be hosted in the cloud as a service and quickly on the data plan we cover this but the the edges as you can leverage both public and private circuit says available they can connect to other edges so multiple edges in data centers as well as to different gateways for different cloud SADS or infrastructure of the service destinations and a branch edge can also dynamically connect to other branch edges for direct branch to branch traffic that's the architecture of the let me let me touch on the some of the key features of SDM to meet the requirements that I spoke o from both Gartner and our extended goals as well so let's slide the the key to both simplifying wiring management as well as the shoring half performance is depend on three critical functions so the first is this to automatically and continuously monitor profile every link is plugged into the overlay then based on the link performance to stare beautiful apps important apps to the best link at that moment in time more VAT solutions can also do this on a per packet not flow basis what this means is a flow can be moved like a phonecall midstream without dropping the session or even the end-user nursing as well as for high bandwidth the applications to aggregate the link capacity for single for a single session and then to also have on-demand remediation it's needed if you have only a single link available or in the the case that both links have degradation at the same time you want to do actual error correction jitter buffering and faster retransmission so the end benefit of this approach is not assuming or depend on the quality of the SLA of the individual links but basically to use the overlay to engineer and assure the app performance so in the GUI snippet on the left hand side good good example the bottom will show the underlying link performance of multiple links one is a private MPLS length one is a cable broadband length Calvary green is good red is bad and gray is actually a disconnected or down so in this and then the over the top bar shows the overlay resulting as performance this case we're looking at how the voice application would work and basically they come pairs if there's degradation outage detected in the in the private link and those were solutions have pin critical traffic to assuming the escalator the private link there could still be a cable cut on that you want to dynamically move the traffic to the second broadband cable link but if you have degradation on that one then you have to also call an on-demand remediation to fix that problem but the end result everyone's looking for is great and great application performance that was on the the assured app performance as I mentioned a second or the other key benefit of Sdn that we're looking for is simplification there are many many ways that Sdn can simplify I'll just cover for the top the top functions that are delivered to simplify the LAN so first it provides centralized provisioning and that was a basic tenet of Sdn so to really help reduce the attached four branch deployments use group profiles they're all abstracted to the application level in this case many solutions can also do smart defaults so the automatic link discovery automates the configuration so you don't have site by site configuration even though each configuration each site as a different thing set up and now this also could all be hosted in the cloud for further simplification or install on premise if you if you desire another good example on the right of simplified configuration is building that secure connectivity that Gartner mentioned so branch the datacenter VPN from on-site device on-premise device on-premise devices probably easy as expected it is more and more infrastructure the services used such as Amazon or your you end up with a NBN branch by n datacenter annual two-sided VPN tunnel configuration depending on the actual IP addresses of both ends becomes very complex so one advantage of having a cloud gateway is it can still provide the consolidated to London connection from all the branches automatically to that gateway without having to backhaul and without having to do a manual tunnels connect to your cloud destinations xxx cakes were simplifying the Malayan is for service insertion so if you back all internet traffic to an on-premise service Sdn makes it easy to actually distribute or deploy services to multiple mini regional scrubbing centers or even to the cloud without complex node by node routing to try to forward traffic at a course level so basically apple where policies can actually do this at an application level and we'll see how this capability fits naturally into supporting the nfe capability to dynamically push services at different locations so it goes hand-in-hand with that with that functionality and finally a addition to selecting link the the NFTY solution can simplify the overall m2n routing and so never route to automatically learned from all the sp1 overlay edge devices talking to the legacy network on the branch and the data center or even the cloud side via standard routing whether it's opf for bgp but we'll see this in the architecture but the visibility control is simplified because we have central management or an enterprise wide consolidation of the stroud information that was also one of the the principles of Sdn was to really bring in some form of central management and once we have that central validation of the of the routing or control policy as this is presented to the orchestrator then we can also make one-click changes to that and redistribute it out to the multiple asking nodes not on a node by node CLI configuration basis and finally as I mentioned that earlier the last extended goal I think for sq and because that's also a goal I think for definitely energy as well as is to support migration of services to the cloud and this shows you the typical problem on the left is legacy or even other sty architectures don't usually support migration to the cloud it's for cloud access either yet to backhaul the traffic across the private plan or the device to device slam or if you do a direct breakout from the branch since there is no sty node on the other side in the cloud it becomes best effort the goal of a cloud delivered solution such as the one develop out delivers is to extend all the same SQL benefits you have from an on-premise site to an arm premise site and extend that directly to the cloud mobility to pre-install gateways that all the the major cloud data centers and services something both develop outdoes and you've seen the analysis that have gone out over the past several weeks via our large service provider partners are deploying in the cloud and at the access to their private cloud network as well so the so I covered the ESPN benefits goals the architecture that supports that and I've covered that and the components let me come back to the Sdn principle of separation of the control plane and really cover how that but since I think for the achieve the goal of easier reprogramming all right multi-vendor interoperability and I think for a lot of cloud providers allowing the use of cheaper switches but since we're since the deployments are at large data centers at a provider or enterprise or typically the controllers were co-located with the with the data plane switches this architecture this architecture works however if you look at the additional architecture for internet scale Network it does have a distributed control plane at the base there's a benefit that is it's highly redundant you have no single point of failure it's highly scalable but the corresponding drawback is that there was no holistic view of the network control so it's very complex to implement end-to-end policies and changes or if you want to really take an application flow point of view and program that across a network that was a fairly complex if we looked at the the FT an approach I think the goal and the what the solutions can deliver is really a best of both worlds approach the architecture implement rescue an had to take into account the distributed nature of the lance will no longer send it to nodes and a single data center or campus so in fact the implementation has distributed control plane so you see the control and data is at the different su and nodes so forwarding decisions can be made locally based on policy as well as is local knowledge of the real-time I'm length of circuit conditions so there is no there is no Lane see or or failure issues caused by an inability to reach a remote remote control yet each su an edge also communicates to multiple centralized with redundant control policy controllers so gifts can get centralized control policies get its relevant information this also provides for enterprise wide visibility up to the management interface to view it and also easy program ability for the management of its configure and push new policies down to the entire Sto an infrastructure let me take a look at a bit more detail on this on the next slide or then also showing these the edges can get centralized control policies from the controllers and these are configured and viewed from the orchestrated management application in this example on the upper right you can see there's a enterprise wide overlay flow control table that shows this little snippet all the well the reach ability for all the subnets across different paths the preferences for that so the this important because the FT one is an overlay so the edge to edge overlaid tunnel information is distributed via the controller's through the different edge nodes not top not hop by hop through the the network pairs the additionally at the at the branch edge or the data center hub edge or in the Gateway we learn the routing from legacy network so it's interoperable with the legacy networks to get that routing information from the pairs is actually then consolidated via the controllers which is viewable and then configurable from the arcs shader and then actually it's redistributed to all the other end points or exit points of the SDN overlay for for cloud deployment these controllers the controller function is typically co-resident with or the cloud gateways might be it might be deployed for enterprise solutions that could be deployed on premises as well but the bottom line of this architecture is that it simplifies the routing you have that central view everyone's going forward but it maintains the advantages of local forwarding control which brings us to the million dollar question I think which we're asked many many times I think one st when was first sort of hitting the marketplace based on the Sdn principles was ok gee if the will pay the plane traffic be negatively impacted if obviously something happens to that control plane so the the questions became is there any impact to my data plane traffic if there's a failure of a controller and perhaps because it's installed on premise and it was not installed redundantly or there's a loss of connection to an Orchestrator are particularly if i'm using a hosted cloud-based Orchestrator maybe the link maybe the internet link to the cloud is down but I still want my private VPN to be working or perhaps the the controllers are too far away if I'm using a hosted controller does latency between the edge and hosted controller also impact the speed of my data flows obviously the correct answer of course is none of the above that's the key at the key point and that's the key design criteria for Sdn it departed a little bit from the very strict Sdn principles separating the the control from the forwarding is that had to be distributed to basically meet these market requirements local control local knowledge of link conditions means that data flow continues without the controllers all four incisions can be made locally automatically adjusts for link performance brownouts this also means it's more flexibility and deploying the controllers and oak stairs remotely they could be hosted in the cloud as a service obviously if an Orchestrator is not reachable the redundant controls will continue to redistribute learned routes the only thing that would be impacted if the orchestrator is currently not reachable is ability to configure new end-to-end policies that would be temporary offline or could be configured in the in the master database it would not be updated throughout the SDN network until the until the reach ability is is reconnected but but bottom line a very very robust very redundant system now let's so that was how st when related to principles of Sdn now in this next session I look at I should both what what NFV and vnf are and then how that relates to how that relates to FD when on this slide how ours first let me just cover how enemy and vnf are related so a little bit history nfe was created by a consortium of service of art is called FC and a PSU i go back and explain if e is network function virtualization the dns are the virtualized network functions this is so they're very closely related so many network services routing two firewalls and even FD n can be virtualized for easy deployment NFV basa refers to both the infrastructure or platform on which dns can run while the management orchestration layer i can oversee the multiple vnf on this infrastructure so it's much more than just having a virtual software instance of a different function available and I'll talk more about this progression or spectrum of offerings available the infrastructure layer has both a software as well as the hardware resource is player in the past much of the NF e has been focused on the data center or there it's been deployed by providers or enterprises but the interest is that holds huge potential for simplifying climates across the land because in the land we have lots and lots of ranches where we might want to more simply distribute services so in the next slide let me just quickly review the the benefits that n of E brings to service delivery and as we go through this you'll see parallels to the business goals that we have for Sdn as well in terms of land connectivity right so first and foremost as a goal was to quickly roll out new services and locations and given that becomes easier to efficiently distribute these services who needed locations so you can see the types of branches ranked since now we have four more locations that we might want to virtually deliver services to I've seen multiple VN EPS can also reduce a set of appliances or the required or or open up the choice of hardware it's all simplifies all aspects of operations the procurement - training - sparing capacity can also be easily scaled up and down and then virtual lifecycle management reduces downtime so if you have a function that went down or in an upgrade virtual as opposed to an appliance deployment simplifies this as well so it's very easy if you look at all these benefits to see how the objectives are very complementary and whether you're applying them to network services or to the win in particular so the next slide let's as I hinted ad hinted at sp1 and if he are very complementary solutions but they're not the same but they're very complementary any solutions that have both capabilities are extremely powerful so there is some of overlap let me just talk about three key aspects or sort of use cases where Sdn and NFV make such a strong combination and make so much sense and so basically a nfe dynamically create services you can put them in different locations Sdn as I mentioned earlier can provide agile connectivity as well as the policy based service chaining to get the traffic to the right locations where the services are offered those two capabilities go hand-in-hand are the primary goal of Sdn is to simplify branch deployment after you get the basic connectivity deployed to the branch the next thing that will come into question is all I want to deploy additional services at the branch how can I simplify that as well and if he provides the architecture to provide the desertion of virtual network functions at the branch as well then finally the path enter via especially as used by providers really helped to move more services to the clouds thin out their branch virtualized services and hanhan you need a next-generation extra generation LAN that can optimize and simplify access to cloud hosted services as opposed to traditional on-premise services so all these things go hand in hand makes for really a powerful combination so that's on the next slide let's look at actually how closely Sdn can actually support whole concept of nsv saw start from the left-hand side alright so one advantage obviously of software-based Sdn is programmability and even better as the hardware independence alright so so there are solutions that I was a software they may used priority Hardware most solutions actually more independence by leveraging commercially available commercial off-the-shelf hardware or white box hardware you'll find many vendors still prepackaged it because it provides convenience and of combining the software the hardware and also optimizing the configuration of the hardware for the particular branch deployment so next on the scale is is offering fd1 as a virtual machine image pouring the key hypervisor sandpaper that simplifies the portability across different hardware platforms and configurations however neither these two things on the Left don't really offer the true simplification of multiple virtual service delivery nfe is more than just having or supporting your typical hypervisor on the right hand side is true ft n plus n of e so capabilities you'd have to include would be our I Do's 0 touch deployment bootstrapping licensing of the services of dedication by service chain among the multiple services that are deployed on the same platform and I troubleshoot problems that might arise I don't do the lifecycle management of the different vnfs and then also obviously how do I support the API to provide the Sdn program ability to to other systems so the two real combinations of Sdn and NFV are the implementations on the right hand side so the first one is the latest through virtualized FTO and CPE those is basically an SD Wang based platform at the has native sp1 capability so something that will be offered by a nephew and a solution provider such as Val cloud but it includes the ability to insert additional and most likely selected virtual services and so it includes that again to achieve the goal of distributing services easily to the to the branch and further to the right you have a general-purpose nfe infrastructure management orchestration platform of meant to really deploy all services not even necessary related to to st-1 at Southwest one could just be one of the service on that the two right hand side deployments are in fact true nfe type of deployment ii support st land on the on the next slide the concept that I want to highlight is looking via blue tations and keeping in with the keeping with a spirit of Sdn the ability to offer choice and an open platform is very important so if we just look at that that that aspect right the on the very left hand side you might have an NFC solution that could provide nfe benefits is primarily for vnf that come from the same and the single and a V vendor and simply having a simply having directly competing vnf services and while technically may not from a business point of view may limit such a platform's ability to offer additional best-of-breed choices and partnerships in the middle is the example of a more open approach this is the in fact the approach develop out of taking a little offer nfe capabilities tied in a mercy with its own st lan solution but for selected so very selected set of network services that are most relevant for branch deployments is where it's different from general-purpose nfe that can also handle the data center side as well so most relevant for branch deployment such as firewalls but the target would be to have open platform a non-competing platform that enables delivery of best-of-breed partners for the selected a fee of interest to the enterprises such as firewalls and on the the right hand side an example of general purpose and a v platform alright these are actually now being packaged for the market by by service providers as virtual CPEs and this can actually offer Best of Breed choices for all the services including for the SDM service sua solution provider the advance providers envelop out does this need to provide the AP is or their FD when vnf for easy integration and orchestration by a general purpose and a V platform oh there were a lot of different concepts some time about fq an Sdn and NFV but summary hopefully as you have seen these three things share very similar principles and objectives but they have five different applications slightly different implementations the bottom line the solutions are highly complementary and there's some overlap between them and any combination of functionalities across these three the spheres are very very powerful and I think the zero commonality is the VN benefit or goal which is agility I think that's top of the list reduced cost availability or redundancy interoperability among multiple systems so now open choice and also really support the corresponding move to software and to the cloud and then these are five for all given these three technologies we've been applies to all aspects of the m10 network and services as well doing that that's the end of my prepared slides hopefully I have given a good intro and overview to these three different technologies and how they relate to each other and let me turn it back to Sasha cause I think we'll have time for some some questions thank you Steve we have quite a few questions so let's jump right in just a quick reminder to the audience that the recording will be available within an hour after the session is over and then you can download the slides from the attachments section your interface click on the attachment tab and you'll see the link to the slides so with that we're going to start on the questions so Steve first question how would you assure performance for an additional vnf inserted into an SD when edge that offers NFV capability all right so some of those actually goes to market the NFP ready version of the platform would have options for different CPE devices and they would typically include additional pores that are necessary for the sizing required by the Pacific vnf that are added to that basically vnf ready sty edge for example would typically have more cores to support the additional functionality that would be virtually instantiated alright if the if performance and security can be achieved over Internet links what benefit would there be to use an SD when over MPLS so the yeah so the number one benefit ashley was the unified visioning and the ability to move application flows independently across multiple links so fact the one of the typical an ideal deployment is if there's an existing an MPLS link to use Sdn to add in a link or take a backup internet link and bring it as an active resource into the virtual LAN bundle and then - based on policy business priority and also link conditions move traffic across the appropriate link I think I mentioned truth is in that example I showed might have degradation on the broadband link and you might want to move traffic back to the private link or you might have a fiber cut on the private line can move trash back and forth really the benefits of sto and in terms of the programmability the chance for independence supply across any type of links and in fact the more different and diverse type of links well as providers that you want to use the publication value becomes even greater alright thank you on to the next question how is the edge configured to work with an existing customer provided firewall so basically the there are many different deployments but the timber recommendation is the nephew an edge would be on the land side of the firewall because basically the eft-1 will typically also do the VPN encryption as well so we want to make sure the firewall has full visibility before putting the traffic into the into the SD when Sdn tunnels that also give the easiest set up for the SDM to allocate traffic across the the different links and while the some of these ft wide solutions will have built-in firewall capability for the native services these are all virtualized on/off options so if you're using an external firewall you would just turn off the internal firewall capabilities to make sure there's no conflict all right next question given that Sdn can do load balancing across multiple links based on app traffic and other parameters will Sdn make when optimization technology obsolete so the I think it's a middle ground at it certainly certainly reduces the requirement for new deployments of Lion optimization because the fact the pathline application was used for for legacy apps also running deployed on-premise running across long distance and running high-quality but limited bandwidth connections though all those issues are going away the one issue the FDA and solves is by allowing the use of broadband connections who bring in economical bandwidth so the deduplication compression is no longer required the ability to go directly to a cloud location as well as the distribution of applications from a central enterprise location now to the cloud automatically reduce the potential latency that an user has to face to get to his deployed application so basically the ability use broadband and the Internet and actually to go straight to cloud applications that reduces a lot of the problems that when optimization used to be used to solve but there's some advice some cases where it would still fit for sort of a legacy type both app and circuit deployment all right um just a quick reminder to our audience that we were hoping to wrap up the webinar about 10 minutes to the top of the hour but given how many questions we were receiving will probably stay on till 11 a.m. Pacific so if we don't get to your questions live we will answer them via email following the webinar so keep sending them in and let's see what you can do okay so Steve next question is if you could provide your opinion on this so the questions we've we've heard some SD when providers tout SD when is a replacement for MPLS VPN my opinion is that it's not replacement but rather an enhancement what are your thoughts absolutely I think that's the way to approach it I really is Enhancement you can add Public Links you can add LTE you can add diversity of types of circuits but to maintain that diversity MPLS is one of those diverse types that have certain characteristics that are good the the other thing that we should distinguish and it's very critical is between use for the for the last mile access loop as versus what's used for the mid mile or the backbone so we have to think there is tremendous use for hybrid on the last mile should be an MPLS plus a broadband link for last mile is obviously use cases that we see from enterprises for completely over the top to the last mile so one single broadband dual broadband in fact even dual LTE for for mobile sites but actually with the introduction of the manage FD web solutions from different service providers the other benefit is it could be hybrid from off net to on net in that case you can use actually hybrid links to the last mile or even over the top internet only for the last mile but if you have a gateway deployed at the cloud access to the MPLS port and internet traffic for last mile that's the only thing available can still hop onto the private mid mile of backbone or a long distance SLA guaranteed journey for example they really go hand-in-hand very well and next question I actually have two questions that are very similar let me read off both even maybe you can combine you answer so the first question is if the on-ramp is via broadband access or LTE how do you assure the performance and the other question was how do you assure performance over Internet all right so that's similar so basically it's the we haven't really coined that the market really hasn't going to standard term yet but it's more engineered performance as opposed to contractual business SLA performance and we basically do that most optimum by having multiple diverse types of links as I mentioned it's it's assured via the link staring so assuming because I can measure the link condition of the multiple links I can choose one length versus another and then addition I only have one link or both links happen to have a problem at the same time which actually does not happen that often use to chosen diverse providers as well as types of links and then we can do the remediation that can still cover for pack a loss as well as jitter problems and then the path selection can help with latency in case there's a hot spot across some internet peering point as well obviously a few multiple links and there's a two fiber links and both fiber landings are cut by a tobacco then and nothing will help you in that case alright next question is the traffic encrypted between edges regardless of link type for example Internet MPLS well that one I can't answer in general but I'll answer for the belicoff solution so it's a policy decision so one one option or advantages some we're going to have then unified secure communications same end-to-end encryption across any link even over a private MPLS or additional security or by application or by link they can choose not to use encryption based on either the link or application as well we have we have all those policy driven options sort of airing to the programmability spot in Sdn type solution all right so next question how many and where are Vela pod gateways located do the edges go to the nearest gateway can I control security at the gateways so we have gateways distributed at all the major cloud data centers so just slightly under 540 locations worldwide for example in the u.s. there are already 10 primary locations the edges will connect to the Gateway that's best optimized for the destination / example a single a single edge and a single branch might connect to the nearest gateway because the Salesforce application or the Skype for business is located nearby the branch and we'll use the nearest gateway that's actually to that destination if that edge is also connecting to a gateway for a tunnel connection to a legacy data site via interoperable VPN tunnel and that edge would connect to a gateway that's closest to that legacy enterprise data center I see us answer and I'm not sure about the question I was curious obviously we we control the encryption we control the hand off the VLANs we do not have a built-in firewall for example at the Gateway that's really a function of the energy services that will be offered by the provider hosting the sd1 as well as other security solutions in the cloud now we have time for a couple more questions so I'll just go on how do you provide connectivity from a premise to a cloud service that requires a layer 2 Ethernet interface so sound solution is a is layer three overlay so it's not not a layer 2 device as a virtual CD for your branch next question is there a specific virtual CPU work with the do provide one on the those two definitions on the virtual CP so for the time about the NFP approach if it's our SD web platform we will provide the the underlying and if the software structure as well as the hardware and we source our hardware from multiple providers the or if it's our it's our SD WAMP solution as a vnf for deployment on a more general-purpose nfe platform for example a TMT announced managed ftom service with Velo cloud and they are offering something called 18t flex wear which is there which is their universal CPE have a couple of different flavors on that so they deliver the virtual CPU is delivered by our service provider partner along with the orchestration all right next question you mentioned that link stats were locally available to make forward in decisions can I get a centralized view as well oh yes no absolutely so the yeah from one hand is very important to have those links stats available at the local edges as the forwarding decisions can be made without any latency without having to have a connection to the remote controller or Orchestrator on the other side we do absolutely all these stats up to the orchestrator for a nice centralized view so a centralized itea traitor can easily troubleshoot down to an individual branch down to the individual links in a multi-link setup and figure out quickly what's going on absolutely alright next question does office 365 software service use develop loud services so the so basically goes back to the Gateway question so we are deployed at all the major cloud data centers so I believe will find that we are either in the exact same facility or definitely within the Metro NFC that's a key is to be in the same Metro in the same very low latency between our Gateway handoff and the target cloud application all right so we should we have time for a couple of requesters I know they're still coming in we will try to get to as many as possible live we also want to be sensitive off time and so if your question doesn't get answered we will email you with the with the answer next question is how many when links are supported so this depends on the different platform so we have a variety of platforms in our portfolio I think that information should be available on our website but on the lowest end we'll have two Gigabit Ethernet ports we'll have one or more SFP ports that can support fiber interfaces for example and then USB ports that will support LTE modems on the larger boxes will have a larger number of Giggy directory Ethernet the interfaces for wine links really depends on the configuration of the platform okay two more questions number one other other risk API so to programmatically control if you went oh yes after I mentioned the key aspect of Sdn and envelope tiles case we actually do already have multiple providers that are using our REST API to integrate actually two different use cases both to their end of the platform orchestration as well as directly to their operational backends actually bypassing our management GUI interface all right we have a couple minutes left if there's a there's a question here that might require some time to answer but I'm going to ask it anyway can you give a real-world use case of Sdn service chaining to NFV deployed services okay that's a great question as reference I believe I covered that in our service chaining webinar so there it would be a slide in that deck but let me just try to walk through that use case the store in the past or there were many fruit services such as firewall security now we're centralized in a single enterprise data center but then the downside of that is all the traffic had to be back halt with nfe becomes an effete becomes much simpler to distribute the security services either to multiple enterprise regional security centers or many regional data centers or actually over to the cloud as well without having st1 we'd have very coarse and then complicated routing updates you would need to do on our branch by branch router for hundreds of branches or thousands to get traffic from different branches to different trivia locations as opposed to one central location sto an application level policy enterprise wide profiles can really simplify service chaining to send traffic from a branch to many different locations where nfe might have populated a firewall or other security service it's really the okay Billy goes hand-in-hand with making an NF e distribution of services practical from a network configuration point of view very good very good question Thanks all right we're going to have to wrap up there's still plenty of questions that left unanswered we apologize but we're just out of time quick note steve is going to be presenting another webinar on December 1st so please join she's going to be tackling application performance anyway thank you so much for joining listening and interacting with us Steve thank you for the presentation and we'll see everyone next time thanks everyone for joining thank you

Channel: Information 12

Views: 23,468

Rating: 4.5658913 out of 5

Keywords:

Id: aFmAjeVxZFE

Length: 60min 16sec (3616 seconds)

Published: Fri Oct 21 2016