A ROUGH alternate proposal to CLNS DB for RIPE

[Susan Hares <]

Victor and all:

This *very* rough draft is the start of an alternate
proposal to be discussed at the ripe data
base working group.  Any comments would be welcomed on this.
I started with Hank's proposal

I'd like some pointers on where to go from here.
I send this document because my questions and alternate
formats provoked no additional comments.

I suggest this alternate proposal to align things more closely
to IP CIDR ideas.  I thought that was the point of CIDR.

I am in hopes this will help tools creation, but again
since I have started anything like that I welcome 
comments.

Are there on-line tools for CLNS traceroutes like
prtraceroute?  I welcome pointers.   Again, thank-you
for letting me comment.  My comment should be taken
as personal, and not representative of Merit.

So flame at me.

Sue Hares

----



















                      CLNS routing-domain object for the
                                RIPE database


				Version 1.3B

                                  Feb 1994























Susan Hares/Hank Steeman
skh@localhost@sara.nl



CLNS routing-domain object                                            Page 2



Introduction.
____________

In the RARE lower layer technology work group for CLNS it was recognised that
in order to coordinate routing between CLNS routing domains a central registry
for such domains was necessary.

At a meeting of the work group at the 27 IETF in Amsterdam it was decided to
write a registry specification. At this meeting the RIPE NCC offered to extend
their database for IP domains/networks with CLNS related objects if a sound
proposal came forward.


Below is a revision of the 1.3 database description to include the following:
RIPE-81++  features:

	- Registration of ISO addresses 
	- Registration of Routing Policy
	- Registration of Aggregation policy



The registration of ISO address needs to include the:


	1) Network Layer Reachability (NLRI) information
		
	    These are simply the Prefix passed in 
	    the routing protocols.  Just as IP network
	    numbers are passed in the IP routing protocols.

	2) Routing Domain Identifier (RDI)

	    Routing Domain Identifiers are the
	    "AS number" equivalent for ISO routing protocols	
	    such as IDRP.

	    The Routing Domain Identifiers are
	    take out of the same address space as 
	    the rest of the ISO addresses.   This
	    address spaces minimizes some allocation
	    issues, but increases the need  to register
	    RDIs.

	    The IDRP for IP specification allows an AS number
	    to be mapped into RDI.  RDI so mapped
	    can be directly mapped into an AS.  The registration
	    should indicate if this registration space i
	    is used.
	

	3) NETs host systems

	   The DNS for CLNS system is under development.
	   As a host.txt file was once used to bootstrap
	   the internet, so a iso_hosts file must 
	   be generated to help boot strap the CLNP Internet.



The routing policy in this database is listed on an Routing
domain basis.

	1) Routing Domains attached to a Routing Domain
	2) Address of Router that provides exit
		points for Routing Domain

	3) Policy of what routes  the Routing Domain 
		will take from other domains.

	   (This equivalent to the IP AS-IN policy used by
		CLNP).

	4) Policy of what the Routing Domain will
	    send to other routing Domains

	   (This equivalent to the IP AS-OUT policy used by
		CLNP).

	5) Communities this RD belongs 

	6) Distribution Policy 

The Aggregation policy in this database object is listed
as:

	1) Aggregator location
	     Location is listed as both RDI (AS)
		 and the NET 
	
        2) Prefix that represents the  aggregation

	3) prefixes that will be are routed
	   by the aggregated prefix

	4) Type of Aggregation
	     Whether the aggregation is proxy or
	     or by the RD holding the routing.

 
Below a description of a three database objects
for CLNS routing domains are defined.

These objects directly mirror the IP objects defined
in the paper RIPE 81 [1] to improve the cross use of tools.

The following uses of the information are envisioned:

	1) The attributes describing routing policy are intended to be
	    set-up such that routing tables for static inter-domain
	    routing can be derived from them or existing routing can
	    be checked against the described policy.

	2) Bootstrapping host to host communication
	   by providing an iso_hosts table
 
	3) With the advent the dynamic inter-domain routin, these
	   objects may be used to configure the initial IDRP sesions.
 
It is desired that tools are made to serve these tasks.

It is understood that the object as described below is subject to change when
CLNS routing developes.

In an appendix, some generally used combinations of the Authority and Format
Identifier (AFI) and the Initial Domain Identifier (IDI) are shown.

The RIPE database expects NSAPs or prefixes to be formatted with dots,
seperating the first two and then every next four digits.


CLNS routing-domain object                                            Page 3



Object Summary 
_______________


Registration of ISO Prefixes:

i-prefix: iso-prefix/length 
prefix-name: character
descr:
country:
admin-c:
tech-c:
colors:
RDI:
community:
rev-srv:
changed:
source:

Registration of ISO capability Hosts:

i-net: NET
type: <bis> <is> <host>  
host-name: character
descr:
country:
admin-c:
tech-c:
guardian:
saps:
RDI:
applications: 
rev-srv:
changed:
source:


Registration of RDIs and policy: 

RDI: [ASxxxx or RDIxxx]
RDI-name:
descr:
RDI-in: 
RDI-out:
default: (points to what RDI)
bis: NETs
tech-c:
admin-c:
guardian:
source:
changed:


Registration of Aggregates:

i-aggr: iso-prefix 
descr:
i-aggr-prefix: (repeated several times)
i-aggr-type: <proxy> <originator> 
country:
admin-c:
tech-c:
connect:
i-aggr-RDI:
rev-srv:
changed:
source:


======

iso_prefix:
	
	Defines an IDRP prefix.  It consists of 
	a NSAP prefix followed by a "/" and a length

	Example: 47.0005.80ff.ff00/48

RDI:

	Defines an unique routing domain, characterised by a
	NSAP prefix , within a certain prefix hierarchy.

	Example:

	RDI: RD39.528f.1100
	AS1200 - Use the AS to RDI mapping used by IDRP for IP

RDI-name:

	String representing the routing domain.

	Format: Text string.

	Example:

	RDI-name: SURFnet-CLNS

descr:

	Description of the organisation and place of its location
	Format is equal to the descr attribute as defined for IP
	autonomous systems in [1].


CLNS routing-domain object                                            Page 4



RDI-in:

	Description of accepted routing domain prefixes, from
	other domain BIS. Analogue to "as-in" in [1].

	Format:< dom-prefix > < cost> <routing policy expression >

	For every BIS you peer with, there should be such an entry

	<dom-prefix> is the routing domain prefix where the BIS
	you peer with belongs to.

	<cost> is a relative cost to discriminate between different
	routes to the same domain. The lowest cost gives the most
	preferred route.

	<routing policy expression > can be expressed in the
	following way's

	1: list of "dom-prefixes"

	Example:

	RDI-in: RD39.528f.1103 100 39.124F/24 47.0005/24

	Example2:
	
	RDI-IN: AS1139 100 39 47


	2: KEYWORD

	Only one keyword for the moment
	ANY - accept everything you get announced.

	3: A logical expression of 1 and/or 2.

	The following operators should be defined
	AND
	OR
	NOT
	Parenthesis are used to group rules.

	Example:

	dom-in: 39.528f.1103 ANY AND NOT 39.756f

	Accept all announcements from EMPB BIS except for the
	Switzerland routing domain.


	3: Community Name
		equivalent to [1]


RDI-out:

	Routing domain prefixes announced to other BIS'.
	Analogue to the "as-out' tag in [1].

	Format : <RDI> <routing policy expression >

	<RDI> is the routing domain prefix where the BIS
	you peer with belongs to.

	<routing policy expression > As defined with the RDI-in
	tag.


	Example:

	RDI-out: 39.528f.1103 39.528f.1100 AND NOT 39.528f.1100.0009.10

	Advertise to Europanet the SURFnet-CLNS routing
	domain but not the PTT-Research routing domain.

default:

	Indication how default routing is done

	default:  < RDI> <cost>

	<RDI> again is the RDI where the
		     the default routes are passed. 

	<cost> indicates which default path is preferred.
	The lower cost gives the preffered path

	Example:

	default: 39.528f.1103 10

	Default points to is routed to 39.528f.1103.
	This default may be passed from multiple routers.

saps:	Well-known transport Service Access Points (SAP)s
	that this node supports over CLNP.
	TCP, UDP, TP4, skinny stack.

admin-c:

	Administrative contact.
	Format equal to  admin-c   in [1].

tech-c:

	Technical contact
	Format equal to  tech-c   in [1].

guardian:

	e-mail and/or postal address of domain guardian.
	Analogue to AS guardian in [1].

source:

	Source of the information.
	Equal to source field in [1].

remark:

	remarks or comments
	Equal to  remark  field in [1]

changed:

	Who and when of last change.
	Equal to change field in [1].


CLNS routing-domain object                                            Page 7



Example:
_________

i-prefix: 39.528f.1103/40 
prefix-name: SURFNET-C
descr: SURFnet-CLNS domain 
country: NL
admin-c: Victor Reijgs
tech-c: Henk Steenman
guardian: domain-guardian@localhost.
connect: 
RDI: RD39.528f.1100    
rev-srv: 
changed: 2-9-94
source: RIPE 


i-prefix: 39.528f.1100.0009.10/64
prefix-name:  PTT-1
descr: PTT CLNS domain 
country: NL
admin-c: Victor Reijgs
tech-c: Henk Steenman
guardian: domain-guardian@localhost.
connect: 
RDI: RD39.528f.1100    
rev-srv: 
changed: 2-9-94
source: RIPE 


i-net: 		39.528f.1100.1000.2000.0000.0001.0000.0c04.29b4.00
i-type:		bis
host-name:	bis.empb.surfnet.net
descr:		Bis that connects surfnet to EMPB cisco-4
country:	NL
admin-c:	Victor Reijs
tech-c:		Henk Steenman
guardian:	domain-guardian@localhost
saps:		TUBA, TP4, TCP
RDI:		RD39.528f.110	
applications:	ftp, telnet, smtp
rev-srv:	
source:		RIPE
changed:	henk@localhost 930716

 
RDI-prefix:	RD39.528f.1100
RDI-name	SURFnet-CLNS	
descr:		SURFnet-CLNS domain.
bis:		39.528f.1100.1000.2000.0000.0001.0000.0c04.29b4.00 39.528f.1103
dom-in:		39.528f.1103 100 ANY AND NOT 39.528f.1100.0009.10
dom-in:		39.528f.1100.0009.10 100 39.528f.1100.0009.10
dom-in:		AS1183 39.528f.1100 
dom-out:	39.528f.1103 39.528f.1100 AND NOT 39.528f.1100.0009.10
dom-out:	39.528f.1100.0009.10 39.528f.1100
dom-out:	AS1183 39.528f.1100
default:	39.528f.1103 10
admin-c:	Victor Reijs
tech-c:		Henk Steenman
guardian:	domain-guardian@localhost
source:		RIPE
changed:	henk@localhost 930716


RDI-Prefix:	RD39.528f.1103
RDI-name:	EMPB
descr:		European Backbone
(rest of entry is truncated for this example)

RDI-Prefix:	39.528f.1103
RDI-name:	EMPB
descr:		European Backbone
bis:		
(rest of entry is truncated for this example)

 
RDI-Prefix:	RD39.528f.1100.0009.10 
RDI-name:	PTT-Research
descr:		PTT Research network
(rest of entry is truncated for this example)


RDI-Prefix:	AS1183
RDI-name:	Interconnect AS
descr:		Interconnect AS to US vai ANSNET	


i-aggr:		39.528f.1100/40
i-aggre-name:	NL-SURFNET-aggr1
descr:		NL SURFNET  aggregate
i-aggr-prefix:	39.528f.1100.03/48
i-aggr-prefix:	39.528f.1100.04/48	
i-aggr-RDI:	AS1183
country:	NL
admin-c:	Victor Reijs
tech-c:		Henk Steenman
guardian:	domain-guardian@localhost
source:		RIPE
changed:	henk@localhost 930716


(Below text needs to be verified:)


SURFnet accepts from EMPB ( 39528f1103 ) all prefixes but one,
39.528f.1100.0009.10, which is PTT-research that is connected to both EMPB
and SURFnet. From PTT-research SURFnet only accepts the PTT-research prefix.

SURFnet announces to EMPB, 39.528f.1100 but not 39.528f.1100.0009.10.
To PTT-research only 39.528f.1100 is announced.

AS1183 is to represent the AS number that this network uses.
This AS number can be used if the IP and CLNP networks are
the same.  

With in the SURFNET addresses, the aggregates 39.528f.1100.03 and 39.528f.1100.04
are aggregated to 39.528f.1100.   
 
Translated to static routing; on the SURFnet BIS connected to PTT-
research, there is a static route to 39.528f.1100.0009.10. And on the SURFnet
BIS connected to EMPB there is a static route to all other
know prefixes. On both the PTT-reserach and EMPB BIS's connected
to SURFnet there is a static route to 39.528f.1100.


Alternate example with names used instead of the
numerical sequences.


RDI-prefix:	RD39.528f.1100
RDI-name	SURFnet-CLNS	
descr:		SURFnet-CLNS domain.
bis:		39.528f.1100.1000.2000.0000.0001.0000.0c04.29b4.00 EMPB 
dom-in:		EMPB 100 ANY AND NOT PTT-1 
dom-in:		PTT-Research 100 PTT-1 
dom-out:	EMPB SURFNET-C AND NOT PTT-1 
dom-out:	PTT-1 SURFNET-C 
default:	EMPB 10
admin-c:	Victor Reijs
tech-c:		Henk Steenman
guardian:	domain-guardian@localhost
source:		RIPE
changed:	henk@localhost 930716


Registration of ISO capable Hosts:

i-net:		39.528f.1100.1000.2000.0000.0001.0000.0c04.29b4.00 EMPB 
type: 		bis
host-name:	BIS.EMPB
descr:		EMPB hosts
country:	NL
admin-c:	Victor Reijs
tech-c:		Henk Steenman
guardian:	domain-guardian@localhost
source:		RIPE
changed:	henk@localhost 930716


Appendix A
-------
Definition of NSAP structure is defined in OSI 8348 Ad2 [2].

In general:

NSAP's are always an integer number of octets where the AFI is always one
octet and the IDI is always an integer number of octets.

NSAP's are hierarchical structured and once the AFI is decided upon,
structuring of the rest of the NSAP is up to authorities down the tree.

Two common AFI are 47 and 39 and can be described by some general rules.

AFI: 39

Describes that the following two octets are the ISO DCC country codes. Since
these codes are always described by three digits, padding with an "f" is
necessary to complete the 2 octets. Further structure is done by the authority
for each country and there is no general rule.

AFI: 47

IDI: 4 defines OSINET.



Followed by a two byte organisation identifier.

IDI: 5 defines US-GOSIP

Version 1 defines a two byte organisation identifier.

Version 2 defines a one byte data format identifier,
	a two byte zero field
	a three byte administrative authority
	a two byte routing domain id.


CLNS routing-domain object                                            Page 9



References
__________

[1] :
RIPE-81, Representation of IP routing Policies in the RIPE database,
Tony Bates, Jean-Michel Jouanigot, Daniel Karrenberg, Peter Lothberg and
Marten Terpstra, Feb. 1993

[2] :
OSI 8348 Ad2
Network Services Definition, Addendum 2, covering Network Layer Addressing.