idnits 2.17.1 draft-ietf-rps-rpsl-v2-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 663 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 5 instances of lines with control characters in the document. == There are 9 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 164 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 383 has weird spacing: '...in text manda...' == Line 475 has weird spacing: '...in text manda...' == Line 518 has weird spacing: '...in text manda...' == Line 563 has weird spacing: '...ponents see...' == Line 564 has weird spacing: '...r-bndry see...' == (18 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 6, 1999) is 9151 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0' is mentioned on line 1835, but not defined == Missing Reference: '65535' is mentioned on line 1835, but not defined == Missing Reference: '4294967295' is mentioned on line 1798, but not defined -- Looks like a reference, but probably isn't: 'ATOMIC' on line 2003 -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2280 (ref. '3') (Obsoleted by RFC 2622) == Outdated reference: A later version (-06) exists of draft-ietf-rps-appl-rpsl-01 ** Downref: Normative reference to an Informational draft: draft-ietf-rps-appl-rpsl (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Downref: Normative reference to an Informational RFC: RFC 1786 (ref. '7') -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 822 (ref. '10') (Obsoleted by RFC 2822) -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Normative reference to a draft: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '19' ** Obsolete normative reference: RFC 1771 (ref. '20') (Obsoleted by RFC 4271) == Outdated reference: A later version (-04) exists of draft-ietf-rps-auth-01 == Outdated reference: A later version (-03) exists of draft-ietf-idr-route-damp-00 -- No information found for draft-zsako-ripe-dbsec-pgp-authent - is the name correct? -- Possible downref: Normative reference to a draft: ref. '23' Summary: 14 errors (**), 0 flaws (~~), 16 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Cengiz Alaettinoglu 3 Expires October 6, 1999 USC/Information Sciences Institute 4 draft-ietf-rps-rpsl-v2-03.txt Curtis Villamizar 5 ANS 6 Elise Gerich 7 At Home Network 8 David Kessens 9 Qwest Communications 10 David Meyer 11 University of Oregon 12 Tony Bates 13 Cisco Systems 14 Daniel Karrenberg 15 RIPE 16 Marten Terpstra 17 Bay Networks 18 April 6, 1999 20 Routing Policy Specification Language (RPSL) 22 Status of this Memo: 24 This document is an Internet-Draft and is in full conformance with all 25 provisions of Section 10 of RFC2026. 27 Copyright (C) The Internet Society (1998). All Rights Reserved. 29 Internet-Drafts are working documents of the Internet Engineering Task Force 30 (IETF), its areas, and its working groups. Note that other groups may also 31 distribute working documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months and 34 may be updated, replaced, or obsoleted by other documents at any time. It 35 is inappropriate to use Internet-Drafts as reference material or to cite 36 them other than as 'work in progress.' 38 The list of current Internet-Drafts can be accessed at 39 41 The list of Internet-Draft Shadow Directories can be accessed at 42 . 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC 2119. 48 Abstract 50 RPSL allows a network operator to be able to specify routing policies at 51 various levels in the Internet hierarchy; for example at the Autonomous 52 System (AS) level. At the same time, policies can be specified with 53 sufficient detail in RPSL so that low level router configurations can be 54 generated from them. RPSL is extensible; new routing protocols and new 55 protocol features can be introduced at any time. 57 Contents 59 1 Introduction 5 61 2 RPSL Names, Reserved Words, and Representation 6 63 3 Contact Information 9 65 3.1 mntner Class . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 3.2 person Class . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 3.3 role Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 4 route Class 13 73 5 Set Classes 14 75 5.1 as-set Class . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 5.2 route-set Class . . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 5.3 Predefined Set Objects . . . . . . . . . . . . . . . . . . . . . . 18 81 5.4 Filters and filter-set Class . . . . . . . . . . . . . . . . . . . 18 83 5.5 rtr-set Class . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 85 5.6 Peerings and peering-set Class . . . . . . . . . . . . . . . . . . 24 87 6 aut-num Class 27 89 6.1 import Attribute: Import Policy Specification . . . . . . . . . . 28 91 6.1.1Action Specification . . . . . . . . . . . . . . . . . . . . . . 28 93 6.2 export Attribute: Export Policy Specification . . . . . . . . . . 29 95 6.3 Other Routing Protocols, Multi-Protocol Routing Protocols, and 96 Injecting Routes Between Protocols . . . . . . . . . . . . . . . . . 30 98 6.4 Ambiguity Resolution . . . . . . . . . . . . . . . . . . . . . . . 31 100 6.5 default Attribute: Default Policy Specification . . . . . . . . . 34 102 6.6 Structured Policy Specification . . . . . . . . . . . . . . . . . . 35 104 7 dictionary Class 38 106 7.1 Initial RPSL Dictionary and Example Policy Actions and Filters . . 42 108 8 Advanced route Class 46 110 8.1 Specifying Aggregate Routes . . . . . . . . . . . . . . . . . . . . 46 112 8.1.1Interaction with policies in aut-num class . . . . . . . . . . . 50 114 8.1.2Ambiguity resolution with overlapping aggregates . . . . . . . . 51 116 8.2 Specifying Static Routes . . . . . . . . . . . . . . . . . . . . . 53 118 9 inet-rtr Class 53 120 10Extending RPSL 55 122 10.1Extensions by changing the dictionary class . . . . . . . . . . . . 55 124 10.2Extensions by adding new attributes to existing classes . . . . . . 56 126 10.3Extensions by adding new classes . . . . . . . . . . . . . . . . . 56 128 10.4Extensions by changing the syntax of existing RPSL attributes . . . 56 130 11Security Consideration 57 132 12Acknowledgements 57 134 A Routing Registry Sites 59 136 B Grammar Rules 59 138 C Changes from RFC 2280 67 140 D Authors' Addresses 68 141 1 Introduction 143 This Internet Draft is the reference document for the Routing Policy 144 Specification Language (RPSL). RPSL allows a network operator to be able to 145 specify routing policies at various levels in the Internet hierarchy; for 146 example at the Autonomous System (AS) level. At the same time, policies can 147 be specified with sufficient detail in RPSL so that low level router 148 configurations can be generated from them. RPSL is extensible; new routing 149 protocols and new protocol features can be introduced at any time. 151 RPSL is a replacement for the current Internet policy specification language 152 known as RIPE-181 [6] or RFC-1786 [7]. RIPE-81 [8] was the first language 153 deployed in the Internet for specifying routing policies. It was later 154 replaced by RIPE-181 [6]. Through operational use of RIPE-181 it has become 155 apparent that certain policies cannot be specified and a need for an 156 enhanced and more generalized language is needed. RPSL addresses RIPE-181's 157 limitations. 159 RPSL was designed so that a view of the global routing policy can be 160 contained in a single cooperatively maintained distributed database to 161 improve the integrity of Internet's routing. RPSL is not designed to be a 162 router configuration language. RPSL is designed so that router 163 configurations can be generated from the description of the policy for one 164 autonomous system (aut-num class) combined with the description of a router 165 (inet-rtr class), mainly providing router ID, autonomous system number of 166 the router, interfaces and peers of the router, and combined with a global 167 database mappings from AS sets to ASes (as-set class), and from origin ASes 168 and route sets to route prefixes (route and route-set classes). The 169 accurate population of the RPSL database can help contribute toward such 170 goals as router configurations that protect against accidental (or 171 malicious) distribution of inaccurate routing information, verification of 172 Internet's routing, and aggregation boundaries beyond a single AS. 174 RPSL is object oriented; that is, objects contain pieces of policy and 175 administrative information. These objects are registered in the Internet 176 Routing Registry (IRR) by the authorized organizations. The registration 177 process is beyond the scope of this document. Please refer to [1, 17, 4] 178 for more details on the IRR. 180 In the following sections, we present the classes that are used to define 181 various policy and administrative objects. The "mntner" class defines 182 entities authorized to add, delete and modify a set of objects. The 183 "person" and "role" classes describes technical and administrative contact 184 personnel. Autonomous systems (ASes) are specified using the "aut-num" 185 class. Routes are specified using the "route" class. Sets of objects can 186 be defined using the "as-set", "route-set", "filter-set", "peering-set", and 187 "rtr-set" classes. The "dictionary" class provides the extensibility to the 188 language. The "inet-rtr" class is used to specify routers. Many of these 189 classes were originally defined in earlier documents [6, 13, 16, 12, 5] and 190 have all been enhanced. 192 This document is self-contained. However, the reader is encouraged to read 193 RIPE-181 [7] and the associated documents [13, 16, 12, 5] as they provide 194 significant background as to the motivation and underlying principles behind 195 RIPE-181 and consequently, RPSL. For a tutorial on RPSL, the reader should 196 read the RPSL applications document [4]. 198 2 RPSL Names, Reserved Words, and Representation 200 Each class has a set of attributes which store a piece of information about 201 the objects of the class. Attributes can be mandatory or optional: A 202 mandatory attribute has to be defined for all objects of the class; optional 203 attributes can be skipped. Attributes can also be single or multiple 204 valued. Each object is uniquely identified by a set of attributes, referred 205 to as the class ``key''. 207 The value of an attribute has a type. The following types are most widely 208 used. Note that RPSL is case insensitive and only the characters from the 209 ASCII character set can be used. 211 Many objects in RPSL have a name. An is made up 212 of letters, digits, the character underscore ``_'', and the character 213 hyphen ``-''; the first character of a name must be a letter, and the 214 last character of a name must be a letter or a digit. The following 215 words are reserved by RPSL, and they can not be used as names: 217 any as-any rs-any peeras 218 and or not 219 atomic from to at action accept announce except refine 220 networks into inbound outbound 222 Names starting with certain prefixes are reserved for certain object 223 types. Names starting with ``as-'' are reserved for as set names. 224 Names starting with ``rs-'' are reserved for route set names. Names 225 starting with ``rtrs-'' are reserved for router set names. Names 226 starting with ``fltr-'' are reserved for filter set names. Names 227 starting with ``prng-'' are reserved for peering set names. 229 An AS number x is represented as the string ``ASx''. That is, 230 the AS 226 is represented as AS226. 232 An IPv4 address is represented as a sequence of four integers 233 in the range from 0 to 255 separated by the character dot ``.''. For 234 example, 128.9.128.5 represents a valid IPv4 address. In the rest of 235 this document, we may refer to IPv4 addresses as IP addresses. 237 An address prefix is represented as an IPv4 address 238 followed by the character slash ``/'' followed by an integer in the 239 range from 0 to 32. The following are valid address prefixes: 240 128.9.128.5/32, 128.9.0.0/16, 0.0.0.0/0; and the following address 241 prefixes are invalid: 0/0, 128.9/16 since 0 or 128.9 are not strings 242 containing four integers. 244 An address prefix range is an address prefix followed 245 by an optional range operator. The range operators are: 247 ^- is the exclusive more specifics operator; it stands for the more 248 specifics of the address prefix excluding the address prefix 249 itself. For example, 128.9.0.0/16^- contains all the more 250 specifics of 128.9.0.0/16 excluding 128.9.0.0/16. 252 ^+ is the inclusive more specifics operator; it stands for the more 253 specifics of the address prefix including the address prefix 254 itself. For example, 5.0.0.0/8^+ contains all the more specifics 255 of 5.0.0.0/8 including 5.0.0.0/8. 257 ^n where n is an integer, stands for all the length n specifics of the 258 address prefix. For example, 30.0.0.0/8^16 contains all the more 259 specifics of 30.0.0.0/8 which are of length 16 such as 30.9.0.0/16. 261 ^n-m where n and m are integers, stands for all the length n to length 262 m specifics of the address prefix. For example, 30.0.0.0/8^24-32 263 contains all the more specifics of 30.0.0.0/8 which are of length 264 24 to 32 such as 30.9.9.96/28. 266 Range operators can also be applied to address prefix sets. In this 267 case, they distribute over the members of the set. For example, for a 268 route-set (defined later) rs-foo, rs-foo^+ contains all the inclusive 269 more specifics of all the prefixes in rs-foo. 271 It is an error to follow a range operator with another one (e.g. 272 30.0.0.0/8^24-28^+ is an error). However, a range operator can be 273 applied to an address prefix set that has address prefix ranges in it 274 (e.g. {30.0.0.0/8^24-28}^27-30 is not an error). In this case, the 275 outer operator ^n-m distributes over the inner operator ^k-l and becomes 276 the operator ^max(n,k)-m if m is greater than or equal to max(n,k), or 277 otherwise, the prefix is deleted from the set. Note that the operator 278 ^n is equivalent to ^n-n; prefix/l^+ is equivalent to prefix/l^l-32; 279 prefix/l^- is equivalent to prefix/l^(l+1)-32; {prefix/l^n-m}^+ is 280 equivalent to {prefix/l^n-32}; and {prefix/l^n-m}^- is equivalent to 281 {prefix/l^(n+1)-32}. For example, 283 {128.9.0.0/16^+}^- == {128.9.0.0/16^-} 284 {128.9.0.0/16^-}^+ == {128.9.0.0/16^-} 285 {128.9.0.0/16^17}^24 == {128.9.0.0/16^24} 286 {128.9.0.0/16^20-24}^26-28 == {128.9.0.0/16^26-28} 287 {128.9.0.0/16^20-24}^22-28 == {128.9.0.0/16^22-28} 288 {128.9.0.0/16^20-24}^18-28 == {128.9.0.0/16^20-28} 289 {128.9.0.0/16^20-24}^18-22 == {128.9.0.0/16^20-22} 290 {128.9.0.0/16^20-24}^18-19 == {} 292 A date is represented as an eight digit integer of the form YYYYMMDD 293 where YYYY represents the year, MM represents the month of the year (01 294 through 12), and DD represents the day of the month (01 through 31). 295 All dates are in UTC unless otherwise specified. For example, June 24, 296 1996 is represented as 19960624. 298 is as described in RFC-822[10]. 300 is as described in RFC-1034[18]. 302 is a uniquely assigned identifier[15] used by routing, address 303 allocation, and other registries to unambiguously refer to contact 304 information. person and role classes map NIC handles to actual person 305 names, and contact information. 307 is a sequence of ASCII characters. 309 is a name of an object of type X. That is is a name 310 of a mntner object. 312 is a name of an IRR registry. The routing registries are 313 listed in Appendix A. 315 A value of an attribute may also be a list of one of these types. A list is 316 represented by separating the list members by commas ``,''. For example, 317 ``AS1, AS2, AS3, AS4'' is a list of AS numbers. Note that being list valued 318 and being multiple valued are orthogonal. A multiple valued attribute has 319 more than one value, each of which may or may not be a list. On the other 320 hand a single valued attribute may have a list value. 322 An RPSL object is textually represented as a list of attribute-value pairs. 323 Each attribute-value pair is written on a separate line. The attribute name 324 starts at column 0, followed by character ``:'' and followed by the value 325 of the attribute. The attribute which has the same name as the object's 326 class should be specified first. The object's representation ends when a 327 blank line is encountered. An attribute's value can be split over multiple 328 lines, by having a space, a tab or a plus ('+') character as the first 329 character of the continuation lines. The character ``+'' for line 330 continuation allows attribute values to contain blank lines. More spaces 331 may optionally be used after the continuation character to increase 332 readability. The order of attribute-value pairs is significant. 334 An object's description may contain comments. A comment can be anywhere in 335 an object's definition, it starts at the first ``#'' character on a line and 336 ends at the first end-of-line character. White space characters can be used 337 to improve readability. 339 An integer can be specified using (1) the C programming language notation 340 (e.g. 1, 12345); (2) sequence of four 1-octet integers (in the range from 0 341 to 255) separated by the character dot ``.'' (e.g. 1.1.1.1, 255.255.0.0), 342 in this case a 4-octet integer is formed by concatenating these 1-octet 343 integers in the most significant to least significant order; (3) sequence of 344 two 2-octet integers (in the range from 0 to 65535) separated by the 345 character colon ``:'' (e.g. 3561:70, 3582:10), in this case a 4-octet 346 integer is formed by concatenating these 2-octet integers in the most 347 significant to least significant order. 349 3 Contact Information 351 The mntner, person and role classes, admin-c, tech-c, mnt-by, changed, and 352 source attributes of all classes describe contact information. The mntner 353 class also specifies authenticaiton information required to create, delete 354 and update other objects. These classes do not specify routing policies and 355 each registry may have different or additional requirements on them. Here 356 we present the common denominator for completeness which is the RIPE 357 database implementation [17]. Please consult your routing registry for the 358 latest specification of these classes and attributes. The ``Routing Policy 359 System Security'' document [21] describes the authenticaiton and 360 authorization model in more detail. 362 3.1 mntner Class 364 The mntner class specifies authenticaiton information required to create, 365 delete and update RPSL objects. A provider, before he/she can create RPSL 366 objects, first needs to create a mntner object. The attributes of the 367 mntner class are shown in Figure 1. The mntner class was first described 368 in [13]. 370 The mntner attribute is mandatory and is the class key. Its value is an 371 RPSL name. The auth attribute specifies the scheme that will be used to 372 identify and authenticate update requests from this maintainer. It has the 373 following syntax: 375 auth: 377 E.g. 378 auth: NONE 380 Attribute Value Type 381 mntner mandatory, single-valued, class key 382 descr mandatory, single-valued 383 auth see description in text mandatory, multi-valued 384 upd-to mandatory, multi-valued 385 mnt-nfy optional, multi-valued 386 tech-c mandatory, multi-valued 387 admin-c optional, multi-valued 388 remarks optional, multi-valued 389 notify optional, multi-valued 390 mnt-by list of mandatory, multi-valued 391 changed mandatory, multi-valued 392 source mandatory, single-valued 394 Figure 1: mntner Class Attributes 396 auth: CRYPT-PW dhjsdfhruewf 397 auth: MAIL-FROM .*@ripe\.net 399 The 's currently defined are: NONE, MAIL-FROM, PGP-KEY and 400 CRYPT-PW. The is additional information required by a particular 401 scheme: in the case of MAIL-FROM, it is a regular expression matching valid 402 email addresses; in the case of CRYPT-PW, it is a password in UNIX crypt 403 format; and in the case of PGP-KEY, it is a pointer to key-certif 404 object [23] containing the PGP public key of the user. If multiple auth 405 attributes are specified, an update request satisfying any one of them is 406 authenticated to be from the maintainer. 408 The upd-to attribute is an email address. On an unauthorized update attempt 409 of an object maintained by this maintainer, an email message will be sent to 410 this address. The mnt-nfy attribute is an email address. A notification 411 message will be forwarded to this email address whenever an object 412 maintained by this maintainer is added, changed or deleted. 414 The descr attribute is a short, free-form textual description of the object. 415 The tech-c attribute is a technical contact NIC handle. This is someone to 416 be contacted for technical problems such as misconfiguration. The admin-c 417 attribute is an administrative contact NIC handle. The remarks attribute is 418 a free text explanation or clarification. The notify attribute is an email 419 address to which notifications of changes to this object should be sent. 420 The mnt-by attribute is a list of mntner object names. The authorization 421 for changes to this object is governed by any of the maintainer objects 422 referenced. The changed attribute documents who last changed this object, 423 and when this change was made. Its syntax has the following form: 425 changed: 427 E.g. 428 changed: johndoe@terabit-labs.nn 19900401 430 The identifies the person who made the last change. 431 is the date of the change. The source attribute specifies the 432 registry where the object is registered. Figure 2 shows an example mntner 433 object. In the example, UNIX crypt format password authentication is used. 435 mntner: RIPE-NCC-MNT 436 descr: RIPE-NCC Maintainer 437 admin-c: DK58 438 tech-c: OPS4-RIPE 439 upd-to: ops@ripe.net 440 mnt-nfy: ops-fyi@ripe.net 441 auth: CRYPT-PW lz1A7/JnfkTtI 442 mnt-by: RIPE-NCC-MNT 443 changed: ripe-dbm@ripe.net 19970820 444 source: RIPE 446 Figure 2: An example mntner object. 448 The descr, tech-c, admin-c, remarks, notify, mnt-by, changed and source 449 attributes are attributes of all RPSL classes. Their syntax, semantics, and 450 mandatory, optional, multi-valued, or single-valued status are the same for 451 for all RPSL classes. Only exception to this is the admin-c attribute which 452 is mandatory for the aut-num class. We do not further discuss them in other 453 sections. 455 3.2 person Class 457 A person class is used to describe information about people. Even though it 458 does not describe routing policy, we still describe it here briefly since 459 many policy objects make reference to person objects. The person class was 460 first described in [16]. 462 The attributes of the person class are shown in Figure 3. The person 463 attribute is the full name of the person. The phone and the fax-no 464 attributes have the following syntax: 466 phone: + [ext. ] 468 E.g.: 469 phone: +31 20 12334676 471 Attribute Value Type 472 person mandatory, single-valued 473 nic-hdl mandatory, single-valued, class key 474 address mandatory, multi-valued 475 phone see description in text mandatory, multi-valued 476 fax-no same as phone optional, multi-valued 477 e-mail mandatory, multi-valued 479 Figure 3: person Class Attributes 481 phone: +44 123 987654 ext. 4711 483 Figure 4 shows an example person object. 485 person: Daniel Karrenberg 486 address: RIPE Network Coordination Centre (NCC) 487 address: Singel 258 488 address: NL-1016 AB Amsterdam 489 address: Netherlands 490 phone: +31 20 535 4444 491 fax-no: +31 20 535 4445 492 e-mail: Daniel.Karrenberg@ripe.net 493 nic-hdl: DK58 494 changed: Daniel.Karrenberg@ripe.net 19970616 495 source: RIPE 497 Figure 4: An example person object. 499 3.3 role Class 501 The role class is similar to the person object. However, instead of 502 describing a human being, it describes a role performed by one or more human 503 beings. Examples include help desks, network monitoring centers, system 504 administrators, etc. Role object is particularly useful since often a 505 person performing a role may change, however the role itself remains. 507 The attributes of the role class are shown in Figure 5. The nic-hdl 508 attributes of the person and role classes share the same name space. The 509 trouble attribute of role object may contain additional contact information 510 to be used when a problem arises in any object that references this role 511 object. Figure 6 shows an example role object. 513 Attribute Value Type 514 role mandatory, single-valued 515 nic-hdl mandatory, single-valued, class key 516 trouble optional, multi-valued 517 address mandatory, multi-valued 518 phone see description in text mandatory, multi-valued 519 fax-no same as phone optional, multi-valued 520 e-mail mandatory, multi-valued 522 Figure 5: role Class Attributes 524 role: RIPE NCC Operations 525 trouble: 526 address: Singel 258 527 address: 1016 AB Amsterdam 528 address: The Netherlands 529 phone: +31 20 535 4444 530 fax-no: +31 20 545 4445 531 e-mail: ops@ripe.net 532 admin-c: CO19-RIPE 533 tech-c: RW488-RIPE 534 tech-c: JLSD1-RIPE 535 nic-hdl: OPS4-RIPE 536 notify: ops@ripe.net 537 changed: roderik@ripe.net 19970926 538 source: RIPE 540 Figure 6: An example role object. 542 4 route Class 544 Each interAS route (also referred to as an interdomain route) originated by 545 an AS is specified using a route object. The attributes of the route class 546 are shown in Figure 7. The route attribute is the address prefix of the 547 route and the origin attribute is the AS number of the AS that originates 548 the route into the interAS routing system. The route and origin attribute 549 pair is the class key. 551 Figure 8 shows examples of four route objects (we do not include contact 552 attributes such as admin-c, tech-c for brevity). Note that the last two 553 route objects have the same address prefix, namely 128.8.0.0/16. However, 554 they are different route objects since they are originated by different ASes 555 (i.e. they have different keys). 557 Attribute Value Type 558 route mandatory, single-valued, class key 559 origin mandatory, single-valued, class key 560 member-of list of optional, multi-valued 561 see Section 5 562 inject see Section 8 optional, multi-valued 563 components see Section 8 optional, single-valued 564 aggr-bndry see Section 8 optional, single-valued 565 aggr-mtd see Section 8 optional, single-valued 566 export-comps see Section 8 optional, single-valued 567 holes see Section 8 optional, multi-valued 569 Figure 7: route Class Attributes 571 route: 128.9.0.0/16 572 origin: AS226 574 route: 128.99.0.0/16 575 origin: AS226 577 route: 128.8.0.0/16 578 origin: AS1 580 route: 128.8.0.0/16 581 origin: AS2 583 Figure 8: Route Objects 585 5 Set Classes 587 To specify policies, it is often useful to define sets of objects. For this 588 purpose we define as-set, route-set, rtr-set, filter-set, and peering-set 589 classes. These classes define a named set. The members of these sets can 590 be specified either directly by listing them in the sets' definition, or 591 indirectly by having member objects refer to the sets' names, or a 592 combination of both methods. 594 A set's name is an rpsl word with the following restrictions: All as-set 595 names start with prefix ``as-''. All route-set names start with prefix 596 ``rs-''. All rtr-set names start with prefix ``rtrs-''. All filter-set 597 names start with prefix ``fltr-''. All peering-set names start with prefix 598 ``prng-''. For example, as-foo is a valid as-set name. 600 Set names can also be hierarchical. A hierarchical set name is a sequence 601 of set names and AS numbers separated by colons ``:''. At least one 602 component of such a name must be an actual set name (i.e. start with one of 603 the prefixes above). All the set name components of an hierarchical name 604 has to be of the same type. For example, the following names are valid: 605 AS1:AS-CUSTOMERS, AS1:RS-EXPORT:AS2, RS-EXCEPTIONS:RS-BOGUS. 607 The purpose of an hierarchical set name is to partition the set name space 608 so that the maintainers of the set X1 controls the whole set name space 609 underneath, i.e. X1:...:Xn-1. Thus, a set object with name X1:...:Xn-1:Xn 610 can only be created by the maintainer of the object with name X1:...:Xn-1. 611 That is, only the maintainer of AS1 can create a set with name AS1:AS-FOO; 612 and only the maintainer of AS1:AS-FOO can create a set with name 613 AS1:AS-FOO:AS-BAR. Please see RPS Security Document [21] for details. 615 5.1 as-set Class 617 The attributes of the as-set class are shown in Figure 9. The as-set 618 attribute defines the name of the set. It is an RPSL name that starts with 619 ``as-''. The members attribute lists the members of the set. The members 620 attribute is a list of AS numbers, or other as-set names. 622 Attribute Value Type 623 as-set mandatory, single-valued, 624 class key 625 members list of or optional, multi-valued 626 627 mbrs-by-ref list of optional, multi-valued 629 Figure 9: as-set Class Attributes 631 Figure 10 presents two as-set objects. The set as-foo contains two ASes, 632 namely AS1 and AS2. The set as-bar contains the members of the set as-foo 633 and AS3, that is it contains AS1, AS2, AS3. The set as-empty contains no 634 members. 636 as-set: as-foo as-set: as-bar as-set: as-empty 637 members: AS1, AS2 members: AS3, as-foo 639 Figure 10: as-set objects. 641 The mbrs-by-ref attribute is a list of maintainer names or the keyword ANY. 642 If this attribute is used, the AS set also includes ASes whose aut-num 643 objects are registered by one of these maintainers and whose member-of 644 attribute refers to the name of this AS set. If the value of a mbrs-by-ref 645 attribute is ANY, any AS object referring to the AS set is a member of the 646 set. If the mbrs-by-ref attribute is missing, only the ASes listed in the 647 members attribute are members of the set. 649 as-set: as-foo 650 members: AS1, AS2 651 mbrs-by-ref: MNTR-ME 653 aut-num: AS3 aut-num: AS4 654 member-of: as-foo member-of: as-foo 655 mnt-by: MNTR-ME mnt-by: MNTR-OTHER 657 Figure 11: as-set objects. 659 Figure 11 presents an example as-set object that uses the mbrs-by-ref 660 attribute. The set as-foo contains AS1, AS2 and AS3. AS4 is not a member 661 of the set as-foo even though the aut-num object references as-foo. This is 662 because MNTR-OTHER is not listed in the as-foo's mbrs-by-ref attribute. 664 5.2 route-set Class 666 The attributes of the route-set class are shown in Figure 12. The route-set 667 attribute defines the name of the set. It is an RPSL name that starts with 668 ``rs-''. The members attribute lists the members of the set. The members 669 attribute is a list of address prefixes or other route-set names. Note 670 that, the route-set class is a set of route prefixes, not of RPSL route 671 objects. 673 Attribute Value Type 674 route-set mandatory, single-valued, 675 class key 676 members list of or optional, multi-valued 677 or 678 679 mbrs-by-ref list of optional, multi-valued 681 Figure 12: route-set Class Attributes 683 Figure 13 presents some example route-set objects. The set rs-foo contains 684 two address prefixes, namely 128.9.0.0/16 and 128.9.0.0/24. The set rs-bar 685 contains the members of the set rs-foo and the address prefix 128.7.0.0/16. 687 An address prefix or a route-set name in a members attribute can be 688 optionally followed by a range operator. For example, the following set 689 route-set: rs-foo 690 members: 128.9.0.0/16, 128.9.0.0/24 692 route-set: rs-bar 693 members: 128.7.0.0/16, rs-foo 695 Figure 13: route-set Objects 697 route-set: rs-bar 698 members: 5.0.0.0/8^+, 30.0.0.0/8^24-32, rs-foo^+ 700 contains all the more specifics of 5.0.0.0/8 including 5.0.0.0/8, all the 701 more specifics of 30.0.0.0/8 which are of length 24 to 32 such as 702 30.9.9.96/28, and all the more specifics of address prefixes in route set 703 rs-foo. 705 The mbrs-by-ref attribute is a list of maintainer names or the keyword ANY. 706 If this attribute is used, the route set also includes address prefixes 707 whose route objects are registered by one of these maintainers and whose 708 member-of attribute refers to the name of this route set. If the value of a 709 mbrs-by-ref attribute is ANY, any route object referring to the route set 710 name is a member. If the mbrs-by-ref attribute is missing, only the address 711 prefixes listed in the members attribute are members of the set. 713 route-set: rs-foo 714 mbrs-by-ref: MNTR-ME, MNTR-YOU 716 route-set: rs-bar 717 members: 128.7.0.0/16 718 mbrs-by-ref: MNTR-YOU 720 route: 128.9.0.0/16 721 origin: AS1 722 member-of: rs-foo 723 mnt-by: MNTR-ME 725 route: 128.8.0.0/16 726 origin: AS2 727 member-of: rs-foo, rs-bar 728 mnt-by: MNTR-YOU 730 Figure 14: route-set objects. 732 Figure 14 presents example route-set objects that use the mbrs-by-ref 733 attribute. The set rs-foo contains two address prefixes, namely 734 128.8.0.0/16 and 128.9.0.0/16 since the route objects for 128.8.0.0/16 and 735 128.9.0.0/16 refer to the set name rs-foo in their member-of attribute. The 736 set rs-bar contains the address prefixes 128.7.0.0/16 and 128.8.0.0/16. The 737 route 128.7.0.0/16 is explicitly listed in the members attribute of rs-bar, 738 and the route object for 128.8.0.0/16 refer to the set name rs-bar in its 739 member-of attribute. 741 Note that, if an address prefix is listed in a members attribute of a route 742 set, it is a member of that route set. The route object corresponding to 743 this address prefix does not need to contain a member-of attribute referring 744 to this set name. The member-of attribute of the route class is an 745 additional mechanism for specifying the members indirectly. 747 5.3 Predefined Set Objects 749 In a context that expects a route set (e.g. members attribute of the 750 route-set class), an AS number ASx defines the set of routes that are 751 originated by ASx; and an as-set AS-X defines the set of routes that are 752 originated by the ASes in AS-X. A route p is said to be originated by ASx if 753 there is a route object for p with ASx as the value of the origin attribute. 754 For example, in Figure 15, the route set rs-special contains 128.9.0.0/16, 755 routes of AS1 and AS2, and routes of the ASes in AS set AS-FOO. 757 route-set: rs-special 758 members: 128.9.0.0/16, AS1, AS2, AS-FOO 760 Figure 15: Use of AS numbers and AS sets in route sets. 762 The set rs-any contains all routes registered in IRR. The set as-any 763 contains all ASes registered in IRR. 765 5.4 Filters and filter-set Class 767 The attributes of the filter-set class are shown in Figure 16. A filter-set 768 object defines a set of routes that are matched by its filter. The 769 filter-set attribute defines the name of the filter. It is an RPSL name 770 that starts with ``fltr-''. 772 Attribute Value Type 773 filter-set mandatory, single-valued, class key 774 filter mandatory, single-valued 776 Figure 16: filter Class Attributes 778 filter-set: fltr-foo 779 filter: { 5.0.0.0/8, 6.0.0.0/8 } 781 filter-set: fltr-bar 782 filter: (AS1 or fltr-foo) and 784 Figure 17: filter-set objects. 786 The filter attribute defines the set's policy filter. A policy filter is a 787 logical expression which when applied to a set of routes returns a subset of 788 these routes. We say that the policy filter matches the subset returned. 789 The policy filter can match routes using any BGP path attribute, such as the 790 destination address prefix (or NLRI), AS-path, or community attributes. 792 The policy filters can be composite by using the operators AND, OR, and NOT. 793 The following policy filters can be used to select a subset of routes: 795 ANY The keyword ANY matches all routes. 797 Address-Prefix Set This is an explicit list of address prefixes enclosed in 798 braces '{' and '}'. The policy filter matches the set of routes whose 799 destination address-prefix is in the set. For example: 801 { 0.0.0.0/0 } 802 { 128.9.0.0/16, 128.8.0.0/16, 128.7.128.0/17, 5.0.0.0/8 } 803 { } 805 An address prefix can be optionally followed by a range operator (i.e. '^-', 806 '^+', '^n', or '^n-m'). For example, the set 808 { 5.0.0.0/8^+, 128.9.0.0/16^-, 30.0.0.0/8^16, 30.0.0.0/8^24-32 } 810 contains all the more specifics of 5.0.0.0/8 including 5.0.0.0/8, all the 811 more specifics of 128.9.0.0/16 excluding 128.9.0.0/16, all the more 812 specifics of 30.0.0.0/8 which are of length 16 such as 30.9.0.0/16, and all 813 the more specifics of 30.0.0.0/8 which are of length 24 to 32 such as 814 30.9.9.96/28. 816 Route Set Name A route set name matches the set of routes that are members 817 of the set. A route set name may be a name of a route-set object, an AS 818 number, or a name of an as-set object (AS numbers and as-set names 819 implicitly define route sets; please see Section 5.3). For example: 821 aut-num: AS1 822 import: from AS2 accept AS2 823 import: from AS2 accept AS-FOO 824 import: from AS2 accept RS-FOO 826 The keyword PeerAS can be used instead of the AS number of the peer AS. 827 PeerAS is particularly useful when the peering is specified using an AS 828 expression. For example: 830 as-set: AS-FOO 831 members: AS2, AS3 833 aut-num: AS1 834 import: from AS-FOO accept PeerAS 836 is same as: 838 aut-num: AS1 839 import: from AS2 accept AS2 840 import: from AS3 accept AS3 842 A route set name can also be followed by one of the operators '^-', '^+', 843 '^n' or '^n-m'. These operators are distributive over the route sets. For 844 example, { 5.0.0.0/8, 6.0.0.0/8 }^+ equals { 5.0.0.0/8^+, 6.0.0.0/8^+ }, and 845 AS1^- equals all the exclusive more specifics of routes originated by AS1. 847 AS Path Regular Expressions An AS-path regular expression can be used as a 848 policy filter by enclosing the expression in `<' and `>'. An AS-path policy 849 filter matches the set of routes which traverses a sequence of ASes matched 850 by the AS-path regular expression. A router can check this using the 851 AS_PATH attribute in the Border Gateway Protocol [20], or the RD_PATH 852 attribute in the Inter-Domain Routing Protocol[19]. 854 AS-path Regular Expressions are POSIX compliant regular expressions over the 855 alphabet of AS numbers. The regular expression constructs are as follows: 857 ASN where ASN is an AS number. ASN matches the AS-path that is of 858 length 1 and contains the corresponding AS number (e.g. 859 AS-path regular expression AS1 matches the AS-path ``1''). 861 The keyword PeerAS can be used instead of the AS number of the 862 peer AS. 864 AS-set where AS-set is an AS set name. AS-set matches the AS-paths that 865 is matched by one of the ASes in the AS-set. 867 . matches the AS-paths matched by any AS number. 869 [...] is an AS number set. It matches the AS-paths matched by the AS 870 numbers listed between the brackets. The AS numbers in the 871 set are separated by white space characters. If a `-' is used 872 between two AS numbers in this set, all AS numbers between the 873 two AS numbers are included in the set. If an as-set name is 874 listed, all AS numbers in the as-set are included. 876 [^...] is a complemented AS number set. It matches any AS-path which is 877 not matched by the AS numbers in the set. 879 ^ Matches the empty string at the beginning of an AS-path. 881 $ Matches the empty string at the end of an AS-path. 883 We next list the regular expression operators in the decreasing order of 884 evaluation. These operators are left associative, i.e. performed left to 885 right. 887 Unary postfix operators * + ? {m} {m,n} {m,} 888 For a regular expression A, A* matches zero or more 889 occurrences of A; A+ matches one or more occurrences of A; A? 890 matches zero or one occurrence of A; A{m} matches m occurrence 891 of A; A{m,n} matches m to n occurrence of A; A{m,} matches m or 892 more occurrence of A. For example, [AS1 AS2]{2} matches AS1 893 AS1, AS1 AS2, AS2 AS1, and AS2 AS2. 895 Unary postfix operators ~* ~+ ~{m} ~{m,n} ~{m,} 896 These operators have similar functionality as the 897 corresponding operators listed above, but all occurrences of 898 the regular expression has to match the same pattern. For 899 example, [AS1 AS2]~{2} matches AS1 AS1 and AS2 AS2, but it does 900 not match AS1 AS2 and AS2 AS1. 902 Binary catenation operator 903 This is an implicit operator and exists between two regular 904 expressions A and B when no other explicit operator is 905 specified. The resulting expression A B matches an AS-path if 906 A matches some prefix of the AS-path and B matches the rest of 907 the AS-path. 909 Binary alternative (or) operator | 910 For a regular expressions A and B, A | B matches any AS-path 911 that is matched by A or B. 913 Parenthesis can be used to override the default order of evaluation. White 914 spaces can be used to increase readability. 916 The following are examples of AS-path filters: 918 919 <^AS1> 920 921 <^AS1 AS2 AS3$> 922 <^AS1 .* AS2$>. 924 The first example matches any route whose AS-path contains AS3, the second 925 matches routes whose AS-path starts with AS1, the third matches routes whose 926 AS-path ends with AS2, the fourth matches routes whose AS-path is exactly 927 ``1 2 3'', and the fifth matches routes whose AS-path starts with AS1 and 928 ends in AS2 with any number of AS numbers in between. 930 Composite Policy Filters The following operators (in decreasing order of 931 evaluation) can be used to form composite policy filters: 933 NOT Given a policy filter x, NOT x matches the set of routes that are not 934 matched by x. That is it is the negation of policy filter x. 936 AND Given two policy filters x and y, x AND y matches the intersection of 937 the routes that are matched by x and that are matched by y. 939 OR Given two policy filters x and y, x OR y matches the union of the routes 940 that are matched by x and that are matched by y. 942 Note that an OR operator can be implicit, that is `x y' is equivalent to `x 943 OR y'. 945 E.g. 946 NOT {128.9.0.0/16, 128.8.0.0/16} 947 AS226 AS227 OR AS228 948 AS226 AND NOT {128.9.0.0/16} 949 AS226 AND {0.0.0.0/0^0-18} 951 The first example matches any route except 128.9.0.0/16 and 128.8.0.0/16. 952 The second example matches the routes of AS226, AS227 and AS228. The third 953 example matches the routes of AS226 except 128.9.0.0/16. The fourth example 954 matches the routes of AS226 whose length are not longer than 18. 956 Routing Policy Attributes Policy filters can also use the values of other 957 attributes for comparison. The attributes whose values can be used in 958 policy filters are specified in the RPSL dictionary. Please refer to 959 Section 7 for details. An example using the the BGP community attribute is 960 shown below: 962 aut-num: AS1 963 export: to AS2 announce AS1 AND NOT community(NO_EXPORT) 965 Filters using the routing policy attributes defined in the dictionary are 966 evaluated before evaluating the operators AND, OR and NOT. 968 Filter Set Name A filter set name matches the set of routes that are 969 matched by its filter attribute. Note that the filter attribute of a filter 970 set, can recursively refer to other filter set names. For example in 971 Figure 17, fltr-foo matches { 5.0.0.0/8, 6.0.0.0/8 }, and fltr-bar matches 972 AS1'S routes or { 5.0.0.0/8, 6.0.0.0/8 } if their as path contained AS2. 974 5.5 rtr-set Class 976 The attributes of the rtr-set class are shown in Figure 18. The rtr-set 977 attribute defines the name of the set. It is an RPSL name that starts with 978 ``rtrs-''. The members attribute lists the members of the set. The members 979 attribute is a list of inet-rtr names, ipv4_addresses or other rtr-set 980 names. 982 Attribute Value Type 983 rtr-set mandatory, single-valued, 984 class key 985 members list of or optional, multi-valued 986 987 or 988 mbrs-by-ref list of optional, multi-valued 990 Figure 18: rtr-set Class Attributes 992 Figure 19 presents two rtr-set objects. The set rtrs-foo contains two 993 routers, namely rtr1.isp.net and rtr2.isp.net. The set rtrs-bar contains 994 the members of the set rtrs-foo and rtr3.isp.net, that is it contains 995 rtr1.isp.net, rtr2.isp.net, rtr3.isp.net. 997 rtr-set: rtrs-foo rtr-set: rtrs-bar 998 members: rtr1.isp.net, rtr2.isp.net members: rtr3.isp.net, rtrs-foo 1000 Figure 19: rtr-set objects. 1002 The mbrs-by-ref attribute is a list of maintainer names or the keyword ANY. 1003 If this attribute is used, the router set also includes routers whose 1004 inet-rtr objects are registered by one of these maintainers and whose 1005 member-of attribute refers to the name of this router set. If the value of 1006 a mbrs-by-ref attribute is ANY, any inet-rtr object referring to the router 1007 set is a member of the set. If the mbrs-by-ref attribute is missing, only 1008 the routers listed in the members attribute are members of the set. 1010 rtr-set: rtrs-foo 1011 members: rtr1.isp.net, rtr2.isp.net 1012 mbrs-by-ref: MNTR-ME 1014 inet-rtr: rtr3.isp.net 1015 local-as: as1 1016 ifaddr: 1.1.1.1 masklen 30 1017 member-of: rtrs-foo 1018 mnt-by: MNTR-ME 1020 Figure 20: rtr-set objects. 1022 Figure 20 presents an example rtr-set object that uses the mbrs-by-ref 1023 attribute. The set rtrs-foo contains rtr1.isp.net, rtr2.isp.net and 1024 rtr3.isp.net. 1026 5.6 Peerings and peering-set Class 1028 The attributes of the peering-set class are shown in Figure 21. A 1029 peering-set object defines a set of peerings that are listed in its peering 1030 attributes. The peering-set attribute defines the name of the set. It is 1031 an RPSL name that starts with ``prng-''. 1033 Attribute Value Type 1034 peering-set mandatory, single-valued, class key 1035 peering mandatory, multi-valued 1037 Figure 21: filter Class Attributes 1039 The peering attribute defines a peering that can be used for importing or 1040 ---------------------- ---------------------- 1041 | 7.7.7.1 |-------| |-------| 7.7.7.2 | 1042 | | ======== | | 1043 | AS1 | EX1 |-------| 7.7.7.3 AS2 | 1044 | | | | 1045 | 9.9.9.1 |------ ------| 9.9.9.2 | 1046 ---------------------- | | ---------------------- 1047 =========== 1048 | EX2 1049 ---------------------- | 1050 | 9.9.9.3 |--------- 1051 | | 1052 | AS3 | 1053 ---------------------- 1055 Figure 22: Example topology consisting of three ASes, AS1, AS2, and AS3; 1056 two exchange points, EX1 and EX2; and six routers. 1058 exporting routes. In describing peerings, we are going to use the topology 1059 of Figure 22. In this topology, there are three ASes, AS1, AS2, and AS3; 1060 two exchange points, EX1 and EX2; and six routers. Routers connected to the 1061 same exchange point peer with each other and exchange routing information. 1062 That is, 7.7.7.1, 7.7.7.2 and 7.7.7.3 peer with each other; 9.9.9.1, 9.9.9.2 1063 and 9.9.9.3 peer with each other. 1065 The syntax of a peering specification is: 1067 [] [at ] 1068 | 1070 where is an expression over AS numbers and AS sets using 1071 operators AND, OR, and EXCEPT, and and 1072 are expressions over router IP addresses, inet-rtr 1073 names, and rtr-set names using operators AND, OR, and EXCEPT. The binary 1074 ``EXCEPT'' operator is the set subtraction operator and has the same 1075 precedence as the operator AND (it is semantically equivalent to ``AND NOT'' 1076 combination). That is ``(AS1 OR AS2) EXCEPT AS2'' equals ``AS1''. 1078 This form identifies all the peerings between any local router in 1079 to any of their peer routers in 1080 in the ASes in . If is not specified, 1081 it defaults to all routers of the local AS that peer with ASes in 1082 . If is not specified, it defaults to 1083 all routers of the peer ASes in that peer with the local AS. 1085 If a is used, the peerings are listed in the 1086 corresponding peering-set object. Note that the peering-set objects can be 1087 recursive. 1089 Many special forms of this general peering specification is possible. The 1090 following examples illustrate the most common cases, using the import 1091 attribute of the aut-num class. In the following example 7.7.7.1 imports 1092 128.9.0.0/16 from 7.7.7.2. 1094 (1) aut-num: AS1 1095 import: from AS2 7.7.7.2 at 7.7.7.1 accept { 128.9.0.0/16 } 1097 In the following example 7.7.7.1 imports 128.9.0.0/16 from 7.7.7.2 and 1098 7.7.7.3. 1100 (2) aut-num: AS1 1101 import: from AS2 at 7.7.7.1 accept { 128.9.0.0/16 } 1103 In the following example 7.7.7.1 imports 128.9.0.0/16 from 7.7.7.2 and 1104 7.7.7.3, and 9.9.9.1 imports 128.9.0.0/16 from 9.9.9.2. 1106 (3) aut-num: AS1 1107 import: from AS2 accept { 128.9.0.0/16 } 1109 In the following example 9.9.9.1 imports 128.9.0.0/16 from 9.9.9.2 and 1110 9.9.9.3. 1112 (4) as-set: AS-FOO 1113 members: AS2, AS3 1115 aut-num: AS1 1116 import: from AS-FOO at 9.9.9.1 accept { 128.9.0.0/16 } 1118 In the following example 9.9.9.1 imports 128.9.0.0/16 from 9.9.9.2 and 1119 9.9.9.3, and 7.7.7.1 imports 128.9.0.0/16 from 7.7.7.2 and 7.7.7.3. 1121 (5) aut-num: AS1 1122 import: from AS-FOO accept { 128.9.0.0/16 } 1124 In the following example AS1 imports 128.9.0.0/16 from AS3 at router 9.9.9.1 1125 (6) aut-num: AS1 1126 import: from AS-FOO and not AS2 at not 7.7.7.1 1127 accept { 128.9.0.0/16 } 1129 This is because "AS-FOO and not AS2" equals AS3 and "not 7.7.7.1" equals 1130 9.9.9.1. 1132 In the following example 9.9.9.1 imports 128.9.0.0/16 from 9.9.9.2 and 1133 9.9.9.3. 1135 (7) peering-set: prng-bar 1136 peering: AS1 at 9.9.9.1 1138 peering-set: prng-foo 1139 peering: prng-bar 1140 peering: AS2 at 9.9.9.1 1142 aut-num: AS1 1143 import: from prng-foo accept { 128.9.0.0/16 } 1145 6 aut-num Class 1147 Routing policies are specified using the aut-num class. The attributes of 1148 the aut-num class are shown in Figure 23. The value of the aut-num 1149 attribute is the AS number of the AS described by this object. The as-name 1150 attribute is a symbolic name (in RPSL name syntax) of the AS. The import, 1151 export and default routing policies of the AS are specified using import, 1152 export and default attributes respectively. 1154 Attribute Value Type 1155 aut-num mandatory, single-valued, class key 1156 as-name mandatory, single-valued 1157 member-of list of optional, multi-valued 1158 import see Section 6.1 optional, multi valued 1159 export see Section 6.2 optional, multi valued 1160 default see Section 6.5 optional, multi valued 1162 Figure 23: aut-num Class Attributes 1164 6.1 import Attribute: Import Policy Specification 1166 In RPSL, an import policy is divided into import policy expressions. Each 1167 import policy expression is specified using an import attribute. The import 1168 attribute has the following syntax (we will extend this syntax later in 1169 Sections 6.3 and 6.6): 1171 import: from [action ] 1172 . . . 1173 from [action ] 1174 accept 1176 The action specification is optional. The semantics of an import attribute 1177 is as follows: the set of routes that are matched by are imported 1178 from all the peers in ; while importing routes at , 1179 is executed. 1181 E.g. 1182 aut-num: AS1 1183 import: from AS2 action pref = 1; accept { 128.9.0.0/16 } 1185 This example states that the route 128.9.0.0/16 is accepted from AS2 with 1186 preference 1. We already presented how peerings (see Section 5.6) and 1187 filters (see Section 5.4) are specified. We next present how to specify 1188 actions. 1190 6.1.1 Action Specification 1192 Policy actions in RPSL either set or modify route attributes, such as 1193 assigning a preference to a route, adding a BGP community to the BGP 1194 community path attribute, or setting the MULTI-EXIT-DISCRIMINATOR attribute. 1195 Policy actions can also instruct routers to perform special operations, such 1196 as route flap damping. 1198 The routing policy attributes whose values can be modified in policy actions 1199 are specified in the RPSL dictionary. Please refer to Section 7 for a list 1200 of these attributes. Each action in RPSL is terminated by the semicolon 1201 character (';'). It is possible to form composite policy actions by listing 1202 them one after the other. In a composite policy action, the actions are 1203 executed left to right. For example, 1205 aut-num: AS1 1206 import: from AS2 1207 action pref = 10; med = 0; community.append(10250, 3561:10); 1208 accept { 128.9.0.0/16 } 1210 sets pref to 10, med to 0, and then appends 10250 and 3561:10 to the BGP 1211 community path attribute. The pref attribute is the inverse of the 1212 local-pref attribute (i.e. local-pref == 65535 - pref). A route with a 1213 local-pref attribute is always preferred over a route without one. 1215 aut-num: AS1 1216 import: from AS2 action pref = 1; 1217 from AS3 action pref = 2; 1218 accept AS4 1220 The above example states that AS4's routes are accepted from AS2 with 1221 preference 1, and from AS3 with preference 2 (routes with lower integer 1222 preference values are preferred over routes with higher integer preference 1223 values). 1225 aut-num: AS1 1226 import: from AS2 7.7.7.2 at 7.7.7.1 action pref = 1; 1227 from AS2 action pref = 2; 1228 accept AS4 1230 The above example states that AS4's routes are accepted from AS2 on peering 1231 7.7.7.1-7.7.7.2 with preference 1, and on any other peering with AS2 with 1232 preference 2. 1234 6.2 export Attribute: Export Policy Specification 1236 Similarly, an export policy expression is specified using an export 1237 attribute. The export attribute has the following syntax: 1239 export: to [action ] 1240 . . . 1241 to [action ] 1242 announce 1244 The action specification is optional. The semantics of an export attribute 1245 is as follows: the set of routes that are matched by are exported 1246 to all the peers specified in ; while exporting routes at 1247 , is executed. 1249 E.g. 1250 aut-num: AS1 1251 export: to AS2 action med = 5; community .= { 70 }; 1252 announce AS4 1254 In this example, AS4's routes are announced to AS2 with the med attribute's 1255 value set to 5 and community 70 added to the community list. 1257 Example: 1259 aut-num: AS1 1260 export: to AS-FOO announce ANY 1262 In this example, AS1 announces all of its routes to the ASes in the set 1263 AS-FOO. 1265 6.3 Other Routing Protocols, Multi-Protocol Routing Protocols, and Injecting 1266 Routes Between Protocols 1268 The more complete syntax of the import and export attributes are as follows: 1270 import: [protocol ] [into ] 1271 from [action ] 1272 . . . 1273 from [action ] 1274 accept 1275 export: [protocol ] [into ] 1276 to [action ] 1277 . . . 1278 to [action ] 1279 announce 1281 Where the optional protocol specifications can be used for specifying 1282 policies for other routing protocols, or for injecting routes of one 1283 protocol into another protocol, or for multi-protocol routing policies. The 1284 valid protocol names are defined in the dictionary. The is the 1285 name of the protocol whose routes are being exchanged. The is 1286 the name of the protocol which is receiving these routes. Both 1287 and default to the Internet Exterior Gateway Protocol, 1288 currently BGP. 1290 In the following example, all interAS routes are injected into RIP. 1292 aut-num: AS1 1293 import: from AS2 accept AS2 1294 export: protocol BGP4 into RIP 1295 to AS1 announce ANY 1297 In the following example, AS1 accepts AS2's routes including any more 1298 specifics of AS2's routes, but does not inject these extra more specific 1299 routes into OSPF. 1301 aut-num: AS1 1302 import: from AS2 accept AS2^+ 1303 export: protocol BGP4 into OSPF 1304 to AS1 announce AS2 1306 In the following example, AS1 injects its static routes (routes which are 1307 members of the set AS1:RS-STATIC-ROUTES) to the interAS routing protocol and 1308 appends AS1 twice to their AS paths. 1310 aut-num: AS1 1311 import: protocol STATIC into BGP4 1312 from AS1 action aspath.prepend(AS1, AS1); 1313 accept AS1:RS-STATIC-ROUTES 1315 In the following example, AS1 imports different set of unicast routes for 1316 multicast reverse path forwarding from AS2: 1318 aut-num: AS1 1319 import: from AS2 accept AS2 1320 import: protocol IDMR 1321 from AS2 accept AS2:RS-RPF-ROUTES 1323 6.4 Ambiguity Resolution 1325 It is possible that the same peering can be covered by more that one peering 1326 specification in a policy expression. For example: 1328 aut-num: AS1 1329 import: from AS2 7.7.7.2 at 7.7.7.1 action pref = 2; 1330 from AS2 7.7.7.2 at 7.7.7.1 action pref = 1; 1331 accept AS4 1333 This is not an error, though definitely not desirable. To break the 1334 ambiguity, the action corresponding to the first peering specification is 1335 used. That is the routes are accepted with preference 2. We call this rule 1336 as the specification-order rule. 1338 Consider the example: 1340 aut-num: AS1 1341 import: from AS2 action pref = 2; 1342 from AS2 7.7.7.2 at 7.7.7.1 action pref = 1; dpa = 5; 1343 accept AS4 1345 where both peering specifications cover the peering 7.7.7.1-7.7.7.2, though 1346 the second one covers it more specifically. The specification order rule 1347 still applies, and only the action ``pref = 2'' is executed. In fact, the 1348 second peering-action pair has no use since the first peering-action pair 1349 always covers it. If the intended policy was to accept these routes with 1350 preference 1 on this particular peering and with preference 2 in all other 1351 peerings, the user should have specified: 1353 aut-num: AS1 1354 import: from AS2 7.7.7.2 at 7.7.7.1 action pref = 1; dpa = 5; 1355 from AS2 action pref = 2; 1356 accept AS4 1358 It is also possible that more than one policy expression can cover the same 1359 set of routes for the same peering. For example: 1361 aut-num: AS1 1362 import: from AS2 action pref = 2; accept AS4 1363 import: from AS2 action pref = 1; accept AS4 1365 In this case, the specification-order rule is still used. That is, AS4's 1366 routes are accepted from AS2 with preference 2. If the filters were 1367 overlapping but not exactly the same: 1369 aut-num: AS1 1370 import: from AS2 action pref = 2; accept AS4 1371 import: from AS2 action pref = 1; accept AS4 OR AS5 1373 the AS4's routes are accepted from AS2 with preference 2 and however AS5's 1374 routes are also accepted, but with preference 1. 1376 We next give the general specification order rule for the benefit of the 1377 RPSL implementors. Consider two policy expressions: 1379 aut-num: AS1 1380 import: from peerings-1 action action-1 accept filter-1 1381 import: from peerings-2 action action-2 accept filter-2 1383 The above policy expressions are equivalent to the following three 1384 expressions where there is no ambiguity: 1386 aut-num: AS1 1387 import: from peerings-1 action action-1 accept filter-1 1388 import: from peerings-3 action action-2 accept filter-2 AND NOT filter-1 1389 import: from peerings-4 action action-2 accept filter-2 1391 where peerings-3 are those that are covered by both peerings-1 and 1392 peerings-2, and peerings-4 are those that are covered by peerings-2 but not 1393 by peerings-1 (``filter-2 AND NOT filter-1'' matches the routes that are 1394 matched by filter-2 but not by filter-1). 1396 Example: 1398 aut-num: AS1 1399 import: from AS2 7.7.7.2 at 7.7.7.1 1400 action pref = 2; 1401 accept {128.9.0.0/16} 1402 import: from AS2 1403 action pref = 1; 1404 accept {128.9.0.0/16, 75.0.0.0/8} 1406 Lets consider two peerings with AS2, 7.7.7.1-7.7.7.2 and 9.9.9.1-9.9.9.2. 1407 Both policy expressions cover 7.7.7.1-7.7.7.2. On this peering, the route 1408 128.9.0.0/16 is accepted with preference 2, and the route 75.0.0.0/8 is 1409 accepted with preference 1. The peering 9.9.9.1-9.9.9.2 is only covered by 1410 the second policy expressions. Hence, both the route 128.9.0.0/16 and the 1411 route 75.0.0.0/8 are accepted with preference 1 on peering 9.9.9.1-9.9.9.2. 1413 Note that the same ambiguity resolution rules also apply to export and 1414 default policy expressions. 1416 6.5 default Attribute: Default Policy Specification 1418 Default routing policies are specified using the default attribute. The 1419 default attribute has the following syntax: 1421 default: to [action ] [networks ] 1423 The and specifications are optional. The semantics are as 1424 follows: The specification indicates the AS (and the router if 1425 present) is being defaulted to; the specification, if present, 1426 indicates various attributes of defaulting, for example a relative 1427 preference if multiple defaults are specified; and the 1428 specifications, if present, is a policy filter. A router only uses the 1429 default policy if it received the routes matched by from this peer. 1431 In the following example, AS1 defaults to AS2 for routing. 1433 aut-num: AS1 1434 default: to AS2 1436 In the following example, router 7.7.7.1 in AS1 defaults to router 7.7.7.2 1437 in AS2. 1439 aut-num: AS1 1440 default: to AS2 7.7.7.2 at 7.7.7.1 1442 In the following example, AS1 defaults to AS2 and AS3, but prefers AS2 over 1443 AS3. 1445 aut-num: AS1 1446 default: to AS2 action pref = 1; 1447 default: to AS3 action pref = 2; 1449 In the following example, AS1 defaults to AS2 and uses 128.9.0.0/16 as the 1450 default network. 1452 aut-num: AS1 1453 default: to AS2 networks { 128.9.0.0/16 } 1455 6.6 Structured Policy Specification 1457 The import and export policies can be structured. We only reccomend 1458 structured policies to advanced RPSL users. Please feel free to skip this 1459 section. 1461 The syntax for a structured policy specification is the following: 1463 ::= from [action ] 1464 . . . 1465 from [action ] 1466 accept ; 1468 ::= | 1469 LEFT-BRACE 1470 1471 . . . 1472 1473 RIGHT-BRACE 1475 ::= | 1476 EXCEPT | 1477 REFINE 1479 import: [protocol ] [into ] 1480 1482 Please note the semicolon at the end of an . If the policy 1483 specification is not structured (as in all the examples in other sections), 1484 this semicolon is optional. The syntax and semantics for an 1485 is already defined in Section 6.1. 1487 An is either a sequence of 's enclosed within 1488 matching braces (i.e. `{' and `}') or just a single . The 1489 semantics of an is the union of 's using the 1490 specification order rule. An is either a single 1491 or an followed by one of the keywords "except" 1492 and "refine", followed by another . Note that our 1493 definition allows nested expressions. Hence there can be exceptions to 1494 exceptions, refinements to refinements, or even refinements to exceptions, 1495 and so on. 1497 The semantics for the except operator is as follows: The result of an 1498 except operation is another . The resulting policy set 1499 contains the policies of the right hand side but their filters are modified 1500 to only include the routes also matched by the left hand side. The policies 1501 of the left hand side are included afterwards and their filters are modified 1502 to exclude the routes matched by the right hand side. Please note that the 1503 filters are modified during this process but the actions are copied 1504 verbatim. When there are multiple levels of nesting, the operations (both 1505 except and refine) are performed right to left. 1507 Consider the following example: 1509 import: from AS1 action pref = 1; accept as-foo; 1510 except { 1511 from AS2 action pref = 2; accept AS226; 1512 except { 1513 from AS3 action pref = 3; accept {128.9.0.0/16}; 1514 } 1515 } 1517 where the route 128.9.0.0/16 is originated by AS226, and AS226 is a member 1518 of the as set as-foo. In this example, the route 128.9.0.0/16 is accepted 1519 from AS3, any other route (not 128.9.0.0/16) originated by AS226 is accepted 1520 from AS2, and any other ASes' routes in as-foo is accepted from AS1. 1522 We can come to the same conclusion using the algebra defined above. 1523 Consider the inner exception specification: 1525 from AS2 action pref = 2; accept AS226; 1526 except { 1527 from AS3 action pref = 3; accept {128.9.0.0/16}; 1528 } 1530 is equivalent to 1532 { 1533 from AS3 action pref = 3; accept AS226 AND {128.9.0.0/16}; 1534 from AS2 action pref = 2; accept AS226 AND NOT {128.9.0.0/16}; 1535 } 1537 Hence, the original expression is equivalent to: 1539 import: from AS1 action pref = 1; accept as-foo; 1540 except { 1541 from AS3 action pref = 3; accept AS226 AND {128.9.0.0/16}; 1542 from AS2 action pref = 2; accept AS226 AND NOT {128.9.0.0/16}; 1543 } 1545 which is equivalent to 1546 import: { 1547 from AS3 action pref = 3; 1548 accept as-foo AND AS226 AND {128.9.0.0/16}; 1549 from AS2 action pref = 2; 1550 accept as-foo AND AS226 AND NOT {128.9.0.0/16}; 1551 from AS1 action pref = 1; 1552 accept as-foo AND NOT 1553 (AS226 AND NOT {128.9.0.0/16} OR AS226 AND {128.9.0.0/16}); 1554 } 1556 Since AS226 is in as-foo and 128.9.0.0/16 is in AS226, it simplifies to: 1558 import: { 1559 from AS3 action pref = 3; accept {128.9.0.0/16}; 1560 from AS2 action pref = 2; accept AS226 AND NOT {128.9.0.0/16}; 1561 from AS1 action pref = 1; accept as-foo AND NOT AS226; 1562 } 1564 In the case of the refine operator, the resulting set is constructed by 1565 taking the cartasian product of the two sides as follows: for each policy l 1566 in the left hand side and for each policy r in the right hand side, the 1567 peerings of the resulting policy are the peerings common to both r and l; 1568 the filter of the resulting policy is the intersection of l's filter and r's 1569 filter; and action of the resulting policy is l's action followed by r's 1570 action. If there are no common peerings, or if the intersection of filters 1571 is empty, a resulting policy is not generated. 1573 Consider the following example: 1575 import: { from AS-ANY action pref = 1; accept community(3560:10); 1576 from AS-ANY action pref = 2; accept community(3560:20); 1577 } refine { 1578 from AS1 accept AS1; 1579 from AS2 accept AS2; 1580 from AS3 accept AS3; 1581 } 1583 Here, any route with community 3560:10 is assigned a preference of 1 and any 1584 route with community 3560:20 is assigned a preference of 2 regardless of 1585 whom they are imported from. However, only AS1's routes are imported from 1586 AS1, and only AS2's routes are imported from AS2, and only AS3's routes are 1587 imported form AS3, and no routes are imported from any other AS. We can 1588 reach the same conclusion using the above algebra. That is, our example is 1589 equivalent to: 1591 import: { 1592 from AS1 action pref = 1; accept community(3560:10) AND AS1; 1593 from AS1 action pref = 2; accept community(3560:20) AND AS1; 1594 from AS2 action pref = 1; accept community(3560:10) AND AS2; 1595 from AS2 action pref = 2; accept community(3560:20) AND AS2; 1596 from AS3 action pref = 1; accept community(3560:10) AND AS3; 1597 from AS3 action pref = 2; accept community(3560:20) AND AS3; 1598 } 1600 Note that the common peerings between ``from AS1'' and ``from AS-ANY'' are 1601 those peerings in ``from AS1''. Even though we do not formally define 1602 ``common peerings'', it is straight forward to deduce the definition from 1603 the definitions of peerings (please see Section 5.6). 1605 Consider the following example: 1607 import: { 1608 from AS-ANY action med = 0; accept {0.0.0.0/0^0-18}; 1609 } refine { 1610 from AS1 at 7.7.7.1 action pref = 1; accept AS1; 1611 from AS1 action pref = 2; accept AS1; 1612 } 1614 where only routes of length 0 to 18 are accepted and med's value is set to 0 1615 to disable med's effect for all peerings; In addition, from AS1 only AS1's 1616 routes are imported, and AS1's routes imported at 7.7.7.1 are preferred over 1617 other peerings. This is equivalent to: 1619 import: { 1620 from AS1 at 7.7.7.1 action med=0; pref=1; accept {0.0.0.0/0^0- 1621 18} AND AS1; 1622 from AS1 action med=0; pref=2; accept {0.0.0.0/0^0- 1623 18} AND AS1; 1624 } 1626 The above syntax and semantics also apply equally to structured export 1627 policies with ``from'' replaced with ``to'' and ``accept'' is replaced with 1628 ``announce''. 1630 7 dictionary Class 1632 The dictionary class provides extensibility to RPSL. Dictionary objects 1633 define routing policy attributes, types, and routing protocols. Routing 1634 policy attributes, henceforth called rp-attributes, may correspond to actual 1635 protocol attributes, such as the BGP path attributes (e.g. community, dpa, 1636 and AS-path), or they may correspond to router features (e.g. BGP route flap 1637 damping). As new protocols, new protocol attributes, or new router features 1638 are introduced, the dictionary object is updated to include appropriate 1639 rp-attribute and protocol definitions. 1641 An rp-attribute is an abstract class; that is a data representation is not 1642 available. Instead, they are accessed through access methods. For example, 1643 the rp-attribute for the BGP AS-path attribute is called aspath; and it has 1644 an access method called prepend which stuffs extra AS numbers to the AS-path 1645 attributes. Access methods can take arguments. Arguments are strongly 1646 typed. For example, the method prepend above takes AS numbers as arguments. 1648 Once an rp-attribute is defined in the dictionary, it can be used to 1649 describe policy filters and actions. Policy analysis tools are required to 1650 fetch the dictionary object and recognize newly defined rp-attributes, 1651 types, and protocols. The analysis tools may approximate policy analyses on 1652 rp-attributes that they do not understand: a filter method may always 1653 match, and an action method may always perform no-operation. Analysis tools 1654 may even download code to perform appropriate operations using mechanisms 1655 outside the scope of RPSL. 1657 We next describe the syntax and semantics of the dictionary class. This 1658 description is not essential for understanding dictionary objects (but it is 1659 essential for creating one). Please feel free to skip to the RPSL Initial 1660 Dictionary subsection (Section 7.1). 1662 The attributes of the dictionary class are shown in Figure 24. The 1663 dictionary attribute is the name of the dictionary object, obeying the RPSL 1664 naming rules. There can be many dictionary objects, however there is always 1665 one well-known dictionary object ``RPSL''. All tools use this dictionary by 1666 default. 1668 Attribute Value Type 1669 dictionary mandatory, single-valued, class key 1670 rp-attribute see description in text optional, multi valued 1671 typedef see description in text optional, multi valued 1672 protocol see description in text optional, multi valued 1674 Figure 24: dictionary Class Attributes 1676 The rp-attribute attribute has the following syntax: 1678 rp-attribute: 1679 (, ..., [, "..."]) 1680 ... 1682 (, ..., [, "..."]) 1684 where is the name of the rp-attribute; and is the name of 1685 an access method for the rp-attribute, taking Ni arguments where the j-th 1686 argument is of type . A method name is either an RPSL name or one 1687 of the operators defined in Figure 25. The operator methods with the 1688 exception of operator() and operator[] can take only one argument. 1690 operator= operator== 1691 operator<<= operator< 1692 operator>>= operator> 1693 operator+= operator>= 1694 operator-= operator<= 1695 operator*= operator!= 1696 operator/= operator() 1697 operator.= operator[] 1699 Figure 25: Operators 1701 An rp-attribute can have many methods defined for it. Some of the methods 1702 may even have the same name, in which case their arguments are of different 1703 types. If the argument list is followed by ``...'', the method takes a 1704 variable number of arguments. In this case, the actual arguments after the 1705 Nth argument are of type . 1707 Arguments are strongly typed. A in RPSL is either a predefined type, 1708 a union type, a list type, or a dictionary defined type. The predefined 1709 types are listed in Figure 26. 1711 integer[lower, upper] ipv4_address 1712 real[lower, upper] address_prefix 1713 enum[name, name, ...] address_prefix_range 1714 string dns_name 1715 boolean filter 1716 rpsl_word as_set_name 1717 free_text route_set_name 1718 email rtr_set_name 1719 as_number filter_set_name 1720 peering_set_name 1722 Figure 26: Predefined Types 1724 The integer and the real predefined types can be followed by a lower and an 1725 upper bound to specify the set of valid values of the argument. The range 1726 specification is optional. We use the ANSI C language conventions for 1727 representing integer, real and string values. The enum type is followed by 1728 a list of RPSL names which are the valid values of the type. The boolean 1729 type can take the values true or false. as_number, ipv4_address, 1730 address_prefix and dns_name types are as in Section 2. filter type is a 1731 policy filter as in Section 6. The value of filter type is suggested to be 1732 enclosed in parenthesis. 1734 The syntax of a union type is as follows: 1736 union , ... , 1738 where is an RPSL type. The union type is either of the types 1739 through (analogous to unions in C[14]). 1741 The syntax of a list type is as follows: 1743 list [:] of 1745 In this case, the list elements are of and the list contains at least 1746 and at most elements. The size specification is 1747 optional. If it is not specified, there is no restriction in the number of 1748 list elements. A value of a list type is represented as a sequence of 1749 elements separated by the character ``,'' and enclosed by the characters 1750 ``{'' and ``}''. 1752 The typedef attribute in the dictionary defines named types as follows: 1754 typedef: 1756 where is a name for type . typedef attribute is paticularly 1757 useful when the type defined is not a predefined type (e.g. list of unions, 1758 list of lists, etc.). 1760 A protocol attribute of the dictionary class defines a protocol and a set of 1761 peering parameters for that protocol (which are used in inet-rtr class in 1762 Section 9). Its syntax is as follows: 1764 protocol: 1765 MANDATORY | OPTIONAL (,..., [,"..."]) 1766 ... 1767 MANDATORY | OPTIONAL (,..., [,"..."]) 1769 where is the name of the protocol; MANDATORY and OPTIONAL are 1770 keywords; and is a peering parameter for this protocol, taking 1771 Ni many arguments. The syntax and semantics of the arguments are as in the 1772 rp-attribute. If the keyword MANDATORY is used, the parameter is mandatory 1773 and needs to be specified for each peering of this protocol. If the keyword 1774 OPTIONAL is used, the parameter can be skipped. 1776 7.1 Initial RPSL Dictionary and Example Policy Actions and Filters 1778 dictionary: RPSL 1779 rp-attribute: # preference, smaller values represent higher preferences 1780 pref 1781 operator=(integer[0, 65535]) 1782 rp-attribute: # BGP multi_exit_discriminator attribute 1783 med 1784 # to set med to 10: med = 10; 1785 # to set med to the IGP metric: med = igp_cost; 1786 operator=(union integer[0, 65535], enum[igp_cost]) 1787 rp-attribute: # BGP destination preference attribute (dpa) 1788 dpa 1789 operator=(integer[0, 65535]) 1790 rp-attribute: # BGP aspath attribute 1791 aspath 1792 # prepends AS numbers from last to first order 1793 prepend(as_number, ...) 1794 typedef: # a community value in RPSL is either 1795 # - a 4 byte integer (ok to use 3561:70 notation) 1796 # - internet, no_export, no_advertise (see RFC-1997) 1797 community_elm union 1798 integer[1, 4294967295], 1799 enum[internet, no_export, no_advertise], 1800 typedef: # list of community values { 40, no_export, 3561:70 } 1801 community_list list of community_elm 1802 rp-attribute: # BGP community attribute 1803 community 1804 # set to a list of communities 1805 operator=(community_list) 1806 # append community values 1807 operator.=(community_list) 1808 append(community_elm, ...) 1809 # delete community values 1810 delete(community_elm, ...) 1811 # a filter: true if one of community values is contained 1812 contains(community_elm, ...) 1813 # shortcut to contains: community(no_export, 3561:70) 1814 operator()(community_elm, ...) 1815 # order independent equality comparison 1816 operator==(community_list) 1817 rp-attribute: # next hop router in a static route 1818 next-hop 1819 # to set to 7.7.7.7: next-hop = 7.7.7.7; 1820 # to set to router's own address: next-hop = self; 1821 operator=(union ipv4_address, enum[self]) 1822 rp-attribute: # cost of a static route 1823 cost 1824 operator=(integer[0, 65535]) 1825 protocol: BGP4 1826 # as number of the peer router 1827 MANDATORY asno(as_number) 1828 # enable flap damping 1829 OPTIONAL flap_damp() 1830 OPTIONAL flap_damp(integer[0,65535],# penalty per flap 1831 integer[0,65535],# penalty value for supression 1832 integer[0,65535],# penalty value for reuse 1833 integer[0,65535],# halflife in secs when up 1834 integer[0,65535],# halflife in secs when down 1835 integer[0,65535])# maximum penalty 1836 protocol: OSPF 1837 protocol: RIP 1838 protocol: IGRP 1839 protocol: IS-IS 1840 protocol: STATIC 1841 protocol: RIPng 1842 protocol: DVMRP 1843 protocol: PIM-DM 1844 protocol: PIM-SM 1845 protocol: CBT 1846 protocol: MOSPF 1848 Figure 27: RPSL Dictionary 1850 Figure 27 shows the initial RPSL dictionary. It has seven rp-attributes: 1851 pref to assign local preference to the routes accepted; med to assign a 1852 value to the MULTI_EXIT_DISCRIMINATOR BGP attribute; dpa to assign a value to 1853 the DPA BGP attribute; aspath to prepend a value to the AS_PATH BGP 1854 attribute; community to assign a value to or to check the value of the 1855 community BGP attribute; next-hop to assign next hop routers to static 1856 routes; and cost to assign a cost to static routes. The dictionary defines 1857 two types: community_elm and community_list. community_elm type is either a 1858 4-byte unsigned integer, or one of the keywords internet, no_export or 1859 no_advertise (defined in [9]). An integer can be specified using two 2-byte 1860 integers seperated by ``:'' to partition the community number space so that 1861 a provider can use its AS number as the first two bytes, and assigns a 1862 semantics of its choice to the last two bytes. 1864 The initial dictionary (Figure 27) defines only options for the Border 1865 Gateway Protocol: asno and flap_damp. The mandatory asno option is the AS 1866 number of the peer router. The optional flap_damp option instructs the 1867 router to damp route flaps[22] when importing routes from the peer router. 1869 It can be specified with or without parameters. If parameters are missing, 1870 they default to: 1872 flap_damp(1000, 2000, 750, 900, 900, 20000) 1874 That is, a penalty of 1000 is assigned at each route flap, the route is 1875 suppressed when penalty reaches 2000. The penalty is reduced in half after 1876 15 minutes (900 seconds) of stability regardless of whether the route is up 1877 or down. A supressed route is reused when the penalty falls below 750. The 1878 maximum penalty a route can be assigned is 20,000 (i.e. the maximum suppress 1879 time after a route becomes stable is about 75 minutes). These parameters 1880 are consistent with the default flap damping parameters in several routers. 1882 Policy Actions and Filters Using RP-Attributes 1884 The syntax of a policy action or a filter using an rp-attribute x is as 1885 follows: 1887 x.method(arguments) 1888 x ``op'' argument 1890 where method is a method and ``op'' is an operator method of the 1891 rp-attribute x. If an operator method is used in specifying a composite 1892 policy filter, it evaluates earlier than the composite policy filter 1893 operators (i.e. AND, OR, NOT, and implicit or operator). 1895 The pref rp-attribute can be assigned a positive integer as follows: 1897 pref = 10; 1899 The med rp-attribute can be assigned either a positive integer or the word 1900 ``igp_cost'' as follows: 1902 med = 0; 1903 med = igp_cost; 1905 The dpa rp-attribute can be assigned a positive integer as follows: 1907 dpa = 100; 1909 The BGP community attribute is list-valued, that is it is a list of 4-byte 1910 integers each representing a ``community''. The following examples 1911 demonstrate how to add communities to this rp-attribute: 1913 community .= { 100 }; 1914 community .= { NO_EXPORT }; 1915 community .= { 3561:10 }; 1917 In the last case, a 4-byte integer is constructed where the more significant 1918 two bytes equal 3561 and the less significant two bytes equal 10. The 1919 following examples demonstrate how to delete communities from the community 1920 rp-attribute: 1922 community.delete(100, NO_EXPORT, 3561:10); 1924 Filters that use the community rp-attribute can be defined as demonstrated 1925 by the following examples: 1927 community.contains(100, NO_EXPORT, 3561:10); 1928 community(100, NO_EXPORT, 3561:10); # shortcut 1930 The community rp-attribute can be set to a list of communities as follows: 1932 community = {100, NO_EXPORT, 3561:10, 200}; 1933 community = {}; 1935 In this first case, the community rp-attribute contains the communities 100, 1936 NO_EXPORT, 3561:10, and 200. In the latter case, the community rp-attribute 1937 is cleared. The community rp-attribute can be compared against a list of 1938 communities as follows: 1940 community == {100, NO_EXPORT, 3561:10, 200}; # exact match 1942 To influence the route selection, the BGP as_path rp-attribute can be made 1943 longer by prepending AS numbers to it as follows: 1945 aspath.prepend(AS1); 1946 aspath.prepend(AS1, AS1, AS1); 1948 The following examples are invalid: 1950 med = -50; # -50 is not in the range 1951 med = igp; # igp is not one of the enum values 1952 med.assign(10); # method assign is not defined 1953 community.append(AS3561:20); # the first argument should be 3561 1955 Figure 28 shows a more advanced example using the rp-attribute community. 1956 In this example, AS3561 bases its route selection preference on the 1957 community attribute. Other ASes may indirectly affect AS3561's route 1958 selection by including the appropriate communities in their route 1959 announcements. 1961 aut-num: AS1 1962 export: to AS2 action community.={3561:90}; 1963 to AS3 action community.={3561:80}; 1964 announce AS1 1966 as-set: AS3561:AS-PEERS 1967 members: AS2, AS3 1969 aut-num: AS3561 1970 import: from AS3561:AS-PEERS 1971 action pref = 10; 1972 accept community(3561:90) 1973 import: from AS3561:AS-PEERS 1974 action pref = 20; 1975 accept community(3561:80) 1976 import: from AS3561:AS-PEERS 1977 action pref = 20; 1978 accept community(3561:70) 1979 import: from AS3561:AS-PEERS 1980 action pref = 0; 1981 accept ANY 1983 Figure 28: Policy example using the community rp-attribute. 1985 8 Advanced route Class 1987 8.1 Specifying Aggregate Routes 1989 The components, aggr-bndry, aggr-mtd, export-comps, inject, and holes 1990 attributes are used for specifying aggregate routes [11]. A route object 1991 specifies an aggregate route if any of these attributes, with the exception 1992 of inject, is specified. The origin attribute for an aggregate route is the 1993 AS performing the aggregation, i.e. the aggregator AS. In this section, we 1994 used the term "aggregate" to refer to the route generated, the term 1995 "component" to refer to the routes used to generate the path attributes of 1996 the aggregate, and the term "more specifics" to refer to any route which is 1997 a more specific of the aggregate regardless of whether it was used to form 1998 the path attributes. 2000 The components attribute defines what component routes are used to form the 2001 aggregate. Its syntax is as follows: 2003 components: [ATOMIC] [[] [protocol ...]] 2005 where is a routing protocol name such as BGP4, OSPF or RIP (valid 2006 names are defined in the dictionary) and is a policy expression. 2007 The routes that match one of these filters and are learned from the 2008 corresponding protocol are used to form the aggregate. If is 2009 omitted, it defaults to any protocol. implicitly contains an "AND" 2010 term with the more specifics of the aggregate so that only the component 2011 routes are selected. If the keyword ATOMIC is used, the aggregation is done 2012 atomically [11]. If a is not specified it defaults to more 2013 specifics. If the components attribute is missing, all more specifics 2014 without the ATOMIC keyword is used. 2016 route: 128.8.0.0/15 2017 origin: AS1 2018 components: <^AS2> 2020 route: 128.8.0.0/15 2021 origin: AS1 2022 components: protocol BGP4 {128.8.0.0/16^+} 2023 protocol OSPF {128.9.0.0/16^+} 2025 Figure 29: Two aggregate route objects. 2027 Figure 29 shows two route objects. In the first example, more specifics of 2028 128.8.0.0/15 with AS paths starting with AS2 are aggregated. In the second 2029 example, some routes learned from BGP and some routes learned form OSPF are 2030 aggregated. 2032 The aggr-bndry attribute is an AS expression over AS numbers and sets (see 2033 Section 5.6). The result defines the set of ASes which form the aggregation 2034 boundary. If the aggr-bndry attribute is missing, the origin AS is the sole 2035 aggregation boundary. Outside the aggregation boundary, only the aggregate 2036 is exported and more specifics are suppressed. However, within the 2037 boundary, the more specifics are also exchanged. 2039 The aggr-mtd attribute specifies how the aggregate is generated. Its syntax 2040 is as follow: 2042 aggr-mtd: inbound 2043 | outbound [] 2045 where is an expression over AS numbers and sets (see 2046 Section 5.6). If is missing, it defaults to AS-ANY. If 2047 outbound aggregation is specified, the more specifics of the aggregate will 2048 be present within the AS and the aggregate will be formed at all inter-AS 2049 boundaries with ASes in before export, except for ASes that 2050 are within the aggregating boundary (i.e. aggr-bndry is enforced regardless 2051 of ). If inbound aggregation is specified, the aggregate is 2052 formed at all inter-AS boundaries prior to importing routes into the 2053 aggregator AS. Note that can not be specified with inbound 2054 aggregation. If aggr-mtd attribute is missing, it defaults to "outbound 2055 AS-ANY". 2057 route: 128.8.0.0/15 route: 128.8.0.0/15 2058 origin: AS1 origin: AS2 2059 components: {128.8.0.0/15^-} components: {128.8.0.0/15^-} 2060 aggr-bndry: AS1 OR AS2 aggr-bndry: AS1 OR AS2 2061 aggr-mtd: outbound AS-ANY aggr-mtd: outbound AS-ANY 2063 Figure 30: Outbound multi-AS aggregation example. 2065 Figure 30 shows an example of an outbound aggregation. In this example, AS1 2066 and AS2 are coordinating aggregation and announcing only the less specific 2067 128.8.0.0/15 to outside world, but exchanging more specifics between each 2068 other. This form of aggregation is useful when some of the components are 2069 within AS1 and some are within AS2. 2071 When a set of routes are aggregated, the intent is to export only the 2072 aggregate route and suppress exporting of the more specifics outside the 2073 aggregation boundary. However, to satisfy certain policy and topology 2074 constraints (e.g. a multi-homed component), it is often required to export 2075 some of the components. The export-comps attribute equals an RPSL filter 2076 that matches the more specifics that need to be exported outside the 2077 aggregation boundary. If this attribute is missing, more specifics are not 2078 exported outside the aggregation boundary. Note that, the export-comps 2079 filter contains an implicit "AND" term with the more specifics of the 2080 aggregate. 2082 Figure 31 shows an example of an outbound aggregation. In this example, the 2083 more specific 128.8.8.0/24 is exported outside AS1 in addition to the 2084 aggregate. This is useful, when 128.8.8.0/24 is multi-homed site to AS1 2085 with some other AS. 2087 route: 128.8.0.0/15 2088 origin: AS1 2089 components: {128.8.0.0/15^-} 2090 aggr-mtd: outbound AS-ANY 2091 export-comps: {128.8.8.0/24} 2093 Figure 31: Outbound aggregation with export exception. 2095 The inject attribute specifies which routers perform the aggregation and 2096 when they perform it. Its syntax is as follow: 2098 inject: [at ] ... 2099 [action ] 2100 [upon ] 2102 where is an action specification (see Section 6.1.1), 2103 is a boolean expression described below, and is as 2104 described in Section 5.6. 2106 All routers in and in the aggregator AS perform the 2107 aggregation. If a is not specified, all routers inside 2108 the aggregator AS perform the aggregation. The specification may 2109 set path attributes of the aggregate, such as assign a preferences to the 2110 aggregate. 2112 The upon clause is a boolean condition. The aggregate is generated if and 2113 only if this condition is true. is a boolean expression using 2114 the logical operators AND and OR (i.e. operator NOT is not allowed) over: 2116 HAVE-COMPONENTS { list of prefixes } 2117 EXCLUDE { list of prefixes } 2118 STATIC 2120 The list of prefixes in HAVE-COMPONENTS can only be more specifics of the 2121 aggregate. It evaluates to true when all the prefixes listed are present in 2122 the routing table of the aggregating router. The list can also include 2123 prefix ranges (i.e. using operators ^-, ^+, ^n, and ^n-m). In this case, at 2124 least one prefix from each prefix range needs to be present in the routing 2125 table for the condition to be true. The list of prefixes in EXCLUDE can be 2126 arbitrary. It evaluates to true when none of the prefixes listed is present 2127 in the routing table. The list can also include prefix ranges, and no 2128 prefix in that range should be present in the routing table. The keyword 2129 static always evaluates to true. If no upon clause is specified the 2130 aggregate is generated if an only if there is a component in the routing 2131 table (i.e. a more specific that matches the filter in the components 2132 attribute). 2134 route: 128.8.0.0/15 2135 origin: AS1 2136 components: {128.8.0.0/15^-} 2137 aggr-mtd: outbound AS-ANY 2138 inject: at 1.1.1.1 action dpa = 100; 2139 inject: at 1.1.1.2 action dpa = 110; 2141 route: 128.8.0.0/15 2142 origin: AS1 2143 components: {128.8.0.0/15^-} 2144 aggr-mtd: outbound AS-ANY 2145 inject: upon HAVE-COMPONENTS {128.8.0.0/16, 128.9.0.0/16} 2146 holes: 128.8.8.0/24 2148 Figure 32: Examples of inject. 2150 Figure 32 shows two examples. In the first case, the aggregate is injected 2151 at two routers each one setting the dpa path attribute differently. In the 2152 second case, the aggregate is generated only if both 128.8.0.0/16 and 2153 128.9.0.0/16 are present in the routing table, as opposed to the first case 2154 where the presence of just one of them is sufficient for injection. 2156 The holes attribute lists the component address prefixes which are not 2157 reachable through the aggregate route (perhaps that part of the address 2158 space is unallocated). The holes attribute is useful for diagnosis 2159 purposes. In Figure 32, the second example has a hole, namely 128.8.8.0/24. 2160 This may be due to a customer changing providers and taking this part of the 2161 address space with it. 2163 8.1.1 Interaction with policies in aut-num class 2165 An aggregate formed is announced to other ASes only if the export policies 2166 of the AS allows exporting the aggregate. When the aggregate is formed, the 2167 more specifics are suppressed from being exported except to the ASes in 2168 aggr-bndry and except the components in export-comps. For such exceptions 2169 to happen, the export policies of the AS should explicitly allow exporting 2170 of these exceptions. 2172 If an aggregate is not formed (due to the upon clause), then the more 2173 specifics of the aggregate can be exported to other ASes, but only if the 2174 export policies of the AS allows it. In other words, before a route 2175 (aggregate or more specific) is exported it is filtered twice, once based on 2176 the route objects, and once based on the export policies of the AS. 2178 route: 128.8.0.0/16 2179 origin: AS1 2181 route: 128.9.0.0/16 2182 origin: AS1 2184 route: 128.8.0.0/15 2185 origin: AS1 2186 aggr-bndry: AS1 or AS2 or AS3 2187 aggr-mtd: outbound AS3 or AS4 or AS5 2188 components: {128.8.0.0/16, 128.9.0.0/16} 2189 inject: upon HAVE-COMPONENTS {128.9.0.0/16, 128.8.0.0/16} 2191 aut-num: AS1 2192 export: to AS2 announce AS1 2193 export: to AS3 announce AS1 and not {128.9.0.0/16} 2194 export: to AS4 announce AS1 2195 export: to AS5 announce AS1 2196 export: to AS6 announce AS1 2198 Figure 33: Interaction with policies in aut-num class. 2200 In Figure 33 shows an interaction example. By examining the route objects, 2201 the more specifics 128.8.0.0/16 and 128.9.0.0/16 should be exchanged between 2202 AS1, AS2 and AS3 (i.e. the aggregation boundary). Outbound aggregation is 2203 done to AS4 and AS5 and not to AS3, since AS3 is in the aggregation 2204 boundary. The aut-num object allows exporting both components to AS2, but 2205 only the component 128.8.0.0/16 to AS3. The aggregate can only be formed if 2206 both components are available. In this case, only the aggregate is 2207 announced to AS4 and AS5. However, if one of the components is not 2208 available the aggregate will not be formed, and any available component or 2209 more specific will be exported to AS4 and AS5. Regardless of aggregation is 2210 performed or not, only the more specifics will be exported to AS6 (it is not 2211 listed in the aggr-mtd attribute). 2213 When doing an inbound aggregation, configuration generators may eliminating 2214 the aggregation statements on routers where import policy of the AS 2215 prohibits importing of any more specifics. 2217 8.1.2 Ambiguity resolution with overlapping aggregates 2219 When several aggregate routes are specified and they overlap, i.e. one is 2220 less specific of the other, they must be evaluated more specific to less 2221 specific order. When an outbound aggregation is performed for a peer, the 2222 aggregate and the components listed in the export-comps attribute for that 2223 peer are available for generating the next less specific aggregate. The 2224 components that are not specified in the export-comps attribute are not 2225 available. A route is exportable to an AS if it is the least specific 2226 aggregate exportable to that AS or it is listed in the export-comps 2227 attribute of an exportable route. Note that this is a recursive definition. 2229 route: 128.8.0.0/15 2230 origin: AS1 2231 aggr-bndry: AS1 or AS2 2232 aggr-mtd: outbound 2233 inject: upon HAVE-COMPONENTS {128.8.0.0/16, 128.9.0.0/16} 2235 route: 128.10.0.0/15 2236 origin: AS1 2237 aggr-bndry: AS1 or AS3 2238 aggr-mtd: outbound 2239 inject: upon HAVE-COMPONENTS {128.10.0.0/16, 128.11.0.0/16} 2240 export-comps: {128.11.0.0/16} 2242 route: 128.8.0.0/14 2243 origin: AS1 2244 aggr-bndry: AS1 or AS2 or AS3 2245 aggr-mtd: outbound 2246 inject: upon HAVE-COMPONENTS {128.8.0.0/15, 128.10.0.0/15} 2247 export-comps: {128.10.0.0/15} 2249 Figure 34: Overlapping aggregations. 2251 In Figure 34, AS1 together with AS2 aggregates 128.8.0.0/16 and 128.9.0.0/16 2252 into 128.8.0.0/15. Together with AS3, AS1 aggregates 128.10.0.0/16 and 2253 128.11.0.0/16 into 128.10.0.0/15. But altogether they aggregate these four 2254 routes into 128.8.0.0/14. Assuming all four components are available, a 2255 router in AS1 for an outside AS, say AS4, will first generate 128.8.0.0/15 2256 and 128.10.0.0/15. This will make 128.8.0.0/15, 128.10.0.0/15 and its 2257 exception 128.11.0.0/16 available for generating 128.8.0.0/14. The router 2258 will then generate 128.8.0.0/14 from these three routes. Hence for AS4, 2259 128.8.0.0/14 and its exception 128.10.0.0/15 and its exception 128.11.0.0/16 2260 will be exportable. 2262 For AS2, a router in AS1 will only generate 128.10.0.0/15. Hence, 2263 128.10.0.0/15 and its exception 128.11.0.0/16 will be exportable. Note that 2264 128.8.0.0/16 and 128.9.0.0/16 are also exportable since they did not 2265 participate in an aggregate exportable to AS2. 2267 Similarly, for AS3, a router in AS1 will only generate 128.8.0.0/15. In 2268 this case 128.8.0.0/15, 128.10.0.0/16, 128.11.0.0/16 are exportable. 2270 8.2 Specifying Static Routes 2272 The inject attribute can be used to specify static routes by using "upon 2273 static" as the condition: 2275 inject: [at ] ... 2276 [action ] 2277 upon static 2279 In this case, the routers in executes the and 2280 injects the route to the interAS routing system statically. may 2281 set certain route attributes such as a next-hop router or a cost. 2283 In the following example, the router 7.7.7.1 injects the route 128.7.0.0/16. 2284 The next-hop routers (in this example, there are two next-hop routers) for 2285 this route are 7.7.7.2 and 7.7.7.3 and the route has a cost of 10 over 2286 7.7.7.2 and 20 over 7.7.7.3. 2288 route: 128.7.0.0/16 2289 origin: AS1 2290 inject: at 7.7.7.1 action next-hop = 7.7.7.2; cost = 10; upon static 2291 inject: at 7.7.7.1 action next-hop = 7.7.7.3; cost = 20; upon static 2293 9 inet-rtr Class 2295 Routers are specified using the inet-rtr class. The attributes of the 2296 inet-rtr class are shown in Figure 35. The inet-rtr attribute is a valid 2297 DNS name of the router described. Each alias attribute, if present, is a 2298 canonical DNS name for the router. The local-as attribute specifies the AS 2299 number of the AS which owns/operates this router. 2301 Attribute Value Type 2302 inet-rtr mandatory, single-valued, class key 2303 alias optional, multi-valued 2304 local-as mandatory, single-valued 2305 ifaddr see description in text mandatory, multi-valued 2306 peer see description in text optional, multi-valued 2307 member-of list of optional, multi-valued 2309 Figure 35: inet-rtr Class Attributes 2311 The value of an ifaddr attribute has the following syntax: 2313 masklen [action ] 2315 The IP address and the mask length are mandatory for each interface. 2316 Optionally an action can be specified to set other parameters of this 2317 interface. 2319 Figure 36 presents an example inet-rtr object. The name of the router is 2320 ``amsterdam.ripe.net''. ``amsterdam1.ripe.net'' is a canonical name for the 2321 router. The router is connected to 4 networks. Its IP addresses and mask 2322 lengths in those networks are specified in the ifaddr attributes. 2324 inet-rtr: Amsterdam.ripe.net 2325 alias: amsterdam1.ripe.net 2326 local-as: AS3333 2327 ifaddr: 192.87.45.190 masklen 24 2328 ifaddr: 192.87.4.28 masklen 24 2329 ifaddr: 193.0.0.222 masklen 27 2330 ifaddr: 193.0.0.158 masklen 27 2331 peer: BGP4 192.87.45.195 asno(AS3334), flap_damp() 2333 Figure 36: inet-rtr Objects 2335 Each peer attribute, if present, specifies a protocol peering with another 2336 router. The value of a peer attribute has the following syntax: 2338 2339 | 2340 | 2341 | 2343 where is a protocol name, is the IP address of the 2344 peer router, and is a comma separated list of peering options for 2345 . Instead of the peer's IP address, its inet-rtr-name can be 2346 used. Possible protocol names and attributes are defined in the dictionary 2347 (please see Section 7). In the above example, the router has a BGP peering 2348 with the router 192.87.45.195 in AS3334 and turns the flap damping on when 2349 importing routes from this router. 2351 Instead of a single peer, a group of peers can be specified by using the 2352 and forms. If form is 2353 being used only the peerings in the corresponding peering set that are with 2354 this router are included. Figure 37 shows an example inet-rtr object with 2355 peering groups. 2357 rtr-set: rtrs-ibgp-peers 2358 members: 1.1.1.1, 2.2.2.2, 3.3.3.3 2360 peering-set: prng-ebgp-peers 2361 peering: AS3334 192.87.45.195 2362 peering: AS3335 192.87.45.196 2364 inet-rtr: Amsterdam.ripe.net 2365 alias: amsterdam1.ripe.net 2366 local-as: AS3333 2367 ifaddr: 192.87.45.190 masklen 24 2368 ifaddr: 192.87.4.28 masklen 24 2369 ifaddr: 193.0.0.222 masklen 27 2370 ifaddr: 193.0.0.158 masklen 27 2371 peer: BGP4 rtrs-ibgp-peers asno(AS3333), flap_damp() 2372 peer: BGP4 prng-ebgp-peers asno(PeerAS), flap_damp() 2374 Figure 37: inet-rtr Object with peering groups 2376 10 Extending RPSL 2378 Our experience with earlier routing policy languages and data formats 2379 (PRDB [2], RIPE-81 [8], and RIPE-181 [7]) taught us that RPSL had to be 2380 extensible. As a result, extensibility was a primary design goal for RPSL. 2381 New routing protocols or new features to existing routing protocols can be 2382 easily handled using RPSL's dictionary class. New classes or new attributes 2383 to the existing classes can also be added. 2385 This section provides guidelines for extending RPSL. These guidelines are 2386 designed with an eye toward maintaining backward compatibility with existing 2387 tools and databases. We next list the available options for extending RPSL 2388 from the most preferred to the least preferred order. 2390 10.1 Extensions by changing the dictionary class 2392 The dictionary class is the primary mechanism provided to extend RPSL. 2393 Dictionary objects define routing policy attributes, types, and routing 2394 protocols. 2396 We recommend updating the RPSL dictionary to include appropriate 2397 rp-attribute and protocol definitions as new path attributes or router 2398 features are introduced. For example, in an earlier version of the RPSL 2399 document, it was only possible to specify that a router performs route flap 2400 damping on a peer, but it was not possible to specify the parameters of 2401 route flap damping. Later the parameters were added by changing the 2402 dictionary. 2404 When changing the dictionary, full compatibility should be maintained. For 2405 example, in our flap damping case, we made the parameter specification 2406 optional in case this level of detail was not desired by some ISPs. This 2407 also achieved compatibility. Any object registered without the parameters 2408 will continue to be valid. Any tool based on RPSL is expected to do a 2409 default action on routing policy attributes that they do not understand 2410 (e.g. issue a warning and otherwise ignore). Hence, old tools upon 2411 encountering a flap damping specification with parameters will ignore the 2412 parameters. 2414 10.2 Extensions by adding new attributes to existing classes 2416 New attributes can be added to any class. To ensure full compatibility, new 2417 attributes should not contradict the semantics of the objects they are 2418 attached to. Any tool that uses the IRR should be designed so that it 2419 ignores attributes that it doesn't understand. Most existing tools adhere 2420 to this design principle. 2422 We recommend adding new attributes to existing classes when a new aspect of 2423 a class is discovered. For example, RPSL route class extends its RIPE-181 2424 predecessor by including several new attributes that enable aggregate and 2425 static route specification. 2427 10.3 Extensions by adding new classes 2429 New classes can be added to RPSL to store new types of policy data. 2430 Providing full compatibility is straight forward as long as existing classes 2431 are still understood. Since a tool should only query the IRR for the 2432 classes that it understand, full compatibility should not be a problem in 2433 this case. 2435 Before adding a new class, one should question if the information contained 2436 in the objects of the new class could have better belonged to some other 2437 class. For example, if the geographic location of a router needs to be 2438 stored in IRR, it may be tempting to add a new class called, say 2439 router-location class. However, the information better belongs to the 2440 inet-rtr class, perhaps in a new attribute called location. 2442 10.4 Extensions by changing the syntax of existing RPSL attributes 2444 If all of the methods described above fail to provide the desired extension, 2445 it may be necessary to change the syntax of RPSL. Any change in RPSL syntax 2446 must provide backwards compatibility, and should be considered only as a 2447 last resort since full compatibility may not be achievable. However, we 2448 require that the old syntax to be still valid. 2450 11 Security Consideration 2452 This document describes RPSL, a language for expressing routing policies. 2453 The language defines a maintainer (mntner class) object which is the entity 2454 which controls or "maintains" the objects stored in a database expressed by 2455 RPSL. Requests from maintainers can be authenticated with various techniques 2456 as defined by the "auth" attribute of the maintainer object. 2458 The exact protocols used by IRR's to communicate RPSL objects is beyond the 2459 scope of this document, but it is envisioned that several techniques may be 2460 used, ranging from interactive query/update protocols to store and forward 2461 protocols similar to or based on electronic mail (or even voice telephone 2462 calls). Regardless of which protocols are used in a given situation, it is 2463 expected that appropriate security techniques such as IPSEC, TLS or PGP/MIME 2464 will be utilized. 2466 12 Acknowledgements 2468 We would like to thank Jessica Yu, Randy Bush, Alan Barrett, Bill Manning, 2469 Sue Hares, Ramesh Govindan, Kannan Varadhan, Satish Kumar, Craig Labovitz, 2470 Rusty Eddy, David J. LeRoy, David Whipple, Jon Postel, Deborah Estrin, 2471 Elliot Schwartz, Joachim Schmitz, Mark Prior, Tony Przygienda, David 2472 Woodgate, Rob Coltun, Sanjay Wadhwa, Ardas Cilingiroglu, and the 2473 participants of the IETF RPS Working Group for various comments and 2474 suggestions. 2476 References 2478 [1] Internet routing registry. procedures. 2479 http://www.ra.net/RADB.tools.docs/, http://www.ripe.net/db/doc.html. 2481 [2] Nsfnet policy routing database (prdb). Maintained by MERIT Network 2482 Inc., Ann Arbor, Michigan. Contents available from 2483 nic.merit.edu.:/nsfnet/announced.networks/nets.tag.now by anonymous 2484 ftp. 2486 [3] C. Alaettinouglu, T. Bates, E. Gerich, D. Karrenberg, D. Meyer, 2487 M. Terpstra, and C. Villamizer. Routing policy specification language 2488 (rpsl). Request for Comment RFC-2280, Network Information Center, 2489 January 1998. 2491 [4] C. Alaettinouglu, D. Meyer, and J. Schmitz. Application of routing 2492 policy specification language (rpsl) on the internet. Internet Draft 2493 draft-ietf-rps-appl-rpsl-01, July 1997. Work in progress. 2495 [5] T. Bates. Specifying an `internet router' in the routing registry. 2496 Technical Report RIPE-122, RIPE, RIPE NCC, Amsterdam, Netherlands, 2497 October 1994. 2499 [6] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, 2500 M. Terpstra, and J. Yu. Representation of ip routing policies in a 2501 routing registry. Technical Report ripe-181, RIPE, RIPE NCC, 2502 Amsterdam, Netherlands, October 1994. 2504 [7] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, 2505 M. Terpstra, and J. Yu. Representation of ip routing policies in a 2506 routing registry. Technical Report RFC-1786, Network Information 2507 Center, March 1995. 2509 [8] T. Bates, J-M. Jouanigot, D. Karrenberg, P. Lothberg, and M. Terpstra. 2510 Representation of ip routing policies in the ripe database. Technical 2511 Report ripe-81, RIPE, RIPE NCC, Amsterdam, Netherlands, February 1993. 2513 [9] R. Chandra, P. Traina, and T. Li. Bgp communities attribute. Request 2514 for Comment RFC-1997, Network Information Center, August 1996. 2516 [10] D. Crocker. Standard for the format of arpa internet text messages. 2517 Request for Comment RFC-822, Network Information Center, August 1982. 2519 [11] V. Fuller, T. Li, J. Yu, and K. Varadhan. Classless Inter-Domain 2520 Routing (CIDR): an Address Assignment and Aggregation Strategy, 1993. 2522 [12] D. Karrenberg and T. Bates. Description of inter-as networks in the 2523 ripe routing registry. Technical Report RIPE-104, RIPE, RIPE NCC, 2524 Amsterdam, Netherlands, December 1993. 2526 [13] D. Karrenberg and M. Terpstra. Authorisation and notification of 2527 changes in the ripe database. Technical Report ripe-120, RIPE, RIPE 2528 NCC, Amsterdam, Netherlands, October 1994. 2530 [14] B. W. Kernighan and D. M. Ritchie. The C Programming Language. 2531 Prentice-Hall, 1978. 2533 [15] D. Kessens, W. Woeber, and D. Conrad. Ride referencing. Internet Draft 2534 draft-kessens-ride-referencing-00.txt, Network Information Center, 2535 August 1997. 2537 [16] A. Lord and M. Terpstra. Ripe database template for networks and 2538 persons. Technical Report ripe-119, RIPE, RIPE NCC, Amsterdam, 2539 Netherlands, October 1994. 2541 [17] A. M. R. Magee. Ripe ncc database documentation. Technical Report 2542 RIPE-157, RIPE, RIPE NCC, Amsterdam, Netherlands, May 1997. 2544 [18] P. V. Mockapetris. Domain names - concepts and facilities. Request for 2545 Comment RFC-1034, Network Information Center, November 1987. 2547 [19] Y. Rekhter. Inter-domain routing protocol (idrp). Journal of 2548 Internetworking Research and Experience, 4:61--80, 1993. 2550 [20] Y. Rekhter and T. Li. A border gateway protocol 4 (bgp-4). Request for 2551 Comment RFC-1771, Network Information Center, March 1995. 2553 [21] C. Villamizar, C. Alaettinouglu, D. Meyer, S. Murphy, and C. Orange. 2554 Routing policy system security. Internet Draft draft-ietf-rps-auth-01, 2555 Network Information Center, May 1998. 2557 [22] C. Villamizar, R. Chandra, and R. Govindan. Bgp route flap damping. 2558 Internet Draft draft-ietf-idr-route-damp-00, Network Information 2559 Center, October 1997. 2561 [23] J. Zsako. Pgp authentication for ripe database updates. Internet Draft 2562 draft-zsako-ripe-dbsec-pgp-authent-00, Network Information Center, 2563 July 1998. 2565 A Routing Registry Sites 2567 The set of routing registries as of November 1996 are RIPE, RADB, CANet, MCI 2568 and ANS. You may contact one of these registries to find out the current 2569 list of registries. 2571 B Grammar Rules 2573 In this section we provide formal grammar rules for RPSL. Basic data types 2574 are defined in Section 2. We do not provide formal grammar rules for 2575 attributes whose values are of basic types or list of basic types. The 2576 rules are written using the input language of GNU Bison parser. Hence, they 2577 can be cut and pasted to that program. 2579 //**** Generic Attributes ************************************************* 2581 changed_attribute: ATTR_CHANGED TKN_EMAIL TKN_INT 2583 //**** aut-num class ****************************************************** 2585 //// as_expression ////////////////////////////////////////////////////// 2586 opt_as_expression: 2587 | as_expression 2589 as_expression: as_expression OP_OR as_expression_term 2590 | as_expression_term 2592 as_expression_term: as_expression_term OP_AND as_expression_factor 2593 | as_expression_term KEYW_EXCEPT as_expression_factor 2594 | as_expression_factor 2596 as_expression_factor: '(' as_expression ')' 2597 | as_expression_operand 2599 as_expression_operand: TKN_ASNO 2600 | TKN_ASNAME 2602 //// router_expression ////////////////////////////////////////////////// 2604 opt_router_expression: 2605 | router_expression 2607 opt_router_expression_with_at: 2608 | KEYW_AT router_expression 2610 router_expression: router_expression OP_OR router_expression_term 2611 | router_expression_term 2613 router_expression_term: router_expression_term OP_AND router_expression_factor 2614 | router_expression_term KEYW_EXCEPT router_expression_factor 2615 | router_expression_factor 2617 router_expression_factor: '(' router_expression ')' 2618 | router_expression_operand 2620 router_expression_operand: TKN_IPV4 2621 | TKN_DNS 2622 | TKN_RTRSNAME 2624 //// peering //////////////////////////////////////////////////////////// 2626 peering: as_expression opt_router_expression opt_router_expression_with_at 2627 | TKN_PRNGNAME 2629 //// action ///////////////////////////////////////////////////////////// 2631 opt_action: 2632 | KEYW_ACTION action 2634 action: single_action 2635 | action single_action 2636 single_action: TKN_RP_ATTR '.' TKN_WORD '(' generic_list ')' ';' 2637 | TKN_RP_ATTR TKN_OPERATOR list_item ';' 2638 | TKN_RP_ATTR '(' generic_list ')' ';' 2639 | TKN_RP_ATTR '[' generic_list ']' ';' 2640 | ';' 2642 //// filter ///////////////////////////////////////////////////////////// 2644 filter: filter OP_OR filter_term 2645 | filter filter_term %prec OP_OR 2646 | filter_term 2648 filter_term : filter_term OP_AND filter_factor 2649 | filter_factor 2651 filter_factor : OP_NOT filter_factor 2652 | '(' filter ')' 2653 | filter_operand 2655 filter_operand: KEYW_ANY 2656 | '<' filter_aspath '>' 2657 | filter_rp_attribute 2658 | TKN_FLTRNAME 2659 | filter_prefix 2661 filter_prefix: filter_prefix_operand OP_MS 2662 | filter_prefix_operand 2664 filter_prefix_operand: TKN_ASNO 2665 | KEYW_PEERAS 2666 | TKN_ASNAME 2667 | TKN_RSNAME 2668 | '{' opt_filter_prefix_list '}' 2670 opt_filter_prefix_list: 2671 | filter_prefix_list 2673 filter_prefix_list: filter_prefix_list_prefix 2674 | filter_prefix_list ',' filter_prefix_list_prefix 2676 filter_prefix_list_prefix: TKN_PRFXV4 2677 | TKN_PRFXV4RNG 2679 filter_aspath: filter_aspath '|' filter_aspath_term 2680 | filter_aspath_term 2682 filter_aspath_term: filter_aspath_term filter_aspath_closure 2683 | filter_aspath_closure 2685 filter_aspath_closure: filter_aspath_closure '*' 2686 | filter_aspath_closure '?' 2687 | filter_aspath_closure '+' 2688 | filter_aspath_factor 2690 filter_aspath_factor: '^' 2691 | '$' 2692 | '(' filter_aspath ')' 2693 | filter_aspath_no 2695 filter_aspath_no: TKN_ASNO 2696 | KEYW_PEERAS 2697 | TKN_ASNAME 2698 | '.' 2699 | '[' filter_aspath_range ']' 2700 | '[' '^' filter_aspath_range ']' 2702 filter_aspath_range: 2703 | filter_aspath_range TKN_ASNO 2704 | filter_aspath_range KEYW_PEERAS 2705 | filter_aspath_range '.' 2706 | filter_aspath_range TKN_ASNO '-' TKN_ASNO 2707 | filter_aspath_range TKN_ASNAME 2709 filter_rp_attribute: TKN_RP_ATTR '.' TKN_WORD '(' generic_list ')' 2710 | TKN_RP_ATTR TKN_OPERATOR list_item 2711 | TKN_RP_ATTR '(' generic_list ')' 2712 | TKN_RP_ATTR '[' generic_list ']' 2714 //// peering action pair //////////////////////////////////////////////// 2716 import_peering_action_list: KEYW_FROM peering opt_action 2717 | import_peering_action_list KEYW_FROM peering opt_action 2719 export_peering_action_list: KEYW_TO peering opt_action 2720 | export_peering_action_list KEYW_TO peering opt_action 2722 //// import/export factor /////////////////////////////////////////////// 2724 import_factor: import_peering_action_list KEYW_ACCEPT filter 2726 import_factor_list: import_factor ';' 2727 | import_factor_list import_factor ';' 2729 export_factor: export_peering_action_list KEYW_ANNOUNCE filter 2731 export_factor_list: export_factor ';' 2732 | export_factor_list export_factor ';' 2734 //// import/export term ///////////////////////////////////////////////// 2736 import_term: import_factor ';' 2737 | '{' import_factor_list '}' 2739 export_term: export_factor ';' 2740 | '{' export_factor_list '}' 2742 //// import/export expression /////////////////////////////////////////// 2744 import_expression: import_term 2745 | import_term KEYW_REFINE import_expression 2746 | import_term KEYW_EXCEPT import_expression 2748 export_expression: export_term 2749 | export_term KEYW_REFINE export_expression 2750 | export_term KEYW_EXCEPT export_expression 2752 //// protocol /////////////////////////////////////////////////////////// 2754 opt_protocol_from: 2755 | KEYW_PROTOCOL tkn_word 2757 opt_protocol_into: 2758 | KEYW_INTO tkn_word 2760 //**** import/export attributes ******************************************* 2762 import_attribute: ATTR_IMPORT 2763 | ATTR_IMPORT opt_protocol_from opt_protocol_into import_factor 2765 export_attribute: ATTR_EXPORT 2766 | ATTR_EXPORT opt_protocol_from opt_protocol_into export_factor 2768 opt_default_filter: 2769 | KEYW_NETWORKS filter 2771 default_attribute: ATTR_DEFAULT KEYW_TO peering 2773 filter_attribute: ATTR_FILTER filter 2775 peering_attribute: ATTR_PEERING peering 2777 //**** inet-rtr class ***************************************************** 2779 ifaddr_attribute: ATTR_IFADDR TKN_IPV4 KEYW_MASKLEN TKN_INT opt_action 2781 //// peer attribute ///////////////////////////////////////////////////// 2783 opt_peer_options: 2784 | peer_options 2786 peer_options: peer_option 2787 | peer_options ',' peer_option 2788 peer_option: tkn_word '(' generic_list ')' 2790 peer_id: TKN_IPV4 2791 | TKN_DNS 2792 | TKN_RTRSNAME 2793 | TKN_PRNGNAME 2795 peer_attribute: ATTR_PEER tkn_word peer_id opt_peer_options 2797 //**** route class ******************************************************** 2799 aggr_bndry_attribute: ATTR_AGGR_BNDRY as_expression 2801 aggr_mtd_attribute: ATTR_AGGR_MTD KEYW_INBOUND 2802 | ATTR_AGGR_MTD KEYW_OUTBOUND opt_as_expression 2804 //// inject attribute /////////////////////////////////////////////////// 2806 opt_inject_expression: 2807 | KEYW_UPON inject_expression 2809 inject_expression: inject_expression OP_OR inject_expression_term 2810 | inject_expression_term 2812 inject_expression_term: inject_expression_term OP_AND inject_expression_factor 2813 | inject_expression_factor 2815 inject_expression_factor: '(' inject_expression ')' 2816 | inject_expression_operand 2818 inject_expression_operand: KEYW_STATIC 2819 | KEYW_HAVE_COMPONENTS '{' opt_filter_prefix_list '}' 2820 | KEYW_EXCLUDE '{' opt_filter_prefix_list '}' 2822 inject_attribute: ATTR_INJECT opt_router_expression_with_at opt_action 2823 opt_inject_expression 2825 //// components attribute /////////////////////////////////////////////// 2827 opt_atomic: 2828 | KEYW_ATOMIC 2830 components_list: 2831 | filter 2832 | components_list KEYW_PROTOCOL tkn_word filter 2834 components_attribute: ATTR_COMPONENTS opt_atomic components_list 2836 //**** route-set ********************************************************** 2837 opt_rs_members_list: /* empty list */ 2838 | rs_members_list 2840 rs_members_list: rs_member 2841 | rs_members_list ',' rs_member 2843 rs_member: TKN_ASNO 2844 | TKN_ASNO OP_MS 2845 | TKN_ASNAME 2846 | TKN_ASNAME OP_MS 2847 | TKN_RSNAME 2848 | TKN_RSNAME OP_MS 2849 | TKN_PRFXV4 2850 | TKN_PRFXV4RNG 2852 rs_members_attribute: ATTR_RS_MEMBERS opt_rs_members_list 2854 //**** dictionary ********************************************************* 2856 rpattr_attribute: ATTR_RP_ATTR TKN_WORD methods 2857 | ATTR_RP_ATTR TKN_RP_ATTR methods 2859 methods: method 2860 | methods method 2862 method: TKN_WORD '(' ')' 2863 | TKN_WORD '(' typedef_type_list ')' 2864 | TKN_WORD '(' typedef_type_list ',' TKN_3DOTS ')' 2865 | KEYW_OPERATOR TKN_OPERATOR '(' typedef_type_list ')' 2866 | KEYW_OPERATOR TKN_OPERATOR '(' typedef_type_list ',' TKN_3DOTS ')' 2868 //// typedef attribute ///////////////////////////////////////////////// 2870 typedef_attribute: ATTR_TYPEDEF TKN_WORD typedef_type 2872 typedef_type_list: typedef_type 2873 | typedef_type_list ',' typedef_type 2875 typedef_type: KEYW_UNION typedef_type_list 2876 | KEYW_RANGE KEYW_OF typedef_type 2877 | TKN_WORD 2878 | TKN_WORD '[' TKN_INT ',' TKN_INT ']' 2879 | TKN_WORD '[' TKN_REAL ',' TKN_REAL ']' 2880 | TKN_WORD '[' enum_list ']' 2881 | KEYW_LIST '[' TKN_INT ':' TKN_INT ']' KEYW_OF typedef_type 2882 | KEYW_LIST KEYW_OF typedef_type 2884 enum_list: tkn_word 2885 | enum_list ',' tkn_word 2887 //// protocol attribute ///////////////////////////////////////////////// 2888 protocol_attribute: ATTR_PROTOCOL tkn_word protocol_options 2890 protocol_options: 2891 | protocol_options protocol_option 2893 protocol_option: KEYW_MANDATORY method 2894 | KEYW_OPTIONAL method 2896 //**** Token Definitions ************************************************ 2898 //// flex macros used in token definitions ////////////////////////////// 2899 INT [[:digit:]]+ 2900 SINT [+-]?{INT} 2901 REAL [+-]?{INT}?\.{INT}({WS}*E{WS}*[+-]?{INT})? 2902 NAME [[:alpha:]]([[:alnum:]_-]*[[:alnum:]])? 2903 ASNO AS{INT} 2904 ASNAME AS-[[:alnum:]_-]*[[:alnum:]] 2905 RSNAME RS-[[:alnum:]_-]*[[:alnum:]] 2906 RTRSNAME RTRS-[[:alnum:]_-]*[[:alnum:]] 2907 PRNGNAME PRNG-[[:alnum:]_-]*[[:alnum:]] 2908 FLTRNAME FLTR-[[:alnum:]_-]*[[:alnum:]] 2909 IPV4 [0-9]+(\.[0-9]+){3,3} 2910 PRFXV4 {IPV4}\/[0-9]+ 2911 PRFXV4RNG {PRFXV4}("^+"|"^-"|"^"{INT}|"^"{INT}-{INT}) 2912 ENAMECHAR [^()<>,;:\\\"\.[\] \t\r] 2913 ENAME ({ENAMECHAR}+(\.{ENAMECHAR}+)*\.?)|(\"[^\"@\\\r\n]+\") 2914 DNAME [[:alnum:]_-]+ 2915 //// Token Definitions ////////////////////////////////////////////////// 2916 TKN_INT {SINT} 2917 TKN_INT {INT}:{INT} if each {INT} is two octets 2918 TKN_INT {INT}.{INT}.{INT}.{INT} if each {INT} is one octet 2919 TKN_REAL {REAL} 2920 TKN_STRING Same as in programming language C 2921 TKN_IPV4 {IPV4} 2922 TKN_PRFXV4 {PRFXV4} 2923 TKN_PRFXV4RNG {PRFXV4RNG} 2924 TKN_ASNO {ASNO} 2925 TKN_ASNAME (({ASNO}|peeras|{ASNAME}):)*{ASNAME}\ 2926 (:({ASNO}|peeras|{ASNAME}))* 2927 TKN_RSNAME (({ASNO}|peeras|{RSNAME}):)*{RSNAME}\ 2928 (:({ASNO}|peeras|{RSNAME}))* 2929 TKN_RTRSNAME (({ASNO}|peeras|{RTRSNAME}):)*{RTRSNAME}\ 2930 (:({ASNO}|peeras|{RTRSNAME}))* 2931 TKN_PRNGNAME (({ASNO}|peeras|{PRNGNAME}):)*{PRNGNAME}\ 2932 (:({ASNO}|peeras|{PRNGNAME}))* 2933 TKN_FLTRNAME (({ASNO}|peeras|{FLTRNAME}):)*{FLTRNAME}\ 2934 (:({ASNO}|peeras|{FLTRNAME}))* 2935 TKN_BOOLEAN true|false 2936 TKN_RP_ATTR {NAME} if defined in dictionary 2937 TKN_WORD {NAME} 2938 TKN_DNS {DNAME}("."{DNAME})+ 2939 TKN_EMAIL {ENAME}@({DNAME}("."{DNAME})+|{IPV4}) 2940 C Changes from RFC 2280 2942 RFC 2280 [3] contains an earlier version of RPSL. This section summarizes 2943 the changes since then. They are as follows: 2945 o It is now possible to write integers as sequence of four 1-octet 2946 integers (e.g. 1.1.1.1) or as sequence of two 2-octet integers (e.g. 2947 3561:70). Please see Section 2. 2949 o The definition of address prefix range is extended so that an address 2950 prefix is also an address prefix range. Please see Section 2. 2952 o The semantics for a range operator applied to a set containing address 2953 prefix ranges is defined (e.g. {30.0.0.0/8^24-28}^27-30). Please see 2954 Section 2. 2956 o All dates are now in UTC. Please see Section 2. 2958 o Plus ('+') character is added to space and tab characters to split an 2959 attribute's value to multiple lines (i.e. by starting the following 2960 lines with a space, a tab or a plus ('+') character). Please see 2961 Section 2. 2963 o The withdrawn attribute of route class is removed from the language. 2965 o filter-set class is introduced. Please see Section 5.4. 2967 o rtr-set class is introduced. Please see Section 5.5. 2969 o peering-set class is introduced. Please see Section 5.6. 2971 o Filters can now refer to filter-set names. Please see Section 5.4. 2973 o Peerings can now refer to peering-set, rtr-set names. Both local and 2974 peer routers can be specified using router expressions. Please see 2975 Section 5.6. 2977 o The peer attribute of the inet-rtr class can refer to peering-set, 2978 rtr-set names. Please see Section 9. 2980 o The syntax and semantics of union, and list types and typedef attribute 2981 have changed. Please see Section 7. 2983 o In the initial dictionary, the typedef attribute defining the 2984 community_elm, rp-attribute defining the community attribute has 2985 changed. Please see Section 7. 2987 o Guideliness for extending RPSL is added. Please see Section 10. 2989 o Formal grammar rules are added. Please see Appendix B. 2991 D Authors' Addresses 2993 Cengiz Alaettinoglu 2994 USC Information Sciences Institute 2995 email: cengiz@isi.edu 2997 Curtis Villamizar 2998 ANS 2999 email: curtis@ans.net 3001 Elise Gerich 3002 At Home Network 3003 email: epg@home.net 3005 David Kessens 3006 Qwest Communications 3007 email: David.Kessens@qwest.net 3009 David Meyer 3010 University of Oregon 3011 email: meyer@antc.uoregon.edu 3013 Tony Bates 3014 Cisco Systems, Inc. 3015 email: tbates@cisco.com 3017 Daniel Karrenberg 3018 RIPE Network Coordination Centre (NCC) 3019 email: dfk@ripe.net 3021 Marten Terpstra 3022 c/o Bay Networks, Inc. 3023 email: marten@BayNetworks.com