I noticed today that the new RFC has been released :

RFC 5517 – Cisco Systems’ Private VLANs: Scalable Security in a Multi-Client Environment

Abstract

This document describes a mechanism to achieve device isolation through the application of special Layer 2 forwarding constraints. Such a mechanism allows end devices to share the same IP subnet while
being Layer 2 isolated, which in turn allows network designers to
employ larger subnets and so reduce the address management overhead.

Some of the numerous deployment scenarios of the aforementioned
mechanism (which range from data center designs to Ethernet-to-the-
home-basement networks) are mentioned in the following text to
exemplify the mechanism’s possible usages; however, this document is
not intended to cover all such deployment scenarios nor delve into
their details.

If this sounds familiar you would be right. This RFC comes almost word for word from Cisco’s website from the Internetwork Technology Handbook and covers the basics of PVLANs in an Informational RFC. There doesn’t seem to be any new information or any value in publishing this RFC.

And then I noticed another: RFC5171 Cisco Systems UDLD Protocol.

Abstract

This document describes a Cisco Systems protocol that can be used to
detect and disable unidirectional Ethernet fiber or copper links
caused, for instance, by mis-wiring of fiber strands, interface
malfunctions, media converters’ faults, etc. It operates at Layer 2
in conjunction with IEEE 802.3′s existing Layer 1 fault detection
mechanisms.

This document explains the protocol objectives and applications,
illustrates the specific premises the protocol was based upon, and
describes the protocol architecture and related deployment issues to
serve as a possible base for future standardization.

Who wrote these ?

Both of these RFC lists an M Foschiano from Cisco Systems as the author ( or joint author).

Eh? What ?

About IETF Information RFC’s

So why has this been done ? First, lets check into what a Informational RFC is.

Types of RFC’s

There are FIVE TYPES of RFC.

• Informational
• experimental
• best current practice
• historic
• unknown

Informational RFC

From

Status “informational”
An informational RFC can be nearly anything from April 1 jokes over proprietary protocols up to widely recognized essential RFCs like RFC 1591. Some informational RFCs form the subseries for your information (FYI). While rarely added to today, some old FYIs are still interesting, for example, FYI 18 (RFC 1983), the Internet User’s Glossary. FYI 17, The Tao of IETF, is now RFC 4677, published in 2006.

From the RFC Editor provided by IETF

Are all RFCs Internet standards documents?

In a word, “NO!”.
Many RFCs have Informational or Experimental status and do not represent any kind of standard. They contain information that may be useful or important to retain in this archival document series.

This is important to understand, because unscrupulous marketeers and a careless trade press sometimes falsely suggest that every RFC represents a standard, or that all standards have equal weight. The relationship among Internet technical specifications is often complex.

So, Why Bother ?

If an informational RFC is the RFC equivalent of “chewing gum on the road” then why is this M Foschiano bothering to write this up ? I have attempted to contact him without success. Is this just an ego trip to submit some RFC’s and make the resume look good, or is this some devilish marketing plot. Maybe he will comment here and share the reason.

The only reason I can see is that Cisco would do that in RFC 5171 is to reserve the data in the SNAP header for the packet format (LLC Value etc). But I’m thinking that this should be handled by the IEEE since Ethernet is managed (albeit in secretive, pay-for-membership, closed-door club). But RFC5571 for PVLANS doesn’t have any protocol data just general chit chat about PVLAN technology.

Either way it demonstrates that not all RFC are equal. Informational RFCs should be considered SPAM until proven otherwise.