On 2002-10-14 10:37:37 +0200, Gert Doering wrote:
Hi,
On Mon, Oct 14, 2002 at 10:23:14AM +0200, Shane Kerr wrote:
Most objects are uniquely identified by the first attribute, or "route:" in this case. However, you must include the "origin:" attribute for a route object. So this is:
route: 143.58.120.0/22 origin: AS3320
The object you are trying to create will be:
route: 143.58.120.0/22 origin: AS8220
Shane, your explanation is confusing me. There are other examples with "same route, different origin AS" in the RIPE-DB (check 194.97.0.0/16), which is sometimes necessary while migrating a network to a new origin AS.
So the database should permit entry of this *new* object, instead of checking for modification permission on the *existing* object.
We currently implement RPSS, as best we understand it. I think the idea is that if there is a route object in the database, then it's creation has been authorised, and that it represents an actual route announcement. If somebody else starts advertising either the same IP space with a different origin, or a more specific route then it will affect traffic to the existing origin, so they should approve the creation. Given this explanation, do you still think that the database should permit the creation of the new object? The reality is that route checking is not 100% clear in the RPSS document, RFC 2725. For instance, when creating a route it is possible to have multiple parent routes with the same prefix, and it is not specified what the behaviour is. I believe it was decided not to look at this too carefully because some people in the IETF have decided that advertising the same prefix from multiple origin AS numbers is bad, and the authors of the document wanted to avoid a flame-war or even having the document rejected over this issue. -- Shane Kerr RIPE NCC