Skip to main content

MUST read! network engineer

http://queue.acm.org/detail.cfm?ref=rss&id=2856460

A Purpose-built Global Network: Google's Move to SDNA discussion with Amin Vahdat, David Clark, and Jennifer Rexford

網路設備廠的噩夢, 連internet-facing的router也要自幹了

-we quickly concluded that a centralized view of global demand would allow us to make better decisions more rapidly than would be possible with a fully decentralized protocol.
>>全域智能
-Our biggest frustration was that hardware and software were typically bundled together into a single platform, which basically left you at the mercy of certain vendors to come up with any of the new features you needed to meet requirements already confronting you.
>>不爽
-What's more, buying a bundled solution from a vendor meant buying all the capabilities any customer of that vendor might want, with respect to both hardware and software.
>> 一張專輯只要其中幾首歌的概念
-we realized decentralized protocols wouldn't necessarily give us predictability and control over our network
-global optimum
-we were tired of being at the mercy of the IETF (Internet Engineering Task Force) standardization process
>> 對IETF也不開心
-no need to support such a wide range of line-card technologies
>>不需樣樣有 
-support for large routing tables was also clearly unnecessary
>>不用通通懂
-Some of the complexity involved in maintaining hierarchical, multilevel control is inherent, given the need to isolate failure domains.
>>階層化說的簡單,只有google能解吧
-you also talk about all the effort made to incorporate IS-IS (Intermediate System to Intermediate System) and BGP as part of the solution. That struck me as strange, given that each of the endpoints within the B4 network or connected to it is under Google's control—meaning you clearly could have chosen not to use any legacy protocols whatsoever. What value did you see in holding onto them?
>>幹嘛不一次到位
-We decided on an incremental deployment strategy after much consideration
>>慢慢來
-there was a fair amount of time where we had only baseline SDN—without any traffic engineering—deployed
>>也還是先爬,不是一開始就會飛
-So, while I agree that BGP and IS-IS are not where we want to be long term, they certainly have provided us with a critical evolution path to move from a non-SDN network to an SDN one.
>>反正就是不能一步登天
-In fact, even now we continue to have a big red button that lets us fall back to shortest-path routing should we ever feel the need to do so.
>>連google都怕死了, 你為什麼不怕, 唉, 
-any scenario that could potentially lead to independent failures of the brain and body might easily result in bizarre failure patterns from which recovery could prove tremendously difficult.
>>裂腦
-most concerned me was that we were breaking the fate-sharing principle
>>google也有深沉的恐懼
-Basically, if the controller were to lose its view of the network, then there would be no way to reach into the network and put it back together again
>>大腦掛點怎辦
-But I would just like to say I think both of those battles have already been lost anyway—even before SDN became particularly prominent. That is, I think if you look closely at a current high-end router from Cisco or Juniper, you'll find they also employ distributed-system architectures, where the control plane might be running in a separate blade from the one where the data plane is running. That means those systems, too, are subject to these same problems where the brain and the body might fail independently.
>>JR就是反分散的大將,你看她以前的論文,愛死 SS7 outband的控制了, SDN這一戰終於成了, 不過拿C/J內部架構來比internet也太......
-Basically, that's because we've never been very good at building distributed protocols capable of doing anything more than simply restoring shortest-path connectivity.
>>傳統分散路由智能還是有限
-There was always this concern that knowledge of a failure absolutely had to be propagated to the controller so the controller could then respond to it
>>大腦知道還不夠
-this concern had nothing to do with unplanned transient failures
>>重要的是不知的
-it seemed that Google was using DiffServ tags, so I just assumed DiffServ tags could be used to increase link loading by ensuring that latency
-DiffServ can indeed be used to increase link loading
>>歧視的意思, 一股腦塞進去, 重要的出來就好, 那不重要的丟, 但你又不開心了
-overprovisioning to cover worst-case convergence scenarios in a decentralized environment.
>>舊招是低使用率 , 你還是不開心
-through a combination of centralized traffic engineering and quality-of-service differentiation, we've managed to distinguish high-value traffic from the bulk traffic that's not nearly as latency-sensitive
-Now, given that we have to support all the different protocol checkbox features and line cards on our public-facing network, our cost structures there are even worse, which is why we're working to push this same approach—not the exact same techniques, but the general approach—into our public-facing network as well. That work is already ongoing, but it will surely be a long effort.
>>自幹宣言
- SDN peering. BGP takes a distrustful view of the world, but what if individual ISPs—or peers, if you will—decide they want to at least selectively open up some additional information about their networks dynamically? Looking at it naively, I think if they were to share some information about downstream traffic patterns, they would be able to make end-to-end transit times a lot faster and basically improve the user experience tremendously. By making it possible for the ISPs to use their more lightly loaded paths better, the carriers themselves would also benefit.
-We've already talked to some customers who are interested in SDN-based peering, and I can tell you they're particularly interested in application-specific peering. They would like to be able to say, "Hey, I want my video traffic to go through this peer, while my non-video traffic goes through this other peer," either for performance or pricing reasons. And that's just awkward to do right now.
>>SDN-based peering , well......
-Another interesting aspect of making the transition to SDN is that when things break, or at least don't work as you expect them to, unless you have a reasonable mental model of what the controller is trying to do, you might find it very difficult to diagnose what's going on.
>>反正你就是要懂的內部才能debug
-Whereas with SDN, whenever things go bump in the night, someone who wasn't involved in writing the software in the first place is probably going to find it a lot more difficult to debug things.
>>是用軟體黏起各元件的,  debug當然要懂造起輪子的軟體
-But I also think there are lots of very talented network engineers out there who are fully capable of adapting to new technologies.
>> awesome! long life network engineers!
-By moving away from a box-centric view of network management to a fabric-centric view, we should be able to make things inherently simpler.
>>還是全域智能
-Yet I think this also remains the biggest open question for SDN: Just how much progress will we actually realize in terms of simplifying operations management?
- If SDN is going to prove successful in a much broader context—one where you don't have a huge software development team at your disposal as well as a supportive organization behind you—it's going to be because there are reusable platforms available, along with the ability to build applications on top of those platforms.
>>so true, 軟體如能取得巨大成功, 是要能讓不太懂 coding的人也能用簡單的元件就
能建構夠用的東西
-Beyond that, I think Google's design demonstrates that if you can separate the distributed management of state required for your network control logic from the network control logic itself, you can avoid reinventing the wheel of how to do reliable distributed state management while also separating that from every single protocol
>>不太懂,真的好繞口
-If you take it as inevitable, for example, that all video content is going to be distributed across the Internet at some point in the near future, then we're surely looking at some phenomenal network growth, which suggests the large carriers will at minimum soon become quite interested in seizing upon any CAPEX and OPEX savings they possibly can.
>> 大頻寬但不要貴東東



Comments

Popular posts from this blog