RIP Justification

Now, when traffic comes from head office destined for a site prefix,
it hits the provider gear. That provider gear will need routing
information to head to a particular site. If you wanted to use
statics, you will need to fill out a form each time you add/remove a
prefix for a site and the provider must manage that. Its called a
'pain in the arse'.

Enter RIPv2.

Or BGP. Why not?

Of course, technically you could use almost any routing protocol.
OSPF and IS-IS would require more configuration and maintenance, BGP
even more still.

I think this is a pretty good example though of how RIPv2 is probably
the most appropriate for the job. It doesnt require further
configuration from the provider side as new sites are added and is
very simple to set up and maintain.

Tim hit the nail on the head. Maintaining statics on a large network would become a huge problem. Human error will eventually occur. The network scenario I am speaking of is DSL/Cable type setups, where a customer could move from router to router(DSLAM/CMTS) due to capacity re-combines. Utilizing a dynamic routing protocol makes these types of changes easier to digest.

Using BGP would be overkill for most. Many small commercial customers to not want the complexity of BGP or want to spend money on extra resources (routers that actually support it) Sure for someone that needs to announce their own space or wants multi-homed connection def use BGP.

-Ruben

Tim hit the nail on the head. Maintaining statics on a large network would become a huge problem. Human error will eventually occur. The network scenario I am speaking of is DSL/Cable type setups, where a customer could move from router to router(DSLAM/CMTS) due to capacity re-combines. Utilizing a dynamic routing protocol makes these types of changes easier to digest.

Just to be perfectly clear with the scenario I was referring to (L3VPN
with all remote sites hitting provider router) that Tim was responding
to.. The kit is all managed - customer has no access to it. I should
have mentioned that before, as it's a pretty key point to the example,
perhaps it was thought the customer could touch it?

What is needed is simply one step above statics so the provider does
not have to maintain them. Loops or hop count are a non-issue, and the
customer sites have no redundancy. It's not even a requirement to have
fast convergence.

All that is required is to have the CPE say 'here is 10.0.0/24', or at
a later date, '10.0.1/24' without any work on any other equipment.
Nice and easy. RIPv2.

Arguing that BGP should be used over RIPv2 in this scenario becomes
interesting, as BGP would offer no real advantages and requires
further configuration in most cases for each site deployed. It also
introduces more overhead for the carrier, the same with OSPF and
IS-IS.

In other scenarios - of course choose a different protocol - but for
this one, I think its a good example for the OP as to why RIPv2 is
still used.

It also scales better from the SP point of view. If you have 1000 L3VPN services on your PE node using OSPF to the customer that would require a lot of memory for the multiple LSDBs and a lot of CPU for the SPF calculations.
BGP is nicer but the reality is that many enterprises don't have the know-how.

Jonathon

The knowhow for BGP in that environment is all of about 30 minutes worth of
training. They should find a way to get it, IMHO.

Owen