Log of the as4 patch project

Released the bug fix from yesterday.
Bug report received. There is a setup in which the as-path synthesizing (or do you call it reconciliation) dumps core. Found and reported by Katsuyasu Toyama, who also supplied a correct patch for correcting the problem which was found by his collegue Arifumi Matsumoto.
Will provide the patch shortly as an incremental patch only because it contains just a few lines (and due to lack of time for putting together a complete patch again).
Paul Jakma has begun to work on the integration into mainline, see his mail on quagga-dev.
Only as number format being supported will be asplain, and that will be for input and output. Extended community syntax will change again, too. For more details or a way to influence things to take another way (or to enforce that this is as it should be), please read the thread starting with the abovementioned mail.
I will look over the adapted patch ASAP, but due to lack of time this will take a while. The good thing is that we *will* get this into quagga mainline in the foreseeable future - and I will get rid of maintaining the patch, though it was fun to do this ;-).
I'll probably choose something else to do next, maybe bgp multipath.
The webcast of my quagga AS4 presentation at RIPE-54 is available on the RIPE website.
Not that many changes in CVS up to now since I put out version 07. Main change has been the memory saving patch by Paul. Well, anyway, I'll rebase onto the then current CVS version again after my summer holidays, i.e. somewhen in August.
RFC4893 has replaced draft-ietf-idr-as4bytes-13.txt. You could also say it the other way round: the draft has been promoted to a RFC. No semantical changes in the document, so no changes in the patch necessary.
Released v07. Further information is on the main page. I should never again give out ETAs for new patches, because I am always faster than I plan ;-).

Wow, new record: Three minutes from posting a new version to the first download. But I would guess there was just someone out there really lucky not visiting the site 5 minutes earlier.

Back from RIPE-54, where I held my presentation about quagga and the AS4 patch (296674 Bytes) (oups, had the link wrong for a day - but never mind, the presentation is also available from the RIPE website), I found an email telling me about the quagga AS4 patch not following a SHOULD in RFC4271. Well, that is not a MUST - but I will update the AS4 patch sortly to be in sync with the SHOULD. In short, the order of the attributes in the update messages are not as they SHOULD be. I am not violating the RFC, and by using a wrong order some routers were detected which do violate a MUST in the same RFC, namely that attributes MUST be accepted in any order. Thus, quagga AS4 helped debugging the rest of the router world ;-).
Conclusion: if one of your peers has become unstable when you started using quagga with AS4 support (up to v06), you may have a peer which relies on the attribute order which is against RFC4271.
Released v06, based on quagga cvs 20070430, which is basically 0.99.7.
Version 06 is more or less just a re-base to be up-to-date again and provide newcomers with an easy entry when they use a current cvs.

Reading current posts on quagga-users I guess the next release will become necessary when Paul commits the shrinkage of "struct attr" - and that is something where I will have to go through the code again and will not be able to "just apply the changes" because the AS4 stuff will have to stick to the spirit of Pauls memory shrinkage and act accordingly...

My quagga presentation at RIPE-54 in Tallinn has been scheduled to be at the Closing Plenary on Friday (changes in the schedule are still possible). I hope there will still be people there and that not everybody has to catch an early flight ;-). After the presentation the pdf will be made available via the RIPE pages and here.

Quagga 0.99.7 is out. And v05 of the AS4 patch does not patch cleanly into it. So you may expect v06 soon, based on 0.99.7.
The quagga AS4 project is being referenced all over the place nowadays - I just stumbled over an article on the "Swiss Internet Scene" (in German) (posted on Friday, 13th April 2007) which mentiones the AS4 patches for quagga and openbgpd, and mentiones that neither the C, J nor F vendor has an AS4 capable stable release available yet.
Again, it is Jac Kloots who gives news about an ipv6 advertisement with an AS4 origin.
Our AS4 activist Jac Kloots gave another update regarding ipv6 announcements from 3.5, and tells us that he is working with Erik at RIPE NCC on RIS peerings.
Jac Kloots found a bug, but it is only a cosmetical one - a statistic output which contains an as number is not printed in the chosen as number format, but always in asplain.
Made a small patch available for that. I hope things like this are the only things which can be found in the AS4 patch... Besides this bug I have a few other renamings pending for v06 (some things I overlooked in the big renaming NEW_* to AS4_*), but this is all syntactical sugar, nothing else.
If you have not seen it yet, the first overview of plenary topics for RIPE-54 is now available.
I said I would not spend time on the web page... but it was time to clean it up a bit.
All quiet on the quagga AS4 front ;-). A lot of people read these pages, some of them download the current patch; some people even do not download the newest version but an older one (though I can not image why anyone would like to run an outdated version). There has been no more feedback coming in, which also indicates that nobody finds any bugs, which is good.

Well.... not all is quiet. There is a place at the RIPE NCC, where someone has been busy for quite some time, and right now he has reached one of his goals: all of RIPE NCCs RIS RRC boxes have been switched to Quagga 0.99.6 with AS4 patch v05. If this runs without problems for some weeks we can all be sure that the AS4 patch is solid as a rock - I hope so, of cause ;-).
Erik: thumbs up, well done, and lets hope it runs until the (proverbial) cow comes home, and thanks again for all the feedback.

I am thinking about implementing a per-peer option to suppress advertising the AS4 capability in order to tell AS4 quagga to "simulate" being only AS2 capable. That means some very special fiddling with as paths to be a "real" AS2 when having all AS4 information present. And raises a problem if the current host has an as number above 65535 - then we can not simulate an AS2 to another AS4 capable speaker because that one can cancel a connect from AS_TRANS without the AS4 capability, because the draft says an AS2 speaker MUST NOT use AS_TRANS, so an AS4 speaker can see that as an error (AS4 quagga does this). Which means "tolerate an AS2 with AS number AS_TRANS" will be another needed option as soon as "do not advertise AS4" is available. This is still in the "think about stage"... reason for providing it is providing more debugging possibilities, and giving the user a knob to turn if an AS2 peer crashes when presented with the AS4 capability in the bgp open message.

Cleaned up some wording on my thoughts on as4. With patch v05 some extended community comments became superfluos there.
Documented what the debug commands do.
Finally, managed to put together v05. Had some other things which intruded, and - as with any patch version - I try out applying the patch to cvs native quagga sources and compiling it to be (reasonably) sure the patch is complete. So this is what is costing time here.
Oups, draft-ietf-grow-mrt-04.txt came out, describing the format used by the new mrt dumps, and there are a few things which have to be cleaned up again. Erik thinks this is trivial, so I'll hold v05 to include the newest version which follows the definitions of draft-ietf-grow-mrt-04.txt.
Wow. Erik is fast: very new mrt patch is here already (after a few hours!), so it is me again burning time to patch, proofread, test, and finally build v05.
Erik's patch looks good, as far as I can tell without using the dumps with some program. So, I'll wrap this up again now... v05 will be there very shortly.
Erik has sent me a new mrt patch again (he withdrew the one from Feb 14th, btw), based on the discussions on GROW. I'll go through it, and it will be included in v05.
The new version for the extcommunites also looks good, and I'll rebase the patch onto cvs quagga-20070307 while I am at it. Don't hold your breath though, this will take a day or two...
I am busy implementing a new version for the extended communities. Looks definitly better than the old syntax, and gets rid of the (broken) dependency on the input format of an AS2.
Erik sent me a new MRT patch, following the discussions on the GROW mailing list. I'll proof-read his implementation, i.e. cross-check it with the specifications which were on the GROW list, and hopefully we get rid of the hacky stuff in the MRT dumps real soon now ;-).
Regretfully, this will probably take some days as I will be occupied with other activities until Feb 21t. So do not hold your breath.
OK, made version 04. There seem to be some people out there downloading the patch, probably even using it although Erik is still the only one giving feedback. But I hope I get no feedback because "it simply works" ;-).
Put some new stuff into the todo paragraph. MRT stuff has to be done again, as is the extcommunity handling. The first because we now have the definitions needed for implementing this proper, and the second because I chose a wrong way of doing it (at least I think so).
A new version of the draft the whole patch is based on appeared two days ago. Surprise: all constants got renamed. In order for the code to be readable I'll have to follow this new naming scheme and rename a bunch of things in the patch. Tedious, but not mission critical, and no changes in semantics.
Erik found another bug - vtysh can not grok the 'router bgp ASNUMBER' correctly. Hm, did not touch that when programming... di not think there would be a dependency there, but a few commands are coded not only in the corresponding daemons, but in vtysh, too - and this is one of them. Good Thing (tm) to have someone trying out just about everything and sending feedback.
Come on you folks, you are out there, you are using this! Tell me about bugs, and send some success stories, too!
After a longish discussion with Paul Jakma on the mailing list two days ago I decided to spell out my thoughts about asn32 problems. This got longer than I thought, so probably nobody will read it - but at least I can say later that I mentioned the problems which arose from an implementation point of view.
Released version 3 with cleaned up asn32 extcommunities.
After a few words about ecommunities with Erik I realized that 'ip extcommunity-list's of the standard type still had the old description in the CLI. So I thought: oups, you can define asn32 extcommunity, but not use them. But it was not that bad: I had only forgotten to update the CLI prompt. Then I saw the problem with printing out / saving a configuration with an asn32 extcommunity when you have an asn16 as asn in there (probably noone would use something like that, but nevertheless... if you configure something like that, you *expect* to be able to save this configuration): With the syntax I chose and the (variable) output format you could not save such an asn32 extcommunity. So I have to enforce asdot+ for asn32 extcommunities - something which does not fit in well with "freely choosable input/output format". So I think the syntax I chose is bogus in the first place. I should not use 'rt <asn32, asdot+>:<nnn>' for asn32 extcommunites and 'rt <asn16>:<nnn>' for asn16 communities but use something like 'rt32 <asn32,anyformat>:<nnn>' for asn32 extcommunities. Then the syntax is always unambigous regardless of the asnumber format used. Feedback anybody?
Does anybody know what particular syntax other router vendors have used?
Patch number 3 (enforcing asdot+ for asn32 extcommunity values) is forthcoming.
Released version 02 of the asn32 patch. This has working MRT dumps in it. Thanks and a virtual beer to Erik Romijn (RIPE NCC) who has provided information, code, and testing for this. Though this is still a very hacky implementation libbgpdump will be able to read it, and all the tools we love from RIPE NCC will soon be asn32 aware.
Erik Romijn (RIPE NCC) found out that MRT dumps do not work yet. Because I did nothing at all in bgp_dump.c that is actually not very surprising. Some message types for 32 bit things in MRT dumps are already defined, so these have to be used. Others are not, so we will try to invent something sensible which will siffice until we get official numbers for this.

Without someone acually using MRT dumps and knowing about the newly defined and necessary things I have had no chance in putting this together. So the whole MRT stuff will be more Erik's work than mine.

I will update the patch as soon as we have put something together which works for the RIPE NCC.

Patch has been downloaded about 10 times now, from ip addresses located all around the world, however still no feedback whatsoever. It still applies to current quagga cvs with only an ignorable (very obvious) conflict in a changelog. There are already asn32s which have been assigned, but none of these have shown up in the global tables yet.

The more ancient time, i.e. the log of 2006 is also available.