AS 690 aut-num progress (LONG!!!)

In message <199503171630.LAA02552 at home.merit.edu>, "Dale S. Johnson" writes:
> Curtis,
> 
> > There is one problem for which there is no way to express the
> > requirement in ripe-181.  There is no way to specify an as-in line
> > (which is required and has no means restrict to specific peers) and no
> > way to specify that certain destinations are not accepted at all at
> > some peers using interas-in or as-in lines.  This is need where we
> > peer with someone at two interconnects, accept one as primary and
> > don't accept the same set of routes from the other peering at all.
> 
> There is a hack Cengiz came up with:
> 
> Create a fake interas-in line for a non-existant interface, and give
> that line the same policy as the as-in line.  (The current AS690 object
> in the RADB does this using local IP 0.0.0.0/32).  That way any code
> following the spec will say "Ok;  everything is accepted through the
> non-existant interface;  I guess the other interfaces accept only
> what they explicitly list".
> 
> --Dale


Does this really do the trick?  The problem is:

  as-in: from ASx 1 accept { x.y.z/24 }
  interas-in: from ASx 1.2.3.4 1.2.3.5 (pref=1) { x.y.z/24 }

  ?? interas-in: from ASx 2.3.4.5 2.3.4.6 (pref=NONE) { x.y.z/24 }

  ?? interas-in: from ASx 0.0.0.0 0.0.0.0 (pref=1) { x.y.z/24 }

The first makes sense to me.  Router 2.3.4.5 does not accept x.y.z/24.
The second doesn't make sense.  

If router 1.2.3.4 accepts x.y.z/24, does that mean no other router
does?  If so, then this is a non-problem.  On rereading, this appears
to be the case.

Also in the object I sent, "except" should have been "AND NOT" when
used in the format "accept ASx AND NOT { x.y.z/24 }".

Curtis




-------- Logged at  Fri Mar 17 23:08:51 MET 1995  ---------