Palo Alto Networks Acquires LightCyber for $105M
Palo Alto will sell LightCyber products until its tech is integrated into its security platform.
Why no YANG??
I was at Cisco Live in Berlin last week, and I came away with a question: why no YANG?
Here is a YANG model represented in YIN—this one describes an interface in Quagga, and is easy to read:
YANG can be expressed in many ways, such as YIN, or in a model format (which is still easy to read), or in json format. This is an example of HTML, taken from the Vimeo site:
The YIN representation of YANG is XML, and XML is also a superset of HTML.
The post Why no YANG?? appeared first on 'net work.
Response: IETF RFC 8033 Proportional Integral Controller Enhanced (PIE)
Proportional Integral Controller Enhanced (PIE) is another active queue management algorithm for dropping packets.
Similar to RED, PIE randomly drops an
incoming packet at the onset of congestion. Congestion detection,
however, is based on the queuing latency instead of the queue length
(as with RED). Furthermore, PIE also uses the derivative (rate of
change) of the queuing latency to help determine congestion levels
and an appropriate response. The design parameters of PIE are chosen
via control theory stability analysis. While these parameters can be
fixed to work in various traffic conditions, they could be made
self-tuning to optimize system performance.
We know that Bufferbloat is problem, and there are many algorithms proposed. PIE might be suitable for existing network hardware since its approximates Random Early Discard. BBR Congestion Control has been suggested and implemented by Google (related to QUIC/HTTP2) and possibly has the momentum, so I’m not sure if PIE
Link:https://www.rfc-editor.org/rfc/rfc8033.txt
Link: BBR: Congestion-Based Congestion Control – ACM Queue – http://queue.acm.org/detail.cfm?id=3022184
The post Response: IETF RFC 8033 Proportional Integral Controller Enhanced (PIE) appeared first on EtherealMind.
Palo Alto Stock Down 22% After Earnings
Competition from the likes of Cisco and Check Point is rising.
Getting Started with Lyft Envoy for Microservices Resilience
This is a guest repost by Flynn at datawireio on Envoy, a Layer 7 communications bus, used throughout Lyft's service-oriented architecture.
Using microservices to solve real-world problems always involves more than simply writing the code. You need to test your services. You need to figure out how to do continuous deployment. You need to work out clean, elegant, resilient ways for them to talk to each other.
A really interesting tool that can help with the “talk to each other” bit is Lyft’s Envoy: “an open source edge and service proxy, from the developers at Lyft.” (If you’re interested in more details about Envoy, Matt Klein gave a great talk at the 2017 Microservices Practitioner Summit.)
Envoy Overview
It might feel odd to see us call out something that identifies itself as a proxy – after all, there are a ton of proxies out there, and the 800-pound gorillas are NGINX and HAProxy, right? Here’s some of what’s interesting about Envoy:
- It can proxy any TCP protocol.
- It can do SSL. Either direction.
- It makes HTTP/2 a first class citizen, and can translate between HTTP/2 and HTTP/1.1 (either direction).
- It has good flexibility around discovery and Continue reading