The router object

Please find below a draft of a proposal for a router object known as
``inet-rtr''. This is the missing link of the current ripe-81++
specifically for the ias-int information which was rightly removed
along with the component attribute iself. This proposal is really a
modification of a similar proposal made by Merit with just one or two
clarifications and all credit belongs to them. 
This object could very quickly added to the Database.
Please let me have comments asap.

		--Tony.

Please note: a postscript version is available as

ftp://ftp.ripe.net/ripe/drafts/inet-rtr.ps









           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.
















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> [Local AS]

          <Interface Address> must be  a  "dotted-quad"  represented
          host  address.  It should be noted that at 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.

          [Local AS] is  an  optional  piece  of  information  which
          allows  this interface to be configured as being in a DIF-
          FERENT autonomous system.  This  is  useful  only  when  a
          router  is configured to `fake' that it is another AS. The
          format of [Local AS] is AS<positive integer between 1  and
          65535>.

     Examples:

          ifaddr: 192.87.45.190
          ifaddr: 192.87.4.99 AS1755

     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>

          <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



ripe-xy.txt                                               July, 1994
                               - 5 -


               version 2 or BGP version 3.

          BGP4
               The routers are using the exterior gateway  protocol,
               BGP conforming to BGP version 4 [9].

          IBGP
               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.

     Example:

          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

     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.

     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.

     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