It is not easy to start and make when learning and mastering a programming language – even these days with “Mr. Google” who knows is all. The main challenge is to dig up the adequate information for you to learn, understand and assimilate depending on your level of need.

Many of us have some URLs you tend to frequently visit and have them as bookmarks in your mini-URL library. These serve you as your main reference material when needed. Well, below are my top 2 URLs that I have found very useful and which are part of my Python URL library:

Python.org:

By far an without a doubt, this is the main site to keep in your Python bookmarks. It is very extensive, clear and has plenty of “to-the-point” information that all Python programmers need at some point in time.

Python For Fun:

This is Chris Meyers’ URL and I enjoy the clarity and explanations that Chris has put into his Python programming examples. It is a good site for initial and intermediate level challenges.

In this new networking era, characterized by the dissemination of concepts such as SDN, automation, X-ops (e.g. DevOps, NetOps, SecOps, etc), it is always good, in fact, critical I would argue, to take time and ponder what some of these commonly used concepts really mean.

Once you start peeling these concepts, you may find that some of those are either old concepts “with new wrapping paper” or incremental variations from old concepts and only occasionally, you are lucky to really find a totally new definition. Those of you who are not new in networking must be nodding your heads in agreement.

However, there are other concepts or definitions which can easily trigger “silent” confusions – those confusions when speakers both believe understand the concept – when in reality, their understandings are different or too general. One of these concepts on top of my list is the definition of flow in networking.

Do you know what a flow is ? — Ohh…that question can make many network engineers, security engineers, system administrators, software engineers, and SDN engineers nod their heads affirmatively and quickly say yes – probably all at once.

Well, a flow is exactly one of those concepts that is ideal for causing undetected confusions. In this blog, I’ll review a few of the different meanings and their applicable context as well as some of the potential “silent” confusions which can derive from these.

Let’s start by checking what “Mr. Google” find for us as answers to the: what is a flow? question:

In Network security, often a flow is defined as the set of packets which satisfies a 5-tuple matching of the packet header fields: Source IP address, Destination IP address, Protocol (these in the IP header), Source Port, and Destination Port (these last two at the TCP or UDP header).

In Ethernet, Network engineers often leverage the IEEE 802.3ad (now IEEE 802.1ax) standard to bundle multiple physical ethernet links and load balance traffic across them. In this context, a flow could mean a set of frames whose following 5-tuple header fields match: SA, DA, protocol, TCP/UDP SA and TCP/UDP DA.

In the RSVP RFC  (RFC 2205), a flow is defined as part of an “RSVP session” which; subsequently, is defined by a set of packets with the following matching triple header fields: IP Destination Address, IP header Protocol ID, and a “generalized” Destination Port. The generalized destination port can be either a UDP/TCP destination port field or another “application-specific” information.

Also in RSVP, there is this concept of “Flowspec” which, along with a filter spec, define a “flow descriptor”. It is this flow descriptor which, along with a session specification, defines a common set of data packets — yes… it defines “the flow” in RSVP.

When using netflow, there definition of flow data can be rather specific. Cisco, as the creator of net flow, originally defined a flow as a unidirectional set of packets matching a set of 7-tuple header fields: Ingress Interface (SNMP ifIndex), Source-IP address, Destination IP address, IP protocol, Source UDP/TCP port, Destination UDP/TCP port, and IP Type of service.  As netflow had additional releases and other versions (e.g. IPFIX) came to the market place, the original concept of a 7-tuple flow definition was abandoned and it gave users freedom to assign the matching fields defining a flow.

When dealing with IPv6 packets, it is entirely possible to define a flow in a unique way given that the IPv6 header field includes a field called: “flow label”. This label technically provides the flexibility to define any set of IPv6 packets to be part of the same “flow” by simply assigning a common value in their IPv6 flow label.
In an SDN Openflow, the matching field of a given flow can technically be any combination from 1-15 fields. An interesting remark is that the ONF’s Openflow standard uses the word “flow” frequently even though it does not explicitly provide its definition.

So, in a nutshell, keep in mind that the concept of flow can be a chameleon in the networking lexicon ecosystem.

Our Networking technology area does not have a widely-accepted, well-known hippocratic oath – and much less a homologous “Hippocrates” representing the moral compass and standard for each action taken.

However, we should consider having one with a good underlying moral fabric:

* Networks should keep clear documentation.

* Network should be designed to first and foremost serve its intended traffic  – not all traffic.

* Networks should be designed with scalability in mind.

* Networks should hold simplicity as one of its major requirements.

* Networks need to support sensible, relevant statistics.

OpenFlow… ahh… that controversial word that has plenty in the industry taking side on whether they are on the “fan” SDN camp or on the “not-important” SDN camp.

For those who are interested in knowing more about how you can get your current network to migrate towards an OpenFlow-driven network, it is important to consider how migrations can take place and who has already done it (so you are not on the “bleeding edge”).

The below is a solutions brief I worked on as part of an ONF team in which the main migration considerations are presented and some prominent use cases are highlighted. This is the link to the solutions brief.

DDoS/DoS attacks have proven to be an interesting security challenge in networks these days. The fact that these can be difficult to detect by differentiating them from the “normal acceptable” traffic is at the center of this difficulty.

For an excellent, practical DDoS Attack Best Common Operational Practices, please Click here

Service providers are well familiar with VPLS as a way to leverage their MPLS infrastructure to effectively provide their customers with extending “Ethernet LANs across WANs”; effectively, creating Ethernet domain stretches. Service providers know that VPLS has its short comings; but overall, it has gained a place in their networks to support certain end customer services.

But EVPNs entered the service provider feature set more recently than VPLS and; the EVPN implementations have been maturing to the point that there are some advantages they bring to a network over VPLS implementations. What are those advantages? Are these significant advantages or not ? – these are the bottom-line questions that customers commonly raise.

Let me mention two main advantages of EVPNs over VPLS. There are others, yes… but, these two clearly fall in the “significant” category.

The first difference is that EVPNs use the control plane to communicate MAC+IP address reachability among PE devices while EVPN’s data plane is similar to VPLS data plane. What does this really mean in simple jargon?  In short, it implies that the multiple PE control planes communicate to each other to exchange the MAC+IP bindings and; since this is done at the control-plane level, there is more freedom for network engineers to filter what is imported or exported at each PE – thus, automatic PE-PE flooding, which is part of VPLS,  is consequently, avoided.

The second difference I like to highlight is that EVPNs allow for an active/active multi-homing scenario from a CE-PE perspective. Unlike VPLS which allows for an active/passive multihoming protection. This feature allows EVPN CE’s to actually run a Link-Aggregation protocol across two distinct PE’s which; consequently, permits the implementation of load balance hashing schemes – very nice.

The above two differences should be sufficient to make those service providers with no EVPNs plans yet to raise their eye brows, shake their heads and think: We need to evaluate EVPNs.

Yardiel