Re: [j-nsp] ACX5448 & ACX710
Mark, So which box is best to just get customers a simple IP, but has all the management and metro-e requirements you need? On Fri, Jan 24, 2020 at 1:53 AM Mark Tinka wrote: > > > On 24/Jan/20 08:49, Saku Ytti wrote: > > > > > When we asked JNPR why Jericho instead of Paradise, as we see these > > chips for the same market, JNPR told that main motivation was OAM > > features which they lack in Paradise but need in metro. > > The OAM story came up as well, as being the major improvements from > Trident to Jericho. > > If I'm honest, given that everything has gone IP + Cloud, the demand for > VPN's - as we've known them - is no longer there, really. Well, at least > in our market anyway. At which point we introduce the fresh buzzword for > 2020 - "SD-WAN". Oooh, but don't forget, we now have "SD-LAN" and > "SD-WLAN". Just keeps getting better and better. > > In short, we don't really have a huge OAM demand simply because our > customers just want simple IP. They just want to get to their Instagram. > > Mark. > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Automation - The Skinny (Was: Re: ACX5448 & ACX710)
On 24/Jan/20 12:10, Saku Ytti wrote: > In my opinion we do roughly the same thing, the same way in networks, > with the same protocols since my start of career in 90s, very little > has changed and you could drop competent neteng from 90s to today and > they'd be immediately productive. Compare this to what has happened to > compute the difference is striking. Agreed - but is it really enough to the extent that the common buzz sentence nowadays is "Network engineers are dead, they'll all be replaced by software [developers]"? I mean, I'd wager that more than half of the problems you find with automation and tooling development is a total lack of protocol between software developers and network engineers; in the same company. While there has been plenty of success with a software developer reading a networking-related RFC and writing code for that without needing to understand, really, how IP/MPLS networks work, it's a whole other issue trying to teach a network engineer how to write code, or a software developer what IS-IS actually does. I can't remember if I gave this example here before, but I know of a network operator in Vienna who had to scramble and get their engineer trained on CLI when they'd been setting up peering sessions fine for 3 years via a GUI, and when the GUI and automation front-end all went to hell, that network engineer didn't know how to fall back to simple CLI to setup even simpler BGP sessions for peering, by hand. While clicking on GUI's is great, I don't have confidence that a network of any decent scale can be ran, today, without some form of CLI jockeying. And on the back of that, do we want to kill off the basics of a network engineer in favour of Day 1 university graduates eager to click a GUI button when provisioning your backbone, and they don't actually understand what the "Wide Metric" checkbox actually means? > People who think that netconf and yang are solving big problems and > are key to solve automation probably haven't done much automation. Totally agreed. But to also be fair, NETCONF/YANG are normally being touted by vendors (much like Segment Routing, 5G and SD-WAN, but I digress). I've not really found actual operators with anything meaningful and useful to say about NETCONF/YANG. Raise your hands if I'm talking nonesense. For us, we find this whole NETCONF/YANG thing to be too heavy for simple instructions you need to send to devices, not to mention the fact that support within and between vendors is questionable (FlowSpec, anyone?). I mean, that's why Ansible was so pleasing to our fingertips - all you need is SSH and a large-enough, repetitive problem you want to go away quickly. > Roughly netconf is new snmp and yang is new mib, what ever they enable > could have been enabled by existing protocols decades ago, the > advantages are modest and will remain so. Completely agreed! > The key enabler for > automation is device accepting arbitrary new B config when it is > running arbitrary new A config and transition there hitlessly. > Generating full new config from DB+template is trivial problem, trying > to be aware of network state and move from arbitrary state A to > arbitrary state B with minimal amount of changes is hard and > unnecessary problem. I tend to agree with you, Saku. What I've heard (from the vendors, again) is that Ansible is not great because you don't inherently get state confirmation feedback after posting the new configuration, and that adding that intelligence into Ansible requires time and energy to code. Okay, fair point, I'll bite. But also, we are network engineers - we know what commands do when they run, and we've spent decades building templates from as simple as a Windows Notepad text to as complex as a MySQL database. Then again, Terraform is meant to fix that downside of Ansible, but for me, I don't really see that as a big issue. We aren't trying to provision services across network domains (despite what MEF's LSO architecture will have you believe), and even if we were, do I really want you fiddling in my network. We each know our networks better than outsiders know them, so what gives? > If/when network becomes more cloudified, more as-a-service, where you > use API to turn up your own active devices and circuits where you > want, when you want, instead of owning anything and once those > proprietary APIs get some subset standard APIs we'll probably start to > see openstack, kubernetes type of complexity explosion in networks > too. MEF's LSO, which they've been pushing since about 2014. The concept is sexy, but honestly, I've not heard much ado in 6 years re: real-world deployment. Also, while I'm wild enough to be one of the first maniacs to run a network-wide Route Reflector on a VM on a server in 2014, you won't find me deploying said RR's in AWS or Azure, so I can access them over some API into an Openstack/Kubernetes/Docker enclosure. Life is too interesting enough as it is :-). > But as long
Re: [j-nsp] Automation - The Skinny (Was: Re: ACX5448 & ACX710)
On Fri, 24 Jan 2020 at 10:33, Mark Tinka wrote: > Since about 2012, every time we've felt we've come close to finding an In my opinion we do roughly the same thing, the same way in networks, with the same protocols since my start of career in 90s, very little has changed and you could drop competent neteng from 90s to today and they'd be immediately productive. Compare this to what has happened to compute the difference is striking. > My 1+1 assessment of all of these issues is, I believe, down to the fact > that the industry wants to automate in an open standards manner, where People who think that netconf and yang are solving big problems and are key to solve automation probably haven't done much automation. Roughly netconf is new snmp and yang is new mib, what ever they enable could have been enabled by existing protocols decades ago, the advantages are modest and will remain so. The key enabler for automation is device accepting arbitrary new B config when it is running arbitrary new A config and transition there hitlessly. Generating full new config from DB+template is trivial problem, trying to be aware of network state and move from arbitrary state A to arbitrary state B with minimal amount of changes is hard and unnecessary problem. If/when network becomes more cloudified, more as-a-service, where you use API to turn up your own active devices and circuits where you want, when you want, instead of owning anything and once those proprietary APIs get some subset standard APIs we'll probably start to see openstack, kubernetes type of complexity explosion in networks too. But as long as we keep owning the network most will keep running it CLI jjockey network, touch when you must, but in many cases no one touches it for weeks or months. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Automation - The Skinny (Was: Re: ACX5448 & ACX710)
On 23/Jan/20 12:59, Thomas Scott wrote: > I had that conversation the again other day - someone said they were > working on "automation" and when I probed deeper it revealed some > (very useful, albeit not scalable) scripting. 'You keep using that > word. I do not think it means what you think it means' seems to be the > gist of most "automation" conversations, and I'm guilty often as not - > 'automate it' seems to be a catch all for most of our operations issues. You raise an important point. The "automation" story is something most operators feel they need to be talking about, and if they aren't doing anything yet or don't know how to contribute to the discussion, feel better about not admitting that they aren't doing anything about it nor have a plan yet that they are really comfortable with. When it all started going to hell with "SDN" back in 2011, skeptical-me was immediately activated. I attended the MPLS/SDN/NFV/IPv6 congress in Paris between 2013 - 2015, and realized I had little appetite for venues where most presenters are trying to out-hype each other with the next buzzword. I mean, you start to get a little "Uh huh" when someone comes up to the stage and announces, "MPLS is dead and will no longer be seen in networks from 2015". Since about 2012, every time we've felt we've come close to finding an "automation" solution that actually works and scales as good as it sounds on the tin and from the community, we just get that niggling feeling that things just aren't yet quite ready. We don't have swaths of software developers lining our corridors ready to write code for whatever we want. The few we do have are inundated with other tasks that could have immediate but long-lasting solutions, as we wade through the maze and sea that is "automation". In 2020, after all the stories and buzzwords, we are honing in on Ansible and Terraform, and even with those, we are being careful not to waste time and resources we don't have. All other solution, IMNSHO, are just a waste of time, in our view. My 1+1 assessment of all of these issues is, I believe, down to the fact that the industry wants to automate in an open standards manner, where both vendors and operators are able to solve all implementation and operational tasks with automation. If we did not have to have an open standards mechanism for this, we'd all be automating - individually - to our heart's content. I mean, we all know that the largest of largest operators have had internal automation for decades, and despite all the work going on at an industry level "to automate", they continue to have and build their own internal automation tools that are bespoke and proprietary to them. While they see the need to join the industry in standardizing stuff they've already been doing for decades, they also aren't feeling the pressure to push that harder than they could. After all, the tools they've built are what has given them the edge, and they aren't going to let that go anytime soon. And yes, even though we sometimes get crumbs and drabs from the large content providers, when they are in the mood, it's what they are willing to share with us, their subjects. There's heaps more of interesting and exciting code they will never share with the community, even though they are some of the loudest faces you will find pushing for "industry-standard automation". Since general consensus amongst those who haven't been "automating" for a while now is that we should only automate if it is standardized, the majority of the industry really interested in that agenda gets both stuck in limbo and yo-yo, almost in an endless loop. Why, because unlike large network operators who've been automating for decades, and unlike large content providers who can throw 1,000 software developers at one command line, the rest of the Internet community is not as gifted. While I'm not suggesting that automating internally and independently of the industry is the solution, my recommendation is to take a step back from all the noise, as an individual operator, and assess your place in the entire mix, and what this all means to you as a single network, and to the industry that you love and want to support into the next 100 years. For us, we still have a healthy dose of CLI communication with our network to keep our engineers fresh and actually in tune with really understanding what the network is actually doing. But we are also going down the Ansible + Terraform path like Indiana Jones into a cave... slowly and looking out for the mine fields laid not by Ansible or Terraform, but by the politics automation has created in our industry. It is also good to realize that if we are working from a "Day 1 to Day End" position, that's never going to come. So we need to be deliberately (and perhaps, selfishly) smarter about the paths we want to go down re: "automation", as individual network operators. Mark. ___ juniper-nsp mailing list
