As long as we had only 16 Bits for as number, the world was easy. Everybody knew how an as number looked, how to define regular expressions matching for as number and as number patterns, everything was defined for 16 bit as numbers only.
Now we are changing that. We could say we *have* already changed it, but the actual count of as numbers truly needing 32 bits or 4 bytes is still very small - so we still have a chance to find the best way of dealing with the complications we bought when deciding to move to 4 bytes.
Everyone agrees we have to move to 4 bytes, and draft-ietf-idr-as4bytes-12.txt (draft-ietf-idr) looks as if it has the "complications on the wire" well in hand for all the attributes it mentions and uses.
But we are a bit in the fog for some other things. I have been confronted with two of them during the implementation of as4 for quagga, and I'd like to elaborate on them a bit.
There are several kinds of as number representations, namely (as I called them) asdot, asdot+, and asplain, which we can use for the text representation of as numbers now. Asdot and asdot+ are defined in draft-michaelson-4byte-as-representation-02.txt , even if they are not called that way in there.
Then we have (at least one) attribute in bgp which has been defined for the 16 bit as numbers, and a wire definition for their counterpart in the world of 32 bit as numbers, but no procedure or commitment about what should happen with these two - namly as number based extended communities (the 2 byte stuff inside of RFC4360 and the 4 byte stuff in draft-rekhter-as4octet-ext-community-01.txt).
Draft-ietf-idr tells us plainly how to deal with AS_PATH and AGGREGATOR, and there is a whole bunch of things to implement in order to care for the "transition time" during which "the world" consists of OLD bgp speakers (knowing only 2 byte as numbers) as well as the as4 aware NEW bgp speakers.
We do not know what to do (yet) with the as number related extended communities.
Then we have the OLD and the NEW as based communites in parallel to care for on as4 aware routers. This is in conflict with "get away from any 16bit-ism" and forces us to provide a syntax for both, may it be very similar with as much auto-detection as possible or different in the stem of the command - both confront the user with a choice between something 16 bit and 32 bit, which is a bad thing because John Doe does not want to deal with such.
The second is something where we do things mostly on the local box. This will only break if a peer expects 4 byte stuff only and no 2 byte stuff at all.
Whatever we decide to do, this has to be done on every as4 aware router in the same way, otherwise it is worthless.
Without anything put down like in 2.) we have to do 1.) - there is no choice if we want an implementation to deal with as4 *now*.
If we use asdot, anyone matching for "one as at this place in the as-path" with "_[0-9]+_" will have to adjust this expression because we now have as numbers with dots in them. We can guess that there are many of these and similar occurances in regular expressions which are in use.
If we use asplain, the same happens for the chap which used _[0-9][0-9]?[0-9]?[0-9]?[0-9]?_ for the same thing because as numbers can have more digits now. We guess this may be not as often.
The thing is, you have to update your as-path regular expressions when you go from as2 to as4. How much you have to change depends on your regular expressions, and on the text representation of as numbers your router uses.
Regarding asdot(+), nobody will ask a router to match "_5_" when it prints as numbers in asdot+, thus always showing "0.5" in output, so you will use "_0\.5_" in that case.
Actually, someone may. There seem to be people out there who want to go
to as4 without *any* impact on *anything* any user has in its old
as2 related configuration. It should continue to work, they say.
What can we do? Define some ways to normalize
regular expressions to the internal as number representation of the router,
or keep 2^^(number of as numbers in the path) versions of every
as-path in memory or to-be-build-on-the-fly when we match a regular
expression against a particular as path. (2^^number of as numbers because
there are 2 representations for each true AS4 (asplain and asdot) and
2 for AS2(asdot/asplain (identical for AS2) and asdot+).
We can use asplain. But even that will not ensure that *all* regular expressions work as before - as numbers can now have more than 5 digits. Are you sure nobody relied on that in any regexp?
What is better? Having only a few as path expressions break (so just about nobody who gets hit will know what hit him if he belongs to the few) or break many of them so everybody will know what hit him? And - are we sure our guess is right in the first place?
So it is a problem to go through your regular expressions when you go to as4? Sure, for people
Only the last item is really valid on a global scale if you try to look impartially onto this. So everyone providing as4 capable bgp equipment has to tell the user to watch out for these regular expressions when they use an old as2 config on their new as4 box.
A reason for choosing a particular textual representation of as numbers?
I do not think so.
What the heck, if you have an as-path regular expression to match "all as numbers allocated by ARIN" you'll have to update that whenever ARIN gets a new as number range allocated from IANA. If you have an accurate bogon exclusion list (on as basis or ip basis) you have to update it whenever some bogons are no longer bogons because IANA has allocated something to an RIR. If you set up a new peering you'll probably have to go through all your regular expressions too (or not - all this is dependend on what you use: only you, the users, know this).
Which means, whenever something new comes up, you have to update your filters if you use them in a way that they are influenced by this new thing. And you know that 4 byte as numbers are new. In fact, this is only a special case of "IANA has allocated something to the RIRs".
OK, if you do not use regular expressions on as-paths at all, then you are lucky and can just forget this whole paragraph.
Some problems will make themselves more prominent with asdot(+), but that can also be seen as a feature, not as a burden.
We would do better if we had not:
As long as there is no definition, implementors have the choice between bad and worse:
I saw the last as the best way.
Best thing would be if we all use one specific representation and be happy with it.
As long as what is used and what is or has been consented on does not focus globally onto the same thing, implementors have the choice between the bad and the worse:
All four ways have their disadvantages. I saw the least disadvantage in the last choice, which is why you can choose which representation you want with quaggas as4 patch. This drops the representation problem in *your* hands, the hands of the (hopefully) capable user. And I wash my hands clear of this ;-).
I will provide all three representations until there is a real consensus and everybody uses the same thing. I even give you a hint: input and output of as numbers have been folded into two functions - kill about 20 lines of code (10 of it comments) and you'll have only one representation anywhere. From the implementation point of view this is truly negligible.
This choice has one drawback:
As long as my patch provides more that one possible representation for as numbers, it looks as if it will not become part of quagga mainline. That seems to be the heart of all discussions with Paul Jakma. He is very concerned that using asdot (providing the possibility to use it) is the wrong way to go (like giving a loaded gun [with a 180 degree bended barrel so you'll definitly shoot yourself if you pull the trigger] to the unaware user), and does believe we will have much more problems using asdot than with using asplain.
In my opinion we will face the same problems regardless of what we use; everybody has to be careful and observing when entering the as4 world. If we want people to form an opinion about as number representations we should provide all representations - and give the users information about what this is all about.
So please, try everything out. Play with all representations. Get a feeling, and voice your experiences and opinions. And always watch your back: You are using something new, it may bite you. You have been warned.
Juergen Kammer, January 2007