Latest draft of ripe-81++

	A few things i'd like to propose:
- A route/AS name attribute. You currently use the first line of the 'desc'
attribute to generate a name (with prtraceroute for instance). Having
a separate name attribute can make the query of the server (whois or whatever)
easier since it doesn't require any parsing.
- Include the time (hour, min, second) in the "changed" attribute. This is
in case of several changes in the same day. Proposed syntax
(compatible with the older one):
changed: <email> YYMMDD [hh:mm:ss] [+oo]
If hh:mm:ss is missing we assume 00:00:00 +00 ???
+oo if the offset from GMT. (i know, we have to deal with the time
difference :-)
		Laurent
> 
> Please find below the latest draft of ripe-81++. This has several
> changes which have been worked in, over the weeks following the RIPE
> meeting as agreed. There are still a couple of open issues for which
> we are waiting on input. However, these have been clearly separated
> (and marked) such that we can (and will) begin implementing the rest
> of ripe-81++.
> We would like to have this agreed by the next RIPE meeting at the very
> latest (if not sooner) to make sure implementation work can take
> place. If this is not done it may be next year before implementation
> work can begin on this.
> 
> 			--Tony.
> 
> Also note that both this and the postscript version are available from
> 
> ftp://ftp.ripe.net/ripe/drafts/ripe-81++.ps
> ftp://ftp.ripe.net/ripe/drafts/ripe-81++.txt
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                Representation of IP Routing Policies
> 
>                        in a Routing Registry
> 
>                             (ripe-81++)
> 
>                          DRAFT DRAFT DRAFT
> 
> 
>                              Tony Bates
>                             Elise Gerich
>                          Laurent Joncheray
>                        Jean-Michel Jouanigot
>                          Daniel Karrenberg
>                           Marten Terpstra
>                              Jessica Yu
> 
> 
>                        Document-ID: ripe-1nn
>                          Obsoletes: ripe-81
> 
>                              July, 1994
> 
> 
> 
>                               ABSTRACT
> 
>            This document is an update to the  original  `ripe-
>       81'[1]  proposal  for  representing  and storing routing
>       polices  within  the  RIPE  database.  It   incorporates
>       several  extensions  proposed by Merit Inc.[2] and gives
>       details of a generalised IP routing  policy  representa-
>       tion  to  be used by all Internet routing registries. It
>       acts as both tutorial and provides details  of  database
>       objects  and  attributes  that use and make up a routing
>       registry.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 2 -
> 
> 
> 
> 
> 
>                          Table of Contents
> 
> 
> 
> 
> 1 Introduction ................................................    ?
> 
> 2 Organisation of this Document ...............................    ?
> 
> 3 General Representation of Policy Information ................    ?
> 
> 4 The Routing Registry and the RIPE Database ..................    ?
> 
> 5 The Route Object ............................................    ?
> 
> 6 The Autonomous System Object ................................    ?
> 
> 7 The AS Macro Object .........................................    ?
> 
> 8 The Community Object ........................................    ?
> 
> 9 Representation of Routing Policies ..........................    ?
> 
> 10 Future Extensions ..........................................    ?
> 
> 11 References .................................................    ?
> 
> 12 Authors Addresses ..........................................    ?
> 
> Appendix A - Syntax for the "aut-num" object ..................    ?
> 
> Appendix B - Syntax for the "community" object ................    ?
> 
> Appendix C - Syntax for the "as-macro" object .................    ?
> 
> Appendix D - Syntax for the "route" object ....................    ?
> 
> Appendix E - List of reserved words ...........................    ?
> 
> Appendix F - Motivations for RIPE-81++ ........................    ?
> 
> Appendix G - Transition strategy from RIPE-81 to RIPE-81++ ....    ?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 3 -
> 
> 
> 1.  Introduction
> 
> This document is a much revised version of the RIPE routing registry
> document known as ripe-81[1].  Since its inception in February, 1993
> and the establishment of the RIPE routing  registry,  several  addi-
> tions  and  clarifications  have  come  to light which can be better
> presented in a single updated document rather than separate addenda.
> 
> Some of the text remains the same the as the original ripe-81  docu-
> ment keeping its tutorial style mixed with details of the RIPE data-
> base objects relating to  routing  policy  representation.   However
> this  document does not repeat the background and historical remarks
> in ripe-81. For these please refer to  the  original  document.   It
> should  be  noted  that whilst this document specifically references
> the RIPE database and the RIPE routing registry one can easily  read
> "Regional  routing registry" in place of RIPE as this representation
> is certainly general and flexible enough to be used outside  of  the
> RIPE  community  incorporating  many  ideas  and features from other
> routing registries in this update.
> 
> As you can see this document has a new RIPE document  identification
> number but can also be referred to as ripe-81++.  Appendix F summar-
> ises the changes from ripe-81 plus the motivation for these changes.
> 
> We would like to acknowledge many people for help  with  this  docu-
> ment.   Specifically, Peter Lothberg who was a co-author of the ori-
> ginal ripe-81 document for his many ideas and Gilles  Farrache.   We
> would  also  like  to thank the RIPE routing working group for their
> review and comment. Finally, we like to thank Merit  Inc.  for  many
> constructive  comments  and  ideas and making the routing registry a
> worldwide Internet service. We would also like  to  acknowledge  the
> funding  provided  by  the PRIDE project run in conjunction with the
> RARE Technical Program, RIPE and the RIPE  NCC  without  which  this
> paper would not have been possible.
> 
> 2.  Organisation of this Paper
> 
> This paper acts as both a basic tutorial for  understanding  routing
> policy and provides details of objects and attributes used within an
> Internet routing registry  to  store  routing  policies.  Section  3
> describes  general  issues  about  IP  routing  policies  and  their
> representation in routing registries. Experienced readers  may  wish
> to  skip  this  section.  Section 4 provides an overview of the RIPE
> database, its basic concepts, schema and objects which make  up  the
> database  itself.   It highlights the way in which the RIPE database
> splits routing information from allocation information.  Sections 5,
> 6,  7  and  8  detail all the objects associated with routing policy
> representation.  Section 9 gives a fairly extensive  "walk  through"
> of  how these objects are used for expressing routing policy and the
> general principles behind their use. Section 10 provides a  list  of
> references  used  throughout  this document.  Appendix A, B, C and D
> document the formal syntax for the database objects and  attributes.
> Appendix F details the main changes from ripe-81 and motivations for
> these changes. Appendix G tackles  the  issues  of  transition  from
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 4 -
> 
> 
> ripe-81 to ripe-81++.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 5 -
> 
> 
> 3.  General Representation of Policy Information
> 
> Networks, Network Operators and Autonomous Systems
> 
> Throughout this document an effort is made  to  be  consistent  with
> terms so as not to confuse the reader.
> 
> When we talk about "networks" we mean physical networks which have a
> unique classless IP network number: Layer 3 entities. We do not mean
> organisations.
> 
> We call the organisations operating  networks  "network  operators".
> For  the  sake  of the examples we divide network operators into two
> categories: "service providers" and  "customers".  A  "service  pro-
> vider"  is  a  network  operator  who  operates a network to provide
> Internet services to different organisations, its "customers".   The
> distinction  between  service  providers  and customers is not clear
> cut. A national research networking organisation frequently acts  as
> a service provider to Universities and other academic organisations,
> but in most cases it buys international  connectivity  from  another
> service  provider.  A University networking department is a customer
> of the research networking  organisation  but  in  turn  may  regard
> University departments as its customers.
> 
> An Autonomous System (AS) is a group of IP networks having a  single
> clearly  defined  routing policy which is run by one or more network
> operators. Inside ASes IP packets are routed using one or more Inte-
> rior  Routing Protocols (IGPs). In most cases interior routing deci-
> sions are based on metrics derived from  technical  parameters  like
> topology, link speeds and load(1).
> 
> ASes exchange routing information with  other  ASes  using  Exterior
> Routing Protocols (EGPs).  Exterior routing decisions are frequently
> based on policy based rules rather than purely on technical  parame-
> ters.  Tools are needed to configure complex policies and to commun-
> icate those policies between ASes while still ensuring proper opera-
> tion  of the Internet as a whole. Some EGPs like BGP-3 [8] and BGP-4
> [9] provide tools to filter routing information according to  policy
> rules and more. None of them provides a mechanism to publish or com-
> municate the policies themselves. Yet this is  critical  for  opera-
> tional  coordination and fault isolation among network operators and
> thus for the operation of the global  Internet  as  a  whole.   This
> document  describes  a "Routing Registry" providing this functional-
> ity.
> _________________________
> (1) The entity we refer to as an AS is  frequently  and
> more generally called a routing domain with the AS just
> being an implementation vehicle. We have decided to use
> the term AS exclusively because it relates more direct-
> ly with the database objects and routing tools. By  us-
> ing  only one term we hope to reduce the number of con-
> cepts and to avoid confusion. The academically inclined
> reader may forgive us.
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 6 -
> 
> 
> Routing Policies
> 
> The exchange of routing information between ASes is subject to rout-
> ing  policies.  Consider  the  case  of two ASes, X and Y exchanging
> routing information:
> 
> 
>              NET1 ......  ASX  <--->  ASY  ....... NET2
> 
> 
> ASX knows how to reach a network called NET1.  It  does  not  matter
> whether  NET1  is  belonging to ASX or some other AS which exchanges
> routing information with ASX either directly or indirectly; we  just
> assume  that  ASX knows how to direct packets towards NET1. Likewise
> ASY knows how to reach NET2.
> 
> In order for traffic from NET2 to NET1 to flow between ASX and  ASY,
> ASX  has to announce NET1 to ASY using an external routing protocol.
> This states that ASX is willing to accept traffic directed  to  NET1
> from  ASY.  Policy thus comes into play first in the decision of ASX
> to announce NET1 to ASY.
> 
> In addition ASY has to accept this routing information and  use  it.
> It  is  ASY's  privilege  to either use or disregard the information
> that ASX is willing to accept traffic for NET1. ASY might decide not
> to  use this information if it does not want to send traffic to NET1
> at all or if it considers another route more  appropriate  to  reach
> NET1.
> 
> So in order for traffic in the direction of NET1 to flow between ASX
> and  ASY,  ASX  must  announce it to ASY and ASY must accept it from
> ASX:
> 
> 
>                  resulting packet flow towards NET1
>                <<===================================
>                                  |
>                                  |
>                   announce NET1  |  accept NET1
>                  --------------> + ------------->
>                                  |
>                      AS X        |    AS Y
>                                  |
>                   <------------- + <--------------
>                     accept NET2  |  announce NET2
>                                  |
>                                  |
>                 resulting packet flow towards NET2
>                 ===================================>>
> 
> 
> Ideally, and seldom practically,  the  announcement  and  acceptance
> policies of ASX and ASY are identical.
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 7 -
> 
> 
> In order for traffic towards NET2 to flow, announcement  and  accep-
> tance  of  NET2 must be in place the other way round. For almost all
> applications connectivity in just one direction  is  not  useful  at
> all.
> 
> It is important to realise that with current destination based  for-
> warding  technology routing policies must eventually be expressed in
> these terms. It is relatively easy to formulate reasonable  policies
> in very general terms which CANNOT be expressed in terms of announc-
> ing and accepting networks. With current  technology  such  policies
> are almost always impossible to implement.
> 
> Usually policies are not configured for each network separately  but
> for  groups of networks.  In practise these groups are almost always
> defined by the networks forming one or more ASes.
> 
> 
> 
> Routing Policy limitations
> 
> The generic example of a reasonable but un-implementable routing  is
> a  split  of  already joined packet streams based on something other
> than destination address.  Once traffic  for  the  same  destination
> network  passes  the  same  router,  or  the same AS at our level of
> abstraction, it will take exactly the same  route  to  the  destina-
> tion(2).
> 
> In a concrete example AS Z might be connected to the  outside  world
> by  two  links.   AS  Z  wishes to reserve these links for different
> kinds of traffic, let's call them black and white traffic.  For this
> purpose  the  management  of AS Z keeps two lists of ASes, the black
> and the white list.  Together these lists comprise all ASes  in  the
> world reachable from AS Z.
> 
>                          "W"
>                         <--->
>                     ...           AS Z .... NET 3
>                         <--->
>                          "B"
> 
> It is quite possible to implement the policy for traffic originating
> in  AS  Z: AS Z will only accept announcements for networks in white
> ASes on the white link and will only accept announcements  for  net-
> works  in  black  ASes  on the black link.  This causes traffic from
> networks within AS Z towards white ASes to use the  white  link  and
> likewise traffic for black ASes to use the black link.
> 
> Note that this way of implementing  things  makes  it  necessary  to
> decide on the colour of each new AS which appears before traffic can
> be sent to it from AS Z.  A way around this would be to accept  only
> _________________________
> (2) Disregarding special cases like "type  of  service"
> routing, load sharing and routing instabilities.
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 8 -
> 
> 
> white announcements via the white link and to accept all  but  white
> announcements  on  the  black  link.  That way traffic from new ASes
> would automatically be sent down the black link and AS Z  management
> would  only  need  to  keep  the  list of white ASes rather than two
> lists.
> 
> Now for the unimplementable  part  of  the  policy.   This  concerns
> traffic towards AS Z.  Consider the following topology:
> 
>        B AS ---)                    "W"
>        W AS ---)                    --->
>        B AS ---)>>  AS A  ---> ...           AS Z .... NET 3
>        B AS ---)                    --->
>        W AS ---)                    "B"
> 
> As seen from AS Z there are both black and white ASes "behind" AS A.
> Since  ASes can make routing decisions based on destination only, AS
> A and all ASes between AS A and the two links connecting  AS  Z  can
> only  make the same decision for traffic directed at a network in AS
> Z, say NET 3.  This means that traffic from  both  black  and  white
> ASes towards NET 3 will follow the same route once it passes through
> AS A.  This will either be the black or the white route depending on
> the routing policies of AS A and all ASes between it and AS Z.
> 
> The important thing to note is that unless  routing  and  forwarding
> decisions   can  be  made  based  on  both  source  and  destination
> addresses, policies like the "black and  white"  example  cannot  be
> implemented in general because "once joined means joined forever".
> 
> 
> Access Policies
> 
> Access policies contrary to routing  policies  are  not  necessarily
> defined in terms of ASes. The very simplest type of access policy is
> to block packets from a specific network S from being  forwarded  to
> another  network  D. A common example is when some inappropriate use
> of resources on network D has been made from network S and the prob-
> lem  has  not  been  resolved yet. Other examples of access policies
> might be resources only accessible to networks belonging to  a  par-
> ticular  disciplinary group or community of interest.  While most of
> these policies are better implemented at  the  host  or  application
> level,  network  level  access policies do exist and are a source of
> connectivity problems which are sometimes hard to  diagnose.  There-
> fore  they should also be documented in the routing registry accord-
> ing to similar requirements as outlined above.
> 
> 
> 
> Routing v Allocation information
> 
> The RIPE database contains both routing registry and  address  space
> allocation  registry  information.  In  the past the database schema
> combined this information. Because RIPE was tasked with running both
> an  allocation  and  routing registry it seemed natural to initially
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 9 -
> 
> 
> combine these functions.  However, experience has shown that a clear
> separation  of  routing  information  from  allocation is desirable.
> Often the maintainer of the routing information is not the  same  as
> the  maintainer of the allocation information.  Also, in other parts
> of the world there are different registries for each kind of  infor-
> mation.
> 
> Whilst the actual routing policy objects will be introduced  in  the
> next section it is worthy of note that a transition from the current
> objects will be required. This is described with in Appendix G.
> 
> This split in information represents a  significant  change  in  the
> representational  model  of the RIPE database. Appendix F expands on
> the reasons for this a little more.
> 
> 
> 
> Tools
> 
> The network operators will need a series of tools for  policy  rout-
> ing.  Some tools are already available to perform some of the tasks.
> Most notably, the PRIDE tools [3] from the PRIDE project started  in
> September  1993 as well as others produced by Merit Inc [4] and CERN
> [5].
> 
> These tools will enable them to use the routing policy stored in the
> RIPE  routing registry to perform such tasks as check actual routing
> against policies defined, ensure consistency of policies set by dif-
> ferent operators, and simulate the effects of policy changes.
> 
> Work continues on producing more useful tools to service the  Inter-
> net community.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 10 -
> 
> 
> 4.  The Routing Registry and the RIPE Database
> 
> One of the activities of RIPE is to maintain a  database   of  Euro-
> pean   IP networks, DNS domains and their contact persons along with
> various other kinds of network management information. The  database
> content  is  public  and  can be queried using the whois protocol as
> well as retrieved as a whole.   This  supports  NICs/NOCs  all  over
> Europe  and  beyond  to  perform their respective tasks.
> 
> The RIPE database combines  both  allocation  registry  and  routing
> registry  functions.   The  RIPE  allocation  registry contains data
> about  address  space  allocated  to  specific  enterprises   and/or
> delegated  to local registries as well as data about the domain name
> space. The allocation registry is described  in  separate  documents
> [6,7] and outside the scope of this document.
> 
> 
> Database Objects
> 
> Each object in the database describes a single entity  in  the  real
> world.   This   basic  principle  means that information about  that
> entity  should  only  be  represented  in   the corresponding  data-
> base   object  and not be repeated in other objects.  The whois ser-
> vice can automatically display referenced objects where appropriate.
> 
> The types of objects stored in the RIPE database are  summarised  in
> the table below:
> 
> 
> R   Object      Describes                        References
> ____________________________________________________________________
> 
> B   person      contact persons
> 
> A   inetnum     IP address space                 person
> A   domain      DNS domain                       person
> 
> R   aut-num     autonomous system                person
>                                                  (aut-num,community)
> R   as-macro    a group of autonomous systems    person, aut-num
> R   community   community                        person
> R   route       a route being announced          aut-num, community
> 
> R   clns        CLNS address space and routing   person
> 
> 
> The first column indicates whether the object is part of the alloca-
> tion  registry (A),  the routing registry (R) or both (B).  The last
> column indicates the types of objects referenced by  the  particular
> type  of  object.   It can be seen that almost all objects reference
> contact persons.
> 
> Objects are described by attributes  value  pairs,  one   per  line.
> Objects   are   separated by empty lines. An attribute that consists
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 11 -
> 
> 
> of multiple lines should  have  the   attribute  name   repeated  on
> consecutive lines.  The information stored about network 192.87.45.0
> consists  of  three  objects,  one network  object  and  two  person
> objects and looks like this:
> 
> 
> inetnum:   192.87.45.0
> netname:   RIPE-NCC
> descr:     RIPE Network Coordination Centre
> descr:     Amsterdam, Netherlands
> country:   NL
> admin-c:   Daniel Karrenberg
> tech-c:    Marten Terpstra
> rev-srv:   ns.ripe.net
> rev-srv:   ns.eu.net
> notify:    ops at ripe.net
> changed:   tony at ripe.net 940110
> source:    RIPE
> 
> person:    Daniel Karrenberg
> address:   RIPE Network Coordination Centre (NCC)
> address:   Kruislaan 409
> address:   NL-1098 SJ Amsterdam
> address:   Netherlands
> phone:     +31 20 592 5065
> fax-no:    +31 20 592 5090
> e-mail:    dfk at ripe.net
> nic-hdl:   DK58
> changed:   ripe-dbm at ripe.net 920826
> source:    RIPE
> 
> person:    Marten Terpstra
> address:   RIPE Network Coordination Centre (NCC)
> address:   PRIDE Project
> address:   Kruislaan 409
> address:   NL-1098 SJ Amsterdam
> address:   Netherlands
> phone:     +31 20 592 5064
> fax-no:    +31 20 592 5090
> e-mail:    Marten.Terpstra at ripe.net
> nic-hdl:   MT2
> notify:    marten at ripe.net
> changed:   marten at ripe.net 931230
> source:    RIPE
> 
> 
> 
> Objects are stored and retrieved in this tag/value format.  The RIPE
> NCC  does  not  provide  differently  formatted  reports because any
> desired format can easily be produced from this generic one.
> 
> 
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 12 -
> 
> 
> Routing Registry Objects
> 
> The main objects comprising the routing registry are  "aut-num"  and
> "route",  describing  an autonomous system and a route respectively.
> It should be noted that routes not described in the routing registry
> should never be routed in the Internet itself.
> 
> The autonomous system (aut-num) object provides contact  information
> for the AS and describes the routing policy of that AS.  The routing
> policy is described by enumerating all neighbouring ASes with  which
> routing  information  is  exchanged.  For each neighbour the routing
> policy  is  described  in  terms  of  exactly  what  is  being  sent
> (announced) and allowed in (accepted).  It is important to note that
> this is exactly the part of the global policy over which an  AS  has
> direct  control.  Thus each aut-num object describes what can indeed
> be implemented and enforced locally by the AS  concerned.   Combined
> together  all  the  aut-num objects provide the global routing graph
> and permit to deduce the exact routing policy between any two ASes.
> 
> While the aut-num objects describe how routing information  is  pro-
> pagated, the route object describes a single route injected into the
> external routing mesh. The route object references the AS  injecting
> (originating)  the  route  and  thereby  indirectly provides contact
> information for the originating AS. This reference also provides the
> primary  way  of  grouping  routes  into larger collections. This is
> necessary because describing routing policy on the level  of  single
> routes would be awkward to impractical given the number of routes in
> the Internet which is about 20,000 at  the  time  of  this  writing.
> Thus  routing  policy  is most often defined for groups of routes by
> originating AS.  This  method  of  grouping  is  well  supported  by
> current  exterior  routing  protocols.  The route object also refer-
> ences community objects described below to provide another method of
> grouping  routes.   Modification  of  aut-num  object itself and the
> referencing by route objects is strictly protected to  provide  net-
> work  operators  control over the routing policy description and the
> routes originated by their ASes.
> 
> Sometimes even keeping track of groups of routes at the AS level  is
> cumbersome.  Consider  the case of policies described at the transit
> provider level which apply transitively  to  all  customers  of  the
> transit provider. Therefore another level of grouping is provided by
> the as-macro object which provides  groups  of  ASes  which  can  be
> referenced  in routing policies just like single ASes. Membership of
> as-macro groups is also strictly controlled.
> 
> Sometimes there is a need to group routes on different criteria than
> ASes  for purposes like statistics or local access policies. This is
> provided by the community object.  A community object is  much  like
> an  AS  but  without a routing policy.  It just describes a group of
> routes. This is not supported at all by exterior  routing  protocols
> and  depending  on aggregation of routes may not be generally usable
> to define routing policies.  It is suitable for local  policies  and
> non-routing related purposes.
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 13 -
> 
> 
> These routing related objects will be described  in  detail  in  the
> sections below.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 14 -
> 
> 
> 5.  The Route Object
> 
> As stated in the previous chapter routing and address space  alloca-
> tion  information are now clearly separated.  This is performed with
> the introduction of the route object. The route object will  contain
> all the information regarding a routing announcement.
> 
> All routing related attributes are removed from the inetnum  object.
> Some  old attributes are obsoleted: connect, routpr-l, bdryg-l, nsf-
> in, nsf-out, gateway).  The currently useful routing attributes  are
> moved  to  the route object: aut-sys becomes origin, ias-int will be
> encoded as part of the "to be proposed" `border-router'  object  and
> comm-list  simply moves.  See [6] for detail of the "inetnum" object
> definition.
> 
> 
> The information in the old inetnum object
> 
> inetnum:   192.87.45.0
> netname:   RIPE-NCC
> descr:     RIPE Network Coordination Centre
> descr:     Amsterdam, Netherlands
> country:   NL
> admin-c:   Daniel Karrenberg
> tech-c:    Marten Terpstra
> connect:   RIPE NSF WCW
> aut-sys:   AS3333
> comm-list: SURFNET
> ias-int:   192.87.45.80  AS1104
> ias-int:   192.87.45.6   AS2122
> ias-int:   192.87.45.254 AS2600
> rev-srv:   ns.ripe.net
> rev-srv:   ns.eu.net
> notify:    ops at ripe.net
> changed:   tony at ripe.net 940110
> source:    RIPE
> 
> 
> will be distributed over two objects:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 15 -
> 
> 
> 
> inetnum:   192.87.45.0
> netname:   RIPE-NCC
> descr:     RIPE Network Coordination Centre
> descr:     Amsterdam, Netherlands
> country:   NL
> admin-c:   Daniel Karrenberg
> tech-c:    Marten Terpstra
> rev-srv:   ns.ripe.net
> rev-srv:   ns.eu.net
> notify:    ops at ripe.net
> changed:   tony at ripe.net 940110
> source:    RIPE
> 
> route:       192.87.45.0/24
> descr:       RIPE Network Coordination Centre
> origin:      AS3333
> comm-list:   SURFNET
> changed:     dfk at ripe.net 940427
> source:      RIPE
> 
> 
> 
> The route object is used to represent a single route originated into
> the  Internet  routing mesh.  The actual syntax is given in Appendix
> D. However, there are several important aspects  of  the  attributes
> worthy of note.
> 
> 
> The value of the route attribute will be a  classless  address.   It
> represents  the  exact  route  being injected into the routing mesh.
> The representation of classless addresses is described in [10].
> 
> 
> The value of the origin attribute will be an  AS  reference  of  the
> form  AS1234  referring  to an aut-num object.  It represents the AS
> injecting this route into the routing mesh.   The  "aut-num"  object
> (see below) thus referenced provides all the contact information for
> this route.
> 
> 
> Special cases: There can only be a single  originating  AS  in  each
> route  object.   However  in  todays  Internet  sometimes a route is
> injected  by  more  than  one  AS.  This  situation  is  potentially
> dangerous  as  it  can  create conflicting routing policies for that
> route and requires coordination between the  originating  ASes.   In
> the routing registry this is represented by multiple route objects.
> 
> This is a departure from the one route (net), one  AS  principle  of
> the  ripe-81  routing  registry.  The consequences for the different
> tools based in the routing registry will need to  be  evaluated  and
> possibly additional consistency checking of the database is needed.
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 16 -
> 
> 
> The examples below will illustrate the usage  of  the  route  object
> further.   Suppose  three  chunks  of  address  space of 2 different
> enterprises represented by the following inetnum objects:
> 
> 
> Examples
> 
> 
> inetnum:   193.0.1.0
> netname:   ENT-1
> descr:     Enterprise 1
>  ...
> 
> inetnum:   193.0.8.0
> netname:   ENT-2
> descr:     Enterprise 2
>  ...
> 
> inetnum:   193.0.9.0
> netname:   ENT-2-SPEC
> descr:     Enterprise 2
>  ...
> 
> 
> Supposing that the Enterprises have their own  AS  numbers  straight
> application of routing without aggregation would yield:
> 
> 
> route:       193.0.1.0/24
> descr:       Enterprise 1
> origin:      AS1
>  ...
> 
> route:       193.0.8.0/24
> descr:       Enterprise 2
> origin:      AS2
>  ...
> 
> route:       193.0.9.0/24
> descr:       Enterprise 2
> origin:      AS2
>  ...
> 
> NB: This representation can be achieved by straight translation from
> the ripe-81 representation. See Appendix G for more details.
> 
> 
> Homogeneous Aggregation
> 
> The two chunks of address space of Enterprise 2 can  be  represented
> by one aggregate route turning two route objects into one and poten-
> tially saving routing table space for one route.
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 17 -
> 
> 
> 
> route:       193.0.8.0/23
> descr:       Enterprise 2
> origin:      AS2
>  ...
> 
> 
> Note that AS2 can also decide to originate all routes  mentioned  so
> far,  two  24-bit prefixes and one 23-bit prefix. This case would be
> represented by storing all three route objects in the  database.  In
> this particular example the additional routes will not add any func-
> tionality however and only increase the amount of  routes  announced
> unnecessarily.
> 
> 
> Heterogeneous Aggregation
> 
> Consider the following case however:
> 
> 
> route:       193.0.8.0/24
> descr:       Enterprise 2
> origin:      AS2
>  ...
> 
> route:       193.0.9.0/24
> descr:       Enterprise 2 / Special
> origin:      AS2
> comm-list:   SPECIAL
>  ...
> 
> 
> Now the prefix 193.0.9.0/24 belongs to community SPECIAL (this  com-
> munity  may  well  not  be relevant to routing) and the other prefix
> originated by AS2 does not. If AS2 aggregates  these  prefixes  into
> the  193.0.8.0/23  prefix,  routing  policies based on the community
> value SPECIAL cannot be implemented in general, because there is  no
> way  to distinguish between the special and the not-so-special parts
> of AS2.  If another AS has the  policy  to  accept  only  routes  to
> members of community SPECIAL it cannot implement it, because accept-
> ing the route to 193.0.8.0/23 would also route to  193.0.8.0/24  and
> not accepting this route would lose connectivity to the special part
> 193.0.9.0/24.  We call aggregate  routes  consisting  of  components
> belonging  to  different communities or even different ASes "hetero-
> geneous aggregates".
> 
> The problems introduced with heterogeneous aggregates are that  once
> the  homogeneous  routes  are  withdrawn  one  cannot tell if a more
> specific part of the heterogeneous has a different policy.  However,
> if  can  be counter argued that knowing this policy is of little use
> if you cannot implement a routing policy based on the less  specific
> (and  only  route  present)  heterogeneous  aggregate. In fact, this
> displays a facet of CIDR itself in that one may actually  compromise
> slight  variations  on  policy  over  announcing  a  larger  (albeit
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 18 -
> 
> 
> heterogeneous in terms of policy) aggregate to save address space.
> 
> However, it is still useful to be able to document these  variations
> in  policy  especially  when this homogeneous more specific route is
> just being withdrawn. For this one can use  the  "withdrawn"  attri-
> bute. The withdrawn attribute can serve to both indicate that a less
> specific aggregate is in fact heterogeneous and also allow the  gen-
> eral documenting of route withdrawal.
> 
> So there has to be a way for AS2 to document this even  if  it  does
> not  originate the route to 193.0.9.0/24 any more.  This can be done
> with the "withdrawn" attribute of the route object.   The  aggregate
> route to 193.0.8.0/23 is now be registered as:
> 
> 
> route:       193.0.8.0/23
> descr:       Enterprise 2
> origin:      AS2
>  ...
> 
> 
> With the two homogeneous routes marked as withdrawn from the  Inter-
> net  routing mesh but still preserving their original routing infor-
> mation.
> 
> 
> route:       193.0.8.0/24
> descr:       Enterprise 2
> origin:      AS2
> withdrawn:   940701
>  ...
> 
> route:       193.0.9.0/24
> descr:       Enterprise 2 / Special
> origin:      AS2
> comm-list:   SPECIAL
> withdrawn:   940701
>  ...
> 
> 
> It should be noted that the date value used in the withdrawn  attri-
> bute can only be in the past.
> 
> 
> Proxy Aggregation
> 
> The next step of aggregation are aggregates consisting of more  than
> one  AS.  This  generally  means  one AS is aggregating on behalf of
> another. It is called proxy aggregation. Proxy aggregation should be
> done  with  great  care  and always coordinates with other providers
> announcing the same route.
> 
> Consider the following:
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 19 -
> 
> 
> 
> route:       193.0.0.0/20
> descr:       All routes known by AS1 in a single package
> origin:      AS1
>  ...
> 
> 
> 
> route:       193.0.1.0/24
> descr:       Foo
> origin:      AS1
> withdrawn:   940310
>  ...
> 
> 
> 
> route:       193.0.8.0/24
> descr:       Bar
> origin:      AS2
> withdrawn:   940310
>  ...
> 
> 
> 
> route:       193.0.9.0/24
> descr:       Bar-2
> origin:      AS2
> withdrawn:   940310
> comm-list:   SPECIAL
>  ...
> 
> 
> 
> 
> 
> If AS1 announced no other routes to a single homed neighbouring  AS,
> that neighbour can in general either take that route or leave it but
> not differentiate between AS1 and AS2.
> 
> Note: If the neighbor was previously  configured  to  accept  routes
> originating  in  AS2 but not in AS1 they lose connectivity to AS2 as
> well.  This means that proxy aggregation has to  be  done  carefully
> and  in a well coordinated fashion. The information in the withdrawn
> route object can help to achieve that.
> 
> 
> Aggregates with Holes
> 
> If we assume that the world of our example still  consists  of  only
> three  chunks of address space the aggregate above contains what are
> called holes, parts of an aggregate that are not reachable  via  the
> originator  of  the  route.  From the routing information itself one
> cannot tell whether these are holes and what part of the route falls
> inside  one.  The only way to tell is to send a packet there and see
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 20 -
> 
> 
> whether it gets to the destination, or an ICMP message  is  received
> back,  or there is silence.  On the other hand announcing aggregates
> with holes is quite legitimate.  Consider a  16-bit  aggregate  with
> only  one  24-bit  prefix unreachable.  The savings in routing table
> size by far outweigh the hole problem.
> 
> For operational reasons however it is very useful to register  these
> holes in the routing registry. Consider the case where a remote net-
> work operator experiences connectivity problems to addresses  inside
> an aggregate route.  If the packets are getting to the AS announcing
> the aggregate and there are no  more  specific  routes,  the  normal
> cause  of  action  is to get in touch with the originating AS of the
> aggregate route and ask them to fix  the  problem.  If  the  address
> falls into a hole this is futile. Therefore problem diagnosis can be
> sped up and unnecessary calls prevented by registering the holes  in
> the  routing  registry. We do this by using the "hole" attribute. In
> our example the representation would be:
> 
> 
> route:       193.0.0.0/20
> descr:       All routes known by AS1
> origin:      AS1
> hole:        193.0.0.0/24
> hole:        193.0.2.0/23
> hole:        193.0.4.0/22
> hole:        193.0.10.0/23
> hole:        193.0.12.0/22
>  ...
> 
> 
> Note: there would also be two routes with the withdrawn attribute as
> displayed above (i.e. 193.0.8.0/24 and 193.0.9.0/24)
> 
> Multiple Proxy Aggregation
> 
> Finally suppose that AS2 decides to  announce  the  same  aggregate,
> they would add the following route object to the registry:
> 
> 
> route:       193.0.0.0/20
> descr:       All routes known by AS2
> origin:      AS2
> hole:        193.0.0.0/24
> hole:        193.0.2.0/23
> hole:        193.0.4.0/22
> hole:        193.0.10.0/23
> hole:        193.0.12.0/22
>  ...
> 
> 
> As per the update procedures below both AS1 and AS2 will be notified
> that there already is a route to the same prefix in the registry.
> 
> This multiple proxy aggregation is very dangerous to do if the  sub-
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 21 -
> 
> 
> aggregates of the route are not the same. It is still dangerous when
> the sub-aggregates are  consistent  but  connectivity  to  the  sub-
> aggregates varies widely between the originators.
> 
> 
> 
> Route object update procedures
> 
> Adding a route object will be have to be authorised by the  guardian
> of  the originating AS. The actual implementation of this is outside
> the scope of this document.  This guarantees that an AS guardian has
> full control over the registration of the routes it announces.
> 
> 
> What is an Inter-AS network ?
> 
> An inter-AS network(3) exists for the purpose of passing traffic and
> routing  information between different autonomous systems.  The most
> simple example of an inter-AS network is a point-to-point link, con-
> necting  exactly  two ASes.  Each end of such a link is connected to
> an interface of router belonging to each of the autonomous  systems.
> More  complex  examples  are  broadcast  type networks with multiple
> interfaces connecting multiple ASes with  the  possibility  of  more
> than one connection per AS.  Consider the following example of three
> routers 1, 2 and 3 with interfaces a through  f   connected  by  two
> inter-AS networks X and Y:
> 
> 
>                           X              Y
>                  a1b     ---    c2d     ---    e3f
> 
> 
> 
> Suppose that network X is registered in the routing registry as part
> of  AS1  and  net  Y  as part of AS3. If traffic passes from left to
> right prtraceroute will report the following sequence of  interfaces
> and ASes:
> 
>         a in AS1
>         c in AS1
>         e in AS3
> 
> 
> The traceroute algorithm enumerates only the receiving interfaces on
> the  way  to the destination.  In the example this leads to the pas-
> sage of AS2 going unnoticed.  This is confusing to the user and will
> also  generate exceptions when the path found is checked against the
> routing registry.
> 
> _________________________
>   (3) Inter-AS  IP  networks  are  those  networks  are
> currently  called FIXes, IXFs, DMZs, NAPs, GIX and many
> other acronyms.
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 22 -
> 
> 
> For operational monitoring tools such as prtraceroute it  is  neces-
> sary to know which interface on an inter-AS network belongs to which
> AS.  If AS information is not known about interfaces on an  inter-AS
> network,  tools  like  prtraceroute cannot determine correctly which
> ASes are being traversed.
> 
> 
> All interfaces on inter-AS networks will be described in a  separate
> object  know  as  the  `border-router'  object.  This is still to be
> defined.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 23 -
> 
> 
> 6.  The Autonomous System Object
> 
> 
> Autonomous Systems
> 
> An Autonomous System (AS) is a group of IP networks run  by  one  or
> more  network operators which has a single and clearly defined rout-
> ing policy.
> 
> An AS has a unique number associated with it which is used  both  in
> exchange of exterior routing information and as an identifier of the
> AS itself.  Exterior routing protocols such as BGP and EGP are  used
> to exchange routing information between ASes.
> 
> In routing terms an AS will normally use one or more interior  gate-
> way  protocols (IGPs) in conjunction with some sort of common agreed
> metrics when exchanging network information within its own AS.
> 
> The term AS is often confused or even misused as a convenient way of
> grouping  together  a  set  of  networks which belong under the same
> administrative umbrella even if within that group of networks  there
> are  various different routing policies.  We provide the "community"
> concept for such use.  ASes can strictly have only one single  rout-
> ing policy.
> 
> The creation of an AS should be done in a conscious and well coordi-
> nated  manner  to  avoid  creating  ASes for the sake of it, perhaps
> resulting in the worst case scenario of one AS per routing announce-
> ment.   It  should  be  noted  that  there is a limited number of AS
> numbers available. Also creating an AS may well increase the  number
> of  AS paths modern EGPs will have to keep track of. This aggravates
> what is known as "the routing table growth problem".  This may  mean
> that  by  applying the general rules for the creation and allocation
> of an AS below, some re-engineering may well  be  needed.   However,
> this  may  be the only way to actually implement the desired routing
> policy anyway.  The creation and allocation of an AS should be  done
> with the following recommendations in mind:
> 
> 
>  o   Creation of an AS is  only  required  when  exchanging  routing
>      information  with other ASes.  Some router implementations make
>      use of an AS number as a form of tagging to identify the  rout-
>      ing  process.   However,  it should be noted that this tag does
>      not need to be unique  unless  routing  information  is  indeed
>      exchanged with other ASes.
> 
> 
>  o   For a simple case of customer networks connected  to  a  single
>      service provider, the IP network should normally be a member of
>      the service providers AS.  In terms of routing  policy  the  IP
>      network has exactly the same policy as the service provider and
>      there is no need to make any distinction  in  routing  informa-
>      tion.   This idea may at first seem slightly alien to some, but
>      it highlights the clear distinction in the use of the AS number
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 24 -
> 
> 
>      as  a  representation of routing policy as opposed to some form
>      of administrative use.
> 
> 
>  o   If a network operator connects to more than one  AS  with  dif-
>      ferent  routing policies then they need to create their own AS.
>      In the case of multi-homed customer networks connected  to  two
>      service providers there are at least two different routing pol-
>      icies to a given customer network.  At this point the  customer
>      networks  will be part of a single AS and this AS would be dis-
>      tinct from either of the service providers ASes.   This  allows
>      the  customer  the ability of having a different representation
>      of policy and preference to the  different  service  providers.
>      This  is  the  ONLY case where a network operator should create
>      its own AS number.
> 
> 
>  o   As a general rule one should always try to populate the AS with
>      as many routes as possible, providing all routes conform to the
>      same routing policy.
> 
> 
> Each AS is represented in the RIPE database by both an AS object and
> the route objects representing the routes originated by the AS.  The
> AS object stores descriptive, administrative and contact information
> about  the  AS as well as the routing policies of the AS in relation
> to all neighbouring ASes.
> 
> The origin attributes of the route  objects define the set of routes
> originated  by the AS. Each route object can have exactly one origin
> attribute.  Route objects can only be created  and  updated  by  the
> "guardian"  of  the  AS and not by those immediately responsible for
> the particular routes referenced therein.  This ensures that  opera-
> tors,  especially service providers, remain in control of AS routing
> announcements.
> 
> 
> The AS object itself is used to represent a description of  adminis-
> trative  details  and  the routing policies of the AS itself. The AS
> object definition is depicted as follows.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 25 -
> 
> 
> 
> Example:
> 
> aut-num:  AS1104
> descr:    NIKHEF-H Autonomous system
> as-in:    from AS1213 100 accept AS1213
> as-in:    from AS1913 100 accept AS1913
> as-in:    from AS1755 150 accept ANY
> as-out:   to AS1213 announce ANY
> as-out:   to AS1913 announce ANY
> as-out:   to AS1755 announce AS1104 AS1913 AS1213
> tech-c:   Rob Blokzijl
> admin-c:  Eric Wassenaar
> guardian: as-guardian at nikhef.nl
> changed:  ripe-dbm at ripe.net 920910
> source:   RIPE
> 
> 
> 
> See Appendix A for a complete syntax  definition  of  the  "aut-num"
> object.
> 
> 
> It should be noted that this representation provides two things:
> 
>     o a set of routes.
> 
>     o a description of administrative details and routing policies.
> 
> The set of routes can be used to generate network list based  confi-
> guration  information as well as configuration information for exte-
> rior routing protocols knowing about ASes. This means an AS  can  be
> defined  and  is  useful  even  if it does not use routing protocols
> which know about the AS concept.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 26 -
> 
> 
> Description  of  local  connections   between   ASes   -   "interas-
> in/interas-out".
> 
> Often two ASes will have more than one physical  connection  between
> them.  In  practice  certain  local  policies  my be placed on these
> inter-AS connections as agreed by the two ASes. If we  look  at  the
> simple example below.
> 
> Example:
> 
> 
>              LINK1
>           +----------+
>           |a        b|
> AS1------AS2        AS3-----AS4
>           |c        d|
>           +----------+
>              LINK2
> 
> 
> It may be that AS2 prefers to get to AS3 on LINK1 (a and b being the
> interface addresses of this link) and to AS4 on LINK2 (c and d being
> the interface addresses of this link) with LINK2  as  a  backup  for
> AS3.  Whilst this is purely of local information and at the AS level
> will have no significance per se to any other ASes  except  AS2  and
> AS3  this  may  be  useful  to represent. The way this is done is by
> using the attributes "interas-in" and "interas-out". The exact  syn-
> tax  is  given  in  Appendix  A.  However, if we follow this example
> through in terms of AS2 we would represent this policy as follows:
> 
> 
> Example:
> 
> 
> SYNTAX TO BE PROPOSED BY MERIT
> 
> 
> 
> Here we see additional local link based information in terms of  the
> IP addresses of the link (in this example represented by a and b and
> c and d respectively). It should be noted  that  the  preference  on
> interas-in attributes is only of relevance to other interas-in lines
> and not to as-in lines. Of  course  this  type  on  inter-AS  policy
> should  always be bilaterally agreed to avoid asymmetry and in prac-
> tice there may need to be corresponding interas-in attributes in the
> policy representation of AS3. It should also be noted that there are
> no interas-out attributes defined. In this case the  general  policy
> is assumed.
> 
> The key difference between  interas-in/interas-out  and  as-in/as-in
> attributes  is  the former describes a local inter-AS policy and the
> latter the general inter-AS policy as seen by other ASes.  The  gen-
> eral  policy  should  always  be  defined. The local inter-AS policy
> should only be defined when such a  policy  really  exists  and  the
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 27 -
> 
> 
> implications of setting such policies is fully understood.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 28 -
> 
> 
> How to describe the exclusion policy of a certain AS - "as-exclude"
> 
> Some ASes have a routing policy based on the  exclusion  of  certain
> routes  if  for  whatever  reason  a  certain AS is used as transit.
> Whilst, this is in general not good practice as  it  makes  implicit
> assumptions  on  topology  with  asymmetry a possible outcome if not
> coordinated, this case needs to be accommodated within  the  routing
> policy representation.
> 
> The way this is achieved is by making use of the "as-exclude" attri-
> bute.  The precise syntax of this attribute can be found in Appendix
> A along with the rest  of  the  defined  syntax  for  the  "aut-num"
> object.  However,  some  explanation of the use of this attribute is
> useful. If we have the following example topology.
> 
> Example:
> 
> 
>            AS4--------AS3
>  |          |          |
>  |          |          |
> AS1--------AS2--------AS5
> 
> 
> With a simple corresponding policy like so:
> 
> 
> Example:
> 
> aut-num: AS1
> as-in:  from AS2 100 accept ANY
> as-out: to AS2 announce AS1
> as-exclude: exclude AS4 to ANY
>  ....
> 
> 
> We see an interesting policy. What this says in simple terms is  AS1
> doesn't want to reach anything if it transit AS4. This can be a per-
> fectly valid policy. However, it should be realised that  for  what-
> ever reason AS2 decides to route to AS3 via AS4 then immediately AS1
> has no connectivity to AS3 or if AS1 is running default to AS2 pack-
> ets from AS1 will still flow via AS4. The important point about this
> is that whilst AS1 can advise its neighbours of its policy it has no
> direct  control  on  how  it  can  enforce this policy to neighbours
> upstream.
> 
> Another interesting scenario to highlight the unexpected  result  of
> using such an "as-exclude" policy. If we assume in the above example
> AS2 preferred AS4 to reach AS3 and AS1 did not use  default  routing
> then  as stated AS1 would have no connectivity to AS3. Now lets sup-
> pose that for example the link between AS2 and  AS4  went  down  for
> some reason. Like so:
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 29 -
> 
> 
> 
> Example:
> 
> 
> 
>            AS4--------AS3
>                        |
>                        |
> AS1--------AS2--------AS5
> 
> 
> Suddenly AS1 now has connectivity to AS3. This  unexpected  behavior
> should be considered when created policies based on the "as-exclude"
> attribute.
> 
> The second problem with this type of  policy  is  the  potential  of
> asymmetry.  In  the  original example we saw the correct policy from
> AS1's point of view but if ASes with connectivity through AS4 do not
> use  a similar policy you have asymmetric traffic and policy.  If an
> AS uses such a policy they must be aware of the consequences of  its
> use.  Namely  that  the  specified routes which transit the AS (i.e.
> routing announcements with this AS in the AS  path  information)  in
> question will be excluded.  If not coordinated this can easily cause
> asymmetry or even worse loss of connectivity to unknown ASes  behind
> (or in front for that matter) the transit AS in question.  With this
> in mind this attribute can only be viewed as a form of  advisory  to
> other  service  providers.  However,  this does not preclude its use
> with policy based tools if the attribute exists.
> 
> By having the ability to specify a route keyword based on any of the
> four  notations  given  in  the syntax it allows the receiving AS to
> specify what routes it wishes to exclude through a given transit  AS
> to a network granularity.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 30 -
> 
> 
> 7.  AS Macros
> 
> It may be difficult to keep track of each and every new AS  that  is
> represented  in  the routing registry.  A convenient way around this
> is to define an `AS Macro' which essentially is a convenient way  to
> group ASes. This is done so that each and every AS guardian does not
> have to add a new AS to it's routing policy as described by the  as-
> in and as-out attributes of it's AS object.
> 
> However, it should be noted that this creates an implicit  trust  on
> the guardian of the AS-Macro.
> 
> An AS-Macro can be used in  <routing  policy  expressions>  for  the
> "as-in"  and "as-out" attributes in the aut-num object. The AS-Macro
> object is then used to derive the list or group of ASes.
> 
> A simple example would be something like:
> 
> 
> Example:
> 
> aut-num: AS786
> as-in:   from AS1755 100 accept AS-EBONE AND NOT AS1104
> as-in:   from AS1755 100 accept AS-EBONE AND NOT AS1104
> as-out   to AS1755 announce AS786
>  .....
> 
> 
> Where the as-macro object for AS-EBONE is as follows:
> 
> 
> as-macro:  AS-EBONE
> descr:     ASes routed by EBONE
> as-list:   AS2121 AS1104 AS2600 AS2122
> as-list:   AS1103 AS1755 AS2043
> guardian:  guardian at ebone.net
>  ......
> 
> 
> So the policy would be evaluated to:
> 
> 
> aut-num: AS786
> as-in:   from AS1755 100 accept (AS2121 OR AS1104 OR AS2600 OR AS2122
> as-in:   from AS1755 100 accept AS1103 OR AS1755 OR AS2043) AND NOT AS1104
>  ......
> 
> 
> It should be noted that the above examples incorporates the rule for
> line wrapping as defined in Appendix A for policy lines.  See Appen-
> dix C for a definition on the AS-Macro syntax.
> 
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 31 -
> 
> 
> 8.  The Community Object
> 
> A community is a group of routes that cannot be represented by an AS
> or  a group of ASes.  It is in some circumstances useful to define a
> group of routes that have something in common.  This could be a spe-
> cial access policy to a supercomputer centre, a group of routes used
> for a specific mission, or a disciplinary group  that  is  scattered
> among  several  autonomous systems.  Also these communities could be
> useful to group routes for the purpose of network statistics.
> 
> Communities do not exchange routing information, since they  do  not
> represent  an  autonomous system.  More specifically, communities do
> not define routing policies, but access or usage policies.  However,
> they  can  de  used as in conjunction with an ASes routing policy to
> define a set of routes the AS sets routing policy for.
> 
> Communities should be defined in a strict manner, to avoid  creating
> as many communities as there are routes, or even worse.  Communities
> should be defined following the two rules below;
> 
> 
>  o   Communities must have a global meaning.  Communities that  have
>      no  global  meaning,  are  used only in a local environment and
>      should be avoided.
> 
> 
>  o   Communities  must not be defined to express non-local policies.
>      It  should  be avoided that a community is created because some
>      other organisation forces  a  policy  upon  your  organisation.
>      Communities must only be defined to express a policy defined by
>      your organisation.
> 
> 
> 
> Community examples
> 
> There are some clear examples of communities:
> 
> 
> BACKBONE -
>      all customers of a given backbone service provider even  though
>      they  can  have  various  different  routing policies and hence
>      belong to different ASes. This would be  extremely  useful  for
>      statistics collection.
> 
> 
> HEPNET -
>      the High Energy Physics community partly shares  infrastructure
>      with other organisations, and the institutes it consists of are
>      scattered all over Europe, often being part  of  a  non  HEPNET
>      autonomous  system.  To  allow  statistics, access or part of a
>      routing policy , a community HEPNET, consisting of  all  routes
>      that are part of HEPNET, conveniently groups all these routes.
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 32 -
> 
> 
> NSFNET -
>      the National Science Foundation Network imposes  an  acceptable
>      use  policy  on routes that wish to make use of it. A community
>      NSFNET could imply the set of routes that comply with this pol-
>      icy.
> 
> 
> MULTI -
>      a large multinational corporation that does not  have  its  own
>      internal  infrastructure,  but connects to the various parts of
>      its organisations by using local service providers that connect
>      them all together, may decide to define a community to restrict
>      access to their networks, only by networks  that  are  part  of
>      this  community.  This way a corporate network could be defined
>      on shared infrastructure. Also, this community could be used by
>      any  of the service providers to do statistics for the whole of
>      the corporation, for instance to do topology or bandwidth plan-
>      ning.
> 
> 
> Similar to Autonomous systems, each community is represented in  the
> RIPE  database  by both a community object and community tags on the
> route objects representing the routes belonging  to  the  community.
> The  community object stores descriptive, administrative and contact
> information about the community.
> 
> The community tags on the route objects define  the  set  of  routes
> belonging to a community.  A route can have multiple community tags.
> The community tags can only be created and updated by the "guardian"
> of  the community and not by those directly responsible for the par-
> ticular network.  This ensures that guardians remain in  control  of
> community membership.
> 
> Here's an example of how this might be represented in terms  of  the
> community  tags within the network object.  We have an example where
> the route 192.16.199.0/24 has a single routing policy (i.e.  that of
> AS  1104), but is part of several different communities of interest.
> We use the tag "comm-list" to  represent  the  list  of  communities
> associated  with  this  route.   NIKHEF-H  uses the service provider
> SURFNET (a service provider with customers with more than one  rout-
> ing  policy),  is  also part of the High Energy Physics community as
> well as having the ability to access the Supercomputer at CERN(4).
> 
> 
> 
> 
> 
> 
> 
> _________________________
> (4) The community `CERN-SUPER', is  somewhat  national,
> but  is  intended as an example of a possible use of an
> access policy constraint.
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 33 -
> 
> 
> 
> Example:
> 
> route:     192.16.199.0/24
> descr:     Local Ethernet
> descr:     NIKHEF section H
> origin:    AS1104
> comm-list: HEPNET CERN-SUPER SURFNET
> changed:   ripe-dbm at ripe.net 920604
> source:    RIPE
> 
> 
> 
> In the above examples some communities have been defined.  The  com-
> munity object itself will take the following format:
> 
> 
> Example:
> 
> community:  SURFNET
> descr:      Dutch academic research network
> authority:  SURFnet B.V.
> guardian:   comm-guardian at surfnet.nl
> admin-c:    Erik-Jan Bos
> tech-c:     Erik-Jan Bos
> changed:    ripe-dbm at ripe.net 920604
> source:     RIPE
> 
> For a complete explanation of the syntax please refer to Appendix B.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 34 -
> 
> 
> 9.  Representation of Routing Policies
> 
> 
> Routing policies of an AS are represented in the  autonomous  system
> object.  Initially  we show some examples, so the reader is familiar
> with the concept of how routing information is represented, used and
> derived.  Refer  to Appendix A, for the full syntax of the "aut-num"
> object.
> 
> The topology of routing exchanges  is  represented  by  listing  how
> routing information is exchanged with each neighbouring AS.  This is
> done separately for both incoming and outgoing routing  information.
> In  order  to  provide backup and back door paths a relative cost is
> associated with incoming routing information.
> 
> 
> Example 1:
> 
> 
>                             AS1------AS2
> 
> 
> This specifies a simple routing exchange of two presumably  isolated
> ASes.   Even  if either of them has routing information about routes
> in ASes other than AS1 and AS2, none of that will  be  announced  to
> the other.
> 
> aut-num:   AS1
> as-out:    to AS2 announce AS1
> as-in:     from AS2 100 accept AS2
> 
> aut-num:   AS2
> as-out:    to AS1 announce AS2
> as-in:     from AS1 100 accept AS1
> 
> 
> The number 100 in the in-bound specifications is  a  relative  cost,
> which is used for backup and back door routes. The absolute value is
> of no significance. The relation between different values within the
> same  AS object is.  A lower value means a lower cost. This is cons-
> ciously similar to the cost based preference scheme used with DNS MX
> RRs.
> 
> 
> Example 2:
> 
> Now suppose that AS2 is connected to one more AS, besides  AS1,  and
> let's call that AS3:
> 
> 
> 
>                        AS1------AS2------AS3
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 35 -
> 
> 
> In this case there are two reasonable routing policies:
> 
>   a) AS2 just wants to exchange traffic with both AS1 and AS3 itself
>      without passing traffic between AS1 and AS3.
> 
>   b) AS2 is willing to pass traffic between AS3 and AS1, thus acting
>      as a transit AS
> 
> 
> Example 2a:
> 
> In the first case AS1's representation in the routing registry  will
> remain  unchanged  as  will  be  the  part  of  AS2's representation
> describing the routing exchange with AS1. A description of the addi-
> tional  routing exchange with AS3 will be added to AS2's representa-
> tion:
> 
> 
> aut-num:   AS1
> as-out:    to AS2 announce AS1
> as-in:     from AS2 100 accept AS2
> 
> aut-num:   AS2
> as-out:    to AS1 announce AS2
> as-in:     from AS1 100 accept AS1
> as-out:    to AS3 announce AS2
> as-in:     from AS3 100 accept AS3
> 
> aut-num:   AS3
> as-out:    to AS2 announce AS3
> as-in:     from AS2 100 accept AS2
> 
> 
> Note  that  in  this  example,  AS2  keeps  full  control  over  its
> resources.   Even if AS3 and AS1 were to allow each others routes in
> from AS2, the routing information would not flow because AS2 is  not
> announcing it(5).
> 
> 
> Example 2b:
> 
> If contrary to the previous case, AS1 and AS3 are supposed  to  have
> connectivity to each other via AS2, all AS objects have to change:
> 
> 
> 
> 
> _________________________
> (5) Of course AS1 and AS3 could just  send  traffic  to
> each  other  to  AS2  even  without  AS2 announcing the
> routes, hoping that AS2 will forward it correctly. Such
> questionable  practices however are beyond the scope of
> this document.
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 36 -
> 
> 
> 
> aut-num:   AS1
> as-out:    to AS2 announce AS1
> as-in:     from AS2 100 accept AS2 AS3
> 
> aut-num:   AS2
> as-out:    to AS1 announce AS2 AS3
> as-in:     from AS1 100 accept AS1
> as-out:    to AS3 announce AS2 AS1
> as-in:     from AS3 100 accept AS3
> 
> aut-num:   AS3
> as-out:    to AS2 announce AS3
> as-in:     from AS2 100 accept AS1 AS2
> 
> 
> 
> Note that the amount of routing information exchanged with a  neigh-
> bour  AS  is  defined  in terms of routes belonging to ASes.  In BGP
> terms this is the AS where the routing  information  originates  and
> the  originating  AS  information  carried  in  BGP could be used to
> implement the desired policy.  However, using BGP or the BGP AS-path
> information  is  not  required to implement the policies thus speci-
> fied.  Configurations based on route lists can easily  be  generated
> from  the  database.   The  AS path information, provided by BGP can
> then be used as an additional checking tool as desired.
> 
> The specification understands one special expression and this can be
> expressed as a boolean expressions:
> 
> 
> ANY - means any routing information known.  For  output  this  means
>      that  all  routes an AS knows about are announced. For input it
>      means that anything is accepted from the neighbour AS.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 37 -
> 
> 
> Example 3:
> 
> AS4 is a stub customer AS, which  only  talks  to  service  provider
> AS123.
> 
> 
>                                 |
>                                 |
>                         -----AS123------AS4
>                                 |
>                                 |
> 
> 
> 
> aut-num: AS4
> as-out:  to AS123 announce AS4
> as-in:   from AS123 100 accept ANY
> 
> aut-num: AS123
> as-in:   from AS4 100 accept AS4
> as-out:  to AS4 announce ANY
> <further neighbours>
> 
> 
> 
> Since AS4 has no other way to reach the outside world than AS123  it
> is  not  strictly necessary for AS123 to send routing information to
> AS4.  AS4 can simply send all traffic for which it has  no  explicit
> routing  information  to  AS123 by default.  This strategy is called
> default routing.  It is expressed in the routing registry by  adding
> one  or  more  default tags to the autonomous system which uses this
> strategy.  In the example above this would look like:
> 
> 
> aut-num: AS4
> as-out:  to AS123 announce AS4
> default: AS123 100
> 
> aut-num: AS123
> as-in:   from AS4 100 accept AS4
> <further neighbours>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 38 -
> 
> 
> Example 4:
> 
> AS4 now connects to a different operator, AS5.  AS5 uses  AS123  for
> outside  connectivity  but has itself no direct connection to AS123.
> AS5 traffic to and from AS123 thus has to pass AS4.  AS4  agrees  to
> act as a transit AS for this traffic.
> 
> 
>                           |
>                           |
>                    -----AS123------AS4-------AS5
>                           |
>                           |
> 
> 
> 
> aut-num:    AS4
> as-out:     to AS123 announce AS4 AS5
> as-in:      from AS123 100 accept ANY
> as-out:     to AS5 announce ANY
> as-in:      from AS5 50 accept AS5
> 
> aut-num:    AS5
> as-in:      from AS4 100 accept ANY
> as-out:     to AS4 announce AS5
> 
> aut-num:    AS123
> as-in:      from AS4 100 accept AS4 AS5
> as-out:     to AS4 announce ANY
> <further neighbours>
> 
> 
> 
> Now AS4 has two sources of external routing information.  AS5  which
> provides  only information about its own routes and AS123 which pro-
> vides information about the external world. Note  that  AS4  accepts
> information  about AS5 from both AS123 and AS5 although AS5 informa-
> tion cannot come from AS123 since AS5  is  connected  only  via  AS4
> itself.  The  lower  cost of 50 for the announcement from AS5 itself
> compared to 100 from AS123 ensures that AS5 is still  believed  even
> in case AS123 will unexpectedly announce AS5.
> 
> In this example too, default routing can be used by AS5 much like in
> the  previous  example.   AS4  can  also use default routing towards
> AS123:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 39 -
> 
> 
> 
> aut-num:    AS4
> as-out:     to AS123 announce AS4 AS5
> default:    AS123 11
> as-in:      from AS5 50 accept AS5
> 
> Note no announcements to AS5, they default to us.
> 
> aut-num:    AS5
> as-out:     to AS4 announce AS5
> default:    AS4 100
> 
> aut-num:    AS123
> as-in:      from AS4 100 announce AS4 AS5
> <further neighbours>
> 
> 
> Note that the relative  cost  associated  with  default  routing  is
> totally  separate  from  the  relative cost associated with in-bound
> announcements.  The default route will never be taken if an explicit
> route is known to the destination.  Thus an explicit route can never
> have a higher cost than the default route.  The relative cost  asso-
> ciated  with  the  default route is only useful in those cases where
> one wants to configure multiple default routes for redundancy.
> 
> Note also that in  this  example  the  configuration  using  default
> routes  has  a  subtly different behavior than the one with explicit
> routes: In case the AS4-AS5 link fails AS4 will send traffic to  AS5
> to  AS123  when using the default configuration. Normally this makes
> not much difference as there will  be  no  answer  and  thus  little
> traffic.   With  certain  datagram applications which do not require
> acknowledgments however, significant amounts of traffic may be  use-
> lessly  directed  at AS123.  Similarly default routing should not be
> used if there are stringent security policies  which  proscribe  any
> traffic intended for AS5 to ever touch AS123.
> 
> Generally it can be said that default routing should only be used in
> very  simple topologies.  Once the situation gets more complex using
> default routes can lead to unexpected results  or  even  defeat  the
> routing policies established when links fail. As an example consider
> how Example 5a) below could be implemented using default routing.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 40 -
> 
> 
> Example 5:
> 
> In a different example AS4 has a private connection to AS6 which  in
> turn is connected to the service provider AS123:
> 
> 
>                                |
>                                |
>                         -----AS123------AS4
>                                |          |
>                                |          |
>                                |          |
>                              AS6 ---------+
> 
> 
> There are a number of policies worth examining in this case:
> 
> 
>   a) AS4  and  AS6  wish  to  exchange  traffic  between  themselves
>      exclusively  via  the  private  link  between  themselves; such
>      traffic should never pass through the  backbone  (AS123).   The
>      link should never be used for transit traffic, i.e. traffic not
>      both originating in and destined for AS4 and AS6.
> 
> 
>   b) AS4 and AS6 wish to exchange traffic between themselves via the
>      private link between themselves.  Should the link fail, traffic
>      between AS4 and AS6 should  be  routed  via  AS123.   The  link
>      should never be used for transit traffic.
> 
> 
>   c) AS4 and AS6 wish to exchange traffic between themselves via the
>      private link between themselves.  Should the link fail, traffic
>      between AS4 and AS6 should be routed  via  AS123.   Should  the
>      connection between AS4 and AS123 fail, traffic from AS4 to des-
>      tinations behind AS123 can pass through the  private  link  and
>      AS6's connection to AS123.
> 
> 
>   d) AS4 and AS6 wish to exchange traffic between themselves via the
>      private link between themselves.  Should the link fail, traffic
>      between AS4 and AS6 should be routed  via  AS123.   Should  the
>      backbone  connection  of either AS4 or AS6 fail, the traffic of
>      the disconnected AS should flow via  the  other  AS's  backbone
>      connection.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 41 -
> 
> 
> Example 5a:
> 
> 
> 
> aut-num:   AS4
> as-in:     from AS123 100 accept NOT AS6
> as-out:    to AS123 announce AS4
> as-in:     from AS6 50 accept AS6
> as-out:    to AS6 announce AS4
> 
> aut-num:   AS123
> as-in:     from AS4 100 accept AS4
> as-out:    to AS4 announce ANY
> as-in:     from AS6 100 accept AS6
> as-out:    to AS6 announce ANY
> <further neighbours>
> 
> aut-num:    AS6
> as-in:      from AS123 100 accept NOT AS4
> as-out:     to AS123 announce AS6
> as-in:      from AS4 50 accept AS4
> as-out:     to AS4 announce AS6
> 
> 
> 
> Note that here the configuration  is  slightly  inconsistent.  AS123
> will announce AS6 to AS4 and AS4 to AS6. These announcements will be
> filtered out on the receiving end.  This will implement the  desired
> policy.  Consistency checking tools might flag these cases however.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 42 -
> 
> 
> Example 5b:
> 
> 
> 
> aut-num:   AS4
> as-in:     from AS123 100 accept ANY
> as-out:    to AS123 announce AS4
> as-in:     from AS6 50 accept AS6
> as-out:    AS6 AS4
> 
> aut-num:   AS123
> as-in:     AS4 100 AS4
> as-out:    AS4 ANY
> as-in:     AS6 100 AS6
> as-out:    AS6 ANY
> <further neighbours>
> 
> aut-num:   AS6
> as-in:     from AS123 100 accept ANY
> as-out:    to AS123 announce AS6
> as-in:     from AS4 50 accept AS4
> as-out:    to AS4 announce AS6
> 
> 
> 
> The thing to note here is that in the ideal operational  case,  `all
> links  working'  AS4  will  receive  announcements for AS6 from both
> AS123 and AS6 itself.  In this case the announcement from  AS6  will
> be  preferred  because  of  its lower cost and thus the private link
> will be used as desired.  AS6 is configured as a mirror image.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 43 -
> 
> 
> Example 5c:
> 
> The new feature here is that should the connection between  AS4  and
> AS123  fail,  traffic from AS4 to destinations behind AS123 can pass
> through the private link and AS6's connection to AS123.
> 
> 
> aut-num:  AS4
> as-in:    from AS123 100 accept ANY
> as-out:   to AS123 announce AS4
> as-in:    from AS6 50 accept AS6
> as-in:    from AS6 110 accept ANY
> as-out:   to AS6 AS4
> 
> aut-num:  AS123
> as-in:    from AS4 1 accept AS4
> as-out:   to AS4 announce ANY
> as-in:    from AS6 1 accept AS6
> as-in:    from AS6 2 accept AS4
> as-out:   to AS6 announce ANY
> <further neighbours>
> 
> aut-num:  AS6
> as-in:    from AS123 100 accept ANY
> as-out:   to AS123 AS6 announce AS4
> as-in:    from AS4 50 accept AS4
> as-out:   to AS4 announce ANY
> 
> 
> 
> Note that it is important to make sure to propagate routing informa-
> tion  for  both  directions in backup situations like this.  Connec-
> tivity in just one direction is not useful at  all  for  almost  all
> applications.
> 
> Note also that in case the AS6-AS123  connection  breaks,  AS6  will
> only be able to talk to AS4. The symmetrical case (5d) is left as an
> exercise to the reader.
> 
> 10.  Future Extensions
> 
> We envision that over time the requirements for  describing  routing
> policy will evolve. The routing protocols will evolve to support the
> requirements and the routing policy description syntax will need  to
> evolve  as well. For that purpose, a separate document will describe
> experimental syntax definitions for policy description.  This  docu-
> ment  will be updated when new objects or attributes are proposed or
> modified.
> 
> Two new attributes of the AS object which are proposed and supported
> by the Merit Routing Registry are as-transit and db-selector.
> 
> as-transit describes the transit preferences of an AS.  It allows an
> AS  to  describe  its  path  preference  in  order  to reach certain
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 44 -
> 
> 
> destinations.  The AS(s) specified in the path preference may or may
> not  be  an  immediate  neighbor of the AS defined in the AS object.
> as-transit accommodates policy decisions involving AS  path  whereas
> as-in  and as-out do not.  It is not unusual for ASs to have routing
> policies which involve path selection based on AS.  Emerging  proto-
> cols like SDRP [13] will allow an AS to choose a path independent of
> a neighboring ASs path choice. as-transit permits descriptions based
> on AS path selection.
> 
> The DataBase Selector (db-selector)  function  allows  one  to  take
> advantage of information registered in other Registries.  It permits
> the selection of networks in a database based on  their  attributes.
> It  is  proposed to be used within the as-in/as-out attribute family
> to make the description of policy concise.  For example,  if  an  AS
> has  the policy of not accepting any routes from country XYZ, the AS
> can use the db-selector to check a database which has a network  and
> country  attribute and relate that information to the information in
> the routing registry. The advantage of referencing another  database
> is  that the routing registry will avoid duplicating the information
> maintained in other information registries.
> 
> Detailed examples and syntax are described in document ???? [14].
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 45 -
> 
> 
> 11.  References
> 
> [1]  Bates, T.,  Jouanigot,  J-M.,  Karrenberg,  D.,  Lothberg,  P.,
>      Terpstra,  M.,  "Representation  of  IP Routing Policies in the
>      RIPE Database", RIPE-81, February 1993.
> 
> [2]  Merit Network Inc.,"Representation of Complex Routing  Policies
>      of an Autonomous System", DRAFT, March, 1994.
> 
> [3]  PRIDE Tools Release 1.
>      See ftp.ripe.net:pride/tools/pride-tools-1.tar.Z.
> 
> [4]  Merit Inc. RRDB Tools.
>      See rrdb.merit.edu:pub/meritrr/*
> 
> [5]  The Network List Compiler.
>      See dxcoms.cern.ch:pub/ripe-routing-wg/nlc-2.2d.tar
> 
> [6]  Lord, A., Terpstra, M., "RIPE Database  Template  for  Networks
>      and Persons", DRAFT, May 1994.
> 
> [7]  Karrenberg, D., "RIPE Database Template for Domains",  RIPE-49,
>      April 1992.
> 
> [8]  Lougheed, K., Rekhter, Y., "A Border Gateway Protocol  3  (BGP-
>      3)", RFC1267, October 1991.
> 
> [9]  Rekhter, Y., Li, T., "A Border  Gateway  Protocol  4  (BGP-4)",
>      INTERNET-DRAFT, draft-ietf-bgp-bgp4-10.txt, May 1994.
> 
> [10] Bates, T., Karrenberg, D., Terpstra, M., "Support for Classless
>      Internet Addresses in the RIPE Database", DRAFT, May 1994.
> 
> [11] Karrenberg, D., "Authorisation and Notification of  Changes  in
>      the RIPE Database", RIPE-96, October 1993.
> 
> [12] Bates, T., "Support of Guarded fields  within  the  RIPE  Data-
>      base", ripe-108, February 1994.
> 
> [13] Estrin, D., Li, T., Rekhter, Y., Varadhan, K.,  "Source  Demand
>      Routing:  Packet  Format  and Forwarding Specification (Version
>      1)", INTERNET-DRAFT, draft-ietf-sdr-sdrp-04.txt, March 1994.
> 
> [14] ?????, "Experimental Objects and  attributes  for  the  Routing
>      Registry, ???, ????.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 46 -
> 
> 
> 12.  Author's Addresses
> 
> 
> Tony Bates
> RARE/PRIDE Project
> c/o RIPE Network Coordination Centre
> Kruislaan 409
> NL-1098 SJ Amsterdam
> The Netherlands
> +31 20 592 5064
> T.Bates at ripe.net
> 
> 
> Elise Gerich
> The University of Michigan
> Merit Computer Network
> 1075 Beal Avenue
> Ann Arbor, MI 48109
> USA
> +1 313 936 2120
> epg at merit.edu
> 
> 
> Laurent Joncheray
> The University of Michigan
> Merit Computer Network
> 1075 Beal Avenue
> Ann Arbor, MI 48109
> USA
> +1 313 936 2065
> lpj at merit.edu
> 
> 
> Jean-Michel Jouanigot
> CERN, European Laboratory for Particle Physics
> CH-1211 Geneva 23
> Switzerland
> +41 22 767 4417
> Jean-Michel.Jouanigot at cern.ch
> 
> 
> Daniel Karrenberg
> RIPE Network Coordination Centre
> Kruislaan 409
> NL-1098 SJ Amsterdam
> The Netherlands
> +31 20 592 5065
> D.Karrenberg at ripe.net
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 47 -
> 
> 
> 
> Marten Terpstra
> PRIDE Project
> c/o RIPE Network Coordination Centre
> Kruislaan 409
> NL-1098 SJ Amsterdam
> The Netherlands
> +31 20 592 5064
> M.Terpstra at ripe.net
> 
> 
> Jessica Yu
> The University of Michigan
> Merit Computer Network
> 1075 Beal Avenue
> Ann Arbor, MI 48109
> USA
> +1 313 936 2655
> jyy at merit.edu
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 48 -
> 
> 
> Appendix A - Syntax for the aut-num object.
> 
> Here is a summary of the tags associated with aut-num object  itself
> and  their  status.  The  first  column specifies the attribute, the
> second column whether this attribute is  mandatory  in  the  aut-num
> object,  and  the  third  column whether this specific attribute can
> occur only once per object [single], or more than  once  [multiple].
> When  specifying  multiple  lines  per attribute, the attribute name
> must be repeated. See [6] the example for the descr: attribute.
> 
> 
> aut-num:      [mandatory]          [single]
> descr:        [mandatory]          [multiple]
> as-in:        [optional]           [multiple]
> as-out:       [optional]           [multiple]
> interas-in:   [optional]           [multiple]
> interas-out:  [optional]           [multiple]
> as-exclude:   [optional]           [multiple]
> default:      [optional]           [multiple]
> tech-c:       [mandatory]          [multiple]
> admin-c:      [mandatory]          [multiple]
> guardian:     [mandatory]          [single]
> remarks:      [optional]           [multiple]
> notify:       [optional]           [multiple]
> maintainer:   [optional]           [single]
> changed:      [mandatory]          [multiple]
> source:       [mandatory]          [single]
> 
> 
> Each attribute has the following syntax:
> 
> 
> aut-num:
>      The autonomous system number.  This must be  a  uniquely  allo-
>      cated   autonomous  system number from an AS registry (i.e. the
>      RIPE NCC, the Inter-NIC, etc).
> 
>      Format:
>           AS<positive integer between 1 and 65535>
> 
>      Example:
> 
>           aut-num: AS1104
> 
>      Status: mandatory, only one line allowed
> 
> descr:
>      A short description of the Autonomous System.
> 
>      Format:
>           free text
>      Status: mandatory, multiple lines allowed
> 
> as-in:
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 49 -
> 
> 
> 
>      Example:
> 
>           descr: NIKHEF section H
>           descr: Science Park Watergraafsmeer
>           descr: Amsterdam
> 
>      A description of accepted routing information between AS peers.
> 
>      Format:
>           from <aut-num> <cost> accept <routing policy expression>
> 
>           The keywords from and accept are optional and can be omit-
>           ted.
> 
>           <aut-num> refers to your AS neighbour.
> 
>           <cost> is a positive integer used to  express  a  relative
>           cost  of  routes learned. The lower the cost the more pre-
>           ferred the route.
> 
>           <routing policy expression> can take  the  following  for-
>           mats.
> 
>           1.   A list of one or more ASes, AS Macros, Communities or
>                Network Lists.
> 
>                A Network List is a list of network numbers in prefix
>                length format, separated by commas, and surrounded by
>                curly brackets.
> 
> 
>                Examples:
> 
>                     as-in: from AS1103 100 accept AS1103
>                     as-in: from AS786  105 accept AS1103
>                     as-in: from AS786   10 accept AS786 HEPNET
>                     as-in: from AS1755 110 accept AS1103 AS786
>                     as-in: from AS3333 100 accept {192.87.45.0/16, 128.141.0.0/16}
> 
> 
>           2.   A  set  of  KEYWORDS.   The  following   KEYWORD   is
>                currently defined:
> 
> 
>                ANY  this means anything the neighbour AS knows.
> 
>           3.   A logical expression of  either  1  or  2  above  The
>                current logical operators are defined as:
> 
>                AND
>                OR
>                NOT
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 50 -
> 
> 
>                NOTE: if no logical operator is given  between  ASes,
>                AS-macros, Communities, Network Lists and KEYWORDS it
>                is implicitly evaluated as an `OR' operation.  The OR
>                can be left out for conciseness.
>                Rules are grouped together using parenthesis i.e  "("
>                and ")".
> 
>                Example:
> 
>                     as-in: from AS1755 100 accept ANY AND NOT (AS1234 OR AS513)
>                     as-in: from AS1755 150 accept AS1234 OR {35.0.0.0/8}
> 
>                     A rule can be wrapped over lines  providing  the
>                     associated <aut-num>, <cost> values and from and
>                     accept keywords are repeated and occur  on  con-
>                     secutive lines.
> 
>                Example:
> 
>                     as-in: from AS1755 100 accept ANY AND NOT (AS1234 AS513)
> 
>                        and
> 
>                     as-in: from AS1755 100 accept ANY AND NOT (
>                     as-in: from AS1755 100 accept AS1234 AS513)
> 
>                     are evaluated to the same  result.  Please  note
>                     that  the  ordering  of  these  continuing lines
>                     matters.
>           Status: optional, multiple lines allowed
> 
> as-out:
>      A description of generated routing information sent to other AS
>      peers.
> 
>      Format:
>           to <aut-num> announce <routing policy expression
> 
>           The to and announce keywords are optional and can be omit-
>           ted.
> 
>           <aut-num> refers to your AS neighbour.
> 
>           <routing policy expression>  is  explained  in  the  as-in
>           attribute definition above.
> 
>      Example:
> 
>           as-out: to AS1104 announce AS978
>           as-out: to AS1755 announce ANY
>           as-out: to AS786 announce ANY AND NOT (AS978)
> 
>      Status: optional, multiple lines allowed
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 51 -
> 
> 
> interas-in:
> 
>      STILL TO BE PROPOSED BY MERIT
> 
>      Status: optional, multiple lines allowed
> 
> interas-out:
> 
>      STILL TO BE PROPOSED BY MERIT
> 
> 
>      Status: optional, multiple lines allowed
> 
> as-exclude:
>      A list of transit ASes to ignore all routes from.
> 
>      Format:
>           exclude <aut-num> to <exclude-route-keyword>
> 
>           Keywords exclude and to are  optional  and  can  again  be
>           omitted.
> 
>           <aut-num> refers to the transit AS in question.
> 
>           an <exclude-route-keyword> can be ONE of the following.
> 
>           1.   <aut-num>
> 
>           2.   AS macro
> 
>           3.   Community
> 
>           4.   ANY
> 
>      Examples:
> 
>           as-exclude: exclude AS690 to HEPNET
> 
>           This means exclude any HEPNET routes which  have  a  route
>           via AS690.
> 
>           as-exclude: exclude AS1800 to AS-EUNET
> 
>           This means exclude any AS-EUNET routes which have a  route
>           via AS1800.
> 
>           as-exclude: exclude AS1755 to AS1104
> 
>           This means exclude any AS1104 route which have a route via
>           AS1755.
> 
>           as-exclude: exclude AS1104 to ANY
> 
>           This means exclude all  routes  which  have  a  route  via
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 52 -
> 
> 
>           AS1104.
> 
>      Status: optional, multiple lines allowed
> 
> default:
>      An indication of how default routing is done.
> 
>      Format:
>           <aut-num> <relative cost> <default-expression>
> 
>           where <aut-num> is the AS peer you will default route to,
> 
>           and <relative cost> is the relative  cost  is  a  positive
>           integer used to express a preference for default. There is
>           no relationship to the cost used in the as-in tag. The  AS
>           peer  with  the  lowest cost is used for default over ones
>           with higher costs.
> 
>           <default-expression> is optional and provides  information
>           on  how  a default route is selected. It can take the fol-
>           lowing formats:
> 
>           1.   static. This indicates that a default  is  statically
>                configured to this AS peer.
> 
>           2.   A network list with the syntax as  described  in  the
>                as-in  attribute.  This  indicates  that this list of
>                routes is used to generate a default route. A special
>                but  valid value in this is the special route used by
>                some routing protocols to indicate default: 0.0.0.0/0
> 
>           3.   default. This is the same as {0.0.0.0/0}. This  means
>                that  the  routing  protocol  between these two peers
>                generates a true default.
> 
>      Examples:
> 
>           default: AS1755 10
>           default: AS786   5 {140.222.0.0/16, 192.87.45.0/24}
>           default: AS2043 15 default
> 
>      Status: optional, multiple lines allowed
> 
> tech-c:
>      Full name or uniquely assigned NIC-handle of a  technical  con-
>      tact  person.  This  is  someone  to be contacted for technical
>      problems such as misconfiguration.
> 
>      Format:
>           <firstname> <initials> <lastname> or <nic-handle>
> 
>      Example:
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 53 -
> 
> 
> 
>           tech-c: John E Doe
>           tech-c: JED31
> 
>      Status: mandatory, multiple lines allowed
> 
> admin-c:
>      Full name or uniquely assigned NIC-handle of an  administrative
>      contact  person.  In  many  cases this would be the name of the
>      guardian.
> 
>      Format:
>           <firstname> <initials> <lastname>  or  <nic-handle>
> 
>      Example:
> 
>           admin-c: Joe T Bloggs
>           admin-c: JTB1
> 
>      Status: mandatory, multiple lines allowed
> 
> guardian:
>      Mailbox of the guardian of the Autonomous system.
> 
>      Format:
>           <email-address>
> 
>           The <email-address> should  be  in  RFC822  domain  format
>           wherever possible.
> 
>      Example:
> 
>           guardian: as1104-guardian at nikhef.nl
> 
>      Status: mandatory, only one line and e-mail address allowed
> 
> remarks:
>      Remarks/comments, to be used only for clarification.
> 
>      Format:
>           free text
> 
>      Example:
> 
>           remarks: Multihomed AS talking to AS1755 and AS786
>           remarks: Will soon connect to AS1104 also.
> 
>      Status: optional, multiple lines allowed
> 
> notify:
>      The notify attribute contains an email address to which notifi-
>      cations  of  changes  to  this  object should be sent. See also
>      [11].
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 54 -
> 
> 
>      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.
>      See also [11].
> 
>      Format:
>           <registered maintainer name>
> 
>      Example:
> 
>           maintainer: RIPE-DBM
> 
>      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-1nn.txt                                              July, 1994
>                                - 55 -
> 
> 
> Appendix B - Syntax details for the community object.
> 
> Here is a summary of  the  tags  associated  with  community  object
> itself  and  their status. The first column specifies the attribute,
> the second column whether this attribute is mandatory in the commun-
> ity object, and the third column whether this specific attribute can
> occur only once per object [single], or more than  once  [multiple].
> When  specifying  multiple  lines  per attribute, the attribute name
> must be repeated. See [6] the example for the descr: attribute.
> 
> 
> community:      [mandatory]          [single]
> descr:          [mandatory]          [multiple]
> authority:      [mandatory]          [single]
> guardian:       [mandatory]          [single]
> 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:
> 
> 
> community:
>      Name of the community. The name  of  the  community  should  be
>      descriptive of the community it describes.
> 
>      Format:
>           Upper case text string which cannot start with "AS" or any
>           of  the <routing policy expression> KEYWORDS. See Appendix
>           A.
> 
>      Example:
> 
>           community: WCW
> 
>      Status: mandatory, only one line allowed
> 
> descr:
>      A short description of the community represented.
> 
>      Format:
>           free text
> 
>      Example:
> 
>           descr: Science Park Watergraafsmeer
>           descr: Amsterdam
> 
>      Status: mandatory, multiple lines allowed
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 56 -
> 
> 
> authority:
>      The formal authority for  this  community.  This  could  be  an
>      organisation, institute, committee, etc.
> 
>      Format:
>           free text
> 
>      Example:
> 
>           authority:  WCW LAN Committee
> 
>      Status: mandatory, only one line allowed
> 
> guardian:
>      Mailbox of the guardian of the community.
> 
>      Format:
>           <email-address>
> 
>           The <email-address> should  be  in  RFC822  domain  format
>           wherever possible.
> 
>      Example:
> 
>           guardian: wcw-guardian at nikhef.nl
> 
>      Status: mandatory, only one line and email address allowed
> 
> tech-c:
>      Full name or uniquely assigned NIC-handle of an technical  con-
>      tact person for this community.
> 
>      Format:
>           <firstname> <initials> <lastname> or <nic-handle>
> 
>      Example:
> 
>           tech-c: John E Doe
>           tech-c: JED31
> 
>      Status: mandatory, multiple lines allowed
> 
> admin-c:
>      Full name or uniquely assigned NIC-handle of an  administrative
>      contact  person.  In  many  cases this would be the name of the
>      guardian.
> 
>      Format:
>           <firstname> <initials> <lastname> or <nic-handle>
> 
>      Example:
> 
>           admin-c: Joe T Bloggs
>           admin-c: JTB1
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 57 -
> 
> 
>      Status: mandatory, multiple lines allowed
> 
> remarks:
>      Remarks/comments, to be used only for clarification.
> 
>      Format:
>           free text
> 
>      Example:
> 
>           remarks: Temporary community
>           remarks: Will be removed after split into ASes
> 
>      Status: optional, multiple lines allowed
> 
> notify:
>      The notify attribute contains an email address to which notifi-
>      cations  of  changes  to  this  object should be send. See also
>      [11].
> 
>      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.
>      See also [11].
> 
>      Format:
>           <registered maintainer name>
> 
>      Example:
> 
>           maintainer: RIPE-DBM
> 
>      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.
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 58 -
> 
> 
>      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-1nn.txt                                              July, 1994
>                                - 59 -
> 
> 
> Appendix C - AS Macros syntax definition.
> 
> Here is a summary of the tags associated with as-macro object itself
> and  their  status.  The  first  column specifies the attribute, the
> second column whether this attribute is mandatory  in  the  as-macro
> object,  and  the  third  column whether this specific attribute can
> occur only once per object [single], or more than  once  [multiple].
> When  specifying  multiple  lines  per attribute, the attribute name
> must be repeated. See [6] the example for the descr: attribute.
> 
> 
> as-macro:     [mandatory]          [single]
> descr:        [mandatory]          [multiple]
> as-list:      [mandatory]          [multiple]
> guardian:     [mandatory]          [single]
> 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:
> 
> 
> as-macro:
>      The name of a macro containing at least two Autonomous  Systems
>      grouped together for ease of administration.
> 
>      Format:
>           AS-<string>
> 
>           The <string> should be in upper case and not  contain  any
>           special characters.
> 
>      Example:
> 
>           as-macro: AS-EBONE
> 
>      Status: mandatory, only one line allowed
> 
> descr:
>      A short description of the Autonomous System Macro.
> 
>      Format:
>           free text
> 
>      Example:
> 
>           descr:  Macro for EBONE connected ASes
> 
>      Status: mandatory, multiple lines allowed
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 60 -
> 
> 
> as-list:
>      The list of ASes that make up this macro.
> 
>      Format:
>           <aut-num> <aut-num> ...
> 
>           See Appendix A for <aut-num> definition.
> 
>      Example:
> 
>           as-list: AS786 AS513 AS1104
> 
>      Status: mandatory, multiple lines allowed
> 
> guardian:
>      Mailbox of the guardian of this AS macro.
> 
>      Format:
>           <email-address>
> 
>           The <email-address> should  be  in  RFC822  domain  format
>           wherever possible.
> 
>      Example:
> 
>           guardian: as-ebone-guardian at ebone.net
> 
>      Status: mandatory, only one line and e-mail address allowed
> 
> 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
> 
> admin-c:
>      Full name or uniquely assigned NIC-handle of an  administrative
>      contact  person.  In  many  cases this would be the name of the
>      guardian.
> 
>      Format:
>           <firstname> <initials> <lastname> or <nic-handle>
> 
>      Examples:
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 61 -
> 
> 
> 
>           admin-c: Joe T Bloggs
>           admin-c: JTB1
> 
>      Status: mandatory, multiple lines allowed
> 
> remarks:
>      Remarks/comments, to be used only for clarification.
> 
>      Format:
>           free text
> 
>      Example:
> 
>           remarks: AS321 will be removed from this Macro shortly
> 
>      Status: optional, multiple lines allowed
> 
> notify:
>      The notify attribute contains an email address to which notifi-
>      cations  of  changes  to  this  object should be send. See also
>      [11].
> 
>      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.
>      See also [11].
> 
>      Format:
>           <registered maintainer name>
> 
>      Example:
> 
>           maintainer: RIPE-DBM
> 
>      Status: optional, multiple lines allowed
> 
> changed:
>      Who changed this object last, and when was this change made.
> 
>      Format:
>           <email-address> YYMMDD
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 62 -
> 
> 
>           <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-1nn.txt                                              July, 1994
>                                - 63 -
> 
> 
> Appendix D - Syntax for the "route" object.
> 
> There is a summary of the  tags  associated  with  community  object
> itself  and  their status. The first column specifies the attribute,
> the second column whether this attribute is mandatory in the commun-
> ity object, and the third column whether this specific attribute can
> occur only once per object [single], or more than  once  [multiple].
> When  specifying  multiple  lines  per attribute, the attribute name
> must be repeated. See [6] the example for the descr: attribute.
> 
> 
> route:          [mandatory]          [single]
> descr:          [mandatory]          [multiple]
> origin:         [mandatory]          [single]
> hole:           [optional]           [multiple]
> withdrawn:      [optional]           [multiple]
> comm-list:      [optional]           [multiple]
> remarks:        [optional]           [multiple]
> notify:         [optional]           [multiple]
> maintainer:     [optional]           [single]
> changed:        [mandatory]          [multiple]
> source:         [mandatory]          [single]
> 
> 
> Each attribute has the following syntax:
> 
> 
> route:
>      Route being announced.
> 
>      Format:
>           Classless representation of a route with the RIPE database
>           known  as the "prefix length" representation. See [10] for
>           more details on classless representations.
> 
>      Examples:
> 
>           route: 192.87.45.0/24
> 
>           This   represents   addressable   bits   192.87.45.0    to
>           192.87.45.255.
> 
>           route: 192.1.128.0/17
> 
>           This   represents   addressable   bits   192.1.128.0    to
>           192.1.255.255.
> 
>      Status: mandatory, only one line allowed
> 
> origin:
>      The autonomous system announcing this route.
> 
>      Format:
>           <aut-num>
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 64 -
> 
> 
>           See appendix A for <aut-num> syntax.
> 
>      Example:
> 
>           origin: AS1104
> 
>      Status: mandatory, only one line allowed
> 
> hole:
>      Denote the parts of the address space covered this route object
>      to which the originator does not provide connectivity.
> 
>      Format:
>           Classless representation of a route with the RIPE database
>           known  as the "prefix length" representation. See [10] for
>           more details on classless representations.  It  should  be
>           noted  that  is  sub-aggregate must be a component of that
>           registered in the route object.
> 
>      Example:
> 
>           hole: 193.0.4.0/24
> 
>      Status: optional, multiple lines allowed
> 
> withdrawn:
>      Used to denote the day this route has been withdrawn  from  the
>      Internet routing mesh. It should be noted that this date cannot
>      be in the future.
> 
>      Format:
>           YYMMDD
> 
>           YYMMDD denotes the date this route was withdrawn.
> 
>      Example:
> 
>           withdrawn: 940711
> 
>      Status: optional, multiple lines allowed
> 
> comm-list:
>      List of one or more communities this route is part of.
> 
>      Format:
>           <community> <community> ...
> 
>           See Appendix B for <community> definition.
> 
>      Example:
> 
>           comm-list: HEP LEP
> 
>      Status: optional, multiple lines allowed
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 65 -
> 
> 
> remarks:
>      Remarks/comments, to be used only for clarification.
> 
>      Format:
>           free text
> 
>      Example:
> 
>           remarks: Multihomed AS talking to AS1755 and AS786
>           remarks: Will soon connect to AS1104 also.
> 
>      Status: optional, multiple lines allowed
> 
> notify:
>      The notify attribute contains an email address to which notifi-
>      cations  of  changes  to  this  object should be send. See also
>      [11].
> 
>      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.
>      See also [11].
> 
>      Format:
>           <registered maintainer name>
> 
>      Example:
> 
>           maintainer: RIPE-DBM
> 
>      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:
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 66 -
> 
> 
> 
>           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-1nn.txt                                              July, 1994
>                                - 67 -
> 
> 
> Appendix E - List of reserved words
> 
> The following list of words are reserved for use within  the  attri-
> butes  of  the  AS  object. The use of these words is solely for the
> purpose of clarity. All keywords must be lower case.
> 
> 
>         accept
>         announce
>         exclude
>         from
>         to
>         transit
> 
> 
> Examples of the usage of the reserved words are:
> 
> as-in: from neighborAS accept route
> 
> as-out: to neighborAS announce route
> 
> as-exclude: exclude ASpath to destination
> 
> as-transit: transit ASpath to destination
> 
> default: from neighborAS accept route
> 
> default: to neighborAS announce route
> 
> 
> Note: that as-transit is an experimental attribute. See section 10.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 68 -
> 
> 
> Appendix F - Motivations for RIPE-81++
> 
> This appendix gives motivations for the major changes in this propo-
> sal from ripe-81. (It is not complete yet).
> 
> The main goals of the routing registry rework are:
> 
> 
>   SPLIT
>      Separate the allocation and  routing  registry  functions  into
>      different  database  objects. This will facilitate data manage-
>      ment if the Internet registry and  routing  registry  functions
>      are  separated (like in other parts of the world). It will also
>      make more clear what is part of the routing  registry  and  who
>      has authority to change allocation vs. routing data.
> 
> 
>    CIDR
>      Add the possibility to specify classless routes in the  routing
>      registry.   Classless routes are being used in Internet produc-
>      tion now.  Aggregation information in the routing  registry  is
>      necessary  for network layer troubleshooting. It is also neces-
>      sary because aggregation influences routing policies directly.
> 
> 
>   CALLOC
>      Add the possibility to  allocate  address  space  on  classless
>      boundaries  in  the  allocation  registry.  This  is  a  way to
>      preserve address space.
> 
> 
>   CLEAN
>      To clean up some of the obsolete and unused parts of the  rout-
>      ing registry.
> 
> 
> The major changes are now discussed in turn:
> 
> 
> Introduce Classless Addresses
> 
> CIDR, CALLOC
> 
> 
> Introduce route object.
> 
> SPLIT, CIDR and CALLOC.
> 
> 
> Delete obsolete attributes from inetnum.
> 
> CLEAN.
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 69 -
> 
> 
> Delete RIPE-DB and LOCAL from routing policy expressions.
> 
> CLEAN
> 
> 
> Allow multiple ASes to originate the same route
> 
> Because it is being done. CIDR. Made possible by SPLIT.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
>                                - 70 -
> 
> 
> Appendix G - Transition strategy from RIPE-81 to RIPE-81++
> 
> Transition from the routing registry described  by  ripe-81  to  the
> routing  registry  described  in  this document is a straightforward
> process once the new registry functions have been implemented in the
> database  software  and  are  understood  by  the most commonly used
> registry tools. The routing related attributes in the classful inet-
> num  objects  of ripe-81 can be directly translated into new routing
> objects. Then these attributes  can  be  deleted  from  the  inetnum
> object making that object conform to the new schema.
> 
> Proposed transition steps:
> 
> 
>   1) Implement classless addresses and new object definition in  the
>      database software.
> 
> 
>   2) Make common tools understand the new schema and  prefer  it  if
>      both old and new are present.
> 
> 
>   3) Invite everyone to convert their data to the new format.   This
>      can  be  encouraged by doing conversions automatically and pro-
>      posing them to maintainers.
> 
> 
>   4) At a flag day remove all remaining routing information from the
>      inetnum  objects.   Before  the flag day all usage of obsoleted
>      inetnum attributes has to cease and all other routing  registry
>      functions  have  to be taken over by the new objects and attri-
>      butes.
> 
> 
> The current estimate is that point three can be reached in the  Sum-
> mer  1994 if the draft is accepted by mid-June.  The flag day should
> be scheduled 3-4 months after this point.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ripe-1nn.txt                                              July, 1994
> 


-- 
Laurent Joncheray,                                 E-Mail: lpj at merit.edu
    Merit Network Inc, 1071 Beal Avenue,           Phone:  +1 (313) 936 2065
    Ann Arbor, MI 48109, USA                       Fax:    +1 (313) 747 3745
"This is the end, Beautiful friend. This is the end, My only friend, the end" JM