as-in/as-out
Daniel Karrenberg
Wed Apr 27 18:50:54 CEST 1994
> 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 ---------
[ rr-impl Archive ]