Archive

Category Archives for "Russ White"

DC Fabric Segment Routing Use Case (3)

In the second post in this series, we considered the use of IGP-Prefix segments to carry a flow along a specific path in a data center fabric. Specifically, we looked at pulling the green flow in this diagram—

benes-segment-02

—along the path [A,F,G,D,E]. Let’s assume this single flow is an elephant flow that we’re trying to separate out from the rest of the traffic crossing the fabric. So—we’ve pulled the elephant flow onto its own path, but this still leaves other flows to simple ECMP forwarding through the fabric. This means some number of other flows are still going to follow the [A,F,G,D,E] path. The flows that are randomly selected (or selected by the ECMP has) to follow the same path as the elephant flow are still going to contend with the elephant flow for queue space, etc.

So we need more than just a way to pull an elephant flow onto a specific path. In fact, we also need a way to pull a specific set of flows off a particular path in the ECMP set. Returning to our diagram, assume we want all the traffic other than the elephant flow to be load shared between H and B, and Continue reading

Reaction: Standardization versus Innovation

Should the Docker container image format be completely standardized? Or should Docker not be held back from evolving the format ahead of the open specification? This was the topic of a heated Twitter tussle last week between Google evangelist Kelsey Hightower and the creator of the Docker itself, Solomon Hykes. —New Stack

What is at stake here is the standardization versus innovation. Should Docker standardize their container technology or not?

On the one side is the belief that standardizing squashes innovation. Once you’ve standardized something, and other people start building on it, you can’t change the standard without a lot of agreement and effort—after all, other people are now depending on your product remaining the same across many cycles of development. This certainly kills innovation, as implementing new things both exposes your ideas to public view before you can implement them, and slows down the pace at which new ideas can be deployed in the real world.

On the other side is the belief that standardizing is necessary for the market to mature, and for a healthy ecosystem to develop that’s better for the entire community. How can customers and other vendors build products around a particular product if the Continue reading

snaproute Go BGP Code Dive (7): Moving to Connect

In last week’s post, we looked at how snaproute’s implementation of BGP in Go moves into trying to connect to a new peer—we chased down the connectRetryTimer to see what it does, but we didn’t fully work through what the code does when actually moving to connect. To jump back into the code, this is where we stopped—

func (st *ConnectState) processEvent(event BGPFSMEvent, data interface{}) {
  switch event {
  ....
    case BGPEventConnRetryTimerExp:
      st.fsm.StopConnToPeer()
      st.fsm.StartConnectRetryTimer()
      st.fsm.InitiateConnToPeer()
....

code-diveWhen the connectRetryTimer timer expires, it is not only restarted, but a new connection to the peer is attempted through st.fsm.InitiateConnToPeer(). This, then, is the next stop on the road to figuring out how this implementation of BGP brings up a peer. Before we get there, though, there’s an oddity here that needs to be addressed. If you look through the BGP FSM code, you will only find this call to initiate a connection to a peer in a few places. There is this call, and then one other call, here—

func (st *ConnectState) enter() {
  ....
  st.fsm.AcceptPeerConn()
  st.fsm.InitiateConnToPeer()
}

The rest of the instances of InitiateConnToPeer() are related to the definition of the function. Continue reading

Layer 2 Routing—Haven’t we been here before?

We often think the entire Internet, as we know it, just popped out of “thin air,” somehow complete and whole, with all the pieces in place. In reality, there have been many side roads taken, and many attempts to solve the problem of pushing the maximum amount of data across a wire along the way. One of these ways came to mind this last week, when I ran across this story—

Also on the virtualisation list is the customer premises equipment (CPE), and this deserves a little explanation. Obviously every premises needs some sort of physical connection to the network providing the services. What CPE virtualisation refers to is making the CPE as generic as possible. —The Register

Pulling layer 2 into the network to centralize the edge—where have I heard this before? Maybe it was all those years ago, when I was in TAC, and we used to support Cisco 1001’s, or the LEX—LAN Extenders. The promise then was the same as the promise now: a lightweight, easy to manage device that would relocate all the intelligence from the network edge into the access layer of the “mother ship,” where it could be properly managed.

Remember Rule 11? If Continue reading