Digital Economy Bill YouTube Questions

         imported      Tech · ISP · UK

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.

UKNOF 16: Enhancing BGP

         imported      Tech · Work · BGP · IETF · UKNOF · Presentations

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

Juniper PSN-2010-01-626 (AS4 Again!)

         imported      Tech · ISP · Cisco · JunOSe · BGP · IOS · JunOS

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.

Visualising MPLS-TE Networks

         imported      Code · Tech · MPLS · MPLS_TE

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.

Network Updates and Opportunities

         imported      Tech · Work · ISP

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.

LINX 65 Presentation

         imported      Tech · Work · ISP · LINX · Cisco · Code · BGP · IETF · Presentations

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.

32-bit AS numbers introduce a new BGP flaw.

         imported      Tech · Geek · ISP · Cisco · BGP · JunOS

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:

Building the RIPEDB server

         imported      Tech · Work · ISP · RIPE

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:

IPv6 - It *Doesn't* Just Work.

         imported      Tech · ISP · IPv6

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.

ic.ac.uk fetchmailrc Settings

         imported      ic.ac.uk · Tech

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.