I know of one large-ish provider that does it exactly like that - RIPv2 between POP edge routers and provider-managed CPE. In addition to the simplicity, it lets them filter routes at redistribution without having to fiddle with inter-area OSPF (or, ghod forbid, multiple OSPF processes redistributing between each other...)
Where folks run into trouble is vendors that decide that RIP is so under-utilized they don't need to fully support or QA it anymore. Implementations tend to be a bit more..."quirky" than OSPF or BGP running on the same box. And occasionally you run into the odd vendor that doesn't care about things like being able to adjust hello/dead intervals... -C On Sep 29, 2010, at 2:50 PM, Jonathon Exley wrote: > RIP is useful as an edge protocol where there is a single access - less > system overhead than OSPF. > The service provider and the customer can redistribute the routes into > whatever routing protocol they use in their own networks. > > Jonathon > > -----Original Message----- > From: Jesse Loggins [mailto:jlogginsc...@gmail.com] > Sent: Thursday, 30 September 2010 9:21 a.m. > To: nanog@nanog.org > Subject: RIP Justification > > A group of engineers and I were having a design discussion about routing > protocols including RIP and static routing and the justifications of use for > each protocol. One very interesting discussion was surrounding RIP and its > use versus a protocol like OSPF. It seems that many Network Engineers > consider RIP an old antiquated protocol that should be thrown in back of a > closet "never to be seen or heard from again". Some even preferred using a > more complex protocol like OSPF instead of RIP. I am of the opinion that > every protocol has its place, which seems to be contrary to some engineers > way of thinking. This leads to my question. What are your views of when and > where the RIP protocol is useful? Please excuse me if this is the incorrect > forum for such questions. > > -- > Jesse Loggins > CCIE#14661 (R&S, Service Provider) > This email and attachments: are confidential; may be protected by > privilege and copyright; if received in error may not be used,copied, > or kept; are not guaranteed to be virus-free; may not express the > views of Kordia(R); do not designate an information system; and do not > give rise to any liability for Kordia(R). > >
