RFC 5396, RFC 5398, RFC 5462

Here are 3 interesting RFCs that i have read lately:

RFC 5398
Autonomous System (AS) Number Reservation for Documentation Use

To allow documentation to accurately describe deployment examples, the use of public or private-use AS numbers is inappropriate, and a reserved block of AS numbers is required. This ensures that documentation does not clash with public- or private-use AS numbers in deployed networks, and mitigates the risks to operational integrity of the network through inappropriate use of documentation to perform literal configuration of routing elements on production systems.

To allow for examples relating to the transition to use of 32-bit AS numbers to be correctly described, a reservation of two blocks of AS numbers is proposed in this document. One reserved block of 16 contiguous AS numbers is to lie in the range of numbers that can be expressed as a 16-bit AS number value (i.e., values less than 65536), and a second reserved block of 16 contiguous AS numbers is to lie in the range of numbers that can only be expressed as 32-bit AS numbers (values greater than 65535).

IANA has reserved a contiguous block of 16 Autonomous System numbers from the unallocated number range within the "16-bit" number set for documentation purposes, namely 64496 - 64511, and a contiguous block of 16 Autonomous System numbers from the "32-bit" number set for documentation, namely 65536 - 65551. These reservations have been documented in the IANA AS Number Registry.

So, from now on, you know what AS number you should use in your documentation.

2-byte (16-bit) ASNs : 64496 - 64511
4-byte (32-bit) ASNs : 65536 - 65551


RFC 5396
Textual Representation of Autonomous System (AS) Numbers

A taxonomy of representation for AS numbers is as follows:

asplain refers to a syntax scheme of representing all AS numbers using decimal integer notation. Using asplain notation, an AS number of value 65526 would be represented as the string "65526" and an AS number of value 65546 would be represented as the string "65546".

asdot+ refers to a syntax scheme of representing all AS numbers using a notation of two integer values joined by a period character: .. Using asdot+ notation, an AS number of value 65526 would be represented as the string "0.65526" and an AS number of value 65546 would be represented as the string "1.10".

asdot refers to a syntax scheme of representing AS number values less than 65536 using asplain notation and representing AS number values equal to or greater than 65536 using asdot+ notation. Using asdot notation, an AS number of value 65526 would be represented as the string "65526" and an AS number of value 65546 would be represented as the string "1.10".

Cisco has chosen the asdot notation for the 4-byte ASNs in most mainstream releases (12.0(32)S12, 12.4(24)T), which might cause you a little bit of headache when dealing with regexp. To make it more interesting, in some other releases (12.0(32)SY8; GSR only?) Cisco has given the option (through the "bgp asnotation dot" command) to use asplain or asdot when displaying or matching (through regexp) 4-byte ASNs, while both formats are available when configuring.
As you may already know, asplain is being used widely for the well-known 2-byte ASNs.

Here you'll find an interesting article regarding 4-byte ASNs by Jeff Doyle.


RFC 5462
Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field

The format of an MPLS label stack entry is defined by RFC 3032 to include a three-bit field called the "EXP field". The exact use of this field is not defined by RFC 3032, except to state that it is to be "reserved for experimental use".

The EXP field, from the start, was intended to carry "Class of Service" (CoS) information. The field was actually called the "Class of Service field" in early versions of the working group document that was published as RFC 3032. However, at the time that RFC 3032 was published, the exact usage of this "Class of Service" field was not agreed upon and the field was designated as "experimental use"; hence, the name has since been the "EXP field".

The designation "for experimental use" has led other Standards Development Organizations (SDOs) and implementors to assume that it is possible to use the field for other purposes. This document changes the name of the field to clearly indicate its use as a traffic classification field.


The use of the EXP field was first defined in RFC 3270, where one of the longest acronyms ever invented has been used:

E-LSP
   which gets translated into
EXP-Inferred-PSC LSP
   which gets translated into
EXP-Inferred-PHB (Scheduling Class) LSP
   which gets translated into
EXP-Inferred-Per Hop Behavior (Scheduling Class) LSP
   which finally gets translated into
EXP-Inferred-Per Hop Behavior (Scheduling Class) Label Switched Path
   which could also get further translated into
Experimental-Inferred-Per Hop Behavior (Scheduling Class) Label Switched Path
   which should get translated into
EIPHBSCLSP to keep everyone happy :-p

Keep in mind that there is a Traffic Class (TC) field in the IPv6 header too.