Thoughts on as4 from an implementation and usage point of view

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).

as number based extended communities

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.

We can

1. ignore the problem

   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.

2. define what the as4 aware router should do

   For example:

   • use only the 4 byte version of as based extended communities internally.
   • convert a received 2 byte version of an extended community always into a 4 byte one
   • when sending an as based extended community to an OLD bgp speaker, use AS_TRANS for an as number larger 65535 in the community, strip the higher bits (which do not fit) from the value in it, and send a 16 bit as based extended community. (Maybe send these excess bytes in a second extended community).
     OR
     Do nothing in this case, send it as-is. Reasoning: even on an OLD bgp speaker you could define an extended community list grasping for a NEW as based extended community (some as bytes get transfered into the extended community value) - this is ugly, depends on the syntax the old box has, but theoretically possible.
     OR
     Send the 4 byte as based extended community as 2 byte based extended community (i.e. change only the second byte). This ensures something like stated in the last paragraph will be possible (but oh dear, what have we done with semantics doing something like this!?).
   or
   • Always use the 2-byte stuff for everything which fits into it
   • Convert all 4 byte stuff received into the 2-byte equivalent when the as number therein fits into 2 bytes.

   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*.

regular expressions in as path lists

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

• with hundreds of as path access lists (a lot of work)
• who can not cope with regular expressions anyway, and will not succeed in escaping the dot in particular (get a clue or an expert)
• who do not know that they have to do it

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.

Where to go from here

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:

• have something defined for as4 and as2 in parallel, different representation on the wire, without deprecating the latter and without a procedure to go from as2 to as4 or a commitment to continue to use the 2 byte stuff where possible.

  As long as there is no definition, implementors have the choice between bad and worse:

  • do not provide the 4 byte stuff at all, because it is not defined what to do with the 2 byte stuff if you do
  • Throw a dice and do what they think is best
  • Always use the old 2-byte stuff for asns smaller 65536, convert any 4byte stuff entering the box with an as number smaller 65536 into that and use the new as4 stuff only for as numbers larger than 65535.
  • Provide for both as2 and as4 things whenever possible

  I saw the last as the best way.

• to have several possible textual representations for as numbers at all.

  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:

  • Use what is used (i.e. by the RIRs) [asdot]
  • Use what they think is best [one out of asdot,asdot+,asplain, or even invent something else]
  • Don't implement as4 at all, it is not defined yet how to really print and accept as4 as numbers [i.e. stay 2 byte, ignore as4]
  • Implement all of it, make it choosable

  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