Russ

Author Archives: Russ

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