The router object
Antonio_Blasco Bonito
Tue Jul 19 10:53:00 CEST 1994
> > > Tony Bates <Tony.Bates at ripe.net> writes: > * > Okay, one immediate change that comes to mind is that the OPTIONAL [Local AS] > information in the ifaddr attrbiute should be moved . It > should in fact move out of ifaddr into peer information as I think the only > time this will be used is actually at the routing/policy level rather than the > interface level. Here is an updated draft with the modified syntax. Other comments/corrections below... > > > --Tony. > > > > > > > > > > > > > Specifying an `Internet Router' in the Routing > Registry > > > Tony Bates > > > DRAFT - DRAFT - DRAFT > > Document ID: ripe-xy > > > > ABSTRACT > > This paper describes a simple specification for > defining an Internet router within a routing registry. > > > > 1. Introduction > > It has become apparent as routing registries are evolving that there > is a need to register some details of an Internet router (1) within > the routing registry. By adding this kind of detailed information it > adds functionality to information based on routing policies [1] > facilitating the ability to build operational tools [2],[3] such as > configuration generators and diagnostic tools within increased local > information. It also provides a direct method to find a contact for > an important component of the Internet infrastructure. This can be > extremely useful when resolving operational problems. > > 2. Acknowledgments > > This specification is based on a similar specification by Merit Inc. > for a `route' object (2). All credit should go to them. This paper > acts purely to clarify the original ideas set out in the Merit > paper. > _________________________ > (1) Here an Internet router means any IP [4] node ca- > pable of running an IP routing protocol. Be that RIP, > BGP or any other of the current IP based routing proto- > cols found in the Internet today. This definition is > intentionally looser than what might be found in the > "Router requirements" Internet draft [5]. > (2) This specification does not use `router' as the > object name to avoid possible clashes with the `route' > object which already exists within the routing regis- > try. > > > > > ripe-xy.txt July, 1994 > - 2 - > > > 3. Router Representation > > The representation must be capable of representing both ``interior'' > and ``border'' routers within ones own autonomous system. Each > object is uniquely identified by its object name. Here is a simple > example of a router object: > > > inet-rtr: Amsterdam.ripe.net > localas: AS3333 > ifaddr: 192.87.45.190 > ifaddr: 192.87.4.28 > ifaddr: 193.0.0.222 > peer: 192.87.45.6 AS2122 BGP4 > peer: 193.0.0.219 AS2122 BGP > peer: 193.0.0.221 AS1104 BGP > peer: 192.87.4.18 AS1103 BGP4 > peer: 192.87.4.24 AS1103 BGP4 > peer: 192.87.4.20 AS286 BGP4 > peer: 192.87.4.5 AS3333 IBGP4 > admin-c: Daniel Karrenberg > tech-c: Tony Bates > tech-c: Marten Terpstra > notify: ops at ripe.net > remarks: The router for the RIPE NCC > changed: tony at ripe.net 940720 > source: RIPE > > > This object provides several key pieces of information. The exact > syntax for each attribute is discussed in the next section. However, > some general remarks about this example are worthy of note. From > this you can see immediately that this router "Amsterdam.ripe.net" > is in the autonomous system 3333 and has three configured inter- > faces. You also see that it has several exterior peers and one inte- > rior peer (192.87.45.6). Details of the actual routing protocol are > given. This can be extremely useful. For example a BGP3 router is > not CIDR [6] capable whereas a BGP4 capable router is. A tool could > use this information when examining routing policy to see if a peer > can make use of aggregation. Finally, we also see who we can con- > tact when problems occur with this router. The example should list also interior peers with internal routing protocols and the explanation text should mention that too. > > > > > > > > > > > > > > > > > ripe-xy.txt July, 1994 > - 3 - > > > 4. `inet-rtr' Syntax Definition > > Here is a summary of the tags associated with inet-rtr object itself > and their status. The first column specifies the attribute, the > second column whether this attribute is mandatory in the inet-rtr > object, and the third column whether this specific attribute can > occur only once per object [single], or one or more [multiple]. When > specifying multiple lines per attribute, the attribute name must be > repeated. > > inet-rtr: [mandatory] [single] > localas: [mandatory] [single] > ifaddr: [mandatory] [multiple] > peer: [optional] [multiple] > tech-c: [mandatory] [multiple] > admin-c: [mandatory] [multiple] > remarks: [optional] [multiple] > notify: [optional] [multiple] > maintainer: [optional] [single] > changed: [mandatory] [multiple] > source: [mandatory] [single] > > > Each attribute has the following syntax: > > > inet-rtr: > The fully qualified domain name of the router. > > Format: > Fully qualified domain name without trailing "." (dot). > This must be registered in the DNS. For routers with more > than one DNS you should pick the one that seems most suit- > able. It should be noted that it is commonly general prac- > tice for a router to have single uniquely defined domain > name. > > Example: > > inet-rtr: Amsterdam.ripe.net > > Status: mandatory, only one line allowed > > localas: > The autonomous system in which this router belongs. > > Format: > AS<positive integer between 1 and 65535> > > Example: > > localas: AS3333 > > Status: mandatory, only one line allowed > > > > ripe-xy.txt July, 1994 > - 4 - > > > ifaddr: > An interface address within the router. > > Format: > <Interface Address> > > <Interface Address> must be a "dotted-quad" represented > host address. It should be noted that at least ONE ifaddr > must be configured for the inet-rtr object to be valid. > This facilitates the registering of route servers which > may only have one interface address and are purely routing > engines. Uhmmm, a route server which does not route packets but is only used by actual routers as a source of routing information IS NOT a router. Does it need to be registered? If yes I think it should be clearly distinguishable by actual routers. > > Examples: > > ifaddr: 192.87.45.190 > ifaddr: 192.87.4.99 AS1755 ^^^^^^ This should be removed after the mod from Tony, right? > > Status: mandatory, multiple lines allowed > > peer: > Details of any router peerings. These can be both interior or > exterior. > > Format: > <Peer address> <Peer AS> <Routing Protocol> [Local AS] > > <Peer address> is the interface address of the remote > peer. This is same format as that used in the ``ifaddr'' > attribute above. > > <Peer AS> is the autonomous system number of the peer. Its > format is AS<positive integer between 1 and 65535>. It > should be noted that even interior peers should have their > <Peer AS> detailed. > > <Routing Protocol> represents the routing protocol running > between the router and the peer. This can be any one of > the following reserved routing protocol keywords: > > EGP > The routers are using the exterior gateway protocol, > EGP [7]. > > BGP > The routers are using the exterior gateway protocol, > BGP conforming to [8]. This can mean either BGP ver- > sion 2 or BGP version 3. > > BGP4 > The routers are using the exterior gateway protocol, > BGP conforming to BGP version 4 [9]. > > IBGP > > > > ripe-xy.txt July, 1994 > - 5 - > > > The routers are using the exterior gateway protocol, > BGP as an interior routing protocol conforming to > [8]. This can mean either BGP version 2 or BGP ver- > sion 3. > > IBGP4 > The routers are using the exterior gateway protocol, > BGP as an interior routing protocol conforming to BGP > version 4 [9]. > > IDRP > The routers are using the exterior gateway protocol, > IDRP conforming to [10]. > > IGP > This is an interior peering using a standard interior > gateway protocol (i.e. RIP, OSPF, etc.). > > OTHER > This peering is using a protocol not in one of the > categories above. > > [Local AS] is an optional piece of information which > allows this peering to be configured as having the router > in a DIFFERENT autonomous system. This is useful only > when a router is configured to `fake' that it is another > AS. The format of [Local AS] is "localas AS<positive > integer between 1 and 65535>". The string `localas' must > be present for this optional information to be valid. Text to be added: Note that in some cases a router configured as being in more than one AS can also peer with itself to exchange routes among its ASes > > Example: > > peer: 193.0.0.219 AS2122 BGP > peer: 193.0.0.221 AS1104 BGP > peer: 192.87.4.18 AS1103 BGP4 > peer: 192.87.4.24 AS1103 BGP4 > peer: 192.87.4.20 AS286 BGP4 > peer: 192.87.4.6 AS2122 BGP4 localas AS2121 > > Status: optional, multiple lines allowed > > admin-c: > Full name or uniquely assigned NIC-handle of an administrative > contact person. > > Format: > <firstname> <initials> <lastname> or <nic-handle> > > Examples: > > admin-c: Joe T Bloggs > admin-c: JTB1 > > Status: mandatory, multiple lines allowed > > > > ripe-xy.txt July, 1994 > - 6 - > > > tech-c: > Full name or uniquely assigned NIC-handle of a technical con- > tact person for this macro. This is someone to be contacted for > technical problems such as misconfiguration. > > Format: > <firstname> <initials> <lastname> or <nic-handle> > > Examples: > > tech-c: John E Doe > tech-c: JED31 > > Status: mandatory, multiple lines allowed > > notify: > The notify attribute contains an email address to which notifi- > cations of changes to this object should be send. The meaning and usage of this attribute is not clear: which kind of changes? > > 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. The meaning and purpose of this attribute is not clear. > > Format: > <registered maintainer name> > > Example: > > maintainer: RIPE-DBM > > Status: optional, multiple lines allowed > > remarks: > Remarks/comments, to be used only for clarification. > > Format: > free text > > Example: > > remarks: This is a router > > > > > > ripe-xy.txt July, 1994 > - 7 - > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ripe-xy.txt July, 1994 > - 8 - > > > 5. References > > [1] Bates, T., Gerich, E., Joncheray, L., Joanigot, J-M, Karren- > berg, D., Terpstra, M, Yu, J., ripe-81++, July 1994. WORK IN > PROGRESS > > [2] PRIDE Tools Release 1. > See ftp.ripe.net:pride/tools/pride-tools-1.tar.Z. > > [3] Merit Inc. RRDB Tools. > See rrdb.merit.edu:pub/meritrr/* > > [4] J. Postel, "Internet Protocol", RFC 791, January 1981. > > [5] Kastenholz, F., draft-ietf-rreq-iprouters-require-01.txt, > April, 1994, INTERNET DRAFT > > [6] V. Fuller, T. Li, J. Yu, K. Varadhan, "Classless Inter-Domain > Routing (CIDR): an Address Assignment and Aggregation Stra- > tegy", RFC1519, Sep., 1993. > > [7] Mills, D., "Exterior Gateway Protocol formal specification", > RFC904, April 1984. > > [8] K. Lougheed, Y. Rekhter, "A Border Gateway Protocol 3 (BGP-3)", > RFC1267, October 1991. > > [9] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", > <draft-ietf-bgp-bgp4-10.txt>, INTERNET DRAFT, May, 1994. > > [10] C. Kunzinger, "ISO/IEC 10747 - Protocol for the Exchange of > Inter-Domain Routing Information among Intermediate Systems to > Support Forwarding of ISO 8473 PDUs", <draft-kunzinger-idrp- > ISO10747-00.txt>, INTERNET DRAFT, April 1994. > > > > > > > > > > > > > > > > > > > > > > > > ripe-xy.txt July, 1994 > -- ---------- ---------- Antonio_Blasco Bonito E-Mail: bonito at nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246 Via S. Maria, 36 Telex: 500371 CNUCE I 56126 PISA Italy Fax: +39 (50) 904052 ---------- ---------- -------- Logged at Tue Jul 19 21:28:33 MET DST 1994 ---------
[ rr-impl Archive ]