Random ramblings

Wednesday July 11, 2007

BGP AS-Dot notation considered harmful

There is a draft, draft-michaelson-4byte-as-representation, which specifies a new notation for BGP AS (Autonomous System) numbers, aka ASNs. It specifies that ASNs greater than 65535 should be represented as two words, seperated by a dot, where each word represents a range of 0-65535 - in stark contrast with existing practice. I.e. the ASN of 196611 would be represented instead as "3.3". This notation has been adopted by RIPE and by at least one vendor for their early 4-byte ASN efforts, as well as by Juergen Kammer's Quagga AS4 patch.

The proponents of AS-Dot have, unfortunately, ignored the significant compatibility[1] issues. As background, many BGP implementations allow policy to be applied by specifying policy in terms of regular-expressions to be applied to a string-form of attributes such as the AS_PATH, COMMUNITY and Extend-Community attributes.

E.g. an AS_PATH might be specified as "123_456_{700,800,900}" in string form, meaning a path of ASes 123,456 in sequence followed by the set of 700,800 and 900. One might apply a regex of "(_([0-9]+)_){3,)" to this, meaning "match AS_PATHs with at least 3 ASNs in them" (e.g. you might do this on low-resource routers, to filter out 'far away' paths, to conserve RAM). If As-dot notation is introduced, the administrator will find that, slowly over time, more and more paths will mysteriously fail to be matched by this filter (despite the filter being well-formed and correct for quite a long time), as "X.Y" style ASNs become more and more prevalent in paths.

One can come up with more examples, they are bounded only by the number of problems network administrators have faced, and their imagination in applying regexps to filter upon AS_PATH and communities to solve such problems.

So As-Dot breaks compatibility with existing configurations that use regexp filtering on either communities or AS_PATHs. Further, there is no way, that I know of, to automatically convert regexps to support asdot. Some proponents of asdot have suggested that implementations should support asdot, but allow it to be disabled or default to off initially - i.e. present two subtly different configuration and UI interfaces to administrators, and two code-paths to maintain. A support nightmare.

All this for no apparent reason other than that some think that "314.6696" somehow looks nicer or is easier to remember than "20585300". ASNs are not hierarchical, as IP is, there is no practical reason why an administrator should have to care to think of an ASN as a multi-word number, or care about low-level details like how many bytes are used on the wire to represent ASNs. Why clutter the life of network admins even further with such trivial details (managing BGP is complicated enough already!).

In summary, as-dot:

• Irretrievably breaks compatibility with configuration of regex-filtering of attributes such as AS-Path and Communities.
• Will fork configuration and UI interfaces as seen by administrators
• Adds complexity to code
• Adds inconsistency; some ASes will be displayed with dots, some without (why???)
• Doesn't seem to solve any problems at all, to make up for the above issues it introduces

In contrast, presenting ASes as plain numbers in string form will just work, always. Concerned operators should engage with others in their RIR communities to ensure the confusion, breakage and inconsistency which "asdot" would introduce is avoided. Quagga will not be introducing support for asdot any time soon, possibly never, to avoid the significant configuration compatibility issues.

See also the ASN Format page of Juergen's Quagga AS4 patch site (that page shouldn't need to exist!! ).

1. This sadly seems to be a general characteristic of the whole 4-byte AS effort. E.g. the overloading of the AS_PATH TLV code rather than using a new code (which the RFC had to do anyway), which means that tools like tcpdump and Wireshark can no longer reliably decode BGP UPDATE messages, or the vaguely thought-out 2/4-transition method. This isn't a reflection on those involved, more of the complexity of the issues involved in trying to transition the width of ASes in BGP from 2 to 4 bytes. We should though try to avoid introducing further complexity without need (i.e. asdot).

Update: Fixed the example regex, as well as some grammar/style issues.