Latest draft of ripe-81++
- Previous message (by thread): Latest draft of ripe-81++
- Next message (by thread): The router object
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Laurent Joncheray
lpj at merit.edu
Tue Jul 12 20:04:16 CEST 1994
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
- Previous message (by thread): Latest draft of ripe-81++
- Next message (by thread): The router object
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]