<HTML><HEAD></HEAD>
<BODY
style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space"
dir=ltr>
<DIV dir=ltr>
<DIV style="FONT-FAMILY: 'Calibri'; COLOR: #000000; FONT-SIZE: 12pt">
<DIV>Arturo, como estas?</DIV>
<DIV> </DIV>
<DIV>Ciertamente Openflow es una de las tecnologias que han estado bajo revision
en varias reuniones este año. En NANOG 54 se presento un panel relacionado con
esta tecnologia (<A
title=http://www.nanog.org/meetings/nanog54/presentations/Monday/NANOG_54_04_Open_Flow.wmv
href="http://www.nanog.org/meetings/nanog54/presentations/Monday/NANOG_54_04_Open_Flow.wmv">http://www.nanog.org/meetings/nanog54/presentations/Monday/NANOG_54_04_Open_Flow.wmv</A>
y <A
title=http://www.nanog.org/meetings/nanog54/presentations/Monday/Beckmann.pdf
href="http://www.nanog.org/meetings/nanog54/presentations/Monday/Beckmann.pdf">http://www.nanog.org/meetings/nanog54/presentations/Monday/Beckmann.pdf</A>)
y en APAN 33 (<A
title=http://www.apan.net/meetings/ChiangMai2012/Session/FIT/APAN33-junbi.pdf
href="http://www.apan.net/meetings/ChiangMai2012/Session/FIT/APAN33-junbi.pdf">http://www.apan.net/meetings/ChiangMai2012/Session/FIT/APAN33-junbi.pdf</A>).
Como bien dice Alvaro Retana, el soporte IPv6 aparece en el estandar 1.2 (de
diciembre 2011), aunque no hay claridad en la documentacion de todos los
aspectos que comprende ese soporte IPv6. En cualquier caso, el estandar maduro
de Openflow es el 1.1; pero a lo largo de este 2012 habra bastante soporte de la
industria a 1.2. </DIV>
<DIV> </DIV>
<DIV>Saludos,</DIV>
<DIV>Jorge</DIV>
<DIV> </DIV>
<DIV>
<DIV
style="FONT-STYLE: normal; DISPLAY: inline; FONT-FAMILY: 'Calibri'; COLOR: #000000; FONT-SIZE: small; FONT-WEIGHT: normal; TEXT-DECORATION: none"></DIV>
<DIV style="FONT: 10pt tahoma">
<DIV style="BACKGROUND: #f5f5f5">
<DIV style="font-color: black"><B>From:</B> <A title=aservin@lacnic.net
href="mailto:aservin@lacnic.net">Arturo Servin</A> </DIV>
<DIV><B>Sent:</B> Wednesday, April 18, 2012 7:16 AM</DIV>
<DIV><B>To:</B> <A title=lacnog@lacnic.net href="mailto:lacnog@lacnic.net">Latin
America and Caribbean Region Network Operators Group</A> </DIV>
<DIV><B>Subject:</B> [lacnog] Fwd: OpenFlow @ GOOG</DIV></DIV></DIV>
<DIV> </DIV></DIV>
<DIV
style="FONT-STYLE: normal; DISPLAY: inline; FONT-FAMILY: 'Calibri'; COLOR: #000000; FONT-SIZE: small; FONT-WEIGHT: normal; TEXT-DECORATION: none">
<DIV> </DIV><SPAN style="WHITE-SPACE: pre"
class=Apple-tab-span></SPAN>Puede ser interesante para la comunidad.
<DIV> </DIV>
<DIV><SPAN style="WHITE-SPACE: pre" class=Apple-tab-span></SPAN>Por cierto,
alguien sabe si OpenFlow soporta ya IPv6? La última vez que lo revisé no lo
hacía a full.</DIV>
<DIV> </DIV>
<DIV>Saludos,</DIV>
<DIV>.as</DIV>
<DIV>
<DIV> </DIV>
<DIV>
<DIV> </DIV>
<DIV>Begin forwarded message:</DIV><BR class=Apple-interchange-newline>
<BLOCKQUOTE type="cite">
<DIV style="MARGIN: 0px"><SPAN
style="FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium"><B>From: </B></SPAN><SPAN
style="FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium">Eugen Leitl <<A
href="mailto:eugen@leitl.org">eugen@leitl.org</A>><BR></SPAN></DIV>
<DIV style="MARGIN: 0px"><SPAN
style="FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium"><B>Date: </B></SPAN><SPAN
style="FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium">17 April 2012 13:37:25
GMT-03:00<BR></SPAN></DIV>
<DIV style="MARGIN: 0px"><SPAN
style="FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium"><B>To: </B></SPAN><SPAN
style="FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium">NANOG list <<A
href="mailto:nanog@nanog.org">nanog@nanog.org</A>><BR></SPAN></DIV>
<DIV style="MARGIN: 0px"><SPAN
style="FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium"><B>Subject:
</B></SPAN><SPAN
style="FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium"><B>OpenFlow @
GOOG</B><BR></SPAN></DIV>
<DIV> </DIV>
<DIV><BR><A
href="http://www.wired.com/wiredenterprise/2012/04/going-with-the-flow-google/all/1">http://www.wired.com/wiredenterprise/2012/04/going-with-the-flow-google/all/1</A><BR><BR>Going
With The Flow: Google’s Secret Switch To The Next Wave Of Networking<BR><BR>By
Steven Levy April 17, 2012 | 11:45 am | <BR><BR>Categories: Data Centers,
Networking<BR><BR>In early 1999, an associate computer science professor at UC
Santa Barbara<BR>climbed the steps to the second floor headquarters of a small
startup in Palo<BR>Alto, and wound up surprising himself by accepting a job
offer. Even so, Urs<BR>Hölzle hedged his bet by not resigning from his
university post, but taking a<BR>year-long leave.<BR><BR>He would never
return. Hölzle became a fixture in the company — called<BR>Google. As its czar
of infrastructure, Hölzle oversaw the growth of its<BR>network operations from
a few cages in a San Jose co-location center to a<BR>massive internet power; a
2010 study by Arbor Networks concluded that if<BR>Google was an ISP it would
be the second largest in the world (the largest is<BR>Tier 3, which services
over 2,700 major corporations in 450 markets over<BR>100,000 fiber miles.)
‘You have all those multiple devices on a network but<BR>you’re not really
interested in the devices — you’re interested in the<BR>fabric, and the
functions the network performs for you,’ Hölzle says.<BR><BR>Google treats its
infrastructure like a state secret, so Hölzle rarely speaks<BR>about it in
public. Today is one of those rare days: at the Open Networking<BR>Summit in
Santa Clara, California, Hölzle is announcing that Google<BR>essentially has
remade a major part of its massive internal network,<BR>providing the company
a bonanza in savings and efficiency. Google has done<BR>this by brashly
adopting a new and radical open-source technology
called<BR>OpenFlow.<BR><BR>Hölzle says that the idea behind this advance is
the most significant change<BR>in networking in the entire lifetime of
Google.<BR><BR>In the course of his presentation Hölzle will also confirm for
the first time<BR>that Google — already famous for making its own servers —
has been designing<BR>and manufacturing much of its own networking equipment
as well.<BR><BR>“It’s not hard to build networking hardware,” says Hölzle, in
an advance<BR>briefing provided exclusively to Wired. “What’s hard is to build
the software<BR>itself as well.”<BR><BR>In this case, Google has used its
software expertise to overturn the current<BR>networking paradigm.<BR><BR>If
any company has potential to change the networking game, it is Google.
The<BR>company has essentially two huge networks: the one that connects users
to<BR>Google services (Search, Gmail, YouTube, etc.) and another that
connects<BR>Google data centers to each other. It makes sense to bifurcate
the<BR>information that way because the data flow in each case has
different<BR>characteristics and demand. The user network has a smooth flow,
generally<BR>adopting a diurnal pattern as users in a geographic region work
and sleep.<BR>The performance of the user network also has higher standards,
as users will<BR>get impatient (or leave!) if services are slow. In the
user-facing network<BR>you also need every packet to arrive intact — customers
would be pretty<BR>unhappy if a key sentence in a document or e-mail was
dropped.<BR><BR>The internal backbone, in contrast, has wild swings in demand
— it is<BR>“bursty” rather than steady. Google is in control of scheduling
internal<BR>traffic, but it faces difficulties in traffic engineering. Often
Google has<BR>to move many petabytes of data (indexes of the entire web,
millions of backup<BR>copies of user Gmail) from one place to another. When
Google updates or<BR>creates a new service, it wants it available worldwide in
a timely fashion —<BR>and it wants to be able to predict accurately how
quickly the process will<BR>take.<BR><BR>“There’s a lot of data center to data
center traffic that has different<BR>business priorities,” says Stephen
Stuart, a Google distinguished engineer<BR>who specializes in infrastructure.
“Figuring out the right thing to move out<BR>of the way so that more important
traffic could go through was a challenge.”<BR><BR>But Google found an answer
in OpenFlow, an open source system jointly devised<BR>by scientists at
Stanford and the University of California at Berkeley.<BR>Adopting an approach
known as Software Defined Networking (SDN), OpenFlow<BR>gives network
operators a dramatically increased level of control by<BR>separating the two
functions of networking equipment: packet switching and<BR>management.
OpenFlow moves the control functions to servers, allowing for<BR>more
complexity, efficiency and flexibility.<BR><BR>“We were already going down
that path, working on an inferior way of doing<BR>software-defined
networking,” says Hölzle. “But once we looked at OpenFlow,<BR>it was clear
that this was the way to go. Why invent your own if you don’t<BR>have
to?”<BR><BR>Google became one of several organizations to sign on to the Open
Networking<BR>Foundation, which is devoted to promoting OpenFlow. (Other
members include<BR>Yahoo, Microsoft, Facebook, Verizon and Deutsche Telekom,
and an innovative<BR>startup called Nicira.) But none of the partners so far
have announced any<BR>implementation as extensive as Google’s.<BR><BR>Why is
OpenFlow so advantageous to a company like Google? In the traditional<BR>model
you can think of routers as akin to taxicabs getting passengers from<BR>one
place to another. If a street is blocked, the taxi driver takes
another<BR>route — but the detour may be time-consuming. If the weather is
lousy, the<BR>taxi driver has to go slower. In short, the taxi driver will get
you there,<BR>but you don’t want to bet the house on your exact arrival
time.<BR><BR>With the software-defined network Google has implemented, the
taxi situation<BR>no longer resembles the decentralized model of drivers
making their own<BR>decisions. Instead you have a system like the one
envisioned when all cars<BR>are autonomous, and can report their whereabouts
and plans to some central<BR>repository which also knows of weather conditions
and aggregate traffic<BR>information. Such a system doesn’t need independent
taxi drivers, because the<BR>system knows where the quickest routes are and
what streets are blocked, and<BR>can set an ideal route from the outset. The
system knows all the conditions<BR>and can institute a more sophisticated set
of rules that determines how the<BR>taxis proceed, and even figure whether
some taxis should stay in their<BR>garages while fire trucks
pass.<BR><BR>Therefore, operators can slate trips with confidence that
everyone will get<BR>to their destinations in the shortest times, and
precisely on schedule.<BR><BR>Continue reading ‘Going With The Flow: Google’s
Secret Switch To The Next<BR>Wave Of Networking‘ …<BR><BR>Making Google’s
entire internal network work with SDN thus provides all sorts<BR>of
advantages. In planning big data moves, Google can simulate
everything<BR>offline with pinpoint accuracy, without having to access a
single networking<BR>switch. Products can be rolled out more quickly. And
since “the control<BR>plane” is the element in routers that most often needs
updating, networking<BR>equipment is simpler and enduring, requiring less
labor to service.<BR><BR>Most important, the move makes network management
much easier. By early this<BR>year, all of Google’s internal network was
running on OpenFlow. ‘Soon we will<BR>able to get very close to 100 percent
utilization of our network,’ Hölzle<BR>says.<BR><BR>“You have all those
multiple devices on a network but you’re not really<BR>interested in the
devices — you’re interested in the fabric, and the<BR>functions the network
performs for you,” says Hölzle. “Now we don’t have to<BR>worry about those
devices — we manage the network as an overall thing. The<BR>network just sort
of understands.”<BR><BR>The routers Google built to accommodate OpenFlow on
what it is calling “the<BR>G-Scale Network” probably did not mark not the
company’s first effort in<BR>making such devices. (One former Google employee
has told Wired’s Cade Metz<BR>that the company was designing its own equipment
as early as 2005. Google<BR>hasn’t confirmed this, but its job postings in the
field over the past few<BR>years have provided plenty of evidence of such
activities.) With SDN, though,<BR>Google absolutely had to go its own way in
that regard.<BR><BR>“In 2010, when we were seriously starting the project, you
could not buy any<BR>piece of equipment that was even remotely suitable for
this task,” says<BR>Hotzle. “It was not an option.”<BR><BR>The process was
conducted, naturally, with stealth — even the academics who<BR>were Google’s
closest collaborators in hammering out the OpenFlow standards<BR>weren’t
briefed on the extent of the implementation. In early 2010,
Google<BR>established its first SDN links, among its triangle of data centers
in North<BR>Carolina, South Carolina and Georgia. Then it began replacing the
old<BR>internal network with G-Scale machines and software — a tricky process
since<BR>everything had to be done without disrupting normal business
operations.<BR><BR>As Hölzle explains in his speech, the method was to
pre-deploy the equipment<BR>at a site, take down half the site’s networking
machines, and hook them up to<BR>the new system. After testing to see if the
upgrade worked, Google’s<BR>engineers would then repeat the process for the
remaining 50 percent of the<BR>networking in the site. The process went
briskly in Google’s data centers<BR>around the world. By early this year, all
of Google’s internal network was<BR>running on OpenFlow.<BR><BR>Though Google
says it’s too soon to get a measurement of the benefits, Hölzle<BR>does
confirm that they are considerable. “Soon we will able to get very close<BR>to
100 percent utilization of our network,” he says. In other words, all
the<BR>lanes in Google’s humongous internal data highway can be occupied,
with<BR>information moving at top speed. The industry considers thirty or
forty<BR>percent utilization a reasonable payload — so this implementation is
like<BR>boosting network capacity two or three times. (This doesn’t apply to
the<BR>user-facing network, of course.)<BR><BR>Though Google has made a
considerable investment in the transformation —<BR>hundreds of engineers were
involved, and the equipment itself (when design<BR>and engineering expenses
are considered) may cost more than buying vendor<BR>equipment — Hölzle clearly
thinks it’s worth it.<BR><BR>Hölzle doesn’t want people to make too big a deal
of the confirmation that<BR>Google is making its own networking switches — and
he emphatically says that<BR>it would be wrong to conclude that because of
this announcement Google<BR>intends to compete with Cisco and Juniper. “Our
general philosophy is that<BR>we’ll only build something ourselves if there’s
an advantage to do it — which<BR>means that we’re getting something we can’t
get elsewhere.”<BR><BR>To Hölzle, this news is all about the new paradigm. He
does acknowledge that<BR>challenges still remain in the shift to SDN, but
thinks they are all<BR>surmountable. If SDN is widely adopted across the
industry, that’s great for<BR>Google, because virtually anything that happens
to make the internet run more<BR>efficiently is a boon for the
company.<BR><BR>As for Cisco and Juniper, he hopes that as more big operations
seek to adopt<BR>OpenFlow, those networking manufacturers will design
equipment that supports<BR>it. If so, Hölzle says, Google will probably be a
customer.<BR><BR>“That’s actually part of the reason for giving the talk and
being open,” he<BR>says. “To encourage the industry — hardware, software and
ISP’s — to look<BR>down this path and say, ‘I can benefit from
this.’”<BR><BR>For proof, big players in networking can now look to Google.
The search giant<BR>claims that it’s already reaping benefits from its bet on
the new revolution<BR>in networking. Big time.<BR><BR>Steven
Levy<BR><BR>Steven Levy's deep dive into Google, In The Plex: How Google
Thinks, Works<BR>And Shapes Our Lives, was published in April, 2011. Steven
also blogs at<BR>StevenLevy.com. Check out Steve's Google+ Profile
.<BR><BR>Read more by Steven Levy<BR><BR>Follow @StevenLevy on
Twitter.<BR></DIV></BLOCKQUOTE></DIV>
<DIV> </DIV></DIV><BR>Consulte la enciclopedia colaborativa cubana.
http://www.ecured.cu
<P>
<HR>
_______________________________________________<BR>LACNOG mailing
list<BR>LACNOG@lacnic.net<BR>https://mail.lacnic.net/mailman/listinfo/lacnog<BR></DIV></DIV></DIV></BODY><br>
Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu
</HTML>