Deploying Cloud onRamp for AWS, Azure, and Office365
Cloud transformation has been a top priority for enterprises, but the adoption is plagued with complex workflows and poor user experience. Even though enterprises onboard AWS or Azure, the workflows to establish connectivity, security and segmentation across VPC (and VNET) are fairly complex. On the other hand, for SaaS, the issue is primarily around user experience. Enterprises deploying Office365 are realizing that performance with Skype for Business and Sharepoint is not reliable. In this webinar we will take a further look at the wide-ranging capabilities the Viptela Cloud onRamp solution offers, and deploying it for AWS, Azure, and Office365.
Senior infrastructure technologies professional with over 15 years of extensive experience in designing and deploying complex multidisciplinary networking environments.
3089 – Deploying Cloud onramp for AWS, Azure and Office 365
[Start recorded material00:00:02]
Rachel: Good morning everyone and welcome to our webinar, Deploying Cloud onRamp for SaaS and IaaS. Today’s presenter is David Klebanov our director of technical marketing here at Viptela. We encourage you to utilize the Q & A box to ask any questions and David will try to get to them at the end of the presentation. We also remind you that this webinar is being recorded and will be available on demand immediately after this. Now I will turn it over to David.
David: All right, thank you very much. All right so today we’re going to talk the talk on Cloud onRamp, which is in essence extending your footprint of either software to service applications. Or as an infrastructure in service from primarily an on-premise deployments of today into the Cloud. So we’re going to spend some time first taking a little bit about the premise of the Cloud and a little bit about Viptela’s architecture. And then we’ll do two demonstrations of Viptela solution, live demonstrations of Viptela solutions of how we do this extension into the Clouds. So first let’s look at the shifts that are occurring in the enterprise workloads. So the data centers of today are primarily based on an on-premise architectures where the entire network compute storage virtualization stack is all hosted in the on-premise data centers.
The shifts that are occurring is the migration of those workloads in two directions. So the first migration is towards the infrastructure at the service for a public and hybrid cloud infrastructure. And here you can find the most common representatives of that—in that spectrum is of course the Amazon web services, the Microsoft Azure and Google compute platform to some degree. So the workloads are being migrated into the public and hybrid cloud infrastructure and that’s one migration that occurs. The second migration that occurs is the migration into the software as a service platform. This is where the cloud application such as Office 365, which is the most common one.
Google Applications, salesforce and Dropbox, these are some of the prominent examples of the applications that are being migrated into the software to service and are being offered as a web only front and interfaces into the user community. So we are observing a very strong trend of migrating from an on-premise data center into either the IaaS for virtualization—from virtualization standpoint or to the software to service from the consumption model. Now we’re not the only ones observing those trends, I’ve selected here a couple of quotes from a Gartner paper that was dated just a couple of months ago in February of this year. And Gartner agrees is that the cloud transformation is having a very strong momentum.
They are projecting of growth of 18 percent in 2017 for the entire public cloud services. And out of that, the two cloud services that we touched upon is the IaaS and SaaS are having a phenomenal growth. As you can see the infrastructure at the service is expecting to have a growth of north of 35 percent, 36.8 percent. And SaaS is growing over just 20 percent. So those are all indicators that organizations should absolutely consider the possibility of moving their traditionally an on-premise infrastructure into either IaaS or SaaS and offerings. Now let’s touch upon Viptela and how Viptela fits into the cloud era. So when you think about Viptela, you can imagine a fabric, so what you’re seeing here is the vFabric, which is the Viptela Fabric.
The essence of the fabric is to connect users devices and things into an application. So user devices and things are the things that live in your local infrastructures connected through either wires or wireless means of communication. The applications are the applications that live in either data centers, virtualized data centers or as we touched upon before, being offered in a cloud environment such as infrastructures and service and [software of service] . So Viptela Fabric is ideally positioned in between the users devices and things and the applications to provide the platform for interconnecting those services together. It comes with a couple of key properties and such as high security, high scale and of course an open architecture.
It also caters to a number of use cases and SD-WAN is absolutely one of the use cases and its founding use case. But it’s been augmented by the cloud onRamping and IoT and of course there’s other use cases that exist in that—that vFabric can offer. Now the fabric is delivered in a cloud, even though it can’t also be delivered for an [prompt] deployment. So it’s equally delivered as a cloud and as an [prompt] deployment and comes with a set of analytical tools that allow you to have—to dissect the information that you receive from the fabric through more of an analytical lens. So let’s dig a little bit deeper and see what are the elements of Viptela Fabric. So how is the vFabric actually being constructed?
And that is a very important thin to understand before we dive into the infrastructures, and service and software’s service. First if the fundamental understanding of how Viptela Fabric is being constructed. So what you see in here is sort of a typical Viptela Fabric that has Viptela vEdge routers, which come in a software or in a hardware form factor. In hardware form factor, these are the devices that are capable of 100 megabits per second, one gigabyte per second, 10 gigabytes per second and north of 10 gigabytes per second in a scale out and deployment. These are the physical platforms. The virtual platforms are deployed in places where the physical platform cannot be installed then, such as specifically an infrastructure as a service installation namely an AWS or Microsoft Azure and Clouds.
The virtual form factor it has the same feature parity from the physical form factor, so you are getting the same set of functionality that you would normally get in the branch offices, small offices, campuses, data centers. Now the same set of functionality as far as security qualitative services, segmentation, multi-task and a whole slew of high viability characteristics; all of that is now extended, not only to the on-premise locations, but also into the cloud data centers. So those are the Viptela vEdge routers. Now Viptela vEdge routers communicate with the vSmart controllers, which is a scale out control infrastructure. The communication between the vEdge routers and the vSmart controllers enables the vEdge routers to operate as a fabric.
vSmart controllers and the vEdge routers work together as a scale out distribution system to distribute the information that is required for the construction of the actual SD-WAN fabric. The SD-WAN fabric is an entity that exists only between the vEdge routers. So it’s a fabric that is—that goes between all of the locations that exist on your network and it connects and interconnects them together. Right? The fabric is built on the principals of zero touch, which means all of the vEdge elements that are being put on the network, video, physical or virtual, can be deployed in a zero touch fashion. And they also—the fabric also follows the philosophy for zero touch. The entire fabric is built on the premise of denied unless permitted. So all of the fabric elements are thoroughly authenticated. And bidirectional authenticated by the vSmart controllers through the use f a PTI infrastructure.
So the entire distribution system between the vSmart controllers and the vEdge routers is highly scalable, highly secured and zero touch. The vSmart controllers, in most of the cases, are cloud-based; the vast majority of our customers is leveraging cloud-based deployment. There are some customers due to a regulatory, primarily due to regulatory considerations, are hosting the control infrastructure in-house for on-premise deployment. Regardless of where the controllers are hosted the functionality is exactly the same, it’s a single product that caters for both cloud-based operations and in on-premise operations. Now the vSmart controllers can be hosted in the Viptela Cloud. They can be hosted, as I mentioned, in your own private data centers. They can also be hosted in managed service providers.
For example in the U.S. the controllers could be hosted by Verizon, they can also be hosted by a set of leading system integrators. vSmart controllers and vEdge routers provide the foundation for the fabric. Now of course the fabric cannot operate without a management claim, so the management claim is being delivered in our solution in the form of a vManage system. So the vManage system is an element that provides a single pane of glass for the entire Viptela Fabric; it connects to the vSmart controllers, it also connects directly to the vEdge routers. It’s not represented on this specific slide for the simplicity purposes, so not to overload the slide itself. But imagine that the vManage system is see-all, know-all type of element that knows about the conditions that happen in the network, knows about the conditions that happen on the vSmart controllers and is able to provide operations for the entire environment.
All of the configuration tasks as far as defining policy, configuration templates, provisioning devices, troubleshooting, all of these functions are performed by the vManage System. At the same time, each one of the elements, the vEdge routers and the vSmart Controllers have their own local interfaces in the form of either programmatic API’s or [it can now blend] interface. This becomes an extremely important element when customers are looking into situations where debugging is required. All of the elements in the SD-WAN solutions are completely transparent. The vManage System manages the entire solution. vSmart provides the control train. vEdge routers provide the data plain.
It’s a clean segregation which follows the principals of the software defined networking. An optional element on top of the SD-WAN fabric is the analytics, I already touched upon that in the beginning, but analytics provides a different angle for the data that comes from the fabric. It allows you to answer questions such as, for example, any sort of trends that are being observed in—within your fabric. I’ll give you an example, let’s say you have defined a certain SLA in—for a specific application. Now the system will absolutely alert you when the SLA is violated. For example, if you set the SLA for voice traffic to be 150 milliseconds of latency, and let’s say two percent [unintelligible 00;12:03] loss, 20 milliseconds of chatter.
The system will absolutely observe that SLA and it will make sure that your traffic is forwarded only across the paths that observe that SLA. Now you’re going to get a notification when violations of that SLA are done. However, what the vManage System is not going to tell you, it’s not going to tell you any trending information as far as how many SLA violations did you have in the past week? Maybe the SLA threshold needs to be adjusted, so that’s more of an analytical type of view. And that’s exactly what analytics platform is all about. So it provides you a different representation of an information that comes from the fabric. Now the power of the fabric is actually the use cases that it can accommodate. Right?
And the use cases that the fabric can accommodate is vast, we’re talking about delivering SLA’s to the applications. We’re talking about an ability to do traffic engineering. We’re talking about an ability to do scale network segmentation. And secure—establishing secure perimeter through an integration of layer four, layer seven, firewall IDS, IPS services into the fabric. So you can bring your own firewall of choice into the fabric, you can connect it to a regional site or you can connect it to the main data centers, you can even distribute this into every single remote office. Whatever the deployment methodology is for those services, Viptela Fabric is able to insert those services in a very dynamic and scale-out fashion into the workflow. And of course the Cloud onRamp, which is what we are going to talk about in the next segment.
Now the entire solution is multitenant, on both the vManage controller and site and it is cloud operated and it is delivered from the cloud. As I mentioned earlier, and some of our customers opt for an on-prem deployment. And the entire solution, it can be deployed on-prem including the vManage and the vSmart Controllers and of course the vEdge routers. So I hope by now, you get an idea about the positioning of the Viptela vFabric and also the solution elements of the Viptela Fabric. So having covered that, let’s now step into, specifically into the Cloud onRamp. Let’s start with the Cloud onRamp for the SaaS services. So a typical—and this is really just sort of we’re trying to do a typical representation of what a customer can encounter.
So imagine an SD-WAN Fabric that has remote sites, data centers, branch offices and maybe some regional data centers or hub sites. And consider one of the remote sites that has potentially a couple of ISP connections, maybe an MPLS connection, maybe 4G connection, basically any variation of transports that has been delivered to that site. Many of our customers are on—embarking on the hybrid WAN journey, which means they are deploying both ISP and MPLS connections at the branch offices. Some of our customers rely only on ISP connections and augment that with integrated 4G LT and connectivity. So any variation is possible. Now when you talk about software as a service, all of those primary software’s service platforms such as Office 365, Google, Dropbox, salesforce, all of these are offered on the internet.
So the question of optimal connectivity into those SaaS platforms; it basically boils down to what is my optimal way to connect to the internet. Which way is the cloud? Is the cloud my direct internet exit from the remote site through a localized ISP connection? Which one of the ISP connections is better for me if I have two ISP’s? Is it through the regional breakout? So it is better for me to backhaul through an SD-WAN Fabric into a regional site or a hot site and then let it go from there? Is it all the way data center backhaul? So the question of the cloud becomes the question of an optimal connectivity into the internet. So how does Viptela address that? We can think about it as two use cases, so the first use case talks about a site that has two ISP connections. Both of the ISP connections are capable of delivering connectivity into those cloud services.
The question is which one of them behaves better? So what Viptela is doing in here is removing the user intervention, the manual process that would’ve otherwise been happening to make sure that the traffic follows the most optimal path to an optimal ISP. Viptela Solutions, Viptela Fabric has the intelligence to take this decision automatically. So should loss and latency be—start occurring on one of the ISP circuits. And let’s say that that ISP circuit was the primary circuit for that specific SaaS application, Viptela Fabric will sense or the vEdge router, which is part of the Viptela Fabric, will sense the change in the quality of the connection to that cloud service.
Specifically monitoring for the quality of that service, so the vEdge router that participates in a cloud onRamp for SaaS is going to perform the quality probing for those SaaS applications of choice. And you would choose, and as I’m going to show you in the demo, you’re going to choose the applications, the SaaS applications of interest. So we won’t just monitor any application, we’re monitor the applications that are relevant for you. And we’ll make the intelligent decision to send the traffic through either ISP1 or ISP2. The probing mechanism continues all the time. As conditions change in the network we may take a different decision and we may route back from ISP2 to ISP1. Whatever the case may be, the traffic is optimally routed to that application, to the SaaS application of choice.
The second use case is when you are—in addition to providing a direct internet acc—
[Audio cut out]
David: You’re also regionalizing this by providing an internet exit point from regional data center or regional hub location. In this case, once the vEdge router in the remote site and the vEdge router in the regional data center or the hub site are going to perform this quality probing. And the Viptela vFabric is going to provide the intelligent routing for either letting the traffic to go direct path from the remote office. Or send the traffic through an SD-WAN Fabric into the regional hub. So the question of when through the regional hub become better than a direct internet exit? So the clearest example is if you have a local ISP connection at the remote office and that local loop ISP is having issues and the performance towards, let’s say, Office 365 degrades.
The fabric is aware that it is maybe better for the user traffic to traverse the SD-WAN Fabric leveraging potentially an MPLS transport or a different ISP transport, which does not have a performance issue towards the regional data center or regional hub and exit from there. All of that intelligence is based into the virtual fabric and the system takes that decision as far as routing the traffic to that SaaS application of choice dynamically and automatically for you. So you sit back and you just let the system do the job for you and the user population is going to enjoy the optimal path towards the SaaS application of choice. So let me do a quick demonstration for you to show you how that occurs.
I’m going to run a short video so we can eliminate some of the delays. So in here what you are seeing is you are seeing— Are we seeing it? Just making sure that—oh I apologize, it’s my mistake.
David: So what you’re seeing in here is—
David: So what we’re seeing here is a wizard for setting up the cloud express functionality, is what we call for the Cloud onRamp for SaaS applications as you had seen use the wizard to configure the applications of choice. And this is the SaaS applications that I mentioned earlier that you’re opting to monitor. You can also monitor them in a specific VPN, Viptela Fabric supports VPN segmentation. So in this case we want to provide this service in VPN1. Now we are going to save the changes, and let them go and proceed into the direct internet access site. So we’re going to add two sites that we have in the system, which is the remote site 1 and remote site 2. And what is happening here is that we’re kicking off the process of quality probing that I mentioned earlier.
And here we’re selecting which one of the interfaces that are connected to the ISP’s, we are going to choose for that probing service. Now as you can see everything shows red for now, because the system is kicking off the process and needs a little bit of time to figure out the performance characteristics. Now we’re adding, also, a gateway which is that regional data center or regional hub site, that we mentioned earlier. And as before, we need to designate the interface that goes to the cloud. Now as you can see once the system figures out the performance characteristics, it starts monitoring. And if we click on a specific application, such as Office 365, you can see that we had a couple of sites.
Site one, site two and the regional data center that the system performs the monitoring support and automatically routes the traffic over the best path. So let’s go back to our presentation. So as you have seen a system automatically figures out and performs quality characteristics and traffic—routes the traffic according to the best path from specific sites. Either directly or through a regional data center. Let’s continue with the second cloud deployment, which is the infrastructure it serves. In this case the two most prominent ones that we’re observing is the Amazon web services and the Microsoft Azure. The Amazon web services offers VPC’s, Microsoft Azure offers VNET. Again, we have the same representation of an SD-WAN Fabric, that has remote sites, has campuses, branches and now we’re talking about a cloud data center.
So it’s not a SaaS service anymore, it’s not a web-consumed service, it’s an actual infrastructure service that is being provided in the cloud. So the question now is how do we provide the same services such as, for example, security segmentation and quality of service to the cloud workloads? So now I want to extend these characteristics not only to be offered across the SD-WAN Fabric between the sites, but have those extended all the way into the cloud. The reason being is very simple, I’m moving my workloads from my data center, from my on-premise data center, into the cloud, so I want to make sure I have a feature transparency for the workloads that are moving into the cloud.
So the workloads were segregated into multiple VPN’s, when I move them into the cloud I want to be able to continue providing that segmentation as the fabric traverses the—as the traffic traverses the fabric and goes into that IaaS service provider. The answer for that is the deployment of the vEdge cloud in the clouds, these on both Amazon web services and Microsoft Azure. vEdge clouds is currently in the marketplace for both of those IaaS service providers. So the question becomes, is that; how do we make that process of expanding the fabric into the cloud simpler? And again, let’s look at two use cases. The first use case is where you have your fabric and you are consuming a handful of VPC’s or VNET’s, depends if you’re doing AWS or Microsoft Azure, in the cloud.
In which case, you are instantiating a vEdge cloud out of the marketplace and for either one of the service providers and that vEdge cloud front end can compute resources that are hosted in that VPC. So if you were to have, for example, in the case of AWS, if you were to have 10 VPC’s, you’re instantiating 10 instances of vEdge cloud and it’s front ending the compute resources in each one of those VPC’s. This model can scale out; Viptela Fabric is a very scalable fabric, it can scale out from anywhere, from single size to tons of size, to thousands of size and 10’s of thousands of size. The architecture is extremely scalable so there’s absolutely no issue for you to scale like that. But it may not be the most optimal way for you to do things.
So if that works directly front ending the compute resources with vEdge clouds, perfect. Are there any alternatives? If you want to minimize, and the alternative is around minimizing the footprint, the vEdge cloud footprint in the cloud. If that’s what you’re trying to do, there’s a second use case where instead of having it compute it directly connected into the vEdge cloud. We’re now designating a Gateway VPC or a Gateway VNET that’s front ends the compute or the host VPC’s and VNET’s. The interconnection between the Gateway VPC and the compute VPC is through a standard-based [unintelligible 00:26:44] tunnel. So as you can see in here, if I have 10 VPC’s or 10 [unintelligible 00:26:50] VPC’s that I wanted to connect into my fabric.
I either deploy 10 vEdge routers which was the first case on the left, or I have an alternative way of deploying a Gateway VPC with a redundant set of vEdge cloud routers and linking them to my post VPC’s. So I’m decreasing the footprint of my vEdge cloud deployed in that IaaS service provider. So it depends which one of the use cases you prefer, the one on the left or the one on the right. Now what we do at Viptela is we completely automate the use case of the VPC’s on the right which is the use case of provisioning the Gateway VPC and linking that into the computer VPC’s. If you were doing this, this could become a very laborious process of spinning off, configuring both on AWS side and applying templates on the Viptela side.
So of course you’d be done with Viptela very fast, but you will take your time to set up things on AWS unless you are using a programmatic approach. That programmatic approach is what Viptela Fabric, Viptela solutions offers you to automate this entire setup. So let me do another quick demonstration for you so we can walk through the process of creating that setup. So what you’re seeing here, we start off with the wizard that adds a cloud service. In this case we’re adding AWS. We’re providing API’s keys in the secret—shared secrets to connect into the AWS service. Now what we’re going to do is we’re going to select a region that would like to walk, in this case it’s U.S. [unintelligible 00:29:03] region.
We’re going to discover all of the VPC’s that exist in there, those are the host VPC’s that—where the compute is located. Now we’re moving on and now we’re talking about a transit or a Gateway VPC. We’re going to give it a name and this is the VPC that is going to host our vEdge cloud devices, in fact a pair of the vEdge cloud devices to provide the connectivity to the backend host VPC’s. We’re going to choose the version of the vEdge cloud we want to deploy, the size of the instance and also which one of the vEdge clouds we want to deploy. Of course in your system you may have numerous vEdge clouds and you’re going to designate two of them for being deployed into the cloud. Now the last step is to link between the host VPC’s and the transit or Gateway VPC’s. We are assigning a specific VPN to this connection and the linking is done.
Now what the system is going to do, it’s going to move forward and issue a set of API’s into AWS. Of course this process here was extremely fast, it will take some time for the AWS configuration to happen. So we are going to be spinning out all of the connections. And at the end what you’re seeing here is you have a Gateway VPC, which has two vEdge routers. And you have a host VPC, which were three host VPC’s that this VPC is connected to. Now let’s do a verification and see that we have all the connectivity. If we go into the monitor network and select one of the vEdge routers, and as you can see two of them were already deployed, these are the ones that were automatically deployed by the wizard.
And we choose one of them, we’ll go into the real time and we’re going to run a query that checks for a IPsec connection.
So we’re going to see a IPsec IKE, which is a standard-based IPsec connection and as you can see, six connections were established, which is the redundant connectivity, three VPC’s, two IPsec connections for each one of them. On top of the IPsec connection, a PGP sessions will run, as you can see, six PGP sessions were established. These are the PGP sessions that connect the transit VPC or the Gateway VPC into the host VPC. And it’s—that PGP connection shares the routing information that learned from the VPC’s and that’s what you see here, this is the [slash] 16 box that’ll learn from the host VPC’s. And that is being shared through the PGP and it’s been inserted into the SD-WAN Fabric for an overall connectivity across the fabric.
So as you can see in here we’ve walked through the two use cases for the IaaS deployment. The case on the left where the compute resources are directly attached to the vEdge cloud or the case on the right where they compute resources are attached—are not attached to the—directly to the vEdge and are linked into the Gateway VPC. I think that concludes our content for today, so let’s see if we have—we have some time, maybe, to take some questions in here. Let’s see what questions we have.
David: We have a lot of questions in here. I just want to see which ones are—okay there’s some questions about Ike [sec] whether Viptela vEdge device is required on both sides of an IPsec connection. That is true and untrue. The true part is that if you’re establishing Viptela SD-WAN Fabric, all of the edges of the SD-WAN Fabric, which means all of your branch offices, data center and campuses, things like that, they all will have Viptela. So the IPsec tunnel that connects those together is a Viptela IPsec tunnel. However as we have demonstrated vEdge routers are capable of doing standard-based IPsec, which is [unintelligible00:33:08] IPsec to the devices which are non-Viptela devices. In this case we stretched the tunnel to an AWS VPC instance.
You can stretch the same tunnel to parallel the firewall, 14 firewall, check the firewall, fit the firewall, whatever the case may be any IPsec endpoint. We also support GRE tunneling for services such as vScaler. So the short answer—it was a long answer, the short answer is that yes Viptela supports both Viptela IPsec connections and standard-based IPsec connections and in addition to that, GRE connections as well. The question is where is the automation residing? Is it in the vManage system or the vSmart controllers? The automation is residing in the vManage system, vManage system, as I mentioned, is a single pane of glass for all of the operational tasks.
So anything you do as far as configuration and troubleshooting, seeing which applications run, everything is done from the vManage System through the vManage [unintelligible 00:34:06]. Or in some cases, if people have an appetite for more programmatic approach, everything that you see in the [unintelligible 00:34:13] also exposed in a set of [ref] API’s. So you can leverage a programmatic approach with [ref] API’s and do it like that. And what I mentioned during the presentation is that every single element such as vEdge routers, vSmart controllers, and of course the vManage itself, comes with its own operating system that is reserved for a deeper troubleshooting. So from the operation of [10 point] you only use vManage.
Should a deeper troubleshooting happen and then it’s possible to go into each individual element and troubleshoot it to the nth degree. All right, let’s see. Do you support Google Cloud for Edge devices? Currently we do not. For Edge devices we support [unintelligible 00:35:04] KBM and ZEN for an on-prem deployment. For a cloud deployment we support AWS and Microsoft Azure, we do not support Google Compute at this moment. There was, let’s see what else happened here. Is AWS direct connect needed in this case? Well, so it’s debatable, as for the best way. AWS direct connect doesn’t hurt.
The vEdge cloud that is being deployed required an IP connectivity to other vEdge or vEdge clouds and it required connectivity to the vSmart controllers and the vManage System. So how this connectivity delivered is really up to the design of the transports. If a transport used a direct connect type of service from, let’s say an MPLS cloud or MPLS carrier network all the way into AWS, of course we can leverage that IP path. If there was no direct connect and we leverage any sort of connectivity which would normally be an internet-based connectivity. So the answer is the direct connect is not required, it could be leveraged and we will, of course, do the intelligence on top of it to figure out which one of the transport behaves the best.
So we will leverage all of them in an active fashion whatever it’s supplied to the system with direct connect or without direct connect. Let’s see what else? Oh I think there’s lots of questions in here. I think we’re coming to the end of our time. So what we’re going to do, we’re going to take all the questions and we’re going to address them one by one offline. So I think back to you Rachel for some closing talk.
Rachel: So we just want to thank everyone again for joining today’s webinar. And again it will be available on demand immediately after this as a recording. So you’ll be able to view it at your leisure, share it with your network, etcetera. If you do have any further questions please feel free to reach out to us, which you can do so directly through the Viptela website. And we hope you enjoyed today’s webinar and have a great day.
David: Thank you so much.
[End of recorded material 00:37:35]