as-in/as-out

> epg at merit.edu writes:
> We had been using the inetnum object to represent classless/aggregates;
> but that may be a problem for you all since you also need it for
> network assignment/allocation. Have you thought about using inetnum
> for the classless/aggregate object or were you leaning toward creating
> a new object?
Here is our current thinking written up.
It is not as long as it seems and it leaves a lot of open points.
Comments are very much appreciated!
Daniel
Major Rework of the RIPE Routing Registry
dfk
mt
tb
Scope
This is a proposal to achieve the following objectives
w.r.t. the RIPE database.
- Separate the allocation and routing registry functions
into different objects. This will facilitate data
management if the Internet registry and routing regis-
try functions are separated (like in the US). It will
make more clear what is part of the routing registry
and who has authority to change allocation vs. routing
data.
- Add the possibility to specify aggregated routes in the
Routing Registry. This is necessary because aggrega-
tion information is necessary for network layer troub-
leshooting. It is also necessary because aggregation
influences routing policies directly.
This proposal does not address the syntax of a classes
address. It just assumes that the "/bits" syntax will be
one of the alternatives.
The Route Object
There will be a new object describing a single route ori-
ginated by and Autonomous system into the Internet routing
mesh. It will have the following attributes:
- 2 -
route: [mandatory] [single]
origin: [mandatory] [single]
component: [optional] [multiple]
comm-list: [optional] [single] [guarded]
descr: [mandatory] [multiple]
remarks: [optional] [multiple]
notify: [optional] [multiple]
maintainer: [optional] [single]
changed: [mandatory] [multiple]
source: [mandatory] [single]
Example:
route: 193.0.2/23
origin: AS1234
component: 193.0.2/24 AS1111
component: 193.0.3/24 AS2222
descr: XYZ campus aggregate
changed: dfk at ripe.net 940427
source: RIPE
The value of the route attribute will be a classless
address. It represents the route being injected into the
routing mesh.
The value of the origin attribute will be an AS reference of
the form AS1234 referring to an aut-num object. It
represents the AS injecting this route into the routing
mesh. This reference provides all the contact information
for this route.
The value of the component attribute will be a classless
address followed by an AS reference. The component attri-
butes represent the components which make up the route.
Components in the same AS as the origin need not be listed.
[There is some discussion needed if we should provide a pos-
sibility to list holes and whether this should be mandatory.
dfk thinks it should] Note that the components do not need
to appear as their own route objects if they are not ori-
ginated somewhere themselves.
The rest of the attributes are analogous to the inetnum
object.
Conceptually there can be multiple route objects with dif-
ferent origins. Representing multiple proxy aggregation
which to our knowledge is not done in the Internet yet. We
have not thoroughly investigated the consequences this added
complexity will have for consistency checking and the PRIDE
tools.
- 3 -
Update process for the route object
Adding a route object will be guarded by the AS guardian
files. A route object will only be added if the classless
address value of the route attribute will appear in the
guardian file of the origin mentioned. This guarantees that
an AS has full control over the routes it announces.
Any AS added or deleted from the components of a route
object will be notified of the event by e-mail to the AS
guardian. This guarantees that ASes are notified if some of
their address space gets aggregated somewhere.
Any community added or deleted from the comm-list of a route
object will be notified of the event by e-mail to the com-
munity guardian.
Changes to the inetnum object
The inetnum object will only represent the assignment of
address space to an organisation.
The following attributes will be deleted from the inetnum
object:
Obsolete:
connect: [optional] [single]
routpr-l: [optional] [single] [guarded]
bdrygw-l: [optional] [single] [guarded]
nsf-in: [optional] [single]
nsf-out: [optional] [single]
gateway: [optional] [single]
Moved to the route object:
aut-sys: [optional] [single] [guarded]
comm-list: [optional] [single] [guarded]
Representable as components of a route to the DMZ:
ias-int: [optional] [multiple]
Consequences for specifying routing policy
Suppose the following universe:
- 4 -
route: 193.0.2/24
origin: AS1111
descr: XYZ Institute 1
changed: dfk at ripe.net 940427
source: RIPE
route: 193.0.3/24
origin: AS2222
descr: XYZ Institute 2
changed: dfk at ripe.net 940427
source: RIPE
route: 193.0.2/23
origin: AS1234
component: 193.0.2/24 AS1111
component: 193.0.3/24 AS2222
descr: XYZ campus aggregate
changed: dfk at ripe.net 940427
source: RIPE
If someone now says:
aut-num: AS9999
...
as-in: AS8888 100 AS1111
they will only allow
193.0.2/24 in.
aut-num: AS9999
...
as-in: AS8888 100 AS1234
will only allow 193.0.2/23 in and not the more specific com-
ponents.
aut-num: AS9999
...
as-in: AS8888 100 AS1234 AS1111 AS2222
will allow everything in.
Now if we have
aut-num: AS9999
...
as-in: AS8888 100 AS1111
and the more specific route 193.0.2/24 will be withdrawn and
the corresponding route object deleted AS9999 will have lost
connectivity to AS1111 unless AS9999 also takes AS1234. We
will have to have tools that warn about situations like
that.
-------- Logged at Wed Apr 27 19:40:40 MET DST 1994 ---------