Tag Archives: NANOG

NANOG: load-balancing facebook and interfacing IPV6 using LISP

Donn Lee talked about LISP Deployment at Facebook. No, not that LISP. This one:
In the current Internet routing and addressing architecture, the IP address is used as a single namespace that simultaneously expresses two functions about a device: its identity and how it is attached to the network. One very visible and detrimental result of this single namespace is manifested in the rapid growth of the Internet’s DFZ (default-free zone) as a consequence of multi-homing, traffic engineering (TE), non-aggregatable address allocations, and business events such as mergers and acquisitions.

LISP changes this by separating IP addresses into two new namespaces: Endpoint Idenfitiers (EIDs), which are assigned to end-hosts, and Routing Locators (RLOCs), which are assigned to devices (primarily routers) that make up the global routing system.

So Lee used that to load-balance facebook, which you can try out here:


If I understood him, he said his group of network engineers did all this without needing to involve software development, because facebook is still “a small, scrappy company” that permits and encourages such things.


NANOG: The Impacts of Adding Undersea Capacity to East Africa

Keven Chege of KENET at NANOG 50 talked about rapid deployment of cable for Internet use throughout east Africa, despite vandalism including copper theft and sabotage by competing ISPs. Many national research and eduction networks (NRENs) at least planned in the area. KENET in Kenya has “Made the big leap from VSAT to fiber” and is helping coordinate the region; slides include proposed regional mesh map. Also talking to google and Akamai.

Akamai guy stood up immediately afterwards and said he hear KENET was talking to google and asked that they should talk to Akamai as well.


NANOG: Submarine adopts 40G and 100G

Per Hansen of Ciena at NANOG 50 talked about growing capacity not by adding more data cables under the sea, rather by increasing spectral density. Eventually new cables will be needed, but meanwhile he thinks we can get up from about 2 bits to to 5 or 6 bits per Hertz. It does require more power: same energy per bit, but more bits.

Plus mesh networks for rerouting, even if it means rerouting backwards around the world, he notes. We’ve observed that sort of emergency backwards routing as long ago as January 2008, in the U.A.E. Cable Cut.


NANOG: Coping with Relentless Demand Growth

David G. Ross ofThe David Ross Group Inc. at NANOG 50 talked about data cables under the sea, in which he revealed that Internet growth has not only not paused during the recession, it has increased, and it continues to increase in every region in which his company operates, including Asia, Middle East, and Africa. North Atlantic hasn’t had any new submarine capacity in years, in “the most competitive capacity market on Earth”. It will probably run out in a few years, so now there is demand to build new cables there. Each cable costs about $200 million to install.

Slight downside: early remark that he was sure things were the same as they were when he worked for a telephone company.


NANOG: Botnets, DDoS and Ground-Truth

Here at NANOG 50 Craig Labovitz just gave an interesting talk about botnet data derived from Arbor Network customers enabling anonymous data (37 ISPs over last 12 months), of 5,000 events classified by operators.

60% of DDoS attacks are by flooding. Yet most attacks involve few IP addresses; indicates address spoofing.

Slight problem: only 1/4 of customers have enabled anonymous data. “Real goal of this talk is to encourage participation.”

Well-received talk.


Community Flow-spec Project

A lightning talk at NANOG 48, Austin, Texas, 22 Feb 2010, by John Kristoff, Team Cymru. See RFC 5575.

Update: PDF of presentation slides here.

| type   | extended community | encoding                 |
| 0x8006 | traffic-rate       | 2-byte as#, 4-byte float |
| 0x8007 | traffic-action     | bitmask                  |
| 0x8008 | redirect           | 6-byte Route Target      |
| 0x8009 | traffic-marking    | DSCP value               |

A few selected points:

  • Dissemination of Flow Specification Rules
  • Think of filters(ACLs) distributed via BGP
  • BGP possibly not the right mechanism
  • Multi-hop real-time black hole on steroids
  • Abuse Handler + Peering Coordinator
    = Abeering Coordinator?
  • Traditional bogon feed as source prefix flow routes
  • A la carte feeds (troublesome IP multicast groups, etc.)
  • AS path prepend++
  • Feed-specific community + no-export
He showed some examples of specs for flows (I can’t type fast enough to transcribe those).

Trust issues for routes defined by victim networks.

Research prototype is set up. For questions, comments, setup, contact: http://www.cymru.com/jtk/

I like it as an example of collective action against the bad guys. How to deal with the trust issues seems the biggest item to me.

Hm, at least to the participating community, this is a reputation system.