here's as far we have got.
Gilles Farrache
Tue May 24 18:41:26 CEST 1994
Tony, I still do not understand the goal of "component". This component lead to a very complicated mechanism of guardians. Why is it no simplier to have multiple route objects ? Let's take the example given in the document : >inetnum: 192.87.45.0 >netname: RIPE-NCC >descr: RIPE Network Coordination Centre >descr: Amsterdam, Netherlands >country: NL >admin-c: Daniel Karrenberg >tech-c: Marten Terpstra >connect: RIPE NSF WCW >aut-sys: AS3333 >comm-list: SURFNET >ias-int: 192.87.45.80 AS1104 >ias-int: 192.87.45.6 AS2122 >ias-int: 192.87.45.254 AS2600 >rev-srv: ns.ripe.net >rev-srv: ns.eu.net >notify: ops at ripe.net >changed: tony at ripe.net 940110 >source: RIPE >will be distributed over two objects: >inetnum: 192.87.45.0 >netname: RIPE-NCC >descr: RIPE Network Coordination Centre >descr: Amsterdam, Netherlands >country: NL >admin-c: Daniel Karrenberg >tech-c: Marten Terpstra >rev-srv: ns.ripe.net >rev-srv: ns.eu.net >notify: ops at ripe.net >changed: tony at ripe.net 940110 >source: RIPE >route: 192.87.45.0/24 >descr: RIPE Network Coordination Centre >origin: AS3333 >comm-list: SURFNET >component: 192.87.45.80/32 AS1104 >component: 192.87.45.6/32 AS2122 >component: 192.87.45.254/32 AS2600 >changed: dfk at ripe.net 940427 >source: RIPE The inetnum object can be split in four object : inetnum: 192.87.45.0 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands country: NL admin-c: Daniel Karrenberg tech-c: Marten Terpstra rev-srv: ns.ripe.net rev-srv: ns.eu.net notify: ops at ripe.net changed: tony at ripe.net 940110 source: RIPE route: 192.87.45.0/24 descr: RIPE Network Coordination Centre origin: AS3333 comm-list: SURFNET changed: dfk at ripe.net 940427 source: RIPE route: 192.87.45.80/32 descr: RIPE Network Coordination Centre origin: AS1104 changed: dfk at ripe.net 940427 source: RIPE route: 192.87.45.6/24 descr: RIPE Network Coordination Centre origin: AS2122 changed: dfk at ripe.net 940427 source: RIPE route: 192.87.45.254/24 descr: RIPE Network Coordination Centre origin: AS2600 changed: dfk at ripe.net 940427 source: RIPE The sofware (whois or anything else ) will describe very easily the components of the route. It also allow easy cross-check as describe in page 17 for route object update procedure. In this case we have no problems of community added on components. The only problem remainig is the "HOLE" problem. Why not add an attribute on the route object called hole. In this case my proposal for the route object will be : Appendix D - Syntax for the "route" object. There is a summary of the tags associated with community object itself and their status. The first column specifies the attribute, the second column whether this attribute is mandatory in the commun- ity object, and the third column whether this specific attribute can occur only once per object [single], or more than once [multiple]. When specifying multiple lines per attribute, the attribute name must be repeated. See [6] the example for the descr: attribute. route: [mandatory] [single] descr: [mandatory] [multiple] origin: [mandatory] [single] hole: [optional] [multiple] comm-list: [optional] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] maintainer: [optional] [single] changed: [mandatory] [multiple] source: [mandatory] [single] Each attribute has the following syntax: route: Route being announced. Format: Classless representation of a route with the RIPE database known as the "prefix length" representation. See [10] for more details on classless representations. Examples: route: 192.87.45.0/24 This represents addressable bits 192.87.45.0 to 192.87.45.255. route: 192.1.128.0/17 This represents addressable bits 192.1.128.0 to 192.1.255.255. Status: mandatory, only one line allowed origin: The autonomous system announcing this route. Format: <aut-num> See appendix A for <aut-num> syntax. Example: origin: AS1104 Status: mandatory, only one line allowed hole: A route that is more specific than the one described and that is unreachable via the less specific route. (my english is poor) Format: <route> Example: origin: 193.48.85/24 Status: optional, multiple line allowed comm-list: List of one or more communities this route is part of. Format: <community> <community> ... See Appendix B for <community> definition. Example: comm-list: HEP LEP Status: optional, multiple lines allowed remarks: Remarks/comments, to be used only for clarification. Format: free text Example: remarks: Multihomed AS talking to AS1755 and AS786 remarks: Will soon connect to AS1104 also. Status: optional, multiple lines allowed notify: The notify attribute contains an email address to which notifi- cations of changes to this object should be send. See also [11]. Format: <email-address> The <email-address> should be in RFC822 domain syntax wherever possible. Example: notify: Marten.Terpstra at ripe.net Status: optional, multiple lines allowed maintainer: The maintainer attribute contains a registered maintainer name. See also [11]. Format: <registered maintainer name> Example: maintainer: RIPE-DBM Status: optional, multiple lines allowed changed: Who changed this object last, and when was this change made. Format: <email-address> YYMMDD <email-address> should be the address of the person who made the last change. YYMMDD denotes the date this change was made. Example: changed: johndoe at terabit-labs.nn 900401 Status: mandatory, multiple lines allowed source: Source of the information. This is used to separate information from different sources kept by the same database software. For RIPE database entries the value is fixed to RIPE. Format: RIPE Status: mandatory, only one line allowed Gilles -------- Logged at Tue May 24 21:38:39 MET DST 1994 ---------
[ rr-impl Archive ]