more specific routes in today reality
Vladimir A. Jakovenko vovik at lucky.net
Tue Oct 9 20:41:58 CEST 2001
On Tue, Oct 09, 2001 at 07:19:35AM -0700, Randy Bush wrote: >> 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. > ^ >note the use of plural above. now read rfc 1930. Randy, rfc1930 consists of 563 lines. I suppose you are talking about: line 287: * Unique routing policy An AS is only needed when you have a routing policy which is different from that of your border gateway peers. Here routing policy refers to how the rest of the Internet makes routing decisions based on information from your AS. See "Sample Cases" below to see exactly when this criteria will apply. line 323: * Multi-homed site Here multi-homed is taken to mean a prefix or group of prefixes which connects to more than one service provider (i.e. more than one AS with its own routing policy). It does not mean a network multi-homed running an IGP for the purposes of resilience. An AS is required; the site's prefixes should be part of a single AS, distinct from the ASes of its service providers. This allows the customer the ability to have a different repre- sentation of policy and preference among the different service providers. This is ALMOST THE ONLY case where a network operator should create its own AS number. In this case, the site should ensure that it has the necessary facilities to run appropriate routing protocols, such as BGP4. Also I think we should pay attention to rfc1930 header: line 10: Category: Best Current Practice line 11: March 1996 line 14: Guidelines for creation, selection, and registration of an Autonomous System (AS) Lets make some logick based on hypotetical situation with ISP (LIR) Network Engineer, Regional Internet Registry and the customer. ISP customer wants to be multihomed mostly for the following reason - resilience in the case of upstream failure (for my experience - on of the most common reasons). Yes, customer already tried to change: - ISP, - equipment, - technical staff. But hadn't reached enough resilience level. They technical and marketing staff considered that without multihoming they can't achieve sufficient resilience level. They don't ready to pay for Enterprise LIR because they know about PI. They asked ISP to help them to obtain PI block and AS num. With ISP Network Engineer assistance they filled in ripe-219. Network Engineer sent it to Regional Internet Registry. After some amount of time Regional Internet Registry staff replied to original request with something like: "They are aware that they can be multihomed with only PA space? Two or more LIRs can announce these address spaces if you discuss it with them, they don't even need an AS number. I don't quite understand why they feel the need to have PI space and all the problems that this will cause them. In addition if they ever have plans to expand in the future and need more address space they are going to have more trouble. I would suggest that you discuss this with them to see if they still want PI space. Finally, we are strict regarding the actual amounts of address space that customers request as there is a tendency to ask for more than is actually required, due to their agregation concerns." Lets imagine, that all customer uplinks are not against from such solution (there isn't any public IX-es, Telecom's, etc). After that please take a look at quoted lines from rfc1930. Who is reponsible for IP address space and AS-num allocation in LIR geographical region? RIR. If - RIR decided that multihomed customer (generaly) don't need separate AS-num - RIR routing database contains 17% of route objects with more than one origin (while rfc1930 defines it as exceptions) should Network Engineer think that: 1. Covered in rfc1930 "Best Practice" is a little bit outdated? 2. Meanings of "Multi-homed site", "Unique routing policy" and "resilenece" terms had been changed since 1996? 3. Something else? -- Regards, Vladimir.
[ lir-wg Archives ]