I’d promised to record another MPLS-related podcast and wanted to refresh my failing memory and revisit the beginnings of Tag Switching (Cisco’s proprietary technology that was used as the basis for MPLS). Several companies were trying to solve the IP+ATM integration problem in mid-nineties, most of them using IP-based architectures (Cisco, IBM, 3Com), while Ipsilon tried its luck with a flow-based solutions.

Most current SDNish tools are too cumbersome for everyday use: OpenFlow is too granular (the controller interacts directly with the FIB or TCAM), and NETCONF is too coarse (it works on the device configuration level and thus cannot be used to implement anything the networking device can’t already do). In many cases, we’d like an external application to interact with the device’s routing table or routing protocols (similar to tracked static routes available in Cisco IOS, but without the configuration hassle).

The usual claim that “IPv6 has better security because it includes mandatory IPsec support” is evidently creating some confusion, at least based on a set of questions I received from one of my readers.

Can IPv6 work without IPsec?

Absolutely. Most IPv6 deployments don’t use IPsec (unless you’re building IPsec-based VPNs over IPv6 transport infrastructure).

I often get three questions about TRILL: Are the TRILL standards finalized? Has anyone implemented it? Is it useful?

Short answers: Yes, No, Maybe (although I remain unconvinced).

A week ago a friend sent me a disturbing email: another creative individual has decided to use my content to attract traffic, this time making sure to remove all the links and even the webinar introductions before republishing it. As expected, the well-populated web site had no about or contact me links, and the domain name registrant was an obvious fake.

Ahmed was reading my EIGRP book (I know it’s hard to get, but fortunately he found a well-marked copy) and wanted to check his understanding of how EIGRP works. The first question was as good a summary as I’ve ever seen:

Does it just simply boil down to the fact that a router will choose not to have anything to do with a reported distance higher than its own cost to that route (feasible distance) for the (paranoid) fear that it could be a loop?

Next, he started wondering why a router would behave that way:

A few years before MPLS/VPN was invented, I’d worked with a service provider who wanted to offer L3-based (peer-to-peer) VPN service to their clients. Having a single forwarding table in the PE-routers, they had to be very creative and used ACLs to provide customer isolation (you’ll find more details in the Shared-router Approach to Peer-to-peer VPN Model section of my MPLS/VPN Architectures book).

Now, what does that have to do with OpenFlow, SDN, Floodlight and Quantum?

Supposedly it works a bit better in silicon ...

During the February Packet Party, someone asked the evergreen question: “Is it safe to run Internet services in a VRF?” and my off-the-cuff answer was (as always) “Doing that will definitely consume more memory than having the Internet routes in the global routing table.” After a few moments, Derick Winkworth looked into one of his routers and confirmed the difference is huge ... but then he has a very special setup, so I decided to do a somewhat controlled test.

Straight from RFC 6670 (section 3.4):

[...] as is usually the case with communications technologies, simplification in one element of the system introduces an increase (possibly a non-linear one) in complexity elsewhere. This creates the "squashed sausage" effect, where reduction in complexity at one place leads to significant increase in complexity at a remote location.

This is probably the most concise description of the great idea of using long-distance vMotion for “mission-critical” craplications, and applies equally well to the kludges used to compensate the simplicity of virtual switches.