Archive for the ‘IETF’ Category

Photo Used in IETF Journal

Thursday, November 3rd, 2011

While we’re on the topic of being famous ;) I wanted to mention (brag, I guess) that the IETF Journal, published by the Internet Society, used a photo I took of the IAB Plenary session in Quebec at IETF-81. You can read the article at http://isoc.org/wp/ietfjournal/?p=2597.

My original photo is on Flickr for comparison. It looks like the editors added some “fill light” to the photo before publishing it. This hurt the color and contrast, obviously, but makes it feel brighter. Trust me, it was not a brightly lit room – most of the photos I took didn’t turn out because it was too dark. The only ones that survived were taken with a Canon S95, thanks to its “Hybrid Image Stabilization” feature.

Final Five IPv4 Blocks Allocated

Thursday, February 3rd, 2011

As anticipated, the final five /8 blocks of IPv4 addresses were allocated from IANA to the RIRs this morning. They were apparently granted in alphabetical order.

http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml

102/8    AfriNIC    2011-02    whois.afrinic.net    ALLOCATED
103/8    APNIC      2011-02    whois.apnic.net      ALLOCATED
104/8    ARIN       2011-02    whois.arin.net       ALLOCATED
179/8    LACNIC     2011-02    whois.lacnic.net     ALLOCATED
185/8    RIPE NCC   2011-02    whois.ripe.net       ALLOCATED

IPv4 Exhaustion is Here

Monday, January 31st, 2011

Today the last “normal ” IANA allocation of IPv4 addresses was made to APNIC.  (See the announcement at http://www.apnic.net/publications/news/2011/delegation.) APNIC received the following two /8 network blocks:

  • 39/8
  • 106/8

By a quick view of the IANA registry at http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml, I can see that there are now five blocks remaining. Per the rules agreed upon by IANA and the five RIRs, these will soon be distributed so that each of the RIRs will receive one more /8. The remaining blocks are:

  • 102/8
  • 103/8
  • 104/8
  • 179/8
  • 185/8

In other words, IPv4 exhaustion is here – the IANA supply is gone, the RIR supply is limited, and soon organizations will be unable to acquire more network space.  This is going to be an interesting year (and decade).

RFC 5952: Recommended IPv6 Representation

Friday, August 20th, 2010

There’s a new IETF document published today, RFC 5952 “A Recommendation for IPv6 Address Text Representation”. It does us the favor of standardizing the text representation of IPv6 addresses, which is otherwise subject to various syntactically-correct yet inconsistent shorthands. To summarize the recommendation:

  • Handling Leading Zeros in a 16-Bit Field – Leading zeros MUST be suppressed.
  • Shorten as Much as Possible – The use of the symbol “::” MUST be used to its maximum capability.
  • Handling One 16-Bit 0 Field – The symbol “::” MUST NOT be used to shorten just one 16-bit 0 field.
  • Choice in Placement of “::”
    • When there is an alternative choice in the placement of a “::”, the longest run of consecutive 16-bit 0 fields MUST be shortened.
    • When the length of the consecutive 16-bit 0 fields are equal, the first sequence of zero bits MUST be shortened.
  • Lowercase – The characters “a”, “b”, “c”, “d”, “e”, and “f” in an IPv6 address MUST be represented in lowercase.

Reflections on MPLS 2009

Monday, December 14th, 2009

It has been well over a month since I attended the MPLS 2009 conference and participated in the panel on Emerging Technologies and Business Architectural Impact, and it is about time (over-due) that I posted my thoughts.

Foremost, I should say Thank You to Monique Morrow for organizing such a great panel and inviting me to participate.  I’ve known Monique as a colleague and friend for a while now, and whenever we have chance to meet she never fails to impress me.  In the context of this panel, I was dumbfounded at the quality and breadth of the other participants that she secured.  Monique moderated the discussion such that the panel’s large size was a benefit rather than liability.  As a panel we managed to cover multiple topics with decent depth, and were each allowed to illustrate our different perspectives.  I’ve been told by several audience members that it was an excellent panel, and from my (admittedly biased) perspective I must agree.

As for the discussion itself, I very much enjoyed participating.  Considering the quality of the other panelists, I am honored to have been included; each of the other panelists are recognizable for their contributions and role in the industry.  Given my respect for the other panelists, I tried to enter the conversation prepared and did not hold back any of my significant thoughts during the discussion… for better or worse.

Some of my comments may have included points that were controversial.  For instance, one theme that ran through the entire discussion was the complex balance of cost vs. capacity vs. features in network devices.  I challenged comments from Vijay Gill (of Google) and Donn Lee (of Facebook) which argued in favor of very-large dumb switches. ("dumb" is my word choice, but I suspect they would agree)  From their perspectives, as engineers for large web properties, they need to scale out single-tenant environments to support Internet-scale traffic loads and a simple L2 or L3 switch would enable their topology.  But, I argued, they were "weird" in their requirements, which are unique to large web properties.  Service providers and enterprise environments need more features in order to deal with the complexity and changing "customer" requirements they face daily.

After the panel I had the opportunity to chat with Vijay and Donn, and they had an interesting view of the cost / capacity / features debate.  Their comments deserve some focus, so look for a future post on this topic.

Another topic was the relevance of standards, which wasn’t particularly controversial but which caused some interesting comments.  My point was that standards are critical to the industry, but in the same way that fundamental research is critical to science and technology (broadly speaking).  We need to put effort into standards because it brings people together and promotes the state of the art.  But we also need to recognize that functioning interoperable implementations are what matter, regardless of the standards conformance, etc.  In other words, standards bodies should work diligently but not take themselves too seriously in the process.

Regardless, I hope to be included in future panels such as this one (at the MPLS conference and/or elsewhere) and I’m glad to have had the opportunity at MPLS 2009.  I would absolutely recommend that you attend future panels by Monique, at MPLS 2010 or otherwise, whether I’m taking part or not. Though, obviously, it would be better with my opinion included. ;)