In my previous post I threw out a few thoughts about the idea of enticing users to switch to IPv6 – a sort of variation on the long-running “we need an IPv6 killer app” argument – and the contradictions such enticement efforts would present: Mainly that IP of any version should be transparent to end-users who only care about services, not how those services are delivered. Any enticements bring IPv6 into the spotlight, where it should not be (except for routing and infrastructure geeks like me).

Read more

Over the years there have been an enormous number of pilot and showcase projects around IPv6. Japan’s WIDE Project probably holds the distinction of the most IPv6-related programs.

Read more

I’m in Beijing for the China IPv6 Summit; this is the eighth year in a row that the organizers have invited me to speak at the event.

I did a tutorial yesterday on IPv6 readiness assessment methodologies, and a speech on IPv6 and network mobility at the associated Mobile Internet Forum. As I write this I’m in the audience waiting for my next speech, on creating a workable IPv6 transition plan.

Read more

This past Wednesday (April 9) we held the first Rocky Mountain IPv6 Summit in Denver. Considering that none of us who organized the event had much of a clue as to what we were doing when we started out, the logistics came off quite well. Having Kyoko Day, who does have experience organizing large events, generously contribute her time certainly had a lot to do with the event’s success. And Scott Hogg put an enormous effort into the event, from managing all of us to hauling drinks coolers. The guy was everywhere.

Read more

I explained in the previous post how the RSVP-TE Explicit Route Object (ERO) specifies the path of an MPLS LSP by means of a sequenced list of Label Switching Routers (LSRs) that the LSP must pass through between the ingress and egress LSRs. RSVP-TE uses the path described in the ERO to signal and set up the LSP. That’s the foundation of MPLS traffic engineering: The ability to set up a path that is different from what the local IGP considers the optimum path between the ingress and egress, as shown in Figure 1.

Read more

I wrote in the previous post about how the Resource Reservation Protocol with Traffic Engineering extensions (RSVP-TE), in addition to being an MPLS label distribution protocol, is also an MPLS signaling protocol. That is, an ingress LSR can use RSVP-TE to notify all LSRs along the path to the egress that it wants to set up an LSP.

As part of that process RSVP-TE can verify that the path is good and that the resources it wants to use are available before the LSP is established. It can also reserve the resources it needs – hence the name – for the LSP.

Read more

I've written several posts on different aspects of MPLS: How the FEC is key to the separation of control and forwarding functions in MPLS, the difference between implicit and explicit null labels, how label stacking works, the VPN forwarding plane, and the VPN control plane.

In almost all of those posts I've discussed label switching in one context or another. The Label Switched Path (LSP) is comprised of a set of entries in MPLS switching tables in the Label Switching Routers (LSRs) along the path from the LSP's ingress to its egress, as shown here:

Read more

I mentioned in some earlier blog that things always seem to come in waves. One year I’ll make multiple trips to Japan. Another year, jobs will pop up that require repeated trips to China or the UK or Korea or Australia. Nice work, if you have good strategies for keeping your sanity on those endless overseas flights.

By the same token, technology-specific jobs seem to keep bunching up on me. Last year almost every consulting job I did concerned IPv6. Over the past few months, it’s been MPLS.

Read more

I wrote in the previous post about IPv6 hour at NANOG, in which the dual-stacked wireless LAN would be shut down and all access would be via the IPv6-only wireless LAN; getting IPv4 destinations outside the LAN would be via NAT-PT.

It started off a little rough. Throughout the conference I had IPv4 turned off on my MAC and had been working just fine on the IPv6-only LAN. Admittedly I didn’t try many different online applications, just the things I use on a regular basis: Web browsing and e-mail. An I FTP’d some files to my editor at Cisco Press – all without difficulty.

Read more

I’m attending NANOG in San Jose this week (and in fact am listening to a panel discussion on 100G Ethernet as I’m writing this).

During the last NANOG in October, there was a heavy emphasis on practical IPv6 implementation experience. For this NANOG, they’re starting an interesting experiment: Throughout the event, we have a choice between a dual-stacked IPv4/IPv6 wireless LAN and an IPv6-only wireless LAN. This second LAN connects to the wider IPv4 world through a protocol translator (NAT-PT).

Read more

The last post discussed the forwarding plane of MPLS VPN networks – in particular, how they remain private by maintaining separate information tables at each PE and connecting the traffic related to each of these tables over separate LSPs.

But there is also the control plane: How is the local reachability information contained in each information table advertised to the other PEs?

Read more

One of the most compelling drivers for MPLS in service provider networks is its support for Virtual Private Networks (VPNs), in which the provider’s customers can connect geographically diverse sites across the provider’s network.

There are three kinds of MPLS-based VPN:

Read more

In the last two posts I discussed the role of FECs in MPLS networks, and implicit and explicit null labels. In this brief post I’d like to discuss MPLS label stacking, as a preliminary to a couple of posts on MPLS VPNs.

Label stacking is the encapsulation of an MPLS packet inside another MPLS packet – that is, adding an MPLS header “on top of” (hence stacking) an existing MPLS header. The result of stacking is the ability to tunnel one MPLS LSP inside another LSP.

Read more

In the previous post, discussing the role of the FEC in MPLS networks, I used in one of my examples a particular label value; I was hoping someone would ask about it, which would give me a nice segue to this post. Well no one did, but I’m going to tell you about it anyway.

Read more

It’s funny how things come in waves. For most of last year the majority of my consulting engagements concerned IPv6 in some way or another. But over the past month and a half most of my time has been focused on conducting MPLS seminars of various sorts and for varied audiences.

A central concept to MPLS is the Forwarding Equivalence Class (FEC), and it’s something many people new to the technology struggle to understand. So in this post I’d like to discuss FECs and their role in MPLS.

An FEC is a set of packets that a single router:

Read more

One of the great challenges of modern networking is the need to support services such as voice and real-time video that are quite sensitive to packet loss, transmission errors, delay, and jitter using a technology - IP - that is designed to be tolerant of packet loss, transmission errors, delay, and jitter.

We design our networks with backup links, alternate routes, redundant node components, and resiliency features such as Fast Reroute (FRR) to insure that we can quickly recover from a detected link failure.

But detecting the link failure is the catch.

Read more

I just returned from a long, intense consulting engagement in India. Now that I’ve got my head back above water, I hope to be able to do some catching up on this blog with some long overdue posts.

But first, I want to thank all of you who posted and e-mailed me so many wonderful suggestions, in response to the last post, about a possible Routing TCP/IP, Volume III.

The majority of your responses suggested one of three topics:

-       CCIE-level switching

Read more

Yep, I’m still around. November has been hectic in the extreme, and this blog has suffered from my preoccupation with other matters. For those of you who check it regularly, I apologize and I thank you for your patience.

When Cisco Press approached me in 1996 or so about writing a book, they were a pretty new operation and they left it to me to choose the topic. So I chose the plum, “Routing TCP/IP,” which originally was supposed to be one volume. Halfway through the project my editor and I both realized we couldn’t squeeze everything I wanted to cover in a single book so it evolved into two volumes.

And those two volumes have been a cornerstone of my career.

Read more

You need to make a business trip from San Francisco to Singapore. At the airport, you find out that you are going to be traveling on the inaugural flight of the brand new BoBus A888.

“Cool,” you think as you board the latest in aviation technology. You gaze in admiration at the gleaming exterior and spotless interior.

Settling into your seat, you strike up a conversation with the guy next to you; sticking to standard business traveler chitchat, you ask what he does for a living.

“Why, I’m a principal architect for BoBus. In fact I led the team that designed this very aircraft,” he tells you.

Read more

I discussed in the previous post the value of offline network modeling for reducing the risk of network change projects. And while I think risk mitigation is the strongest benefit of modeling (particularly when combined with a well-provisioned lab), that’s far from the only benefit.

One of the key goals of any network architect is to build networks that are resilient to one or, ideally, multiple failures. So you design redundancy into the network wherever you can and within the limits of whatever you can afford: Redundant links, redundant nodes, redundant logical paths.

Read more