more specific routes in today reality
Vladimir A. Jakovenko vovik at lucky.net
Tue Oct 9 15:02:08 CEST 2001
On Tue, Oct 09, 2001 at 12:15:57PM +0200, Gert Doering wrote: >Hi, > >On Tue, Oct 09, 2001 at 01:10:49PM +0300, Vladimir A. Jakovenko wrote: >> According to my observations at least since this summer the RIPE NCC staff >> promotes usage of more specific PA routes (originated by more than one AS) >> for multihomed customers opposite to the "classic" scheme with PI addresses >> (or new enterpise LIR ;-). >> >> In this situation we are going to expect increase of ammount of: >> >> 1. Routes with more than one origin. > >No - the more specifics are announced by the customer AS *only* (and the >upstream AS that this blocks belongs to will permit them "through"). We are talking about different types of multihoming. I mean simple multihoming situation when all multihomed customer's needs in routing are covered by they upstream providers routing policies. In this situation more specific PA route can be originated by upstreams without allocation to customer new AS-num. Moreover, according to ripe-185: In order to help decrease global routing complexity, a new AS Number should be created only if a new routing policy is required. >> 2. Less specific routes within existing more specific. > >Yes. > >> Actual (ripe-185) document of "IPv4 and ASN Policies in the RIPE NCC Service >> Region" and working draft (on http://www.ripe.net/rs/ipv4policy.html) >> refer to rfc1930 which contains section 7 - "One prefix, one origin AS": > >Yes, but this is a non-issue here. Why? >[..] >> According to measurements on RIPE DB dump on Oct 4 there were about 17% of >> prefixes with more than on origin AS. It isn't just RIPE specific - >> measurements from other IRRs are close. > >This is well possible, but not a necessity for this type of multihoming - >to the contrary, in most cases it's a mistake or a transitional thing. I do not believe that the most of them are errors. Yes, not all of them was created for multihoming purposes (don't forget about incoming-channel load balancing :), but amount of multihoming part (on my opinnion) are increasing. >> Announcement of less specific routes within existent more specific route >> (lets assume that there is no bgp routing process misconfiguration - both, >> less and more specific, routes have route objects) clashes with an aggregation >> issues promoted in many RIPE documents. > >Yes, but looking at the overall table, it's beneficial. > > - you have the same amount of routes as with "small PI", so it's not worse Agree. > - if one is filtering "no /24's", the end site is *still* be reachable, > which would not work with PI space. Disagree. During last time a number of routing curioses at least in our country have been caused by incorect announcements or filtering more specific routes within already announced less specific routes. If you want, I can describe some of the most common problems. PI addresses have its own set of problems, more specific PA addresses also have own set problems. This sets partly overlaps, but not same. And PA more specific isn't safer than PI. They just unsafe a bit more different. >[..] >> Unfortunately it is difficult to dispute such policy unactuality without >> appropriate documents. Is it possible at least "to legalize" applicability >> of more specific routes with more than one origin for multihoming purposes >> in ripe-185 successor? > >RIPE has no power about *routing*. But there has been talk on the last >meeting about writing a BCP concerning routing issues and recommendations >(I have no idea what the state of this is or whether anybody is working >on it). RIPE has the power to make recomendations and publish documents. RIPE NCC has the power in ip address space allocation. Good practice for people who make decisions in this region is to take into consideration RIPE recomendations. If RIPE NCC are going to propose usage of more specific routes for multihoming why not to cover that technique with all pros and cons in appropriate documents? -- Regards, Vladimir.
[ lir-wg Archives ]