(via Searching for an SDN Definition: What Is Software-Defined Networking? - Network Computing) Required reading.
“
In my view, SDN is not a tipping point. SDN is not obsoleting anyone. SDN is a starting point for a new network. It is an opportunity to ask if I threw all the crap in my network in the trash and started over what would we build, how would we architect the network and how would it work? Is there a better way?
All we are seeing today are failures and proofs of varying success to a new network. Drawing conclusions at this stage of development is pointless. We should be intrigued that people are asking: is there a better way?
”Missing the Point on Software Defined Networking (SDN) « SIWDT
Could not agree more. In fact, one of the big reasons I came to Juniper.
QFabric:
- Clean sheet approach to the DC network problem
- Software architecture with distributed control plane, but managed as a single entity. (An SDN)
- Hardware architecture that lowers latency & provides the equal-distant performance needed from SOA and turning DCs into computers without relying on the vulgarities of Ethernet as a transport mechanism (an integrated SDN)
- No change in behavior for compute / storage required as external interfaces are all standard.
- JUNOS automation (Netconf, etc) for infrastructure workflow/orchestration & connectivity to Openflowy sorts of stuff
Will QFabric be the cats meow vs and along with the 30 other solutions to DC networking? Time will tell. What’s important is the market is now questioning new decisions, something it hasn’t done in a decade. Game on.
“Mr. Hölzle said Google would not be donating its networking software to any open source project. “It is very specialized,” he said.”
Google Opens Up About Its Network - NYTimes.com
Google’s Openflow is not your Openflow.
“Support is perhaps the biggest hurdle that stands in the way of adoption of OpenFlow. In order for product networks to adopt and deploy OpenFlow, ‘enterprise-class’ support must be made available. This is not as simple as troubleshooting a single switch, which can in itself be complicated depending on the logging capability and probes one may have on/in the network, but rather will span multiple devices, multiple disciplines, and (the greater challenge) quite possibly multiple vendors.”
Software-Defined Networking: Part 2 « IT Connection Blogs
Good observation. Likely why some of the Openflow start-ups want to be the “Red Hat” of networking.
“ODM hardware + Openflow does not = innovation”
Notebook 03.13.12: Datacenter, Equities and HPC for Wall Street « SIWDT
Follow this blog. A rare combination of network and financial savvy.
Struggling with emerging Datacenter network architectures
Over the last four days an interesting discussion around Openflow and QFabric. Granted it was kicked off by @Bradhedlund who is a knowledgeable guy when it comes to networks, but also works for Cisco as is known to shall we stay incite conversations from time to time.
[I’ll note here that when I originally posted this, I used a semi-derogatory name to describe Brad - which might have been fine had we been sitting around drinking beers, but was obnoxious on all other levels. I wasn’t thinking and it wasn’t right even though he and a bunch of others seemed to take it well. Brad - my apologies.]
This conversation highlights a common misconception of QFabric which is because it is deployed in multiple components, many network folk want to treat all the bits like a network… except it’s not. It’s a switch.
In general when ever you have a question about QFabric, start with - How would a single switch do that today?
Of course, the insightful people in the network community acknowledge the data path, but then go straight to the control plane, congestion management, and management of a intra-datacenter connectivity solution and begin asking lots of questions. Which of course is the right thing to do as at the end of the day resiliency and stability often trump performance.
Updated with tweets from @boobasan and @ccie15672
bradhedlund If the goal is “one big switch”, is it just me or did OpenFlow already obsolete QFabric? 11:26 PM May 20th, 2011
colinmcnamara @bradhedlund Correct me if I am wrong, but isn’t OpenFlow more focused on end end standard based PVLAN equiv? 11:44 PM May 20th, 2011
colinmcnamara @bradhedlund Though I can see the VNtag / Qfabric analogy being made as an implementation to support the similar goal 11:45 PM May 20th, 2011
bradhedlund @colinmcnamara multi tenant isolation is one use case for OpenFlow, another is a global/domain view of the network akin to QFabric 11:57 PM May 20th, 2011
abnerg RT @bradhedlund: If the goal is “one big switch”, is it just me or did OpenFlow already obsolete QFabric? <- No. Scale + data path 2 start 11:57 PM May 20th, 2011
colinmcnamara @bradhedlund Makes sense, I like the idea of standards based interface for mgmt host control 11:59 PM May 20th, 2011
bradhedlund @abnerg alright, good, can you elaborate on that? :) 11:59 PM May 20th, 2011
abnerg . @bradhedlund At 5 on a Friday?!? DC net needs manage, control, data planes. Openflow = some control & manage, but unicornville 2 solve all 12:11 AM May 21st, 2011
abnerg . @bradhedlund Personally I think openflow excitement is a reaction to the byzantine software regime most networks run under today 12:14 AM May 21st, 2011
TechJournalist @abnerg @bradhedlund it’s 8:15 et for me..but OpenFlow is open. I still have 0 idea how qfabric will interoperate with other tech 12:15 AM May 21st, 2011
abnerg @TechJournalist @bradhedlund Huh? 3 ways - 1 Ethernet or Fiberchannel just like any switch 2 via the JUNOS SDK 3 via JUNOS Space 12:18 AM May 21st, 2011
abnerg @TechJournalist @bradhedlund BTW - that’s the same way Big Switch connects to the MX router… 12:19 AM May 21st, 2011
TechJournalist @abnerg makes sense. You should be doing Qfabric PR! That’s the most articulate qfabric answer i’ve ever received 12:20 AM May 21st, 2011
abnerg A few of you liked my unicornville statement, in full disclosure I should hat tip @omarsultan http://bloga.tw/lW7idy 12:28 AM May 21st, 2011
bradhedlund @ccie25655 why not? 1:29 AM May 21st, 2011
bradhedlund @abnerg @techjournalist that’s my point, with OpenFlow one _could_ build a standards based “Big Switch” w/o a proprietary fabric. No? 1:34 AM May 21st, 2011
djspry @bradhedlund Is OF a distributed architecture or are all smarts in the Controller? Wouldn’t OF threaten all- switches would be a commodity? 2:10 AM May 21st, 2011
ioshints @bradhedlund You think OF-only approach would scale to QFabric size? 5:49 AM May 21st, 2011
bradhedlund @ioshints why not? both employ a logically centralized control plane #openflow #QFabric 4:23 PM May 21st, 2011
bradhedlund @djspry OpenFlow is a centralized control plane, distributed data plane. switch vendors need to embrace & solution sell, otherwise commodity 4:31 PM May 21st, 2011
mfratto @bradhedlund proprietary architecture obsoleted Qfabric, but you have a point. Tho OF and QFabric are wildly different:-) 5:25 PM May 21st, 2011
bradhedlund RT @mfratto: @bradhedlund proprietary architecture obsoleted Qfabric, but you have a point. Tho OF and QFabric are wildly different:-) 5:51 PM May 21st, 2011
ioshints @bradhedlund We don’t know yet what QFabric does. I doubt it has a single centralized control plane. 6:07 PM May 21st, 2011
ioshints @bradhedlund @colinmcnamara Like what? Haven’t heard of one yet. 6:08 PM May 21st, 2011
bradhedlund @ioshints well, it does. Each QF-Node needs to connect to the QF-Director (control plane) over a separate oob net. 6:10 PM May 21st, 2011
ioshints @bradhedlund Might be the same ;) See comments to that post. 6:12 PM May 21st, 2011
ioshints @bradhedlund If that’s the case, I’m sorely disappointed … 6:14 PM May 21st, 2011
bradhedlund @ioshints @colinmcnamara defining a logical topology per app, or for specific flows - alert of congestion and route around, etc. 6:15 PM May 21st, 2011
icemarkom @bradhedlund @ioshints @colinmcnamara Hm. All of this can be done today in roured IP/MPLS networks. This all sounds like MPLS hype to me. 6:19 PM May 21st, 2011
ioshints @bradhedlund @colinmcnamara As @icemarkom said, all this can be done w/MPLS. DC engs not getting MPLS is not a good excuse for another tech 6:21 PM May 21st, 2011
bradhedlund @ioshints @colinmcnamara @icemarkom MPLS doesn’t have an API. Net Gurus not thinking up the stack is no excuse for dismissal ;) 6:34 PM May 21st, 2011
dgourlay @bradhedlund @ioshints @colinmcnamara not sure how QF can detect congestion rapidly enough when 3:1 oversubscribed to do anything about it 6:36 PM May 21st, 2011
icemarkom @bradhedlund @ioshints @colinmcnamara Neither does Ethermet, or IP, yet we have 1000s of APIs successfully building on the solid foundation. 6:36 PM May 21st, 2011
icemarkom @bradhedlund @ioshints @colinmcnamara MPLS allows for arbitrary FECs. Upper layers can program LSPs based on their needs. Your ball :-) 6:38 PM May 21st, 2011
ioshints @bradhedlund @colinmcnamara @icemarkom OpenFlow doesn’t have a usable API yet. Not better (if anything, worse) than MPLS. 6:45 PM May 21st, 2011
bradhedlund @icemarkom @ioshints @colinmcnamara right, it makes more sense for the switch to have an API, not each protocol… 7:14 PM May 21st, 2011
bradhedlund @icemarkom @ioshints @colinmcnamara … once the switch has an API, the value of some protocols become diminished, or obsolete 7:15 PM May 21st, 2011
ioshints @bradhedlund @icemarkom @colinmcnamara Only if you believe a single controller can handle the whole network. 7:22 PM May 21st, 2011
icemarkom @bradhedlund @ioshints @colinmcnamara Most of the switches already have an API. It’s called SNMP. 9:30 PM May 21st, 2011
bradhedlund @icemarkom @ioshints @colinmcnamara SNMP wasn’t designed for data plane programability, and therefore doesn’t meet the requirements 12:33 AM May 22nd, 2011
icemarkom @bradhedlund @ioshints @colinmcnamara Why does the new API need to be specifically designed? SNMP can provide two-comms - isn’t that enough? 12:38 AM May 22nd, 2011
ccie15672 @nbk1 @ioshints @bradhedlund @colinmcnamara @icemarkom Virtualizing the network ==> Complexity. There is no way around it. 12:51 PM May 22nd, 2011
colinmcnamara @bradhedlund interesting thoughts about openflow leveraging bold transport though. The control plan abstraction is nice 3:36 PM May 22nd, 2011
ccie15672 @bradhedlund @nbk1 @ioshints @colinmcnamara @icemarkom But the complexity isn’t “less.” You could centrally control an MPLS network too… 3:50 PM May 22nd, 2011
ccie15672 @colinmcnamara This is the sort of application I imagine OpenFlow being useful for. That an embedded network components. 4:29 PM May 22nd, 2011
ccie15672 @ioshints @colinmcnamara the end result is the same… A virtualized network. 5:58 PM May 22nd, 2011
boobasan @bradhedlund @abnerg @techjournalist So you swap proprietary fabric for mostly proprietary software, which is almost as scary. 9:10 PM May 22nd, 2011
boobasan @abnerg @bradhedlund Openflow excitement is due to an illusion that most of this nw stuff will be somehow manageable. 9:11 PM May 22nd, 2011
ccie15672 @colinmcnamara @ioshints Oh I quite agree with Ivan. My statements are more anti-hype than anything else… 11:37 PM May 22nd, 2011
ccie15672 Lot of good dialogue on OpenFlow. I think the network engineers among us need to stay on top of this. It has some potential.. good and bad 12:23 AM May 23rd, 2011
boobasan @prontosystems: not dismissing it at all. Look at my tweets on the subject. I just find some claims naive. I do believe in OF potential. 3:05 AM May 23rd, 2011
boobasan “@ccie15672:good dialogue on OpenFlow. I think the nw engineers among us need to stay on top of this” I hope apps guys can join in. 3:07 AM May 23rd, 2011
boobasan @ccie15672 without them it will remain to be just another way of nw control, and full potential will not be recognized. 3:08 AM May 23rd, 2011
boobasan “@ioshints: @bradhedlund @colinmcnamara @icemarkom OpenFlow doesn’t have a usable API.” At which level? Controllers do, but very specific. 3:11 AM May 23rd, 2011
abnerg @bradhedlund @techjournalist Sure you _could_ but then it would be as slow as fabricpath, well prolly not that slow if you used Arista 4:36 AM May 23rd, 2011
abnerg @bradhedlund @techjournalist Sure you _could_ but then it would be as slow as fabricpath, well prolly not that slow if you used Arista 4:36 AM May 23rd, 2011
abnerg . @bradhedlund @techjournalist Openflow doesn’t solve the data path problem. Count the number of asics needed to traverse the DC 4:39 AM May 23rd, 2011
abnerg @boobasan @bradhedlund @techjournalist There will always be a proprietary something. Does it lock you in, limit you, prevent you, or not? 4:42 AM May 23rd, 2011
boobasan @ioshints I’m not even sure if controller API can be standardized given the general philosophy of why such controllers are needed. 5:30 AM May 23rd, 2011
boobasan @abnerg @bradhedlund @techjournalist management software today is a much more limiting and lock-in factor than hardware. 5:40 AM May 23rd, 2011
boobasan RT @sd2sd2: OpenFlow can’t do anything that today’s hardware chipsets cannot do - it CAN do things that today’s distributed control can … 7:13 AM May 23rd, 2011
mfratto @abnerg @bradhedlund @techjournalist why would an openflow based network be slow? 1:00 PM May 23rd, 2011
abnerg . @mfratto @bradhedlund @techjournalist If you stitch autonomous switches together, process multiple times to cross the DC vs single switch 3:23 PM May 23rd, 2011
abnerg @mfratto @bradhedlund @techjournalist The original question was relative to QFabric. Openflow is a control plane technology. 3:26 PM May 23rd, 2011
ioshints @abnerg Are you talking about suboptimal paths? 3:26 PM May 23rd, 2011
ccie15672 @boobasan It is another form of network control. What sort of apps do you think are going to control the forwarding plane of the network? 3:35 PM May 23rd, 2011
abnerg @ioshints what’s faster - traversing a single Ethernet switch or traversing multiple ethernet switches? 3:36 PM May 23rd, 2011
mbushong @abnerg I know the answer to this one. Pick me! Pick me! 3:37 PM May 23rd, 2011
mfratto @abnerg @bradhedlund @techjournalist forwarding look-ips light to be as fast as any other switching. Less since the decision. Is made once. 3:37 PM May 23rd, 2011
mfratto @abnerg yep, I read the thread. :-) 3:39 PM May 23rd, 2011
ioshints @abnerg Are you claiming QFabric will perform a single store-and-forward to get packet across 3 devices? 3:39 PM May 23rd, 2011
boobasan @ccie15672 it’s not the direct/explicit control by app,but think about it in a way of app meta-data/requirements influencing network control 3:41 PM May 23rd, 2011
mfratto @abnerg @ioshints more relevant question: how important is sub-ms delay and is it worth the trade off proprietary vs STD based. 3:41 PM May 23rd, 2011
mfratto @abnerg @ioshints re: STD based, I am not advocating OpenFlow is the only way. The question is relevant to current STD as well. 3:43 PM May 23rd, 2011
abnerg @ioshints Does a chassis switch perform a single store-and-forward to get from a port in line card A to a port in line card B? 3:44 PM May 23rd, 2011
ioshints @abnerg Good point. 3:45 PM May 23rd, 2011
ccie15672 @boobasan I can agree with that. And embedded network components in apps… 3:46 PM May 23rd, 2011
ccie15672 QFabric could potentially be a distributed server-backplane extension… I wonder what API we could use to facilitate that… 3:47 PM May 23rd, 2011
boobasan @ccie15672 embedding in apps is possible but requires app mods - unlikely, therefore needs to.be treated as extension of container. 3:51 PM May 23rd, 2011
abnerg @mfratto @ioshints while speed is a nice win and big deal to some. Value of operational simplicity is a much bigger win. 3:57 PM May 23rd, 2011
AndreKindness RT @abnerg: “Value of operational simplicity is a much bigger win.”
mfratto RT @ioshints @abnerg It depends on the application; for many apps it doesn’t matter. «+1 a point why proprietary sometimes beats STDs. 4:15 PM May 23rd, 2011
abnerg @dgourlay @bradhedlund @ioshints @colinmcnamara re: congestion management: Edge 3:1 not as relevant as speed & complexity across the DC 5:23 PM May 23rd, 2011
Powered by blogatweet
Index Ventures Blog – Big Switch: Virtualizing IP Networks
Interesting additions to the team and words from Volpi of all people.
