Re: The router object

> 
> 
>  Tony Bates <Tony.Bates@localhost 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@localhost
> remarks:  The router for the RIPE NCC
> changed:  tony@localhost 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@localhost
> 
>      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@localhost 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@localhost
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
----------                                                     ----------