A ROUGH alternate proposal to CLNS DB for RIPE

Sue,
	okay some quick comments while here in Seattle.
After a quick look through this certainly looks to be something we can
come to consensus on reasonably quikcly. If I underastand this
correctly it gives us a similar amount of database information for
CLNP as we have today for IP and maps very nicely to boot. Form an
implementation (RIPE database) point of view these new objects and
attributes should not be a problem as soon as the DB indexing system
is truly classless which it isn't today. Now to answer some of the
questions.

  * 
  * 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 guess from a RIPE DB point of view the next step needs for these new
objects to be agreed and for a RIPE document to come out of this.
What say the RIPE DB chairman. Wilfried ?

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

  * 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.
  * 
Right now there is nothing like prtraceroute for CLNP. However, if you
can give me some pointers to the CLNP based tools out there we can
certainly look at the feasibility (which looks pretty good as your
proposed objects look in line with the current IP objects) for
building such tools.

  * So flame at me.
  * 
No flames yet at least ;-)

  * Sue Hares
  * 
		--Tony

  * ----
  * 
  * 
  * 
  * 
  * 
  * 
  * 
  * 
  * 
  * 
  * 
  * 
  * 
  * 
  * 
  * 
  * 
  * 
  * 
  *                       CLNS routing-domain object for the
  *                                 RIPE database
  * 
  * 
  * 				Version 1.3B
  * 
  *                                   Feb 1994
  * 
  * 
  * 
  * 
  * 
  * 
  * 
  * 
  * 
  * 
  * 

  * 
  * 
  * 
  * 
  * 
  * 
  * 
  * 
  * 
  * 
  * 
  * Susan Hares/Hank Steeman
  * skh at merit.edu/Henk_Steenman at sara.nl
  * 
  * 
  * 
  * CLNS routing-domain object                                            Page 
  * 2
  * 
  * 
  * 
  * Introduction.
  * ____________
  * 
  * In the RARE lower layer technology work group for CLNS it was recognised th
  * at
  * in order to coordinate routing between CLNS routing domains a central regis
  * try
  * for such domains was necessary.
  * 
  * At a meeting of the work group at the 27 IETF in Amsterdam it was decided t
  * o
  * write a registry specification. At this meeting the RIPE NCC offered to ext
  * end
  * 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 followin
  * g:
  * 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 wh
  * en
  * CLNS routing developes.
  * 
  * In an appendix, some generally used combinations of the Authority and Forma
  * t
  * 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 at surfnet.
  * 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 at surfnet.
  * 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 at surfnet.nl
  * saps:		TUBA, TP4, TCP
  * RDI:		RD39.528f.110	
  * applications:	ftp, telnet, smtp
  * rev-srv:	
  * source:		RIPE
  * changed:	henk at sara.nl 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.5
  * 28f.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 at surfnet.nl
  * source:		RIPE
  * changed:	henk at sara.nl 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 at surfnet.nl
  * source:		RIPE
  * changed:	henk at sara.nl 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.1
  * 100.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 SURFn
  * et
  * 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 at surfnet.nl
  * source:		RIPE
  * changed:	henk at sara.nl 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 at surfnet.nl
  * source:		RIPE
  * changed:	henk at sara.nl 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. Sinc
  * e
  * 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 author
  * ity
  * 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.
  * 
  * 
  *   
  *