Hierarchical authorisation failed, request forwarded to maintaine r ???

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