Since I'm taking the Computational Physics module in my third year at IC, we're using some libraries like GSL to provide "better-than-default" random number generators and such like. It turns out that those of us using a Mac don't get GSL installed by default with Xcode, or under OS X - and unlike Windows and Linux - there's no instructions on the course site. Here's a really quick way to ensure that you can link against it:

• Install MacPorts from MacPorts.org.

• $ sudo /opt/local/bin/port install gsl

• In the directory that you're writing your code from, perform the following:
  

  $ g++ -I/opt/local/include -L/opt/local/lib -lgsl -o binary_name source_file.cpp

Which should let you link against GSL just fine :-)

I finally got myself an iPhone - and am loving it. It's great how I can now sync my calendars, and address book to my phone without having to worry at all about having six clones of each event on my calendar (which of course, makes it rather difficult to tell what I'm actually meant to be doing that day). However, a topic that has come up a couple of times in discussion with a few friends is that of the iPhone SDK. I feel that the big question here is, "Do Apple have enough incentive to make a fully featured iPhone SDK?".

With a friend moving to work at a VoIP start-up that deals with having a client on mobiles that allows SIP calls to be made, the big discussion we have been having is whether the iPhone SDK will allow a VoIP client to be implemented on it. My initial feeling on this is, no - not initially. It's been documented in a number of places that Apple are taking call revenue from the networks on each iPhone that is sold. If this is true, then it would be against Apple's interest to actually allow a functional SIP implementation make it onto non-hacked iPhones - since they're going to lose money if users start making their calls via SIP rather than via the cell networks (this assumes that Apple get revenue based on all calls - not just based on the actual contract worth).

However, I can't say that I'm sure of this - Apple may only be taking their cut from the revenue that is generated from the subscription fee on each iPhone - rather than the additional calls, and in this case, they might feel that allowing users to utilise VoIP when they're in a hotspot area would be another cool feature that the iPhone can offer. They might also feel that a lot of the iPhone users aren't savvy enough to be using SIP very often - I guess something like Skype from hotspots (or iChat for voice, or Google Talk...) might be more popular with the less tech-savvy userbase. It's hard to call really.

Alternatively, Apple might just wait until the networks stop paying them revenue, and roll the SDK with better network support then, increasing sales on a device that they're no longer making such revenue on.

Either way, the iPhone really just slots in where a phone should, it works with wireless and a mobile-data mechanism without having to think about it at all (although I'd like an 802.1X implementation). Calendar data syncs, Mail accounts sync, my Music syncs, my contacts sync - it integrates with my (primarily Apple based) digital life very well.

I'm impressed with my iPhone - roll on the SDK so that I can start making it do even funkier things!

So, at the moment, I'm writing a presentation about the operation and the security implications of RFID. During the course of the random searches around the internet, I've found that there's a lot of really, really cool work going with respect to RFID. Even more great than the output on the subject is who is studying it. Lots of really cool observations are coming out of the open source friendly community - some of the best presentations on the subject are from presentations at CCC. Along with projects like OpenPCD, this output is pretty cool!

However, that's not really the point of this post. During the course of reading around, I've found that whilst there's a lot of information around - there's also a lot of FUD that surrounds that information. My presentation is trying to give people (with some physics background) a simple idea of what RFID is, and particularly how it works. Given that I've already done a quick summary of how RFID works, I figured I'd blog about it, so that I can add to the mush of material that you just can't reference online.

I'll discuss a high frequency system - since cards such as MIFARE (which e.g. Oyster uses) work at around 13.56MHz. The RFID system consists of two elements - the reader, and the tag. Tags come in a number shapes - active, passive, and semi-passive. Really, it's the passive tags that I'm interested in. The image below shows the anatomy of a (simple) passive tag. It's composed of an antenna - running around the card, an IC, and a substrate that they're both attached to.


The reader consists of a dipole-antenna, a transceiver, and some controlling electronics (this is hugely simplified, check OpenPCD for much more detail). Obviously, the consideration of the conversation between the reader, and the tag is the interesting part.

1. The reader emits a signal from a dipole antenna at a fixed radio frequency. The magnetic field of the signal induces a current in the dipole antenna loop of the tag - hence powering it on.
   
   
   
   
2. The tag is now powered up, and a capacitor in the tag is charged, the current is trapped using a diode. The resulting voltage across the capacitor powers up the IC within the tag. In the really simple case that we're considering - we'll assume that this tag just has a unique ID, and isn't doing anything interesting. The IC replays the unique tag ID (as a digital binary signal). The signal is fed into a transistor, causing the antenna to reflect/absorb more of the signal - hence modulating it.
   
   
   
   
3. The modulated signal shows variations in the frequency which are dependent on the way in which the transistor responded to the input from the IC within the tag. This results in a load-modulated signal - the trace below shows the frequency distribution of the reflected signal from the tag.
   
   
   
   The RFID tag information is contained completely in the sidebands of the signal, and the figure above shows that compared to the reader-generated centre frequency - these are extremely weak. The 90dB difference accounts for some of the reason why RFID transmission range is so limited.
   
   
4. The modulated signal is received by the reader, where it is resolved into a tag ID.

This isn't exactly the most exciting part of RFID, but its the basics of how the technology works, in a fairly friendly format I hope, and without a spin that's trying to present any kind of agenda about RFID. There's a lot more interesting things to look at, and blog about on this subject, so I'll probably discuss those at some other time. But for the time being - I'm interested in this, and hope that this helps someone one day - questions/comments/corrections are welcomed to my mail address.

For anyone interested, the slides for my RFID presentation are here.

30 23 28-31 * * [ "`date +%m`" != "`date +%m --date=tomorrow`" ] && /Users/rjs/bin/monthEnd.py 2>&1 >/dev/null

Pretty handy for running on the last day of the month - and should work on Linux.

Since I've got a few moments, and I've decided to actually write down some rants rather than deciding that I can't be bothered to - I'm going to use some space to single the praises of Django.

I've been using Django for a couple of years now - since around the autumn of 2005, and as such, feel that I've got a pretty good grasp of how the framework works. I haven't really hacked around that much with the innards of Django (although I did propose a patch), however, what I really like about this framework isn't particularly the internals, but just the whole philosophy that there seems to be in terms of building a web application.

Let's face it, when you sit down to write a web application, especially as a sysadmin or a network engineer - your primary motivation isn't to write a web application, your motivation is to get some data out in a very easily readable format to some audience. So, you start looking at how your database should be designed (or retrofitting your code around an existing database), and you start writing code for updating one table, or grabbing data from another. Stop. This is where Django comes in. With Django, you just rapidly develop your data into a set of models, which can be related in a number of different ways - almost everything that you want to do (for generic data handling) can then be done straight from a generic Django view - without you having to go around writing a lot of code for really generic things. It really speeds up web application development.

I love the fact that Django has things like overloadable save(), and delete() methods for each model - it sounds fairly trivial, but it's great to be able to have the application create the ports on a switch when it saves it into the database the first time - and remove them when the user removes the switch. I've found myself able to work on really quite complicated model layouts without getting too tied up in it, because it's just a case of breaking it down simply into models.

I've got a couple of Django based projects that I'm maintaining (hint: you're reading one of them). The other is a portal system for Catalyst2. I've been working on this system for almost 2 years now - it started out as a PHP application, and then morphed into Django when I discovered it. As a PHP app it was just unmanageable, because of the amount of code that I was having to write. Django's inbuilt admin application has let me just worry about actually presenting data to users - and keeping the boring stuff (like adding data to simple database tables) out of the way of the application. It's become a pretty complicated application.

The system tracks ISP assets, things like racks, servers, switches, routers, cabling...the list goes on. For servers it can control APC MasterSwitches via SNMP, it integrates into cacti for network graphs, it can access RANCID SVN repositories to obtain device configurations...I built an SNMP poller that collects traffic data, and produces billing data as both HTML and PDF. I've integrated it with our automated DNS and MX secondary system. The list is pretty huge (hence why this project is almost two years old!).

Before it sounds like I'm just trying to give a list of features that I've written into an application - I'll get to the point. Django and python's flexibility means that I've been able to sit down and write features, I haven't had to sit down and write a lot of generic type functions that add entries to a database, allow them to be updated, and then save them, I haven't had to handle how my site is going to be templated - I've written features. This is the massive difference for me using Django.

Sure, I could get this functionality with just about any framework out there - BUT, Django does this really well - there are very, very few things that you come across and say "Oh, I don't like that" that you can't change. I didn't really like the authentication system that it uses by default - no worries, I can just replace it with an LDAP authentication system for our users, and use the Django one to provide application-specific privileges. Django does things easily, in a sane manner, that you can just code for. What's even better, is it fits in with people like me - who just want to get an application out - but also it fits in with those guys who want to produce just the frontend part of the system - the templating language allows really simple creation of complex pages, without a steep learning curve.

I didn't really plan this entry before I started, but I hope I've got across what I actually wanted to say, Django is a really great framework that's very, very flexible. It's also getting better, they're carefully considering what's added to it, and keeping it so that its very database neutral, and can fit into many, many development styles.

I've written >5,000 lines of just python code in my Django applications, and I'm still finding new and cool things that the framework can do - I really do recommend it for web application RAD!

Imperial College are currently implementing changes so that you need to access either POP3 or IMAP with SSL enabled, I figured since they didn't list Fetchmail in their new site, then I'd post my configuration (.fetchmailrc) here in case anyone else uses it:

poll icex.imperial.ac.uk 
    proto pop3 
    user "USERNAME" 
    password "PASSWORD" 
    is "LOCALADDRESS" here 
    ssl 
    sslfingerprint "7D:E8:74:1F:E8:B1:E6:15:A6:0C:02:2B:BA:89:BE:4D"

Enjoy.

I was reading an entry posted by Brett Carr on Nominet's techblog today entitled "ipv6 It just works". Unfortunately, for IPv6, and for the sentiment behind this message (IPv6 can be run pretty easily!), in my experience, IPv6 - it doesn't just work!

It's easy to dismiss the previous sentence, given that many networks aren't designed to run IPv6, and there's kit out there that's just not IPv6-capable yet. When building the AS29636 network, we specified that IPv6-capability was one of the things that would be a requirement of the kit that was going into the new network, not just something that we'd like to have. We work to a similar specification at my current employer, - which ensures that we can deploy IPv6 within a pre-agreed timeframe once we have some commercial drive for it (either from customers, or for business continuity reasons). I think that this is the best way for a SP network to be a the moment - there's no revenue in having IPv6 deployed (generally), but there might be lost revenue when a customer comes to your network with IPv6 as a requirement in their RFQ...

Returning to the reason that I started writing this post - the problems for IPv6 deployment don't just come from the fact that your hardware doesn't necessarily support it, and it isn't just that running IPv6 on your kit might have financial implications for the software licensing that you're going to be deploying (the arbitrary Cisco requirement for advipservices for IPv6 is a completely separate post). There are going to be issues where you don't necessarily expect them - which can be hard to debug, where IPv6 "should just work", it doesn't.

Without mentioning any specifics of a case that was brought to my attention in the last couple of weeks - a customer was having problems getting IPv6 traffic flowing across a layer 2 ethernet circuit. The expectation of this circuit that you can put ethernet frames onto it (and it doesn't really matter what the ethertype is, just that they're valid ethernet frames) - and they are going to be punted down the link, to whatever you terminate the L2 circuit on. With IPv4, this not working would be a disastrous failure - the product just wouldn't be working. However, this particular circuit was not passing frames that contained IPv6 packets. As it turns out, the carrier's equipment in the path contained a firmware bug that was causing the frames containing IPv6-packets to be dropped - and hence, no neighbour-discovery, and no traffic flow between the two ends of the circuit.

This is just one isolated case - but the question is, where else in your network do you have a problem like this one? How much kit that may, right now, be considered something that shouldn't be interfering anywhere above L2, is going to exhibit this type of problem? How much load is this going to cause your NOC? How much time liasing with circuit suppliers, and telcos is going to be spent actually deploying IPv6 on your network? I think these questions are starting to form a basis of why SPs should be startng to roll out IPv6 onto your network now. The lack of transition plan from IPv4 to IPv6, and the fact that IPv6 hasn't had widespread deployment testing across many platforms and transmission media mean that deploying IPv6 in a rush across your network isn't necessarily going to be as easy as you've thought.

Whilst I applaud the fact that Nominet are ensuring that they're going to be ready to run the UK ccTLD with IPv6 nameservers, and that their infrastructure is ready - I don't think that IPv6 is going to be quite as easy to deploy as Brett found in his blog post.

It took me a few hours over the course of this week to build the RIPE whois server for some internal projects -- given that there seems to be a very limited amount of documentation for the build process, and threads on mailing lists, I'm going to post this here. I hope that it gets picked up by Google.

The first problem that is encountered is that the libtool that is included with the whois server does not support 'modern' tags, such as --tag=CC. This looks to be because the included libtool is somewhat dated. This can be easily fixed by using the system libtool:

[rjs@dbhost whoisserver-nightly]$ mv libtool libtool.old
[rjs@dbhost whoisserver-nightly]$ ln -s `which libtool` .

(NB: after doing this, you should specify --no-all --setup-db --setup-config --install --setup-tests, and _NOT_ --configure, otherwise the existing libtool will just replace the symlink that you've created)

The next problem is that there are a large number of definitions of yywrap() that conflict when they are being linked. On examination, these seem to be of the form:

int yywrap(){
    return 1;
}

There are definitions in:

• src/modules/rpsl/syntax.c
• src/modules/rpsl/mnt_routes.lex.c
• src/modules/rpsl/mnt_routes6.lex.c
• src/modules/rpsl/mnt_routes_an.lex.c

that conflict with each other. Simply removing the yywrap function that only returns 1 from each of these files resolves this linker issue.

The next problem is that there is a multiple definition of a 'set_dynamic' function -- I believe that this is a function that's used both in the src/modules/pc/pc_commands.c files, and in the MySQL headers.

/usr/lib/mysql/libmysqlclient_r.a(array.o): In function `set_dynamic':
/home/mysqldev/rpm/BUILD/mysql-4.1.22/libmysql_r/array.c:175: multiple definition of `set_dynamic'
/home/rjs/tmp/whoisserver-nightly/src/.././src/librip.a(pc_commands.o):
/home/rjs/tmp/whoisserver-nightly/src/modules/pc/pc_commands.c:509: first defined here
/usr/bin/ld: Warning: size of symbol `set_dynamic' changed from 366 in
/home/rjs/tmp/whoisserver-nightly/src/.././src/librip.a(pc_commands.o) to 203 in
/usr/lib/mysql/libmysqlclient_r.a(array.o)

The first definition (/home/mysqldev/rpm/BUILD/...) is from the RPM package of the shared MySQL libraries. I've tried the compatibility libraries, as well as versions from MySQL 4.1, and MySQL 4.0. The only way I can find to correct this is to change where the include path is from the files that are provided by the MySQL development libraries, to the shared libraries provided by MySQL:

[rjs@dbhost whoisserver-nightly]$ diff Makefile Makefile.orig 
214c214
< MYSQL_LIBS = -L/usr/lib/ -lmysqlclient_r -lz -lcrypt -lnsl -lm
---
> MYSQL_LIBS = -L/usr/lib/mysql -lmysqlclient_r -lz -lcrypt -lnsl -lm
[rjs@dbhost whoisserver-nightly]$ diff src/Makefile src/Makefile.orig 
378c378
< MYSQL_LIBS = -L/usr/lib/ -lmysqlclient_r -lz -lcrypt -lnsl -lm
---
> MYSQL_LIBS = -L/usr/lib/mysql -lmysqlclient_r -lz -lcrypt -lnsl -lm

This then allows the whoisd to compile.

However, when starting the server a number of segmentation faults are experienced:

[rjs@dbhost bin]$ ./whoisd_start --config=rip.config --crashes=1
Starting whois-server daemon with configuration
/home/rjs/whoistmp//conf/rip.config from /home/rjs/whoistmp//bin
./whoisd_start: line 165: 23118 Segmentation fault      (core dumped) $NOHUP_NICENESS $WHOISRIP -p $pid_file -c ${CONFIG} >> $err_log 2>&1
mv: cannot stat `core': No such file or directory
./whoisd_start: line 165: 23145 Segmentation fault      (core dumped) $NOHUP_NICENESS $WHOISRIP -p $pid_file -c ${CONFIG} >> $err_log 2>&1
mv: cannot stat `core': No such file or directory
081008 11:24:36  $WHOISD ended

This is because the MySQL connections do not work correctly out of the box -- what you will need to do is to go to src/SQL/ and create the DB manually:

[rjs@dbhost SQL]$ mysql -utest_db -pPASSWORD test_db < create.tables.sql
[rjs@dbhost SQL]$ mysql -utest_db -pPASSWORD test_db < main.index.1

As long as your $PREFIX/conf/sources.config is correct (correct U/P for the object database, not the admin db), and the rip.conf has the admin DB specified correctly -- then the server should then start.

This was originally going to be an e-mail to ripe-dbm, but I seem to have fixed it during the course of writing the mail!

Last Friday, Andy Davidson, Jonathan Oddy, and I pushed out some research that has some quite worrying repercussions. Whilst I've heard from a lot of people privately about this matter, there's a big flaw here, and as Andy posted on his blog (which is much more informative than mine, I think!), this is a big problem.

The reason, I think, that we're getting limited public discussion of this exploit (I hesitate to call it an exploit, it's a flaw really, because it's actually a result of the RFC that the problem exists), is because the implementations of 4-byte AS support that are out there already are generally not standards compliant. Let's run down the list:

• Juniper - not standards compliant on this matter, some form of AS4_PATH and AS_PATH munge happens during processing, and the paths don't come out with the confeds in. I've verified this by looking at the updates via a Goscomb Technologies Juniper box - look at the monitor traffic output.
• Force10 - Greg Hankins has a test peering box running at route-server.cluepon.net, which shows the following
  

  Received from : 
    72.37.255.12  (72.37.255.1)    Best
      AS_PATH :  18508 19151 35320 196629 23456
  

  This looks to be doing the same thing as JunOS is doing, and ignoring the invalid parts of the AS4_PATH when building the AS_PATH.
• Cisco - IOS XR/XE - I've not yet confirmed this one, but I believe this doesn't have a standards compliant implementation either. I'm hoping to get some time with someone to discuss what they're seeing later tonight, or maybe later this week. I think that, given that we haven't heard anything, and there are likely to be _some_ SPs that are learning 91.207.218.0/23 via 35320, this is probably another platform that doesn't comply.
• Cisco - IOS - There's just one lonely IOS release that runs AS4 right now, and that's 12.0(32)S12. This is the IOS that we used to demonstrate how IOS reacts to the flaw in the RFC. When IOS sees AS_CONFED_SET in the AS4_PATH, it drops the session, as required by the RFC

Maybe there are a couple of interesting points here, why are most vendors not actually complying with this RFC, does this mean that they've spotted what Andy, Jonathan and I have reported on, and dropped this requirement? If this is the case, then I wonder, when IETF IDR is so full of people with @juniper.net, and @cisco.com addresses - why did this ever appear in the first place?

This is a serious flaw in the standards, and despite the fact that today, we reported on how the issue has actually come to pass, this is going to remain open, unless we fix the RFC.

The issue here is, with most (if not all) BGP attributes, there's almost an expectation that the immediate neighbour will sanity-check what their peer has sent - if it's one hop away, you can generally interact directly with that neighbour, and work out what the problem is, there's no-one harmed, as just one session is dropped, by two networks sharing some adjacency. A case in point of this, is the problem that we saw with Cisco not obeying the RFC relating to sending UPDATES before KeepAlives in BGP conversations (CSCsu84268). As far as I saw, this bug only affected directly connected neighbours, and hence there was no major impact. Now, let's consider what happens the case of the AS4_PATH problem we reported. AS4_PATH is optional transitive in BGP, hence, if you hand it to a non-AS4 speaker, the router will just transmit it along to the peers it advertises the route to. This is a reasonably neat solution, one would think, as AS4 information is transmitted, but it doesn't require every router in the path between two AS4 speakers to understand it, yet they can still get the same information as they could if the path was completely made up of AS4 speakers. Furthermore, by appending 23456 to AS_PATH, then even the non-AS4 speakers understand that there was some AS in this path. However, this also means that if I announce, to a non-AS4 speaker, a completely invalid AS4_PATH, they don't know anything about it, or the contents, and hence can't sanity check it. This results in me being able to tunnel my AS4_PATH across the internet.

Great, so now I've described, in some more chatty language, what we wrote on NANOG, and C-NSP. What does this mean to any operator? Well, if I take a prefix, originate it, and then announce it to the internet, then I can get the first AS4 speaker I find to tear down whatever session they learned my prefix on. If I combine this with injecting some ASNs into the path, so that some networks don't accept it (due to loop prevention), then I can probably work out a way to get _my_ copy of the update across to you. In IOS's logs, you can't even tell who originated that prefix, and it doesn't seem to show the whole AS_PATH/AS4_PATH either. Say I send two prefixes that you learn one via one transit provider, and the other via another, I'll disconnect your full table connectivity.

This isn't even a bug, this is a flaw in the standard. I'd really like to get this fixed, and the way to do that is to get a bunch of operator experience/views, and take it to the IETF. So, if this concerns you (or you're going to need to deploy a new point release -- like 12.0(32)S12 is, or maybe need hardware support with 12.2SRE...), please put some pressure on your vendor, or drop me a note at rjs@eng.gxn.net.

Further to my previous post - I presented this issue at LINX65 - video and slides can be found below.

Video
Fixed Slides - LINX's PowerPoint install seems to have corrupted my slides on the day.




Comments and feedback are most welcome.

A quick personal post to break the silence here!

I'm currently very interested in hearing about any UK or EU-based network engineering or architecture opportunities that are out there, especially in SP networks that run MPLS with TE. If anyone has some such opportunity, or knows of something that they think might suit me -- please drop me a mail to rjs@rob.sh for a copy of my CV.

An outline of my CV is available on LinkedIn.

I'm hoping to find some time to put some technical articles together that can be posted here in the near future.

For all network deployments, there is a requirement to present information relating to both topology, and various utilisation statistics to some human operator. In many cases, this process has become so ingrained in network requirements that there are almost ubiquitous solutions to the visualising data - for example, link utilisation is almost always presented via some framework or tool powered by RRDTool. Other tools, such as network "weathermap" diagrams linking this utilisation information into an overview of a network topology are also seen in many NOCs. In most cases, the problem of visualising data relating to a flat MPLS or IP network is solved for most common deployments.

The problem of data presentation is somewhat altered in the case of an MPLS-TE network. Whilst link utilisation graphs, and weathermap diagrams may continue to provide useful information, suddenly the overlaid tunnels within a network are of interest to operators. Whilst a first-line NOC engineer may not be aware of what is indicated by a certain LSR becoming a midpoint for a large number of tunnels within a network, this almost certainly identifies some form of failure, or congestion that should be reacted to. In addition to identifying events such as TE LSP path changes to particular nodes, it is often useful to retain some insight into the constraints within which CSPF is currently selecting paths for LSPs. In order to solve these problems, there's a requirement for an additional set of visualisation tools. In some cases, these tools may be implemented using existing visualisation tools - however, this often results in overly-complex presentations. The intent of this post is to outline some of the challenges, and interesting methods that appear to be available for presenting data relating specifically to MPLS-TE networks - a number of beta-quality solutions in use within AS5413 are presented, however, this post does not intend to define a complete solution.

In order to properly consider the available solutions to any visualisation problem, the data to be presented to an operator needs to be defined. Ideally, the information that is required by an operator is likely to include the following:

1. The path taken by specific TE LSPs throughout a network -- within an straight MPLS or IP network, it is likely that there is a relatively easy set of nodes through which traffic is forwarded, since within a TE deployment paths are dynamic according to constraints, rather than following the shortest-path, then the presentation of path information to a human is of operational benefit.
2. The resource consumption on any TE-enabled path -- this requirement is likely to include the presentation of resource utilisation over a specific link by reservations associated with a TE LSP. However, it should also view of the resources consumed by a specific TE LSP, both in terms of reserved bandwidth, and actual traffic forwarded in the interface
3. Efficiency of path selection across a MPLS-enabled topology -- in many cases, TE is deployed in order to ensure that service level guarantees are upheld. Since typically, these guarantees are made in terms of loss, latency and jitter, the effect of TE path selection on forwarding between specific points in a TE network is of interest to an operator. Where the 'efficiency' of path selection is referred to, this should be interpreted as the proximity of path selection in the network to the optimal path throughout a network (this should be assumed to be the shortest-path as would be selected typically by an IGP).

In order to address requirement 1 above - there are two types of visualisation tool that is of direct interest to an operator - a view based on a specific node, and a whole path view. For a specific LSP, a per-node view showing the egress interface for each LSP is relatively trivial to produce from the output of a command such as show ip rsvp reservation or similar. An example of this form of diagram (as produced by one of the tools built for AS5413 use) is below.

A significant limitation of producing static images such as the example above, is that it is difficult to visualise changes between egress interfaces. The node in the example is a midpoint for a small number of nodes running MPLS TE - during the time at which the example output was gathered, a small number of test PEs had been deployed with automatic bandwidth adjustment on each TE LSP, and hence the number of TE reservations is relatively small. In order to determine egress paths for each LSP on the node, and hence determine the cause of any imbalance across equal-cost paths, a diagram such as this can be useful. However, to properly view the changes in paths over time, a relatively large number of diagrams of this nature need to be examined. It is likely that a better result would be achieved by having some form of dynamically updating graphic representation.

The second type of diagram requires a topological view of the network - it is almost impossible to represent all TE paths for which a specific node is the head-end in a network on a single diagram whilst retaining a clear, easy-to-parse image. Producing per-LSP diagrams is possible, but again produces some difficulty in representing the changes of path for an LSP. Diagrams can quickly become convoluted if all possible paths are included. For example, the diagram below shows all possible NHOP and NNHOP LSRs for a specific node within the AS5413 network topology. Where there is a secondary device via which all nodes can be seen, the topology becomes relatively complex very quickly. The problem of finding a computational method to produce layouts that are clear for human interpretation is relatively complex, with Graphviz being the standard OSS tool utilised for this purpose.

Should there be a requirement to scale a diagram such as the example above to show all possible nodes via which a TE LSP may be routed, and overlay the actual path taken, then a large number of diagrams are likely to be required. In addition, the information presented to an human is unlikely to be easy to parse. Again, a requirement would appear to exist for dynamic means of displaying information, and the ability to adjust an image to show specific nodes or paths of interest would be advantageous.

The second requirement in the list above is somewhat easier to solve, as it mirrors existing visualisations that are utilised for a straight IP/MPLS network. A weathermap-type topology diagram, where each link is marked according to the reservations made on it can easily display information relating to the size of reservations on specific interfaces. Additional information can be shown in such a topology diagram by adjusting the display of specific nodes to reflect the number of LSPs carried. Such a solution can be implemented with relatively minor changes to existing tools such as Network Weathermap. It should be noted that this is likely to require human interaction to develop a set of topologies with a network that are of interest to those using such a weathermap - for instance, certain NOC engineering teams may require specific topologies - or specific subsets of nodes. Displaying every PE within a relatively large network on a single diagram is unlikely to provide useful information to an engineering team.

To monitor SLGs within a network (as per the third requirement above), typically, some form of graphing of an IP SLA probe, or some end-to-end ICMP graph (via a tool such as SmokePing) is used. It is likely that such implementations can continue to be utilised to support SLAs. However, the problem of displaying efficiency of path selection within a network is not as trivial to solve, and indeed is unlikely to ever be a requirement in a network where a packet is routed according to an SPF algorithm. This is not something that has been implemented within AS5413 currently, however, it would appear that some interesting approaches do exist - for example, Karol Kowalik and Martin Collier from Dublin City University present an eye-diagram approach to displaying the efficiency of path selection throughout a TE network. Within their paper, they note that this approach does not scale easily to TE networks above 30 nodes, however, since there appears to be no open reference implementation for this method, it hard to evaluate its performance. This paper appears to be one of the few approaches to showing path efficiency through a TE network that has been discussed.

The post's intention, as discussed, is to present the small number of solutions, and their limitations that have currently been implemented at AS5413 - clearly, these tools are not production quality, or complete at the current time. If there is interest in providing a non-commercial solution (as an alternative to solutions like OPNET, and the Cisco TE tools) that provides information for small to medium SPs, where such an investment does not seem justified, then there may be a possibility to push some collaborative OSS visualisation tools. If you, or your organisation have any such interest, please let me know via the comments.

I've had a couple of mails relating to this PSN, which again references the research that Andy Davidson, Jonathan Oddy and I did last year. It seems that some of the sources of the initial mailing list posts we made are gone (particularly the merit.edu one that is referenced from both Juniper's site and most other places). For that reason, I've included both the mails that we sent to NANOG/C-NSP/J-NSP last year here.



In addition to this - it looks like there's some fairly interesting coverage of another Juniper PSN at this blog.

After a late programme committee request, I presented on "Enhancing BGP" at UKNOF 16. The presentation was intended to be an update on the current drafts in the IDR working group, and give some encouragement to operators to get involved, and contribute.

I'll put the video up when the Tom at PortFast and Brandon of Bogons have done their excellent job on it. For the meantime, the slides are linked below.

There's also a good add-paths presentation that John Scudder and Dave Ward gave at NANOG here

So, if we take a moment to look at the following responses to questions that the leaders of the three parties involved in the "Digital Debate" on YouTube gave, concerning the Digital Economy Bill: Sure, we get some tired old rhetoric, as expected. However, the key point here is that both Labour and the Conservatives appear to believe that they've done the right thing with this bill. Combine this with the fact that Gordon Brown mentioned a broadband rollout as part of the few ideas that he could during one of the debates, and I think that it starts to become apparently that politicians do not understand the UK "Internet" industry. Where there can be comments as to who is being "looked after" by each party (Cameron even mentions that the bill is most important for the media producers (or 'rights holders")) - I think the problem here is that politicians in the UK fundamentally do not understand how this industry operates. I think increasingly we are going to see the UK fall behind in terms of what we can roll-out due to impractical over-taxation, and ideas such as those put forward in the DEA.

Looking simply at two issues:

1. Fibre Taxation - in the UK, if a business is to light up a fibre pair, as well as any standard taxes (e.g. VAT) that must be paid, then an additional VoA Business Rate is due on these fibres. This can be up to £500/pair/year outside of London, and £600/pair/year in the London metro region [source: Valuation Office Agency].
   
   Let's look at what this does for the telecommunications industry in the UK, especially for small players. Since such a company probably does not have a DWDM system, then the relatively cheap fibre runs are now taxed quite highly, should such a company then want to start increasing their capacity, then the additional costs are inflated due to taxation. Where larger players might be able to split these rates over a large number of DWDM channels (up to 32 or 64) a smaller provider might only have one channel - and hence the cost of infrastructure or customer links for smaller companies is inflated, due to the fact that they cannot justify the CapEx required for such multiplexing systems. Even for larger players, this isn't encouraging large scale fibre build out. If tax is paid per route-KM for every FTT{H,P,C} deployment, then this adds an additional overhead (in avoidable taxation!) to any such roll-out. Hardly an incentive for a commercial entity to begin such a deployment! Alongside the CapEx, OpEx, and business rates you are required to pay - the UK government will tax you just for lighting up the infrastructure they are encouraging you to build! This alone is not helping with any of the three party's plans for any kind of broadband roll-out, especially to rural areas where there is no profit for commercial entities to roll out such technologies.
2. Digital Economy Act - Andrew Cormack of JANET (UK) gave an excellent presentation at UKNOF relating to the DEA. There are two key points here:
   • The government (and apparently the Tories) believe that this bill being pushed through in "wash-up" was the right thing to do. Contrast this with the fact that they also appear to be stating that the digital economy (and communications that such an economy provides) is key for Britain. I agree it's key, we're a services based economy, and if more services can be provided utilising the Internet, then one of two things will happen. Either the UK will not be equipped to deliver such services globally, and the "Digital Economy" will mean that these can then be out-sourced to other countries - or the UK will be in a position to grow the services that it can deliver, with the considerable skill of the UK workforce, into both global and European markets. Any bill therefore, that affects the manner in which this "Digital Economy" (by which I'm now referring to ISPs and telcos), should therefore, one would have thought, justify reasonable debate by the fully attended (?!) Commons!
   • Westminster appears to have no idea as to who they are legislating for. I am not against ensuring that the creative industries are able to protect their rights - however, this needs to be done in a manner that can be policed without damaging another industry. As Andrew said in his presentation the Government is unsure of how many ISPs are in scope - stating it could be 5, 10, 20 or 450. How can the impact of legislation be considered, if the Government cannot identify the scope? In addition, whilst many rights holders, I would imagine, will say "well, there is very little that is being requested of the ISPs here!" - the technical challenges of implementing mechanisms whereby specific IP addresses, and users can be located, within the timeframes that such complaints appear to take to be progressed, should be costed. I believe that most people within the xSP industry are not going to say "We don't care about your rights as a content producer", however, how can the Government expect our industry to pay directly to police this? We don't care that customer X is pulling data A, B and C - really, once it comes down to working in a larger ISP, we care about getting bit X to endpoint Z whilst ensuring any commercial guarantees that we have made for bit X.
   Another concern following these points is that it appears that very few of the UK ISP industry are being directly consulted here. Whilst there may be involvement - it's not something that I have seen mention of particularly amongst smaller ISPs in the community. Government should remember that legislation such as this affects all enterprises within this sector, and hence should consider them. The role of incumbents within this country already affects the delivery of many services, we don't need further legislation to push things further into their favour.

The reason I feel the need to mention this, is that it aggravates me whilst seeing responses such as the above. Politicians cannot absolve themselves of blame for such issues being pushed through in what I feel is quite an undemocratic manner. I'm still not sure who I am going to vote for - but as far as I see it, the huge lack of understanding of the industry within which I work will mean that whoever is in power during the next Parliament will likely not be in the right place to make legislation that actually takes into account how this industry works. Because of this, the UK's economy will suffer - which is a great shame.

Checking out a few videos that people have linked me to recently I thought that this piece was amazing - really great speed. It also looks like the 5D and 7D are really quite awesome at doing 60fps HD! The video presentation over at vimeo is really cool too!