Cisco Software Defined Access Evolution

well good afternoon good morning good evening depending on where you may be we'll talk a little bit about SD axis and its evolution and I'll give you my view on where I think it's it's evolving too and share with you some of the details of the recent improvements and features that have been introduced into SD axis my name is Victor Moreno I'm a distinguished engineer with the enterprise business entity within Cisco we're the ones that actually build SD axis we also oversee all the integration with SD Wan and I'm particularly in charge of basically interactions between domains so data centers the campus the way etc there's zero the protocol is running underneath days I've also been responsible for some of the definition of those protocols so deeply involved with this project so hopefully I can answer all your questions so we'll talk a little bit about SD axis where it's at and where we're taking it and and basically where we're taking it is we're giving you a distributed footprint of the access network basically to cover your global global enterprise and maybe beyond how we integrate with the sd1 how we integrate with data centers those are going to be basically two two key topics that we're going to cover and that will basically cover the time that we have allocated for our conversation is this afternoon so you're probably well familiar with the whole message around this loop of expressing intent driving it into the infrastructure achieving levels of security that we couldn't achieve before and then constantly reading and monitoring that infrastructure with telemetry ingestion and taking basically all that information and processing it sometimes in real time sometimes we will basically provide suggestions on what to do in the network and keep that loop going so that that network is healthy right and when we first introduced as the axes that was probably one of the first instantiations of this outside of the data center we've been doing some of this in the data center for a while and with ACI and what we drove in SD axis was the ability to combine wired with wireless was the ability to provide mobility at rates that we couldn't address before so the entropy that you find in in the campus is much much higher ironically than what you will find in data centers just because people follow no pattern there's nobody pushing a button there to move a VM people basically come and go and move around or you have robots in a in a in a plant where you're actually trying to follow these around but in any case mobility and it became evident with the spread of malware that segmentation was going to be a key play for us to secure the network and not just as we had done it in the data center not how we had secured the data center from the rest of the network only at the perimeter but also keeping infections from actually going from user to user keeping me from basically air-dropping my virus into your computer was basically one of the key things that we were after so how we did segmentation in there was basically something we did at two levels we did core segmentation creating virtual networks with V RFS and we provided mechanisms to automate that and speaking of snowflakes right there's many ways that you could actually have implemented this we chose what we thought was the optimal way and we basically automated that so you have a very efficient way of delivering segmentation in an automated manner so where this is evolving to is it goes beyond just the one axis site to cover a multitude of exercise and you could think of an exercise as anything from your main campus ranging all the way to your smaller branches right and we want to have the policy that we've defined for the segmentation actually spanned across that entire infrastructure into it it's no it's a little benefit to be able to segment in one pocket when you actually go to some other location and and you're out of a segmentation and security zone right so so basically think of this as our evolution of the SD axis from location to a multitude of locations to cover a global footprint in doing that we basically bring in DSD where as an integrated component of obviously axes so you will find that basically all our sty and offerings are tightly integrated with SD axis moving forward so so now we have a consistent view of the network which we can actually manage through the same principles of defining policy automating the implementation of that policy and constantly having an assurance loop alive but we can actually take that those principles all the way from the axis of the network regardless of where the axes would be all the way into the data center so we drop you basically at the footstep of the data center and then I'll talk a little bit about what we're doing to basically have those data center networks interface with this axis network that is fully segment right so that's the vision the vision is that we can now create one network that interface with the second domain so rather than having a multitude of smaller domains we're gonna look at this as one big domain how many of you are familiar with SD X is a safe to assume most of the room okay so just a very quick recap on what it is think of a network that is delivering overlay services and in a normalized way basically giving you layer 2 and layer 3 services as well as multicast policy etc all basically following one single principle so that you're not creating snowflakes and and then having a base basically the management infrastructure that can give you all the policy driven behavior as well as the automation and the assurance that we require right so that's our management layer that management layer is basically driving behavior in a network that has a few roles so we have control plane nodes that are going to be the place where we maintain the state regarding who connects where so your computer connects to wireless network and we're going to keep track that that wireless network is actually dropping you at this particular switch and we by knowing that we can basically deliver the required policy to those ports again another device connects somewhere else and I keep a directory of basically what the locations and policies are for the different elements that are connecting to my network very different from a routing protocol I'm simply maintaining a list of who is connected where under which policy conditions right now this is one pocket of the network and we have borders to that network so that whatever framing we're using within that fabric is terminated at those borders and I now have an network to network interface that is going to allow me to communicate with traditional IP networks with the internet with your legacy network and we have what we call edge nodes and those edge nodes is are basically where those devices connect right that's where I'm going to apply my policy that's where I'm going to be able to recognize who is connecting to the network and all we do is basically create tunnels amongst them based on the information that we have registered into the control plane so there's some very efficient mechanisms in terms of how we support mobility when it happens here and how we update that control plane plus the caches that we have here we've reduced a state that is maintained in those nodes significantly only relevant flows are going to create state in all of these nodes so how do we take this beyond a single site and take it to basically a multitude of sites and when I say multitude of sites we're talking thousands tens of thousands right the entire footprint of vehicle the enterprise so basically we've tagged this as the distributed campus there's an internal joke at Cisco about well you called it multi site but multi site in the data center means one thing if you're in IC island means a different thing if you're in a VPN LAN and it means yet a different thing in the in the in the case of account so we refer to it as a distributed campus but you still see some references to multi site as the architecture in our case it's under the control of a single management entity but what we have here is those roles that we mentioned before where we have a control plane borders and edge nodes are basically present in each site and the goal of doing such a thing is to actually give you independence from a fate sharing perspective in each site okay so if my control plane goes bad on one site or my border start failing in one site I lose my internet access on one of these sites that doesn't affect the other site one of the examples that led to the inception of this was basically the case where we had an emergency room in a hospital so they liked the idea of the segmentation etc by they they came back and said listen the emergency room cannot be have any shared fate with any any other part of the hospital or the hospital system for that matter as a small footprint where we had to basically dedicate things now if you think about it this looks very much like what an OSP f network would look like area zero areas one two three so it makes sense to structure things in this way autonomous system 6500 one two three and some autonomous system in the transit right so so it's not it's not counterintuitive to structure things this way now some of the benefit that you get is that not only do we have this structured in such a way that that you get the independence from a fate sharing perspective but you also get some interesting scale benefits because now one site only needs to have basically information about what's locally connected so what I'm keeping in this control plane here is only what I have locally connected anything beyond what I have locally connected is going to be and to the borders and basically opted into the transit to get to the other sites mmm now the difference between what I could do with those PF with three areas and an area zero in the middle and this is that now I can do mobility across the site and still maintain that very nimble state so what happens is the hosts get rehomed from one site to the next and I maintain basically my scale controls so as far as capacity planning goes basically I'm planning for this state both in the size of the caches on the switches at the edges but as well as the size of the control plane capacity okay in many cases you won't need the mobility across the site but when you do basically there are ways to engineer the control plane and the transit so that it can actually scale horizontally to whatever size you need to do such a thing right so we have some in the transportation industry we have some interesting use cases where you're actually seeing mobility across a multitude of sites and the sites are actually regions geographic regions so the other thing that's interesting here is you can have independent services like Internet access and things of that nature so let's look at it in a little more detail what happens is that we define what we call a fabric site right and the fabric site is basically that independent entity it has its own control plane it has its own edges its own borders but it can also have its own Wireless LAN controller it can also have its own instance of an ice PSN to actually enforce policy it can have its own instance of DHCP servers of DNS servers it can be as independent as you wish to design it or it can share some of these services with other sites in general the bare minimum are the control plane and the borders are dedicated to the site and you can have basically sites of different sizes they they align with the design portion of DNA center where you're actually defining your geographic regions and your sites but they can be as small as this room and they can be as large as an entire city or a country okay all depends on how you want to design things so example this would be an example of the ER in the hospital just one floor this could be an entire building that happens to be one site and it has to survive whatever everybody else does you may have an entire campus that can be a site in the case of Cisco in our campus we have this pocket right and and engineering seems to align with those pockets we got clusters of three or four buildings and and basically the design for for the Cisco campus would be something like that we'll have three or four buildings that have are their own site and another three or four buildings that are their site and no one there building ten is its own site but you get the idea right now all of this is built so that we can get to the data center whether that data center is our own private data center or that data center is basically in the cloud we're building this so that we can get to the data center and I'm showing a logical representation of a site that could be thought of as an exchange site but basically we're extending the same policy models all the way in the segmentation all the way to the footstep of the data center and I can go into my private data center and I'll show how we interface with a CI by putting basically an SD a a capable device right in front of my of my a CI order yep picture I've got a question so on your slide the green routers are control planes and the red routers or border routers are that are the red routers actually the orange ones yes are those border routers just running Cisco IOS or are they capable of doing this with some kind of Sdn like the one from patellar so yes there's yesterday a running iOS okay they're running iOS into the teller code eventually gets merged into iOS and it's a matter of a quarter - okay so this because this looks like a classic SD landslide to me yeah okay things are coming logically together okay yes just my great great insight but yes so so these routers will eventually and I'll walk you through the through the variations that take was there over time right they eventually become a single device that is running both the sd1 code and the and DSD access code and they are basically one leg twitch that's where we get to that's where we want to get to at the border it can be when it couldn't be Metro as well so see this little cloud here right that could be a metro network and I I don't need to deploy a full-on sty on solution there I can basically use native do I have a border router but you have different areas right or you have a fabric side a transit area and a fabric side right and then you go through the borders yes I'll show you exactly after this slide where did it go but basically we will we will encapsulate from the ball from the edge to the border do another look up encapsulate again subject that to whatever policies you have there if your policies are going to say for application they follow service provider one or service writer to you will apply that there you will encrypt if you want to encrypt and then get to the to the remote border and then do another look up again there's many variations of it which we will walk over okay but yes they they can be shared it's short term they prolly or not now this whole thing is a fabric domain and the fabric domain consists of fabric sites and the fabric sites are connected by the translator I think that's become obvious by now there are two types of transit there are transit areas that are native SD axes and they're basically using the same control plane and encapsulation that we use within DSD is the access sites and there are transit domains that are what we call IP based transit and they basically are seen from nest axis boarder perspective as handing off the traffic to an IP network now that could very well be in the form of a traditional LAN it could be in the form of an MPLS set of circuits from a service provider or they could be basically a Vitello network at that point a victor yes I see it up here in the corner this DNA see one point two and I so I'm assuming you're saying you have to be running this code to be able to use correct okay yes thanks for thanks for calling that out i I do really bad with numbers so I tend to ignore them separate and that was like there's a reason that's there yeah that so that's the evolution that's what's being introduced right so so this was released very recently I think one or two came out last week and one dot H has been there for not too long but but it's basically this is our our latest release so when the transit is native basically what you see is a fabric site with borders edges control plane it's all controlled by DNA Center right all the borders all the edges the control plane and then you have basically a transit site that is running the same technology and it has its own instance of the control plane okay so as I go from left to right I look up on the left control plane I get my route to the destination if it's not known locally it means it's somewhere else I go to the border from that border I do a second look up I go to the next border and I iterate this way I show one transit you could have the concatenation of transits and different flavors of transits all managed by DNA Center it's a common policy end to end what you see here at the bottom is basically a V excellent header that contains the two sets of metadata that support our segmentation we support micro segmentation based on groups and for us to enforce it we require the carrying in the data plane of group tags so you can see how the group tag is basically maintained as we cut across all the domains nothing special to be done there the other part that is important is the virtual network ID and those are basically 24 bits that identify which vrf the traffic belongs to so that's how we support micro segmentation and micro segmentation so when it's native right so the question that was asked earlier basically we can use the native technology very simple to configure the only thing that I need to specify is who do I want the control plane to be in the transit otherwise all of these devices are known to DNA Center they show in the inventory without me having to do anything special I do not even need to specify which interfaces physical interfaces pointing in a direction it's all abstracted for us to the point where I'm dealing with this at a very very simplified level ok so I can I can create a network and put a transit in between with very little effort now the feature said that you will have here is the same feature set that in the transit is the same feature set that you would have in the SD axis no more no less and that might not be sufficient for you to go over what could be why they're in it in general we we recommend the use of this in the metro area but it's basically all it needs is IP connectivity to get from one side to the other ok the SD axis uses the list control plane for the population of that database that we talked about and we have basically the list control plane at each at every stage ok so this is a the native transit and and we described this already basically this is native transit fabric site through transit to fabric site we have n cap and D cap those solid lines with the dots are basically indicating a tunnel the tunnel is terminated doing the lookup terminate it again doing a lookup ok so i'm concatenating these tunnels now I have in most cases a wine that is already operational it may be a service from a provider it may be something that I've done with dmvpn or something else that God forbid and maybe something that no it's not even provided by Cisco but the the model continues to apply and the way we apply the model is basically my management is unified in terms of the segmentation end-to-end what I'm going to do is within my sites everything continues to operate the way it operates I am normalizing operations to what we considered to be the least common denominator as far as network to network interfaces for segmented networks goes this is basically interests up ssin a veer which some of us refer affectionately as we are a flight so basically we've two routers back-to-back with a bunch of villains in between and we align brf's to VLANs and we run a routing protocol instance in each over each one of those villains and you can now keep your your VR so this gets you the continuity of the virtual network across so you can see the the yellow tag they're in different frame formats basically contains the same set of information it is strangled down from 24 bits to 12 bits here at the edge but we have found rarely found an enterprise that will exercise more than 4,000 v ends usually it's 5 or 6 so I think we have enough spacer now do these handoffs become a challenge in in provider networks and when you're having doing this as a service and being a multi-tenant host er yes there's other ways of doing this now what we're saying is for enterprises that are already doing things in the when we can actually integrate with them and get you the experience of end-to-end segmentation now the red tag is lost in that nni right let network to network interface I'm losing the red tag so what do we do we basically transfer the information on which IP addresses belong to which tags are and yeah so that means that there is a reclassification table at these borders so when I get to traffic I'm going to look at the source IP and I'm gonna impose the tag that SXP gave me okay so I give it continuity so that I can apply the policies no matter where I go now there's always a catch right there's a little bit of manual configuration that needs to occur especially here we have workflows for this we don't necessarily for the border on the SDS side for whoever we're peering with you're gonna have to basically set up a bunch of VRS and and and the BGP instances that you have over the VLANs that go over the viera flight okay and I believe the SSP was not automated either so so that is XP era that you see there basically it's a couple of commands saying yes because XP with this guy it's very gossipy anything it knows it's going to communicate and I believe Essex business for secure exchange protocol or something of that nature you're probably more familiar with it and I done I intend to be but then in Iowan - oh we have a similar type of handoff now I went to Oh has the characteristic that or 2x I went to has the characteristic of being able to carry the group text ok so we don't need DSP bridge out-of-band same model Vera flight but now in Viera flight I can I can include the group tags and I don't lose any fidelity in the group text is always 16 bits wherever you go and basically that's a layer two framing that I can use to actually carry group tags over that vieira flight link okay so what I've eliminated in the case of i-12 is the need for me to actually have an SSP arch between the between the borders in one site and the borders in another site so this is what I refer to as our IP option for for the transit okay so so you can see it's very it's very generic now in comes with teller right so we buy the teller and and now well guess what the teller doesn't support the group tag so we need to give continuity to that so we need the arch back in again at least in the first instance she a ssin of it okay so this is fresh out of the box we just purchase our Christmas gift we paid we paid six units of some sort for it and and now we have basically our new Christmas square you get it out of the package of no tags sorry okay let's we do the same thing now but we have an opportunity we have AP is we have AP ice so you can see how we can integrate the API so that least the yellow portion of things are automated as we cut across these domains okay so that's the foundation of the first stage and integration is basically okay let's assume we don't carry these and we're just going to do API integrations where I can automate the creation of a virtual network so now I go to DNA Center and when I go to DNA Center in the workflow where I create my V ends I create my V ends once and if I say that it goes across the domains it will go across the domains and it will trigger the creation of a VN to transport this in the manage no no rocket science there the next step is well I can pass the SU T's here and the wine doesn't really need to do anything with the SU T's other than just transport it right so that's stop number two in the integration which takes us once you have that integration of the data plane well if you change your interfaces now it can be brought to one box so now I guarantee su T's directly and if you've looked under the hood of what we tell our does they basically have an MPLS label stack so you can you can first see how we can add you know any sort of stuff we want to put in that packet weekly at potentially so it looks like to me that the end result of using patella to do this is the cleanest approach yes so does that mean that you're not going to be putting much effort into doing this for whatever comes after island 2x yes okay so the way forward is Vitelli SD Wham that's alright went three oh yeah okay good answer so and you can see how we can basically have the API I don't know why the error is not there but so this is our direction okay I don't make very clear that this is where we want to go this is where we're headed where we're at is probably the first light I showed you with with the VIP teller separated by a veer flight wedge okay I should be more affectionate with the area flight because it does solve a lot of problems but and locally to wedge but so so now you've seen how we have these multiple domains and basically what you saw in the last few slides is basically us creating those network to network interfaces between the data plane and the control plane so we create that linkage right now the management and orchestration systems are either totally decoupled or loosely coupled but they are independent and they're independent for a good reason because they're doing different things in the case of the when we're looking at application recognition we're looking at choosing paths based on application we're doing all sorts of interesting things in the case of the axis we are basically looking at integrating wired and wireless we're managing stuff that that pertains doesn't pertain to to the to the transport in the in that core in transit so so we have very independent independent systems same thing applies for the data center right the problem space in the data center bears little correlation to the purlins space that we have in the in the campus and when okay so expect those management orchestration tiers to remain independent loosely coupled through API calls right so I can choose to basically drive the behavior from one into the other there is no real master what we do look at in in a land of equals is basically creating a single sheet of music that can they can all read from right and that's our policy that's how we translate our intent into I mean that everybody can read and it's a very simplistic approach right now we're we're basically defining groups of assets either users things or applications and and our task is basically to define what the interaction is expected to be between those either we allow communication with this allow communication if we allow communication how do we allow it which port numbers do we want to do application recognition to make sure that it is the right application if the communication is allowed should it be subject to certain checks depending on where I'm asking from do I do different checks so if I am trying to get in from overseas versus a local site do i do i vary the path that i followed to get there and if it's a different different types of applications do they go over different when links right so all of that is defined in my policy that's my common sheet of music so all of these domains would look at it and they will interpret it to the best of their abilities okay so that's that's a view on how we get these guys together so when you look at the integration and here you will see that there's some loose coupling between DNA sensor and be managed and then as it pertains to the data center there isn't really any management coupling because that we're not handling common devices the interface of the data center we expect to be basically this very flight air-gapped handoff for the most part actually for all purposes because what we don't want is this separate management system to be controlling a border and then this other management system to be trying to control the same board so we want to keep those borders within the realm of their own management systems plus we want to normalize this to not just be the private data center interface but also be the interface in TOR where our cloud services right so what we do initially is we exchange identity information between those data centers sites and an our domain okay so now we've simplified this whole structure that had all these different moving parts to be one domain and that domain from a policy perspective from that single sheet of music perspective is actually communicating with the neighboring glooming now that neighboring domain is rich in itself if you've heard about things like ACI everywhere what ACI everywhere it is doing in a nutshell is trying to normalize the interface and how you've modeled applications across all that variety of clouds and presented in a way that basically maps to our view of what an identity is or what a group is okay so two halves to this and we basically need to have them talk to each other so in order for us to talk to each other we're going to exchange identity eventually we get to a point where we can exchange both identity and policy so if you have defined policies in one domain and I only showed the data center and and enterprise network because that's what Sisko controls but the reality is there is a domain there that integrates in the same way that is a security domain okay and cisco has an offering in the secure domain as well it will it will complicate the graph to a point where it would be it wouldn't be a useful graph but but you get the idea so all of these different domains could now basically exchange information say you went into your firewalling management system and you define your policies and now you want to make sure that your networks that are now putting ACLs and and whitelisting stuff are actually compliant with that so that they don't get in the way of that policy well you can push that to a cross domain bus and that cross domain bus is a readwrite for everybody who's dealing with policy so now I've effectively normalized it okay before getting to that point everybody has their own policy domain so the key is for that to be effective you need to have complete information you need to know about the groups that you have locally and the groups that you have over in the data center and vice versa in the data center you need to have the full picture so that you can then create all the rules that apply to user to application communication so in a more graphical way this is what I'm getting at basically I have users I've classified users here by all sorts of methods I look at tool factor authentication their credentials certificates on their devices etc and I combine all this stuff and I identify them as as user Group one or user group two once I know that I am going to communicate the results of all my hard work in the access to the data center guys the data center guys in turn have knowledge that we will never aspire to have on the axis side of the house they know about all these applications well they're going to share that great knowledge with us okay so now I have policy domain one policy domain to the connection still needs to go all the way from left to right so these things better align but the first is give me enough information so that I can author the pulse on either side they're independent for now so now two independent policy domains that need to be orchestrated eventually what we get to is that federated system where it's defined once no conflict okay there are ways to get there it's not necessarily where we want it to be there's a lot of development at Cisco to actually get to that point one example of systems that are separated that way is you will see ant iteration analytics that we have ways of actually doing segmentation within the data center that is done on the host it's not done in the infrastructure right well they understand all the grouping that we're talking about they render this into IP ACLs or they call it IP lists basically the community communication here is here is Group A and by the way this is the list of IP addresses that belong to group a so when he receives a packet from a particular IP address he knows that it's from this group and we can define policies consistently as groups relationships between groups okay now that same principle and and of course I continue to enforce my user to user policies in in the in the axis network right so that continues to be critical and what we will find is that there is some semblance of groups no matter where you go in the data center space if you go to open daylight it looks very much like what we like what we offer if you look to a CI of course it's pretty much identical if you go into Amazon now it's a series of tags and it's a little richer than just a flat structure of one group per endpoint now when you start combining those tags with certain rules you can actually distill that into a flat space of groups and that's what we do with our tool for the cloud policy integration where we have the the cloud policy platform that allows us to basically write the conditions on how I combine those different tags to translate them into groups what we're doing is basically normalizing all of these different clouds assuming you're not using a CI everywhere right but we're taking the tags that are being exposed on the API is from the cloud and we're distilling them into groups that we can manage and we can continue to establish the policy just the way we do in the SD axis ok so that all gets distilled it gets communicated to our identity services engine and there we can now basically offer this to the a CI domain or for this to the SD access to me and apply policy no matter where the workloads go the policy is the same and for that scenario where I have policy defined in one place policy defined on another I may want to use eyes or some of our partners Olga said toughen to actually make sure that there is consistency okay so there's ways to instrument is today where we can actually start checking for that consistency of policy one thing that I find interesting is that we will be applying policy within this domain usually when we go to the IAS offerings is up to us to apply the policy there so I would say that even a VP C that is leading into the applications is now part of our access network from that diagram that we saw in left and right that falls onto our so we put basically a CSR 1000 B you see demos up in in the innovation cluster where you have basically an implementation of a footprint of SD axes in a container so you can put it right in front of your work look but the key is that we're basically stretching that access network all the way to the foot of the data center and then and then you could argue that well the policy is only being implemented on on the left side there's really no policy user to access policy being implemented on the right side of that at which point exchanging identity only it's enough you only have one domain proposed and that brings me to to the footprint so this is basically our network and and it looks very much like an SD one diagram right so it's SDA in all sorts of flavors in different places integrated with Meraki integrated with the legacy campus bringing us to the data center whether we access that data center through a physical colocation or we take the footprint of our SDA into a V PC or we build a traditional data center and create a DMZ and then from there branch off to the cloud regardless of the model you could model that as just a cloud edge and it has three or four different ways of being instantiated but the key is I'm bringing my segmentation all the way to this edge and in here I have a full ecosystem of solutions to do things but I showed you a couple of ways in which we bring things together and translate it to the same to the same model so you can choose to enforce your policy in a distributed manner basically I have all my enforcement points at my internet access point or at my branches at the borders and now I have basically enforcement points at all the places where I can procure a footprint notice that sass tends to be the exception so for direct internet access who says you're probably going to be enforcing all your policy with the zone based firewall at the branches right or some people choose to drive it all through a carry neutral facility where they scrub all this traffic in a centralized way they put a big honking set of firewalls there and other other measures and then all of this has basically optimized links into the different cloud offerings okay the key is that whichever way you're getting to that data center we're providing the segmentation end-to-end from the axis all the way to that last enforcement point right because things can go wrong in transit and we don't want infections to go between those containers so once once I've deemed you are allowed to gex's this application well you better be clean you better not be exposed to tourism and that's basically me being two minutes overtime Briana that's a miracle I'm usually like 10 minutes overtime okay questioning in I'm a bit skeptical about the policy translation okay and so and when I say this I understand we talked about Cisco Enterprise when it comes to SDA and then also SD when I'm sure you guys are going to work well together originally in Cisco we've seen challenges working across be use so is the ACI and that and the data center of business working with you guys to do this or is this you guys independently trying to do translation in and out of a CI because I see I see three different mechanisms I see entities which you don't control cloud a we're trying to translate you've got a different business units within Cisco which you have to translate between and then you have your own ecosystem on the enterprise side which I have lots of hope there some hope for the data center clouds so ironically cloud is easiest one okay because basically all we're doing is grabbing information that is basically public publicly available from the cloud provider right so this is exposed in a public API open API we just grabbed it and and then we enforce policy wherever wherever you can procure a footprint we enforce the policy so so that integration is basically exercising API for the most part now the tool that I showed you is a tool that basically allows you to basically take that information that is not structured in the way that we'd expected and distill it into a structure that you can use so that you have one model and in how you apply pause sure that that one that one I'm confident that that will succeed okay for the enterprise two data center interaction one way to summarize it is I think we've got an increased budget for a bar tab so that the two groups can actually get together and discuss so in all seriousness we are working together very tightly this has being this is bubbled up to upper management as a priority and basically it's being mandated from the top down that we actually do go to the bar and figure it out it's really important that you can as we are working together so so what what you've heard here is basically being done in collaboration with within Insp you team and we we meet regularly and eagerly okay and then within en there is always the challenge of prioritization of features right and the minute product management hears that we can have a workaround then they're like okay so then I'll get other features in so that that's more of a once the prairies fall in place you will start seeing more and more results okay so how are you guys using the priority of those features I mean there's a lot of them and so how are you cherry-picking those essentially that I quit product management a few years back so I it's basically a business the amount okay this is demand quarter by quarter revenue the street basically it's it's printing it's printing money that's basically alright so it drives it of course there's always there's always a few slots there for making sure that we have the right direction and it continues to progress right so so it progressed faster or slower depending on what the demand is the key to all this right now is the DNA center and DNA center is not necessarily approachable for a variety of reasons to customers that are not very large so is there a point when that's expected to scale down to be more approachable for smaller customers yeah more affordable DNA center there's a lot of discussions going on in terms of how we can actually trim down the footprint of DNA Center and the key thing that is driving the large footprint in DNA center is assurance so we we have a confluence of the automation and the assurance functions on the same set of servers now you think about it some of the ideas that are being tossed around is you have a relatively large footprint in the network and all of those network devices have either four or six cores the appliance that we're looking at in DNA Center right now it's basically 140 114 course right it doesn't take much to get to 120 course of processing distributed in the network so those are some of the things that are being considered that cost is already built into your network and yes you will continue to have appliances but they will be much lighter appliances you could potentially get to a point where where you have virtual machines actually running this that's very far outdoor right but there is an intent there is there is a desire to actually get to that because we're seeing the pressure back right because the causes are necessarily aligned thank you so with everything headed that way very very very quickly what's what's gonna fill the gap there are only 500 fortune 500 companies did the math where's the rest of the market can I go when everything is DNA Center driven and rocky yeah it's it's leaving behind a massive massive chunk yes and yeah and we can't act fast enough on that and basically providing the options I talked to you about the most futuristic option that I have in my mind right now realistically the group is looking at of cloud offerings they're looking at separating assurance from from automation so you can offer automation as a package and in a smaller footprint type of things so I I see what DNA Center is and where it is but you know that's that's big companies the the smaller companies all universities the stuff like that well what's gonna happen to those customers that don't want automation don't want assurance just want management you know we're prime infrastructure is sitting now and everyone sees the writing on the wall there what's gonna happen to those people that just want to config management and templates yes the functionality continues to be offered right through through DNA Center the question is the the footprint and the form factor that that we need to deliver for that kind of customers

Channel: Tech Field Day

Views: 18,655

Rating: 4.9731545 out of 5

Keywords: Tech Field Day, TFD, Tech Field Day Extra, TFDx, Cisco Live US, Cisco Live, CLUS, CLUS18, Cisco, Software-defined access, Victor Moreno

Id: tbM9uNZ-IxE

Length: 50min 2sec (3002 seconds)

Published: Wed Jun 13 2018