stuck the link back in for the meeting that's um also wanted to remind everyone the call was recorded from the time the meeting starts and automatically posted to youtube one of the amazing things that i discovered was the videos are not automatically posted there's actually someone sitting there who actually drags the video on so we really need to send that person like flowers or something absolutely i think i know who it is let let let me see what i can do for kubecton all right and so um you were engaged outside of nsm yesterday during the call and i kind of brought some stuff up with frederick um diving back into glossary today i kind of want to rip the bandaid off and really have a discussion on like what the data plane is um when i talk to frederick i feel like i'm kind of in line with you know what he says that nsm is almost like a controller of controllers um it seems like there's some weirdness from like what the demon does um because it seems like right now the data plane concept is very kubernetes centric and then it gets super super weird when we start moving into like some of um romkeys use cases etc um because if i'm living in a vim i'm not actually talking directly to the data plane at this point at least from like some of the examples and some of the use case documents that i've been looking at it it seems like in this instance from nsm's perspective the data plane is really neutron it's making api calls making requests getting stuff instantiated very well quickly so i mean part of the thing is and i may have not sufficiently emphasized this is do you remember in the deep dive talk where i made this point about talking about the abstract architecture and then the architecture specific to kubernetes um a big part of why i did that is because there are certain aspects of the system as currently written in code that are pretty specific to kubernetes so for example as you pointed out the the data plane that we run in kubernetes is quite dissimilar from the data plane that we might choose to run in some other environment right um at the end of the day what it really comes down to is um something has to stand up the plumbing for the point to point connections um and the the other thing that that's very interesting about data planes is a concept when you think about them and this is where i think we've gotten hung up in the past is um i don't know how many folks have ever had the privilege of actually working on building a real physical router switch but you end up with some kind of a control uh module and it has what it believes is the control plane because it's on top and it goes and it talks to something below it that it thinks is the data plane the something below it actually is the control plane that then farms it out to a bunch of line cards and it thinks of itself as the control plane and the line cards is the data plane when you get to the line cards there is a control plane level of the line cards that's actually being talked to it thinks of itself as the control plane and it pushes things further down into the data plane on the line card and if you're really having a fun time, the line card has daughter cards and the whole dance repeats again. So my experience has been that the most productive definition of a data plane is one of two things, right, used sadly interchangeably. But the first definition would be to say that a data plane is that thing which you talk to when you would like the handling of packets to happen in some way, right? So it may be that internal to that thing it's talking further down the line as in the example that I gave, but effectively from your point of view, you happen to sit in the system, that thing is the data plane because it's the thing you ask to do things that involve handling packets. That's one way of defining data plane. The other way of defining data plane, which is often less useful, but is still valid, is to say the data plane is the thing that actually touches the packets. Now, it's interesting to note that neutron is absolutely not the data plane in the second definition. In fact, very few things are actually the data plane in the second definition, which is why its scope of utility is less. I just, okay, so let me, everything you say makes perfect sense to me and let me kind of then express my concerns with like this distinction between these two types of concepts is in the Kubernetes world, an NSE seems to be very tightly coupled to the data plane concept. And I mean, we're not going to try to make neutron an NSE, are we? Because an NSE tends to be directly in the second definition of a data plane where there is flow of packets going in and out of an entity. So in this case, it would be a VM that neutron is provisioning for you. But in the Kubernetes space, there's also like a, there's like a fracturing of how we treat Kubernetes versus everything else. Say I want to go into the PNF space. I can go into the PNF space by either having the demon call a controller, such as ODL. And in this instance, from an SPS perspective, ODL is my data plane, right? From like the first definition that you gave me. But then I can also have an instance where I'm taking some of that general purpose compute on an NCS box or a Juniper MX box or whatever, hosting like a container that's running our demon. And now that's the data plane. And it's making requests directly to the box maybe via its APIs, right? So we're getting into like this weird scenario. And it's making me a little bit nervous because Frederick was talking about his interactions at Mobile World Congress. There's starting to be these third parties that are going to be interested in building these NSEs. And it seems like there's going to be a very disconjointed way because it doesn't seem like everything's treated quote unquote the same, which is kind of what we're trying to normalize here with this glossary is like, this is a data plane. This is an NSE. This is an NSE. And the way that it's set up now, depending on like what space I want to work in, it seems like we're running the risk of having very disjointed like implementations of an NSE, a data plane, et cetera, et cetera. So I'm just kind of curious why Kubernetes isn't treated the same where like I just call the Kubernetes APIs and ask for stuff other than the fact that the namespace injection is weird. So there's a lot of impact there. So the first thing is when you mention about Neutron, so like why could Neutron not be an NSE? Because if you think about what service Neutron provides, it provides things like a bridge domain or a subnet. And those actually false square into being a service in the definition of how a network service looks at things. I didn't say that it wouldn't be an NFV though, right? I said that it's not going to have any traffic flow through it at any point in time, unless you're going to try to like make an abstract of like the Neutron router, which is its own little Linux namespace, et cetera. But I'm just saying though, right, like, am I going to pack Neutron into an NSE so that I can treat it and call it a certain way? Let's actually back up and look at that concrete example because I think it's a really interesting one, right? So this is part of why I always start with the definition of a network service, always, right? So Neutron is providing a network service, full stop, right? That's what Neutron does. And so you could imagine having a pod running in Kubernetes or even some other thing running someplace that would like to consume the network service that is a Neutron network, right? So you want a specific Neutron network that you want an L2L3 connection to. And so at that point, you need to basically look at, okay, how do I connect that client to something that will provide me with that network service, right? Now, if you look at the Neutron case, what that's going to inevitably look like is provisioning on a V-switch somewhere, a VXLAN or other sort of port that plums into the bridge domain that is Neutron, right? And so if you really want to put a fine pack on it, you can say the network service endpoint that you are actually connecting the workload to is actually a particular V-switch that is part of providing that Neutron network that you're providing with say a VXLAN connection is the point-to-point connection there. And that's how you would treat Neutron as a network service. And then when you go track down the concrete thing you're talking to for that, it's going to be about some V-switch running on some particular host node for Neutron that is the way that you get it into the system. Does that make sense? Yep. Now, one of the things that may be useful, because I get your point about this, this sounds different in lots of places. So picture this conceptually as a tree, right? So if you start on a particular network service mesh as an abstract thing, because then you can start at the abstract and drill down to the concrete, and if instead of looking side by side to your siblings, you look up to your parent node and then how that reflects down to the siblings, it's a much more familiar game. Does that make sense? Yeah, no, I mean everything you say makes sense to me. It's just like what we're describing, we do it completely different in the Kubernetes space, like instead of just going through Kubernetes and demanding more things from Kubernetes, we're kind of like supplementing some of its functionality, I feel like. Well, effectively, this is because we can, right? The unfortunate problem for OpenSack for the better part of half a decade has been you're trapped in Neutron, whether Neutron meets your needs or not, right? And so effectively, in a VM, you have two options basically that you can play in OpenSack, right? You can either plug into a Neutron network as a network service or if you're a VM running in OpenSack, you can as that VM simply act as both the network service endpoint and the network service manager for yourself and expose the remote API and go register yourself at which point Neutron is a happenstance in that path and you've completely bypassed what's going on in the networking for OpenSack. Did that help at all? Well, I mean, yeah, I understand it. It doesn't make me feel any better. It's going to like, when I look at like my network and like me trying to implement this, it's going to raise like lots of challenges with the lack of consistency and it's going to make people less inclined to want to use Kubernetes, in my opinion, like I don't know, it's just weird like. Consistency is at the wire. That's the trick, right? So if you have a wire and you want to plug the wire from your workload into a Neutron network, that's fine. You've plugged a wire into a bridge domain that has a bunch of other things going on in it because that's the thing you wanted and there may be other things plugged into that bridge domain that you're interested in. If you have a wire and you want to plug it into a particular VM, because that VM is doing the thing that you care about, then you need to be able to plug that wire directly into that particular VM. The consistency is at the fact that we're dealing with virtual wires, not virtual bridge domains, right? So I think like a confusion that we're going to render that I see in lots of places is we have a ton of people who spent an entire time thinking only in terms of L2 network segments on the open stack side. And those segments don't even exist on the Kubernetes side. And it turns out they're a terrible abstraction for most of what you want to do. Like I said, the thing that makes it a challenge for me in the Kubernetes, because I'm way less worried about the open stack space and recreating the problems, it's just how in certain instances, NSM wants to kind of bring the data plane with it versus me having my infrastructure out there with predefined data planes already in place.  We'll just say the method that I'm in a forward pack, it's like the actual flow of something making decisions saying forwarded out of this physical or this virtual interface. Like NSM with a lot of these NSCs, a lot of times, and I don't think that VPP is the default data plane, but like VPP tends to get packaged into a container, which also acts as an NSC, et cetera, et cetera. And I don't understand like why NSM isn't just like, as I put up containers that maybe doesn't have any forwarding element in it at all. Like it's an NSC, but like maybe it's just Quagga or GoBGP with no forwarding element. And all I want is to look at ASNs and push things with different headers, et cetera. And I want to rely on a completely separated data plane sitting underneath in the host. It seems like the methodology, and maybe it's just because this is the only examples I've seen that I would have to pair something like VPP or OBS or something in that container with Quagga. So that way it's pushing and pulling packets in and out of this network stack versus it just consuming the data plane that sits underneath. So not necessarily at all. So let's see the simple example of a BGP route reflector. Let's say you want to run a BGP route reflector. If you're running a BGP route reflector, effectively what happens is you've got TCP connections coming in and TCP connections going out. You're not actually programming a data plane. You're just doing reflection of the routes that you receive as a BGP route reflector. That's not a super different, quite frankly, from running a web server. I know that on the telco side they like to talk about those things as VNFs, but they're really, from a cloud data point of view, they're just another application that talks TCP. Does that make sense? But the place where life gets interesting is when you start touching packets. That's where things get interesting and different than just saying, oh yeah, just take FRR or a Quagga and stick it in a container and roll it out like any other pod, just like a web server or a medicines or anything else. It's when you actually need to start hauling packets across virtual wires because they're actually being processed by things. Because in the case of a BGP route reflector, it's not actually dealing with L2 or L3 payloads. It's talking about them, but it never deals with them. It's all an L4 and above kind of game. So I don't have to deliver L2 frames or L3 packets to a BGP route reflector. I just have to be able to get TCP streams to and from it. Does that help make sense at all? Yeah. And as to sort of bringing the data plan along, NSM is only bringing a data plan to the places where the existing data plan is deficient for the purpose. And please note, deficient for the purpose is this purpose. It's not all purposes. The Kubernetes stuff is super good for the kind of application things that people normally want to write on it. It's really good at those things. But if the thing you want to do is to take a packet and move it through a collection of CNFs, the BGP data plan, the Kubernetes system was never designed for that. And the data plan that it has is incredibly ill-suited to that purpose. And so all NSM does is say, okay, great, we have a situation where we need dynamism, meaning we need to be able to have wires come and go, not just at the beginning of the lifecycle of the system, and where we need to think in terms of wires, not in terms of entire cluster-wide L3 reachability. And with all the other things that that happened as part of Kubernetes as a network service, which Kubernetes networking is brilliant if you're writing an application. It's exactly what you want. But if you're writing a CNF, as many people have discovered, it's not great. Likewise, if you're running in OpenStack and the neutron networking is doing the things you want, then probably you just want to be allowed other workloads to connect to a neutron network. And that's great. But if neutron networks has nothing to do with what you're actually trying to accomplish, if what you really have is a packet handling VNF that is sitting in a VM that happens to be plugged into a neutron network, the neutron network is just your only option for getting out of that VNF. It's not really serving you. And so in that case, you probably want your VNF to expose itself as an NSE directly with a remote API so that it could accept incoming connections that may come in as tunnels of various sorts, et cetera, so that it can get the wires from the people it's talking to and deal with them. Another good example is if I have a physical network that does SRV6, as an example, I'm going to throw this out for you, Daniel. That data plane is actually entirely capable of doing things to the moral equivalent of virtual wires. You just have to ask it the right way. Hello? So can we say that the data plane is, there's a connection, and we can maybe define the connection as maybe some type of acknowledgement, and then some type of sending of packets, and then there's the packet treatment portion of the data plane, which is some type of manipulation, changing headers, whatever. It seems like there's two pieces that compose and make the data. Isn't that the network service though? Because I mean, I'm saying too, that's why I'm a little confused. Right, because in the neutron example, it's not providing you like, well, here's the thing. It is providing an SM a connection, or ODL talking to PNFs is providing a connection, but it isn't actually quote unquote in the literal since providing said connection, it is just actuating it, right? Like, I don't know, the sneaky network people's heads are going to explode. Maybe because of the explanation of how neutron works. For example, right now, in any kind of solutions, we have like this, we have the kind of SDM control plane that comes in, whether it's tungsten, whether it's ODL, even neutron, the weight work is defining as you do GRE, you do VCEN or you do those things, you're bound to what it thinks it should be doing. So that means that if I want to run, for example, tungsten, I have to do the boxes that can actually talk with tungsten to make it do the overlay correctly to the node. If I had a service plane and a control plane, which is agnostic, I have this, I need to connect router A to compute our communities node B. And for me, I decided it's going to use I don't just VLAN, then I will use the, I will define in that NSM mesh the proper data point I want to use for this. If I'm other company, but if I decided I'm going to use IP sector nodes, then I can actually make that work. I'm not bound to one telling me, because I decided religious is going to be GRE and everybody needs to be GRE, which is right now the problems we always have.  All of us have MPLS networks, which is the first burden we got is we need to find a gateway. We're going to centralize, we've built everything like flat out across networks. We remove summarization people because we want to be able to do MPLS, but we're jamming every traffic onto one box that needs to be translating one data plane to another because it's the only way to work with the virtual world, which is to me, it was our biggest challenge with the lab. So if I'm able to do with NSM, that abstraction that say I have a physical box, I decided it's going to be, I'm going to use that kind of tunneling or that kind of overly or packet measure in packet encapsulation to go to wherever I need to be. I think that that's why I think it's a valuable point, a valuable solution or vision. Maybe I rented them. So if I rented, please. I'm just happy to have people who are not me ranting. I'm definitely over ranting. I mean, I kind of get into the point that I was trying to make Daniel, which is effectively you're in this world where you're held prisoner by whatever the SDN control I thought it was because he wants to own the world and you want a world where you look, I've got these different things and I want to collect together with wires and I will decide how the hell the world works.  So let me ask you this question then. Are we going to, in some cases, just completely bypass Neutron and just manually configure the virtual switch and add ports to a VNF?  And like what ML2s are and aren't in place? So are we going to go in and say, we're just going to bypass Neutron, go into the stem and make direct port connections, similar to the concept of directly interjecting interfaces into namespaces and pods? Or are we only going to work through Neutron? But if you look at the history of all the SDN controls that came out, tungsten, even the New Age of this, well, everything, first off, they kind of bypass Neutron. They are just the way of knowing what Neutron was doing. And afterwards, you needed to go to their APIs to make the nice VPN stuff work, because Neutron was not able to do so. And over time, they added the modules within OpenStack to be able to do it. So doing it the same way now means maybe I should have stayed this way because, and the cool things with CRDs and things like this, I can still make it happen and make it look like an umbrella of APIs, which are standardized, but I don't have to recode everything to make it work, which is one of the big challenges we've had. I mean, I agree partially, but ML2 has two different types of drivers, right? And it's usually a specific type of driver that's saying, from an orchestration standpoint, I am outsourcing all of this from Neutron to tungsten to VTS to ODL, whatever, right? And then I'm going to bring in my own agents, et cetera. But I mean, it still doesn't change the fact that there's specific device type ML2 plug-ins inside of Neutron that enables the ability to do VLANs, to do VXLAN, to do GRE. What typically was happening in my experience the last time I put my head over the wall was that what would occur would be that you would get effectively what people did is you would simply redefine what all the words in Neutron meant, right? So you would go and write an ML2 plug-in and you would use all the Neutron API, but what semantically was meant by those words was completely different for you. And a lot of folks did that kind of stuff, but again, look at the domain of control.  What we do here that's quite different is that we essentially allow you to connect the pieces together so there can be multiple opinions about the world going on simultaneously, it's not our problem. Now as to the question of whether we ever bypass Neutron and OpenStack, I honestly, you know, that's a question if someone wants to go to the investigation for how that might be doable and doing that work. I don't honestly know what the appetite is in the OpenStack world for that. I know that OpenStack has historically taken actions to prevent anything that is Neutron from happening, that is not Neutron from happening with networking. You know, maybe their opinions will be different now, but effectively from a broader network service mesh point of view, all we need is something that talks the network service mesh, GRPC APIs, and we're good to go. So if somebody were to go and do something like this for Neutron, where it basically will do the direct wires into VMs in Neutron, like that would be something we would be okay attaching to because it's not something that, you know, that differs from the way the world looks to us. The world still looks like somebody advertised the network service endpoint. We can reach out to someone who could help us connect to it and that someone ensures that that into the connection happens. Did I actually answer any of your question, Jeffrey? I feel like I may have walked around it in circles. Yeah, I don't know. I'm just going to have to keep driving ahead and seeing how things materialize, I guess. One major thing that I think is going to have to happen for people to adopt network service mesh, and I don't think it'll be difficult, but it'll be a change, rather, is that the view that most people have of the networking world is usually centered around a bridge domain or centered around a VNF or some bigger thing that's occurring. What we're doing is we're actually saying, well, let's not center the world around that. Let's center the world around the individual wires themselves and focus on making all of those things work. I know we can work out how the airport's any type of services or other things that you want to attach to it. There's going to be a change in how people think about networking as they start to use network service mesh. I think it's something that'll come naturally. The people here in this conversation are already going through that transition to a significant degree. I think as we start to expand out, we'll see more of that happen, but I think part of what we need to do is work out how do we help people reorient their mindsets to no longer be core-centric on a bridge domain or subnet and rather to be more connection oriented. Why oriented? Well, you bring that up, and Watson has even in a comment, like he said, we need a connection for, a definition for connection. I'm just saying, the problem is, and this is where my evil sneaky networking person is going to come out, the lack of consistency between when and when there isn't a forwarding element because that does matter. If we say we're going to move into the CNF space, then almost all of your developers are going to be sneaky networking people. That lack of consistency between some use cases, bringing a forwarding element, some use cases not bringing a forwarding element, et cetera, et cetera. It makes my head hurt and it makes my heart sad. I don't know. Maybe like Watson says there, we need a definition for what a connection is, but there's not enough consistency for me. My theoretical mind is exploding. We got the word virtual wire. We definitely need a definition for a connection. I think to Frederick's comment about thinking, part of what I think we have to realize is that the cloud native people have already completely abandoned the notion of a bridge domain. There is no L2 concept in Kubernetes at all. That concept does not exist and they don't want it. So the world has already moved on in the application space for bridge domain.  As to the definition of a connection, I think that probably would have helped a lot. Here's my only thing on that, Ed. I know that like Kubernetes doesn't have this concept developed too, but it doesn't change the fact that there is a virtual switch or a pass-through technology with something doing like something is looking up back addresses and making decisions on what ports to forward things out of. Just because Kubernetes wants to ignore all that, and I'm completely supportive of the idea that we continue to abstract that from them, it doesn't change the fact that there is something that is looking at MAC addresses and saying, guess what? You're going to go out this port because that's what ARP told me. That doesn't go away just because Kubernetes ignores it. Actually not. So if you look at the most popular CNI driver today, which is Calico, Calico is a pure L3. There is no L2 domain there at all. It's all L3. But that's one CNI. It's the most popular CNI today. It probably is. 95% of the Kubernetes traffic out there. No, and I get it. And there is literally like another senior architect in my company who is trying to convince us that we should do no L2 anywhere. We should put an ASN per data center and do BGP with L3 all the way down to everything. And I get it. If I'm going to do any L2 stuff in NSM because I have this giant commercial network where all we do is sell private circuits to people, all L2 via VPLS or EVPN. Some variant of MPLS is going on there. Then maybe we just say Kubernetes doesn't fit in this space then, I guess. Well, the other thing that you actually should probably look at is go look at how people who actually run massively scalable data centers do it, right? And I'll put you to one public example you can go look at. If you go in GCP today, it will have a slash 32. Period. Full stop. Right. So you get what you get there is a slash 32 because everybody running a massively scalable data center has long since realized that you want to move L3 as close to the edge as you possibly can. And many of them move all the way down to the VMs. So here I'm seeing two types of world, right? One is what we are trying to say is we are trying a pure green field environment where every workload is basically cloud native and then Kubernetes tried to solve the problem, right? But back in the service provider world, we are also seeing a bit of hybrid where you would have physical network function, virtual network function, and so does the cloud native, right? Now, the most important thing is I think we probably need to if we get into the service provider world, we probably need to get a mechanism or a way where we can say, okay, here is the non cloud native world. Here is what I would probably help you to define the entity's until you migrate to the cloud native world. And probably we may need to put definitions or some steps or exercise that would essentially help embrace the non cloud native world, right? So I Absolutely. And here's the baseline quick, which is if you want to bridge domain, if an L2C makes you happy, that's a network service dude. It's fine. You're absolutely right.  In cloud native world, you can in fact have apps or have any of it without the data plane or without the data plane playing any important role. It can just be an IPC or an RPC between endpoints. And then the data plane programming does not play an important role, right? It's just L3 endpoints everywhere and then do it. But when we come to that of service provider, you have MPLS endpoints, you have those endpoints which are not really L3, but still you need to address it. So, I mean, I sincerely feel that probably we would need to put in that effort and exercise in order to define those definitions or try to do a mapper type of thing, so that what we can do is we can essentially go and tell to customers or tell to some of the folks, Hey, I like I know that you are using Neutron world, but in Neutron world, I know that you're talking about bridge domain, I know you're talking about this, but then if you want to migrate it, this is the step or if you want to address it, something on those lines, right? But it, I mean, what I'm feeling is either we can continue to do here or we can in fact have a separate discussion where in people who are interested in trying to bridge the gap between Neutron or physical world and then try to do it, right? Because I really love the way we are driving NSM, but only thing is, I mean, we don't want to really, I mean, I should put it in a different way. We should probably be focusing on what is right for the pure cloud native world, but also try to get the rest of the world to be part of the journey. That's what I'm completely with you. So my suggestion would be the following, which is in terms of the legacy world, if I have a world where I am, I'm like Neutron and in OpenStack, where I've got pure L2 segment, right? An L2 network that I'm doing. You can absolutely connect workloads to that L2 network as a network service, right? So if you go and run a pod in Kubernetes, you want it connected to your OpenStack Neutron network, that Neutron network is a network service, we should be able to connect you to that as a network service. It will have payload type L2 in a way you know you're going. If you want to move further than that, say I actually want something. Sorry, can I request others to go on? There's a lot of background noise. There we go. So I mean, you can absolutely do that. I think that's actually exactly the right first step because as I think Jeffrey's pointed out, there's a lot of legacy in the world and it will be a lot of legacy for a long time. And so I think that first step of okay, great, how do I offer my Neutron networks as network services to the broader universe, some of which is going to be cloud-native in Kubernetes, I think that's an important first step. It's just not the last step. Yes, but one thing I think what I strongly feel is also we would need to seriously look at how do we address the data plane elements, right? When we say data plane elements, where is the plumbing happening? Whether the plumbing is enough? Aspects like that. Yeah, I mean, one thing to keep in mind is the plumbing is very distributed and federated here as opposed to being centrally controlled, generally speaking. Right. So if I'm running a Kubernetes cluster over here, and in that Kubernetes cluster I have a pod, then I'm probably talking to something that looks roughly like the VPP agent data plane right now, even though it may or may not be driven by VPP agent, right? And it just produces cross-connects. If I am over on the open stack side, and I am exposing Neutron networks as a network service, I'm probably something that talks the NSM remote API and that basically picks a V switch instance and sticks a VXLan in point into that instance and configures it, even though there's no VM on the other end and passes that back as the remote end of the connection to whoever talked to me. I don't have to have a single unified data plane for the whole world. This is, I think, part of where we're actually in a post-SDN world. SDN basically presumed that you had a single entity that controlled all things. And we're an NSM, we're in a world where that doesn't have to be true, which means that we can actually collaborate with all the things, which was not possible in the SDN, I must control all the things, model. Well, that's useful information for the, for the glossary and probably. Yeah. So I think at the end of the day, part of what it comes down to is something has to arrange for the connection to whatever is providing the network service. And it may be different some things at different points in the architecture, right? So it may be a data, you know, a data plane on a Kubernetes node where the pod is running, but it may also be something that is twiddling V switches in OpenStack to expose what OpenStack would think of as a port. Okay. Can I have one other suggestion here, please? So what we can do is we can probably create a separate section and then say, these are the mappings, right? And then try to keep this specific to the cloud native world, right? So just a suggestion, right? An alternative to that would be if in the definition, if you could say this is sometimes called X in the NFE world or the yes, for each of those definitions, but some type of mapping. Right. Yep. So let me ask a question. I keep going back to talking about this sort of tree approach and saying there's the definition of things in the abstract and then there's the particular ways that the institute in the broader world. Would it be helpful to sort of build out that tree in the glossary documentation we're talking about? I think so. Yeah. I tend to think abstract to concrete personally. Well, that's not true. I think both. But I know that people have different tastes. I know lots of very smart people who think from the concrete up to the abstract. And I know lots of very smart people who think from the abstract down to the concrete. And I know a few very smart people who start in the middle and think outward. Those guys are really interesting to talk to. But, you know, bye. I think we just need more definitions. And I think to Watson's point, we need to unpack some of these things that are just too complicated to get under a single bold little statement there. Right. Like, I mean, in the NSM context, a data plane is just anything that you can request to forward packets, whether there's a layer of abstraction between you and that forwarding plane or not. Like NSM is going to go and say, Neutron, give me this. Kubernetes, give me this. Kubernetes, you don't give me what I need. So I'm going to go around you and make a request for a kernel interface on my own. But unpacking those things and then talking about separating and making it granular enough so it's obvious that, okay, this is at the highest level how the developer is going to look at this. And then here's these sub-considerations for the developers who are going to be writing network service endpoints and writing network services themselves. Because I mean, I know we keep saying we want to, like, appeal to the application development community, but Sarah's going to write her app and then request a network service by name, right? Like that's how it works. Well, who wrote the network service that's sitting behind that namespace? Like, I'm sorry, that domain name, like it wasn't Sarah, more than likely.  And then if I go out, like in this space, I've got VXlan in my network. So that's going to be the next one down. Like, it's going to be a sneaky network person that writes really hideous code that ends up writing those network services and those network service endpoints. Yeah, no, no. I completely get that. I completely get that. So, you know, and those views will be somewhat different. But effectively, at the end of the day, I can tell you, having talked to a lot of people right now who struggle with a lot of these problems in VFs, where they're trying to cobble together things from L2 networks, and it doesn't always make sense. And you end up with these extremely complicated top-down configuration scenarios. I think once it sinks in to the people who are writing the network service endpoints, I think it's going to be an incredible relief. No, I agree. I'm just saying, as the person who will end up consuming all of those network service endpoints, I'd want there to be some level of consistency. Yep, yep. Well, and the, yeah, and I think part of that may actually be breaking down roles and situations because the roles and situations are going to vary somewhat, depending on the environment you're in. Even though you're trying to do the same thing, you may do it a slightly different way. So, for example, if you ask me to go and write a CNF to do something, I would go out and write a CNF that consumes MIF and call it a day, right? Because that's super easy and simple, and it actually performs super well. If you asked me to go and write you a VNF that participates in the network service mesh, probably I would write that, what I would do is I would have to keep the remote API, I would have it register itself, and I would have it terminate at some tunnels because the things that make it super nice and easy to write a MIF-based CNF simply don't exist in neutron. And so that's probably what I would choose to do in that circumstance. In both cases, you have something that is terminating, that is advertising, that it provides a network service, and that is accepting requests for connections to that network service from various clients. Just in the latter case, the mechanisms you would use would be some variety of tunnel types, as opposed to using nice convenient MIF and letting the infrastructure take care of the tunnel types for you. No, I'm tracking. I'm more worried about the SARA example where I've got my application and I've got a firewall CNF and a VPN gateway CNF, and I get them from two different vendors and they've decided to just completely implement said CNFs in a completely different manner. Well, so the thing is, if you're talking about CNFs, as long as it doesn't actually matter if they've implemented them in a different manner, because they're exposing network service API for how connections are requested, and they are accepting a payload of some type. That's literally all they get to have towards the outside world. That doesn't mean it's going to be an optimal negotiation though, right? Well, it may not be an optimal negotiation, but it'll be as optimal as those two can communicate with each other. So there is also a potential responsibility of the operator who's providing the services on behalf of SARA to make sure that he or she validates and ensures that the components, if there are any performance requirements or so on, match the needs of the user as well. So it doesn't eliminate or obviate the need for those choices to be made, but it does make it easier so that when you make those choices that those items can get wired up based upon the negotiation. And has a nice premise as well where, suppose if you have like a MIF to MIF connection for most of them, but suppose you run out of capacity on your local system, then you don't just say, okay, we're fail the connection.  So to my view is SARA should not know anything about this. That's one, the next step is about how to make sure like, how can an app developer, which we had the problems before, know, oh, I need a VPN connection and need this and need that kind of network service. They normally don't know. So that's the second, I think it's a future step is how to make that kind of intent simpler for an app developer who wants to consume network services to make it simple for her to ask this. The second one is you won't be able to normal, you won't be able to say everybody needs to develop the same thing because VNF developer in Israel might decide it's not going to code the same thing. He decides to use VO's doesn't want to use an MIF. So you need to have the NSM be able to adapt to it. So that entry points might be going from a VO's and then the second phase needs to be going to MIF. You need an SM to be able to adapt to it. And that's, that's the same burden we've had with the NS. And we've been fighting for this for five years now. So I don't think NSM will completely solve the way people badly or goodly in a good way create their code. I think that's overall us having to stick and beating them up. Yeah, exactly to the point.  They exist.  Right? Exactly. That's what those definitions like put some guardrails in place. So these goofballs, like, just going to go off into right field designing something rando, like, we can be like, look, you didn't follow like what the definition says this use cases. So this is, this is crazy town. Yeah, absolutely. And so like, for example, you know, let's look at the number of things that you could do as a CNF vendor that would be stupid, right?  I could hard code the name of the next network service into my CNF as a hard coded string. That would be not particularly bright. I could also hard code the name of the network service that is being exposed by my CNF into the code. Both of those would be super not good. My favorite is my favorite is receive a lot of and accept a lot of new connections over kernel interfaces.  So I was thinking, yes, so definitely. So that the using really, really bad choices of mechanisms is also one, but kernel interfaces are so slow that anybody who's writing a VNF, the CNF that uses kernel interfaces isn't even going to get to the point of evaluation. Right. Because it's going to be how much traffic in your CNF pass dot, dot, dot less than 1% of what you need. So again, part of the whole point is to limit the number of things that can be done super badly in the system. So part of that is limiting the number of knobs that are externally facing. And so for example, one of the things that you may have noticed about network service mesh is we literally don't say anything about how you would configure a CNF because that's a very broad space. But we do say this is how you would have people request connections to your CNF and we're orienting this towards wires and payloads. And I think that's a super helpful way to approach the problem because it limits the amount of stuff at the edge when you have different CNFs chained together that they can screw up. As long as I can basically tell you as a CNF, please advertise what you're doing with this name and please, you know, this logical next step that you want, please consume it using this name and these labels. As long as I have those knobs to turn, there's not a lot you can actually do to screw up interoperability between CNFs and the network service mesh world. Sub-definitions within the data plan and maybe we like tab those in or whatever. Because if I'm Sarah, all I care about is that top definition, this logical construct that provides me connections, right? But then for the people that are writing NSC's, writing network service, network services themselves, et cetera, we need to like make sure that they know definitively like when you're considering your forwarding element, you have these considerations and maybe the forwarding element doesn't even exist as part of this network service because you're actually going to call something else that does it for you. You're just looking for forwarding, right? Like we don't need to define it right this second because we're pretty close to the top of the hour, but we need to give people as little rope to hang themselves as possible through these definitions. So when they come in, they have a clear and concise understanding of what they should be coding. Or if you guys think I'm crazy, I'm open to that suggestion as well. I don't think I'm crazy. I do think I'm bad at operating a mute button. You're bad at what? But actually Jeff, I mean, bad at operating a mute button. But I believe, Jeff, you brought in a very, very important point, I believe. I think this has pivoted into a clear distinction of what would a cloud native be and how would the legacy or the NS world would be. And I think this is very, very important in my opinion. Right. Like a roadmap of how you take your legacy stuff into the cloud native world. So my personal goal for this glossary is that they can take this glossary and equalize SDK and start working on things, right? Like hopefully they do more research than that, but at a bare minimum, they know it like the definition of an individual component in this space is, and then they can use equalize SDK to like hack around with some stuff. And we give them some guardrails via said definitions to keep them from getting themselves into trouble. Quick question though, the SDK is currently goal-rank only. Do you think that there should be an example of how to use it from other languages or even a SDK for C, for example, or Python? I don't know. Well, so for SDKs for the language, great. For C, C has an annoying problem in that C has good protobuf support, but nobody has yet written a decent ACDB to library for C. So like client or server library for C. So GRPC tends not to be supported in C. It is supported in C++. It is supported in virtually every other language on earth. But so C is a little minor niggle. But I think if you look at what the SDK is doing, a lot of what it's doing is primarily helping you out around the actual GRPC calls themselves. Multi-language. Well, I would be perfectly delighted if people were to start writing SDKs for other languages that would help them out in other languages. I think the real fundamental API is what's represented in the GRPC. Cool. All right. So I think now that we have a client and endpoint defined, I think we largely have what a service is defined. And we know that the data plane is what it is, and it just needs to be articulated. Next week, we can get away from some of these more. I don't know what to call these type of calls, but just trying to like puzzle and inform and maybe just get down to like, I mean, I don't feel like a network service registry is going to be too controversial and defining.  So that way Ed and Frederick and friends can start refining this document and looking to push it out. Sound good? Is there any other topics that people like from a definition standpoint want to just really dive deep on next week before we start just trying to get a lot of the busy work out of the way? I suggest creating an audience, defining the different audiences and having a name that everyone can reference. And then that can be used either in sections or directly on each one of the plus returns, but defining all the audiences and giving them a name will be easier for discussions. Okay, I'll put that in the meeting notes that we need to do that next week. Oh, you already did. Thank you, anonymous bat. That would be me, Taylor. You don't certainly get to know Riley like feeling to the entire experience. No, but I mean, I feel like the people that attend this call are getting a better understanding of what's actually going on. And I think we're getting pretty close to now where we can just like, you know, the network service manager domain, we just need to go into the spec, pull out the information, put it into two or three sentences and drop it in here. I think we're getting pretty close on this document. Yeah, I mean, by the way, like, I think understanding closing all directions, I certainly feel like I understand quite a bit better the places that and better ways to try and phrase the thoughts that I'm trying to express to be more comprehensible. Yeah, I mean, Ed, my big fear is I tend to understand usually right out the gate what you're trying to convey. I have a hard time articulating your thoughts, though, to people that sit in my building. So I'm just trying to figure out how I put the language around all of this, you know? No, no, that's absolutely fair. And articulating things is actually useful. And having easily replicable articulation is super important, because much as I enjoy explaining things to people, I cannot do that all the time. All right, friends. Well, I'll see you maybe on Friday's call, and it's not definitely next week.


The following is a presentation of TFNN. Trade what you see with Larry Pezzavento toll-free at 1-877-927-6648 or internationally at<PHONE_NUMBER>. Now, Larry Pezzavento. Okay, looking good, Billy Ray, feeling good, Lewis. Sounding bad, feeling good. Let's take a quick look here at this gold market, folks. Once we went above that 1,500 level that we talked about on Tuesday, it was pretty much clear sailing. We had a tiny bit of resistance at 1,508. We went through there like it didn't even exist. We're now at around 1,514. The interesting part is that gold is one of the more susceptible to lunar cycles than anything else, and we have a new moon with a solar eclipse coming in here today. Very, very important. And another thing, folks, if you do the silver charts, go back to look and see the last time we had a move like this in silver. It measured to 1,803. We've been as high as, I believe, 1,808. 1,810 is the 50% retracement. So I certainly can't recommend going along the gold and silver in here even though they could go straight up. We're up 13 days in a row in the silver market just by itself. So that in itself makes it very, very overbought, but it could stay overbought for a very, very long time. That's for sure. We want to remember that because it's very easily to see that happen. Let's just take a look what this is going to look like today for those of you that are out there in the stargazing mode. We'll bring up here to let you see one second here. We've got to change the venue just a little bit. There we go. Here's what it looks like. There you go. There's what that solar eclipse is going to look like in different parts. It's actually visible in the northern hemisphere, I think, from what someone said. But you can go online and check that if you wanted to take a quick look at it. Another thing that's happening that I think is relatively very important. And that is, if we look at the Bradley date, we'll bring this up here to see where we are. You'll see here where we're looking at the Bradley model. Now go back to last year, folks. Remember we had that huge rally after the first of the year? Well, look what's happening now. We're right in the Bradley zone right now. You can see it right now. We're right at that level. So it's going to be really interesting to see if the market explodes to the upside from this level again, which it certainly could, or whether it's going to invert this time and possibly move to the downside. We really don't know that. I've done a lot of... Well, I've done every Bradley model since we had good data in the stock, which was in the 1870. We started getting data from the New York and Philadelphia newspapers and then later on the Wall Street Journal to get pretty good data. But that tells us that these things do work, but they don't work all the time. I wanted to go back and take a look at the history. Well, just look at the longer term history on some of these things here. But here's one. This goes back all the way. We're going to go back about 25 years into 1966. You'll notice here, I just want to show you the patterns that you're looking at. You can see the three drive to a pattern at the bottom there in October and December. There was a double bottom. That was later on in life. I would realize much later. 20 years later, I would realize that that double bottom was a double conjunctions and oppositions. So in October and December of that year, that was one of the reasons that got me really interested into the astro aspects of this stuff. And I was working with some of the folks out of Pittsburgh at the Foundation for the Study of Cycles, Gertrude Scherk. And it really gave me an idea later on. This was 10 years later. I didn't get this until 1986 when I was working with Dr. Ruth Miller. But just looking at these old patterns, you're going to see that they're really, really very interesting. The main one that I really wanted to bring up to you is the fact that if you'll notice that the low we made there in 1978, in March of 1978, and then the low we made on August the 12th of 1982, that was just a slightly lower low. If you'll notice, look closely on those red market coming down, you'll see it's a beautiful three-drive to a bottom pattern. It's setting exactly at the 61% retracement from the low of 1974. And from there, we went from a little bit higher in the Dow at 720, I believe, all the way up to 28,500 and counting. So that was a major, major bottom. And all of those were absolutely major cycle things related to the harmonics of the move. So yeah, the Bradley model, it works part of the time, but when it works, it works really good. The dates themselves are pretty good, but sometimes the trends get a little upset. Now take a look here. This happens to be, since we're talking about this, I wanted to spend a little bit of time this morning because it's important. You'll notice that we had this three-drive to a top pattern back in 07. It was in October of 07. The most significant part of this chart was on the high right there that week. Bernard Bernanke came on and said that, you know, all systems go. Everything looked great. And from there, the NASDAQ gave back, what did it give back? About 75%. And we lost 67% in the S&P 500. So notice here, this is the Dow Jones industrial average. And we bottomed in 2008 or 2009 in March, and the Dow was trading at 6,600. So that's how far down we came from this. But when it does work, it works pretty well. Now you'll notice in June, you see where that low was made. That was an inverted market. And it went up and then it came back and tried to make a low. Missed it by just a little bit. But overall, it does a pretty good job. And so we're at one of those points right now. And we're also looking at the, you know, these different cycles that we have, not just the lunar cycle, which is the solar eclipse and new moon we have today, which is the, you know, the 28-day cycle. You're having that Mercury is in there too. It's really, you know, moving around. And Ritzke pointed that out in his talk that we had, we had him on for, well, actually, Dana was a technical problem. But there's some really heavy cycles in here. This is very, very important days that we have over the market right now. So we'll see. We'll be up. This is, yeah, this is only the fit. There's, I think there's, I don't know if you know this enough, but you know that there are five Sundays and five Mondays in the month of December this time, which is that doesn't happen again for another 823 years, I think I heard. Yeah, I'm pretty sure it's that. Let's, let's move on. I want to, I have to discuss this thing about open interest because I tried to do a lot of information on, you know, what's going on. Let me get this up here to see my market up here. Here's the open interest. I wanted to show you this folks because I think it's important. This is the open interest in the E-mini S&P as of the 20th of December. This is where at the close, there was only 589,000 open interest versus 2.7 million in the March. Very, very important. Okay. The next thing you want to do is to take a look at what happened to that open interest as we went through. Here's where my red lights came on here. Look at this here folks. This is where, and I, let me get, we'll get right back and talk about this again. I think it's important, so I'm going to talk about it. We'll be right back. The Taz Profile Scanner is a standalone piece of software that instantly filters over 2,500 global financial markets such as stocks, ETFs, commodity futures, and forex. Heated by Steve Dahl, Taz understands that in today's technological world, the use of top-flight software applications and technical analysis expertise is essential to successful trading in today's market. You also gain access to the webinar that Steve Dahl and Tom O'Brien just hosted, the best way to use the Taz Profile Scanner to profit. This webinar archive is available for all subscribers immediately upon signing up. All new subscriptions also come with a 30-day money-back guarantee, so you have nothing to risk. Start your subscription by visiting the front page of TFNN.com today and you'll find the Taz Profile Scanner under the Services tab. Sign up today. Are you in the market for buying or selling real estate in the Bay Area, including the surrounding St. Petersburg, Tampa, and Clearwater markets? Tiger Real Estate LLC is a firm that has extensive experience in the Tampa Bay Area. Whether you're looking to sell your current property for maximum value or you're in the market for a second home or investment property, Tiger Realty has the experience across all areas of real estate in the Tampa Bay Area to help buyers and sellers make the most informed decisions across all price levels. From the price you should be paying per square foot in certain up-and-coming areas to the type of cash flow investment properties are capable of creating, Tiger Real Estate can help you make the best decision when it comes to all areas of the market. Before you make one of the biggest decisions of your financial future, call Tiger Real Estate LLC today at<PHONE_NUMBER> or email us at Tiger at TFNN.com. That's<PHONE_NUMBER>. Call us today. Many of our new listeners have heard about the Tiger's Den. The Tiger's Den is a lively community where professional traders and investors can meet, exchange ideas and information in a comfortable moderated atmosphere. Hear all of the TFNN shows, plus see all of the charts as they happen live and have access to archives of all of those charts. You can test drive the Tiger's Den absolutely free for 30 days and greatly enrich your knowledge of these markets and how to make your money work for you. Details on the Tiger's Den are on the front page of TFNN.com. We even have new pricing in six months and yearly options. Check out the new TFNN.com now and experience all the upgrades. TFNN.com educating investors. Call now toll free at 1-877-927-6648 internationally at<PHONE_NUMBER>. Okay, we're back folks and I'm on my little horse riding the open interest story. I posted in here what the open interest has done. Do you notice the other day it was almost 3.2 million. Now it is 2.7. We've dropped a little over 600,000 in the open interest. And I wanted to bring to your attention what happened. If you'll just give me a second, I'll bring it up what happened on Tuesday, the day before Christmas. Again, we had another drop in open interest that day also. So it's very interesting folks that this open interest is dropping at a time when prices are going higher. Because I couldn't get any information off the internet from anybody saying, gee, this looks very interesting. And I went back and compared. So I called Chicago to ask him, is there anything in the contracts that have changed that would make it? The guy said, no, he said there's a cash settlement for the S&P. In other words, if you bought the S&P last week, say on Thursday and you carried it through until Tuesday, it didn't even take off the trade. When it goes off of expiration, it's a cash settlement. So if it sells at $3221, then that's the price that you get. You don't have to do anything as far as liquidating your contracts. But that still doesn't account for the fact that open interest last week was setting at 3.2 million and now at $650,000 less. So there's 650,000 less players in there, folks. And if you go back to John Murphy's book and take a look what that means is, if you come up and look at this, you'll see that if open interest is falling, you'll see the second link. They're bracketed off in blue. If open interest is falling and prices are rising, the market is weakening. And that's what we're seeing here in all of the indices, especially they don't mean they don't roll. That means they did not roll the contracts, Bill. That's exactly right. In other words, there were 620,000 people that left the market. That's long and short. But because the market's going up, it's short covering. And that means the market's in a weakened condition. I've shown you this stuff. I don't want to beat the horse any more than they already did. There's some other things that they're interesting that's going on in the market. If we take a quick look here, this is a real interesting one, too. Oh, I think I can do this really easily. Let's see if we can do that. Yeah, wow. Did that post that easy? Are you kidding me? Oh, my goodness. Look how much time I could have saved. Did that post okay? The put call ratio? I bet it did work.  What a great Christmas present. It didn't post, huh? Yeah, it did. Sure. I'm getting it, Marshall. It showed that it posted perfectly. Did the put call ratio chart whether it would make my life a lot easier if it posted? It really didn't post. Uh-oh. And then I got to do it another way. Posted as a picture. All right. Let's do it. Let's do it the old way. Get it up here. And here it'll work this way for sure. It should work that way, but I don't know why it didn't. Here's the put call ratio. What you can see here, we made new lows back into January of last year when we had the put call ratio at pretty much the same price. So we're at very, very extreme levels. You need to keep an eye on that, especially with all these cycles that are due at this time. And I think it's important to remember, you know, what's going on. Sorry for the, I have a little bit of a sore throat and stuff, folks, but I wanted to go through some of these other patterns and some of these other things, astrology-wise, that we don't cover too often. Here's the, this is the SMP going back to 1958. I bring this to your attention just to show you these patterns have worked for a very long time. You'll notice that we had the one, two, three, four, five expanding trying, three to a top pattern that was also expanding triangle because four was lower than two, two, three was higher than one and five was higher than three and one. That's a three drive to a top pattern and a five point reverse wave and the, during the time of 1973, that's when the market went down and made that double bottom down there in October, October and December of 1974. And then we made the other bottom in August of 1982. But if you just went and did the ratios on these, I think you'd be quite surprised to see that these Fibonacci numbers are still just a much, pretty much spot on doing what they were doing. And I think that's why we have to keep reminding ourselves that they don't work all the time, that they work more often than they fail. And that's the, that's the key to looking at. We have a question about the Bradley model. Why does it invert? Well, Norm says it's because of the inversions to happen because of the retrograde planets moving. And that's certainly possible. I don't know the answer to that. The way I try to use the Bradley model are the key dates because it, it does pretty good with the key dates and we are certainly over one of the major key dates right now today and tomorrow.  You don't know because when they fail, they certainly move. We've got a situation monetarily that the Fed can do almost anything they want as far as, you know, keeping interest rates lower, whatever they want to do. At least that's what they're trying to tell us. So we'll see whether that's going to be the case or not. We'll have a chance to take a look at Bitcoin here this morning. And as we look at Bitcoin here, you'll see here that we've, we did hold that low at 6400. That took out the low of early November right there around Thanksgiving time. We took that low out by just about 50 points at 6400, which was the 61% retracement almost spot on on the long-term charts going back a year and a half to two years ago. But if you looked at it logarithmically from the start of $100 a share in Bitcoin, that was a 382 retracement. So just like the gold was so important at that 382 level, that's the same reason why you have to pay, you know, very close attention to the same thing in the other thing that we've been watching here. Let's just take, since we're talking about gold here, because we've cleared 1512, 1510 very easily. And you'll see here that we've got above these levels, the 78% level of the move comes in around 1517, I believe, and we're having a really strong move today. So that will bring us up near this level that we're looking at. What looks like toast? I don't know what means, what that means. Marshall, so you tell me what looks like toast. Gold doesn't look like toast. It looks like it's actually acting pretty good. You know, it's running up pretty much. Once we cleared 1500, there was nothing above it that would make it. We've gone, you know, yeah, Bitcoin, it doesn't look that bad. Actually, if you look at a longer term, Marshall, that 6400 is a really big figure, and we came out of there really strong saying it's important. If we go back below 6400, it would not only look like toast, it'll look like burnt toast. But right now, it's still acting relatively well, whether that's going to be the case or not. I don't know, it's Boxing Day over in the U.K., so there's hardly nothing open over there in Europe. Currencies are moving around a little bit, but other than that, there's not too much happening here. So we've got a break coming up here,<PHONE_NUMBER>. And he's already delivering content to his subscribers on a daily basis when the markets opened and even on weekends. Each Monday, you'll receive Larry's written report that provides detailed commentary and a summary on the charts and videos that Larry sends out. And throughout the week, when warranted, Larry will send out via charts or videos or both the key markets that he is watching during the day. This will be up to the date active trading information that will help you in your daily trading. In Larry's first week alone, he sent out 25 charts, 6 videos, and a full report to his subscribers in just one week. If you're a technical trader that uses patterns and retracements to trade, then Larry's service Fibonacci 24.7 is something that you must try. Right now, new subscribers can get a full 30-day money-back guarantee. With nothing to risk, sign up now to Larry Pezzavento's Fibonacci 24.7 by visiting the front page of TFNN.com under Trading Newsletters. The path of least resistance is David White's daily trading newsletter. And if you're looking for active trading ideas, then now is a perfect time for a 30-day free trial to this powerful daily trading advisory service. David uses his years of trading experience to offer his subscribers his trading ideas each morning in his path of least resistance newsletter. Using a combination of equity trades along with options, David keeps his subscribers up to date with all pertinent market information with intraday afternoon updates when warranted. Don't miss out on this great chance to get a 30-day free trial to David's daily newsletter, The Path of Lease Resistance, with no obligation to pay anything. David has been delivering solid recommendations for his subscribers recently, and if you'd like to see the type of newsletter he delivers every morning, then visit the front page of TFNN and you'll find The Path of Lease Resistance under Trading Newsletters. For all the details and to start your 30-day free trial today, log on to TFNN.com now. TFNN is excited about our new software charting program, The Art of Timing the Trade Charts. In collaboration with Tom O'Brien and using his best-selling book The Art of Timing the Trade, Your Ultimate Trading Mastery System, David White has programmed an outstanding piece of software that will complement any trader's methodology. Using this first-of-its-kind program, The Art of Timing the Trade Charts allows you to scan thousands of stocks for Fibonacci formation setups, including guardleaf, ABCs, butterflies, and much more. The Art of Timing the Trade Charts is designed to help you when scouring the markets for stocks just beginning to form the trading patterns that many investors spend days, weeks, or even months searching to find. And right now we're offering licenses available at only $79 a month. We are so confident that you're going to love this new charting software that will even give you a 30-day unconditional money-back guarantee. Don't miss out on this incredible new piece of software. Get your copy of The Art of Timing the Trade Charts today by visiting tfnn.com. This segment is brought to you by Think or Swim. For more information, just click the Think or Swim banner on the front page of tfnn.com. Okay, folks, we're going to take a look at the Hang-Sing Index, the weekly index going back to 2018.  Almost went to the exact 61% that retracement missed it by about 200 points and then rallied up exactly to the 61% retracement and then came down and almost made a double bottom in August. And since that time, Hong Kong has been under extreme pressure. It started about that time when the rioting started and the folks that are arguing about who should run Hong Kong. And you'll notice at the high that we made here in the rally just a week or so ago came in at 61% retracement. But I want to spend just a moment to look at this chart very closely. Here's one of those things that you hear about Warren Buffett and by where there's blood. Look down there in August how bad it looked with that big gap down. It looked like it was going to go down forever. That was the bottom of the market, folks. There's nothing but turmoil and all kinds of bad things happening in Hong Kong and yet the market rallied from 25,000 all the way up to 28,000. That's a big rally. And the rumor is from China from what we're hearing from our friends over there is that George Soros was in a short position in this and he was hurt really badly. Now, if you believe that, I still have two shares at the Brooklyn Bridge that I've been saving for you. So please contact me and I'll be able to sell those to you at a very, very wonderful Christmas price. Folks, that stuff when you hear about the news, those are reporters just trying to get their name in the news most of the time. For first of all, if George Soros wants you to know what he's doing, he's probably doing the exact opposite. Because if he's doing something in the markets, he certainly doesn't want people to know what he's doing. I know sometimes he'll say that I'm selling and he's buying, we see that all the time. Warren Buffett is the master of that. But when you hear that in the news, take it with a grain of salt, folks, really look at the charts. Look at all during that time of all that writing and stuff, the market was rallying for heaven's sakes. That really doesn't... That's not... Mr. Peake is saying that it's not his real name and he doesn't trade anymore. I don't know any of those things. That sounds like conspiracy theory stuff. So I'm going to stay away from that. Hold on one second, folks. Okay. 877-927. I'm going to move on here to cover a couple other things that we're watching very closely. In the futures market, folks, keep a very, very close eye on the cotton. We've really... We're getting ready here. This is the daily cotton chart. We don't trade this... Mr. Z's been following this very closely and we just went up to the 50% retracement level. We're at that 68 resistance level. If you're like the cotton, the ideal situation, if you'd like to buy on a dip, would be to see it back off to about 63. That would be a 382 retracement of that big three-drive to a bottom. That happened down into August. How cotton... 7, and now we're up at 68. We rallied a little more than 20%. We're setting right at the 50% level. We're up like five days in a row, so we're watching this closely. I don't trade cotton, but Mr. Z has piqued my interest once again, and so we're going to keep following it, and he'll be following it in the room here. So pay attention to what he does, because it is... All we need is a little bit of a break down, and then a move back up above 68, and this thing can really have good legs. If you look at the rally that we had from December to April of last year, you see we went from... We went from 70 all the way up to 79. That was 9 cents. This time we went from 57 to 67. This time we went 10 cents. So these are almost equal rallies. So now we're due for correction. So I can't buy that into this, so I'd like to see it back off and make a beautiful ABCD pattern. Sometime in January or early February, that would be an ideal situation to take a look at cotton. Haven't traded cotton for a long time, but I'm going to be watching it because the pattern looks pretty good. It's tradable. The situation regarding cotton as trading is so different than it was 40 years ago. 40 years ago it was traded by a whole bunch of relatives in the cotton pits in New York, and now it's traded electronically, so you've got just as good as a chance as anybody else does trading cotton. So that's another one that looks real interesting. Also, remember the natural gas. I want to bring this up to your attention too because we had a really nice double bottom form here in the natural gas that we talked about last week. We got down to that 219 level. We're now back above that substantially. We're trading around 226. So as long as we stay above 219 in that natural gas, it looks like it could have a pretty good chance here to have a pretty good move to the upside. Someday I believe natural gas is going to be trading around eight or nine, but whether that happens in my lifetime, I don't know it or not because it's very clean energy and there's a whole lot of it, but with the solar energy and some of the other things that are happening, maybe we won't need that kind of energy. I don't know with the green piece coming, anything's possible, I guess. So we'll pay very, very close attention to that one. Also, another one that I'm watching for the new year, one second is this hopper, because we're up here in this area where copper should be running into some pretty stiff resistance. I don't know what it's doing now, but around that 286 level, we have some major ABCD patterns. I think I haven't checked copper in the last couple of days, but someone would be kind enough to let me know what copper is trading at right now because at 287, it's going to be pretty interesting possibility for a short at that level because it was a really great buy down there at 260 that Mr. Z was talking about quite a bit of the time. So let's, someone give me a heads up on where we are at 284. Okay, we're very, very close. So we've been a couple cents away and of course we've got the gold and silver running pretty good right now into this solar eclipse and new moon. I'll tell you that's a really big cycle, folks, in this gold and silver. So I think it would be really interesting to pay close attention to it when you watch these charts because that's a very, very, sorry for the phone folks, I can't turn it off.  So my wife usually takes care of that for me, but we'll hope it's not bothering you too much. I know it rings a little too loud, but there we go. There was nothing more than a, hit the little button on its side. Yeah, I tried that, it didn't work. Okay, I'll try it again to see if I can get it to work. I'm just not a technical person, but you know, I've survived this long, I guess I'll be okay. Okay, let's move on to the next one. It's the one on the opposite side maybe. I'll try to figure it out. I've only had it a little short period of time just a few days, so we'll see what happens with the rest of this. Oh, someone asked, oh, we got a break coming up here pretty soon, but I had a couple of Christmas stories that I wanted to share with you from the old Drexel days that I think you would really enjoy to hear, but we'll do that when we come back for the break. If you have a question, please call<PHONE_NUMBER>, and I'll be happy to answer it for you if I can. One of the questions people were asking me about the negative interest rates, folks, stop and think that's common sense.  That breaks every single rule of finance. Don't be concerned on the return on your money. Be concerned on the return of your money, and they're making, you're paying them and they're giving you no guarantee. Hello, it judges ruling, not a good idea.<PHONE_NUMBER>. For a secure investment, the Tiger First mortgage program may work for you. The security for these first mortgages are building lots in the tax opportunity zone in St. Petersburg, Florida. The Tax Act of 2018 set up tax-free zones across the country where you can build and hold for 10 years and pay no tax on the profits, which makes these lots valuable. The investment is anywhere from 30,000 to 75,000. The interest paid is 7% yearly paid on a monthly basis. According to bankrate.com, the best rate for a four-year CD in the country as of February 20th is 3.1%. A $50,000 investment at a normal four-year CD rate of 3.1% would give you income of $1,550 per year or $6,200 over the four-year period. That same $50,000 investment in the Tiger First mortgage program would give you $3,500 per year or $14,000 over the four years. What should you prefer? $6,200 or $14,000 of interest on your investment. If you'd like more information about the Tiger First mortgage program, you can call me at<PHONE_NUMBER>. That's<PHONE_NUMBER>. If you're a trader in the market looking for exposure to gold or gold mining equities, then now is the perfect time to sign up for Tom O'Brien's gold report. The summer is over. Gold is trading back above $1,500 and the 10-year treasury is hovering at around 1.5%. Tom O'Brien has been writing his weekly gold report for almost 18 years. There's no one that knows more about how the gold market trades and how gold mining equities react. New subscribers get a 30-day money-back guarantee so you have nothing to lose. Every Monday morning, Tom publishes his weekly gold report with coverage of gold, silver, bonds, the XAU, HUI, GDX, the dollar, as well as more than 30 different mining equities. As of September 3rd, gold report subscribers have five active open positions with an average, unrealized profit of almost 38% for each position. To see for yourself the types of profitable trades that are recommended within the gold report, sign up today by visiting TFNN.com. Will the S&P 500 continue to climb for bold trades on U.S. large-cap stocks in either direction, trade SPXL, SPUU, or SPXS, directions daily, S&P 500, bull and bear, leveraged ETFs, direction leveraged ETFs? An investor should carefully consider a fund's investment objective, risks, charges, and expenses before investing. A fund's prospectus and summary prospectus contain this and other information about direction shares. To obtain a fund's prospectus and summary prospectus, call<PHONE_NUMBER> or visit DirectionInvestments.com. A fund's prospectus and summary prospectus should be read carefully before investing. An investment in the funds is subject to risk, including the possible loss of principal. The funds are designed to be utilized only by sophisticated investors such as traders and active investors. Distributor for Side Fund Services, LLC. The Bull Bear Trading Hour with Tom and Tommy O'Brien. Next. Okay, folks. I've been asked to share a couple of old stories from Drexel days. And Christmas time is always one of the best. We had a retail broker there, Gene Fairman. And he was good with Drexel for quite a while. He had worked for Reynolds & Company for quite a few years and then switched over to Drexel. He'd been there about 10 years by the time I got there, which was in 1976. And we were having a Christmas promotion for one of the orphanages in Los Angeles that one of the big wigs at Drexel was promoting. And they started to have a little contest about which of the brokers could give the most... give the most money, you know, to the charity.  All the expenses paid. And so they started bidding on this thing. Of course, remember, this is 1979 and things are heck of a lot cheaper than they were now. But it quickly got to $50,000. Then it got to $75,000. Then it got to $100,000. And then it stalled there. And we had about three weeks to go in the thing. And one of the Milken guys, I don't know, it wasn't Mike, but it was one of the other guys that was in the group. It wasn't any of the big four, but it was one of the big, big boys. All those boys made a million bucks. I mean, that was nothing to make a million dollars up on that floor. Anyway, we got to about... I think it was about $200,000 bidding and Fairman came in one morning and he said, okay, he said, I'm giving $500,000 for these tickets. And everybody says, you're nuts. And he was... It was just about all he made for the whole year. It was around $500,000. He's just going to give the whole thing. You see, I'm going to give the whole thing. And so he did win. He won the whole thing. And what was really interesting was, is that after he did it, Drexel picked up the tab for the hodarn thing. All right, we got a caller.  John from Oakland, Michigan. John, how are you? Larry, I'm great. I haven't had a chance to call you in a long time, but today's the day I wanted to get in with you. Hey, the reason for my call is I saw a story. I want to say it was last week that someone had bought a huge shot of gold call options. And here's what it said. Somebody plucked down a million and a half dollars to buy 5,000 June 2021. Not this June coming up in 2020, but June 2021, $4,000 strike, $4,000 strike price, gold calls. Have you seen that story? Have you heard that? Well, John, I know the answer to that. I have not heard the story, but there's one other thing I could add to it. It was not me. I don't see why anybody... Well, hey, people do a lot of different things, but to sell calls is a better thing to do. Somebody took the other side of that trade, but 5,000 is a very... It couldn't have been very expensive. It had to be just a dollar or two. It was $3. $3. Yeah, $3. So someone's got $2 million to play back or add or what do they want to do? That's what it amounts to. But I don't believe those things. And that's over my pay grade to try to figure it out. All I know is in the only way you're going to make money in options is you've got to be an option seller. If you sell the calls and you sell the puts, you can make money. But if you buy a put or buy a call, you're going to make money maybe one out of 10 times. But usually it's a losing proposition. Tom O'Brien Jr. and Tom O'Brien Sr. talks about that quite a bit. They have the boys on with TD Ameritrade talking about it. So it's good information to talk about at a dinner party and stuff. But I really don't know the answer to that. Certainly could be. There's no question. All you have to do is you look at the open interest and you're going to see if somebody came in here and bought that money because it'll tell you whether they did or not. I couldn't find open interest with that number. And it wasn't a reliable publication that I saw that. It was either.  I look at barchart.com from time to time. It was one of those types of outfits, I thought. But I couldn't find the open interest worth. You know, we had that number of calls out there. Well, you know what I'll do is when we come up to the next break here, which is going to be in about three minutes, what I'll do is I will go into the CME and pull up the calls for that. You said June of 2021? Yeah, June 2021. And it was the $4,000 call. I don't think they had a strike crisis. I didn't take anything of it. I just looked at it.  But, you know, 13 days in a row with silver up, gold popping over 1,500. And I remember one other thing, you know, I keep things in my mind. Paul Tudor Jones, and I called you about this probably a couple months ago. Paul Tudor Jones made a call one time on a show called Real Vision. And he said that if gold broke through 1,400, it would run to 1,700 in a shot. And we had that, you know, we had that breakout was a couple months ago where it broke through 1,400 and made a big run and then all of a sudden just collapsed, you know, come back and now all the time it's making a run. So I just thought I'd call you. It only made it. It only made it big call that, which I can't find proof of. But I like it. I will do this, John. It wasn't some goofball thing. If I can't check it today, I will check it by tomorrow to find out if there's anything like that in the data. And I just been talking to the Mercs or I know the person to call there and they can tell me, and they could probably tell me who's on the other side of the trade too. Well, they know the answer to that, whether they give it away or not, that's a little question you might have to agrees upon or two, but you can find that kind of stuff out. But I will take a look at it. Regarding that gold, you know, that pullback was really not a collapse. We dropped about 160 bucks an ounce down to 15, excuse me, to 1445, which was the 382 retracement of the last low. So that's why gold looks so bullish. I mean, it really does. I mean, it's got roots rocking and rolling. I have a hard time buying it today. I did a little last night, just because I knew it was going to get up above 1510 for a minute, but right now I'm just waiting to see how it handles this next high that we got in about two hours. We'll see if it does anything. But hey, listen, thanks for calling in and please call in more often. Welcome to you and you have Tom who guard and David, I can't David Paul. So wonderful. And happy holidays to you and your family. Mark Douglas's DVDs on trading. So thanks very much. You bet. Thank you. All right, folks, we're going to have another break coming up in here and we'll see what's going on here. Let's see what we have here with how gold's acting so far this morning. We've been up almost to 1514. The resistance is 1515. That's the one that we're sort of keeping a little bit of an eye on. But keep a close eye at about 1140 today, folks. Excuse me, 1040. That's in about an hour, just about, well, 50 minutes from now. Watch the gold because there's a possibility we might have a little bit of a high coming in at that point. And it'll be interesting to see whether it'll actually do anything from that level and we'll watch it closely. Another one to watch, of course, is the E-mini S&P. I think we just made new highs in the NASDAQ, as I recall. I think we did. Yeah, we just did. We just popped up and made new highs in the NASDAQ and we're making new highs in the S&P as we should because we're over a lunar eclipse and a new moon.<PHONE_NUMBER>. It's the best of the best at everything you do in life. It's the most common trait that we tigers and tigers share. If you're looking to become the best of the best when it comes to managing your money, let me teach you to do what most wealth managers tell you can't be done, which is how to time the markets. I'm Steve Rhodes, author of Mastering Probability and for the last 12 months, Timer Digest has been tracking my newsletter signals which have earned me the ranking for the last six and three months. Timer Digest also ranks me as the number one market timer for gold as well. The fact is, markets can be timed and I'll teach you the exact set of tools that I use that has transformed me into one of the best at what I do. Sign up for Mastering Probability today by clicking on the newsletter tab on the homepage of TFNN.com and get immediate access to workshops where I take you step by step how to use an extraordinary set of tools as well as provide great market calls too. Sign up today. If you haven't checked out the newsletters page of TFNN.com, what are you waiting for? All of the TFNN newsletters are informative, up to date, affordable and must have for every trader looking to gain a competitive informational edge in today's markets. TFNN newsletters cover every aspect of the markets to offer you the very latest in market news. Plus, new subscribers get to test drive our newsletters risk free for 30 days. From all aspects of the markets including stocks, bonds, metals, commodities and tech, there's a newsletter to fit your needs exclusively from TFNN. Stay informed each day you trade and get the competitive edge that will help you stay ahead of the game. Visit our newsletters page by going to TFNN.com and click the newsletters button near the top of the page. TFNN.com Since 1984, Basil Chapman has been using the Chapman Wave methodology to advise traders of his expert market opinion. While originally hand drawing charts from the late 1970s into the 1980s, Basil noticed that prices under most circumstances virtually always had a certain number of legs to the upside before declining sharply. Later Basil found that computer software which included the standard market technical indicators enhanced the degree of accuracy in calling price turns as well as market trend calls. Thus was born the Chapman Wave sequence. Using the Chapman Wave methodology along with other indicators, Basil Chapman advises his subscribers of his expert market opinion each market day with his opening call newsletter. Right now you can get a two week free trial to the opening call, Basil's daily trading newsletter, by visiting the front page of TFNN.com. Cancel at any time during that trial and pay absolutely nothing. Get your two week free trial to Basil's newsletter today by visiting TFNN.com. This segment is brought to you by Think or Swim. For more information, just click the Think or Swim banner on the front page of TFNN.com. Okay we're back folks and we were talking to John in Michigan about options in gold for 2021. The open interest, the total open interest in June Gold for 2021 is only 17,000 excuse me, 1718 contracts. So I think that person I'm not even sure what the strike price is let me double check the strike. No, there's nothing anywhere near that. He might be doing it off exchange or a different exchange or foreign exchange. I don't know but it doesn't show that in the Merc anywhere at all. My two cents worth but I will watch it but I'm not sure how it's going to end up to see what's going on here. Okay I think what we'll do here this is the day after Christmas so we'll just do something a little different here. I'm going to send a few ideas out today because we're over something really interesting now in the Nasdaq. You don't have to wait very long if this is correct. Yeah it's you're right Marshall it's on the BS exchange that's the Boston Singapore exchange. I've used it quite a few times in my life. Okay here's the Nasdaq it looks exactly like the S&P we should be topping here in the first hour right around now whether we get much above these new highs or not I don't know it's all about risk control but keep a close eye on it but this is a lunar eclipse full moon type thing. I want to do the gold one too if I can I think I've got it ready here I don't know if I do or not I don't know but it's due to top in about 40 minutes of gold if it's not much above 15 15 it would be a very low risk short at that level if it does get to there but we'll have to do one thing at a time that's really what we're paying attention to here. You can see here what it looks like from early this morning that I was looking at I told you that I nibbled the gold from the long side and got out of it a little above 15 11 but here you see that time we're looking at there that is a 10 about an hour from where we are right now 1045 to 1050 for up around 15 15 15 16 and what you do is you wait for it to back off a little bit so you can quantify your risk live every day in an attitude of gratitude and may God bless you. See you on the flip side tomorrow. Bill Meridian on Monday boys and girls. Bill Meridian on Monday.