Hi Sascha, I agree that it works, no problem with that (it even works with the same announcement in different ASes, though it is clearly not nice at all...). But the whole point of PA address space is to avoid having zillion of small blocks lying around. If a customer can use PA address space the same way as PI, what's the point of making a difference? Note also that in the case of a multi-homed customer not using BGP, the route would indeed appear in multiple ASes, and would require the other ISP to announce its whole PA block _and_ the more specific for load-sharing to occur... It looks to me like it should be prohibited to announce parts of a PA block. If the customer needs to announce addresses via multiple providers, he should switch to PI, shouldn't he? Jacques. --- Jacques Caron PSINetworks Europe Network Engineer PSINet Europe Regional Peering Coordinator Mail: Rue Friz-Courvoisier 103 - CH-2100 La Chaux-de-Fonds Phone: +41 32 967 5418

The only thing that is definitely not allowed due to bgp4-specifications is to announce the same prefix from different origin-ASes.

this is not bgp spec. it is rfc 1930, see appended, and is not a MUST NOT. randy 7. One prefix, one origin AS Generally, a prefix can should belong to only one AS. This is a direct consequence of the fact that at each point in the Internet there can be exactly one routing policy for traffic destined to each prefix. In the case of an prefix which is used in neighbor peering between two ASes, a conscious decision should be made as to which AS this prefix actually resides in. With the introduction of aggregation it should be noted that a prefix may be represented as residing in more than one AS, however, this is very much the exception rather than the rule. This happens when aggregating using the AS_SET attribute in BGP, wherein the concept of origin is lost. In some cases the origin AS is lost altogether if there is a less specific aggregate announcement setting the ATOMIC_AGGREGATE attribute.

Philip,

My interpretation of "generally should belong to one AS" does not equate to "MUST NOT be announced by more than one AS".

Not commenting on the rights and wrong, but if this is really a "MUST NOT" it needs to be documented as such.

Somewhere in Basham Halabi's "Internet Routing Architectures" (Cisco Press) he mentions that two different origins for a prefix is an "illegal configuration". Unfortunately I just can't find the exact phrase in the book. Anyway, I am sure that announcing the same prefix under 2 different origins should work although I never did something like this.

philip

Let's further discuss this at ripe-37. Regards, Sascha

--

At 02:59 01/09/00 +0900, Randy Bush wrote:

...

...

The only thing that is definitely not allowed due to bgp4-specifications is to announce the same prefix from different origin-ASes.

this is not bgp spec. it is rfc 1930, see appended, and is not a MUST NOT.

randy

7. One prefix, one origin AS

Generally, a prefix can should belong to only one AS. This is a direct consequence of the fact that at each point in the Internet there can be exactly one routing policy for traffic destined to each prefix. In the case of an prefix which is used in neighbor peering between two ASes, a conscious decision should be made as to which AS this prefix actually resides in.

With the introduction of aggregation it should be noted that a prefix may be represented as residing in more than one AS, however, this is very much the exception rather than the rule. This happens when aggregating using the AS_SET attribute in BGP, wherein the concept of origin is lost. In some cases the origin AS is lost altogether if there is a less specific aggregate announcement setting the ATOMIC_AGGREGATE attribute.

--- Sascha E. Pollok Internet Port Hamburg Technical Staff / Network Operations Grosse Reichenstrasse 27 D-20457 Hamburg Germany Tel.�� +49 (0)40 37 49 19-0 Fax��� +49 (0)40 37 49 19-29 Email: sp@iphh.de ICQ #38955239

...

Somewhere in Basham Halabi's "Internet Routing Architectures" (Cisco Press) he mentions that two different origins for a prefix is an "illegal configuration". Unfortunately I just can't find the exact phrase in the book.

Anyway, I am sure that announcing the same prefix under 2 different origins should work although I never did something like this.

Indeed, it happens today, and my guess is that it works, or networks wouldn't do it (not necessarily a valid assumption, I know). :)

Shane

This can probably be made to work, but it is quite easy to create a routing loop, as by default an external BGP learnt route is preferred (admin dist) over an iGP or iBGP: so provider 'A' would prefer to route via provider 'B', rather than via the direct customers interface. This can be got around by not carrying this route in IGP, but only in iBGP with local preference higher than any eBGP peerings. i.e. carry customer static routes in iBGP with your highest local-prefernce. Which is usually the best way anyhow. Both providers would need to implement it this way, or one provider would end up carrying all the traffic. Not that I have tried this, just thought it ought to work. It's getting a bit away from the original question ... -- ---- Steve Alvey Email: steve.alvey@ip-engineering.bt.com Global IP Design Specialist