proposal for inet-rtr obj extensions, for multicast, etc.

["Wilfried Woeber, UniVie/ACOnet" <]

  Dear all,

  		(to complete a long-standing RIPE action and to make progress)

  please find below a modified version of a document (originally by Erik-Jan Bos)
  which then was describing a multicast router in a routing registry. 

  This version proposes a more generalized approach and tries to discuss some
  implications, benefits and compatibility issues. It is up for discussion in the
  relevant RIPE working groups - in particular Routing, Mbone, (IPv6??) and
  DataBase. Of course any input and suggestions welcome!

  I would like to have your comments before and at the RIPE 25 Meeting, as well
  as on the mailing lists.
  
  Apologies for any rough edges, inconsistencies, omissins and typos. 
  I'm sure we're going to change and improve this text (if this is at all
  perceived as a useful exercise) and before it could eventually become a RIPE
  Document.

  Best regards,
  Wilfried.
 --------------------------------------------------------------------------
  Wilfried Woeber                :  e-mail: Woeber@localhost
  Computer Center - ACOnet       :  
  Vienna University              :  Tel: +43 1 4065822 355
  Universitaetsstrasse 7         :  Fax: +43 1 4065822 170
  A-1010 Vienna, Austria, Europe :  NIC: WW144
 --------------------------------------------------------------------------

--- Start of document


   Generalized Description of Peering Relations in a Routing Registry

		      Erik-Jan Bos, Wilfried Woeber

			  Document ID: ripe-nnn

			     September, 1996

      [ adapted and extended from a previous proposal titled: ]
      [                                                       ]
      [        A Multicast Router in the Routing Registry     ]
      [                       Erik-Jan Bos                    ]
      [                  Document ID: ripe-nnn                ]
      [                         May, 1995                     ]





               **** DRAFT ** WORK IN PROGRESS ** DRAFT ****








                                ABSTRACT

   This document describes an extension and generalization of concepts as
   documented in ripe-122 (Specifying an "Internet Router" in the Routing
   Registry) by which it becomes possible to define peering relations in
   a very general way.

   This approach should in particular be understood to support
   documentation and debugging of "overlay networks" and regular routing
   protocol peerings at the same time. 

   Originally this work was started to acommodate the description of a
   multicast capable Internet router within a routing registry. Comments
   and suggestions received at RIPE DB-WG sessions and private input led
   to the proposal to generalize the functionality.

   In addition to the inet-rtr specific attributes we propose the
   inclusion of a url: attribute, which is already proposed as an
   extension to all defined objects.




1. Introduction

With the growing of the Mbone worldwide, managing the Mbone becomes a
complex task. The multicast-bone is already suffering from problems that
used to be present in the unicast-bone several years ago, such as routing
coordination (and the lack of scoping of announcements).

While the Mbone is currently a focus of interest, activity, growth and
coordination efforts, we expect the general concept of an overlay network
that needs routing coordination to become a general issue (e.g. IPv6
tunnels).

Today, registries are available for administering policies and routes
and routers [1]. Tools are availble [2,3] for checking and analyzing the
real world against what is registered. The Mbone in particular, and other
"overlay networks" in general, could and should benefit from these
technologies coming from the unicast world.

The features of the specification described in this document will be
usable e.g. in the RIPE Data Base, after review by the RIPE Data Base WG.

After implementation tools could be developed for mapping and analyzing
the various different peering environments and/or overlay meshes.
Furthermore, administrative details (such as contact person) and
operational information (e.g. NOC info as described in role objects) are
easily administered by well known procedures and become easily retrievable.

Further discussion of the basic concepts led to the idea of generalizing
this approach to cater for registering all sorts of peerings, with the
dynamic exchange of routing information being a secondary issue.

A long-term goal should be to provide the level of configuration and
debugging support that is already available for maintaining external
unicast routing to a broader range of routing domains.


2. Multicast routers versus unicast routers

An "Internet Router" or a "gateway" in the current version of IP (IPv4)
can be defined as follows [4]:

"Gateways in the Internet form a cooperative, interconnected structure.
Datagrams pass from gateway to gateway until they reach a gateway that
can deliver the datagram directly."

This definition can be applied to both unicast and multicast routers.
Since both a unicast and multicast router are fulfilling the "Internet
Router" function for different natures of traffic, there is no need for a
special routing registry data base object. Moreover, both functions could
be present in the same box.


3. A Router specification a multi-protocol router in the Internet

Because an Internet Router 

  - can perform different types of routing at the same time, e.g. 
  	. IP unicast routing
	. multicast routing using DVMRP tunnels or PIM
	. IPv4/IPv6 or "general purpose" tunnels

  - in many situations there are defined or potential interactions
    between the routing domains

documentation of these facts should be possible in the routing registry.


3.1 A Simple Router Object, IPv4-only, Current Definiton

Each router is uniquely defined by by its object name, also known as the
fully qualified domain name. Below is an example of a internet router
object, specifying a general purpose unicast router:

inet-rtr:  broodjeham.surfnet.nl
localas:   AS1103
ifaddr:    192.87.106.102 255.255.255.192
ifaddr:    192.87.4.99 255.255.255.0
peer:      161.53.2.1 AS2108 BGP4
admin-c:   Erik-Jan Bos
tech-c:    Henk Steenman
notify:    netmaster@localhost
changed:   Erik-Jan.Bos@localhost 950505
source:    RIPE

Several pieces of important information are present in this object as
described in ripe-122. First of all there is the FQDN of the router,
acting as object name. The Home Autonomous System Number is shown, which
(currently) is only meaningful in the context of external IP routing.
Furthermore, the ifaddr:-lines show that this router has two interfaces,
connected to two different networks, and the masks used on these
networks. Finally the peer attribute records the IP (Version 4) address
for an external BGP peering and lists peering specific information,
eg. the localas: of the peer router (AS2108) and the type and version of
the EGP used (BGP4).


3.2 A Router for IPv4 and DVMRP, extending the current structure

For a moment, let us assume that this box is at the same time used as a
multicast router and has a DVMRP tunnel configured. One of the approaches
would be to define a dedicated attribute to describe this configuration,
say mpeer: for multicast peering. The router object would then look like
the following example:

inet-rtr:  broodjeham.surfnet.nl
localas:   AS1103
ifaddr:    192.87.106.102 255.255.255.192
ifaddr:    192.87.4.99 255.255.255.0
peer:      161.53.2.1 AS2108 BGP4
mpeer:     192.87.108.13 16 1
admin-c:   Erik-Jan Bos
tech-c:    Henk Steenman
notify:    netmaster@localhost
remarks:   SURFnet Multicast router
changed:   Erik-Jan.Bos@localhost 950505
source:    RIPE

While all the previously defined and well-known attributes would remain
unchanged, the newly invented mpeer: line would be used to describe a
DVMRP peering and showing it's peer's IP address, the treshold and
metric. Again, the format and interpretation of the entries beyond the IP
(Version 4) address would be specific for that attribute. The advantage
of that approach is that there is no need to change the definition of
exiting attributes, which in turn preserves the functionality of any
tools written to understand the specific information.

However, there is a couple of major disadvantages when proceeding in that
direction - the most important ones being that 

  - the object's definition and schema has to be changed whenever a new
    attribute for a differnet kind of peering is proposed
    
  - frequent changes of the objects schema would lead to incompatible
    versions of the software
    
  - eventually having a sizeable number of different attributes for the
    various peerings leeds to congestion of the namespace for attribute
    tags and (probably) to confusion and errors on the human part of the
    system

  - and (maybe the most important thing) there is currently no way to
    describe peerings that do not use IPv4 addresses to identify the
    peer, e.g. IPv6 and some other protocols


3.3 The Generalization of the Peer Description Concept

Because of these reasons given in 3.2 we propose to change the concept of
the peering description to become more general and extensible by moving
the peering protocol identifier into the first part on the line and
deriving the format and meaning from that.

Thus the example object used here would look like the following:

inet-rtr:  broodjeham.surfnet.nl
localas:   AS1103
ifaddr:    192.87.106.102 255.255.255.192
ifaddr:    192.87.4.99 255.255.255.0
g-peer:    BGP4  161.53.2.1 AS2108
g-peer     DVMRP 192.87.108.13 16 1
admin-c:   Erik-Jan Bos
tech-c:    Henk Steenman
notify:    netmaster@localhost
remarks:   SURFnet Multicast router
changed:   Erik-Jan.Bos@localhost 950505
source:    RIPE

Changing the object's schema in that way raises the issue of backwards
compatibility versus "cleanliness" (tools) and compatibility of possibly
different versions of the software deploied at different registries.


3.4 Backwards Compatibility Discussion

For the backwards compatibility we propose to define a new attribute
g-peer, "generalized peering description", and eventually make the peer:
attribute obsolete - as soon as the tools have been converted to
understand the new format. The disadvantage is the coexistence and/or
duplicate registration of BGP4 specific information in peer: and/or
g-peer: lines. An alternate approach would be to stick with the peer:
attribute for the BGP4 specific information and to specify all other
types of peering in g-peer: attributes. While this may be an advantage in
the short term, it might add complexity for the tools in the long run by
requiring them to understand different attribute formats.

For the different software version issue we propose to have the
implementation treat any unknown peering type (and the rest of the line)
as a remark. This situation should generate a warning at the time of
registration or update, and there should probably a switch to instruct
the software to suppress the warning or do more stringent tests.

We specifically ask the maintainers of tools which are currently relying
on the peer: attribute, and the RIPE- and Internet-Community in general,
for guidance about these issues!

All other attributes would remain as already defined for a routing
registry [1].

See next chapter for the syntax definition and concepts for extension.


4. Multiprotocol Router Syntax Definition

An object for a router capable of maintaining different routing protocol
(or tunnel) peerings in parallel is defined here. Each of the possible
attributes are shown, on a single line. The second column defines whether
the attribute must be present [mandatory] of could be present [optional].
The third column defines whether exactly one line is allowed [single] or
that more than one line of the same attribute is allowed [multiple]. In
case an attribute has more lines than one, the name of the attribute must
be repeated on each line.

inet-rtr:    [mandatory]      [single]
localas:     [mandatory]      [single]
ifaddr:      [mandatory]      [multiple]
peer:        [obsolete]       [multiple]
g-peer:      [mandatory]      [multiple]
admin-c:     [mandatory]      [multiple]
tech-c:      [mandatory]      [multiple]
notify:      [optional]       [multiple]
remarks:     [optional]       [multiple]
changed:     [mandatory]      [multiple]
source:      [mandatory]      [single]

Each attribute has the following syntax:

inet-rtr:   The fully qualified domain name of the router.

localas:    The Autonomous System to which the router belongs.
            [Note: For the time being this is specific for the IPv4
                   external routing domain. 
		   It might even be useful to move that information to a 
		   g-peer: BGP4 entry?!]

ifaddr:     An interface IPv4 address of the router.
            [Note: the current draft of this proposal does not deal with
                   necessary or desirable changes for IPv6.]

peer:       obsolete, potentially useful until RR tools are changed!

g-peer:     A peering of the router with another router, indicating the
            protocol and any protocol-specific information.
            [Note: please refer to the next section for the protocols
                   being proposed in this draft and the proposed mechanisms
                   for extension]

            Format:
                 <protocol-ID> <peer address> <additional information>
            Examples:
                 g-peer: DVMRP    192.87.108.13 16 1
                 g-peer: BGP4     161.53.2.1 AS2108
                 g-peer: IPv6-TUN IPv6-Address IPv6-specific
            Status: mandatory, multiple instances allowed.

admin-c:    Full name or uniquely assigned NIC-handle of a contact person
            for administrative matters.

tech-c:     Full name or uniquely assigned NIC-handle of a contact person
            for technical matters.

notify:     An e-mail address to which notifications of changes to this
            object should be send.

remarks:    Remarks or comments, for clarification purposes only.

changed:    The e-mail address and date of a change.

source:     Source of the information.


4.1 Discussion of Application

Use of this approach has already been discussed for

BGP4:

  g-peer:	BGP4 <remote-peer address> <peer AS>
  example:      BGP4 192.87.4.6 AS2122 localAS AS2121

  or even

  g-peer:	BGP4 <remote-peer address> <peer AS> [localAS <ASnumber>]
  
DVMRP
  
  g-peer:	DVMRP <remote-peer address> <metric> <thresh>
  example:	DVMRP 192.87.4.6 192.87.108.13 16 1

IP-over-IP

  g-peer:	IPv4-TUN <remote-peer address>
  example:	IPv4-TUN 192.87.4.6
  
  or 
  
  g-peer:	IPv6-TUN <remote-peer address>
  example:	IPv6-TUN IPv6-Address


4.2 Extensions

  * t.b.s. *
  
   [
     The gist of it should be that future extensions could be incorporated by
     simply editing a software configuratin file to define additional protocol
     types and supplying the syntax checking rules. 
     To be discussed in more detail.
   ]


5. Acknowledgements

This specification, being an addition to ripe-122, leans on the specification
done by the author of ripe-122. Credits go to Tony Bates.  Furthermore, the RIPE
Mbone-WG has already done some reviewing of a previous version of this document
and they receive credits as well.

We are grateful for detailed suggestions received from David Kessens (ISI, then
with the RIPE-NCC) and Steve Richardson (Merit).


6. Security considerations

Security is not considered in this document.


7. References

[1]   Bates, Tony, "Specifying an Internet Router in the Routing 
      Registry", ripe-122, October 1994.
      On-line at URL: ftp://ftp.ripe.net/ripe/docs/ripe-122.txt

[2]   PRIDE Tools Release 1.
      On-line at URL: ftp://ftp.ripe.net/pride/tools/pride-tools-1.tar.Z

[3]   Merit Inc. RRDB Tools.
      On-line at URL: ftp://rrdb.merit.edu/pub/meritrr

[4]   Douglas Comer, "Internetworking with TCP/IP", Prentice-Hall, 1988.
      ISBN: 0-13-470188-7.

--- End of document
--------------------------------------------------------------------------------