Re: Latest draft of ripe-81++
- Date: Tue, 12 Jul 1994 14:04:16 -0400 (EDT)
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@localhost
> changed: tony@localhost 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@localhost
> nic-hdl: DK58
> changed: ripe-dbm@localhost 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@localhost
> nic-hdl: MT2
> notify: marten@localhost
> changed: marten@localhost 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@localhost
> changed: tony@localhost 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@localhost
> changed: tony@localhost 940110
> source: RIPE
>
> route: 192.87.45.0/24
> descr: RIPE Network Coordination Centre
> origin: AS3333
> comm-list: SURFNET
> changed: dfk@localhost 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@localhost
> changed: ripe-dbm@localhost 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@localhost
> ......
>
>
> 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@localhost 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@localhost
> admin-c: Erik-Jan Bos
> tech-c: Erik-Jan Bos
> changed: ripe-dbm@localhost 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@localhost
>
>
> Elise Gerich
> The University of Michigan
> Merit Computer Network
> 1075 Beal Avenue
> Ann Arbor, MI 48109
> USA
> +1 313 936 2120
> epg@localhost
>
>
> Laurent Joncheray
> The University of Michigan
> Merit Computer Network
> 1075 Beal Avenue
> Ann Arbor, MI 48109
> USA
> +1 313 936 2065
> lpj@localhost
>
>
> Jean-Michel Jouanigot
> CERN, European Laboratory for Particle Physics
> CH-1211 Geneva 23
> Switzerland
> +41 22 767 4417
> Jean-Michel.Jouanigot@localhost
>
>
> Daniel Karrenberg
> RIPE Network Coordination Centre
> Kruislaan 409
> NL-1098 SJ Amsterdam
> The Netherlands
> +31 20 592 5065
> D.Karrenberg@localhost
>
>
>
>
>
>
>
>
>
> 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@localhost
>
>
> Jessica Yu
> The University of Michigan
> Merit Computer Network
> 1075 Beal Avenue
> Ann Arbor, MI 48109
> USA
> +1 313 936 2655
> jyy@localhost
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 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@localhost
>
> 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@localhost
>
> 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@localhost 900401
>
> Status: mandatory, multiple lines allowed
>
> source:
> Source of the information.
>
> This is used to separate information from different sources
> kept by the same database software. For RIPE database entries
> the value is fixed to RIPE.
>
> Format:
> RIPE
> Status: mandatory, only one line allowed
>
>
>
>
>
>
> ripe-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@localhost
>
> 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@localhost
>
> 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@localhost 900401
>
> Status: mandatory, multiple lines allowed
>
> source:
> Source of the information.
>
> This is used to separate information from different sources
> kept by the same database software. For RIPE database entries
> the value is fixed to RIPE.
>
> Format:
> RIPE
> Status: mandatory, only one line allowed
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ripe-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@localhost
>
> 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 contac |
you are here: RIPE -> RIPE Maillists > Archives
