Internet Draft Per Bilse BGP Innovations Category: Informational NLnetLabs Expires October 2014 April 21, 2014 Routing Documentation Language Status of this Memo Distribution of this memo is unlimited. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 21 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Bilse October 2014 [Page 1] Internet Draft Routing Documentation Language April 21, 2014 Abstract This document provides an introduction to RDL (Routing Documentation Language). RDL is a high level language capable of describing BGP topology as well as both inter- and intra-AS route filtering and announcements, and can be compiled to actual router configuration detail for a number of vendors' equipment. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Elements of RDL . . . . . . . . . . . . . . . . . . . . . . . . 4 3. RDL Objects . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3.1. Internal Peers . . . . . . . . . . . . . . . . . . . . . . . 6 4. Lexical Scope, and Object and Attribute References . . . . . . . 7 5. Setting Policy . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Bilse October 2014 [Page 2] Internet Draft Routing Documentation Language April 21, 2014 1. Introduction As of early 2014 there are around 46000 distinct ASs in the global routing system, of which some 6600 are transit ASs [HUSTON]. The complexity of configuring routers, and specifically BGP, has not diminished over the years, not least because there has been no development and/or reduction of the configuration detail required. This has led to common router configurations bloating to unmanageable proportions, with much detail routinely machine generated, and it is impossible to avoid increasing amounts of "cargo cult" configuration. Not only does this impact router performance, in turn impacting routing recovery and stability, but more importantly it requires extensive and detailed maintenance and management by operators, thereby both wasting manpower on tedious and repetitive low level tasks and increasing the probability of accidental errors being introduced. There are numerous studies in software development showing that the more code it takes to accomplish a given task, the more likely it is errors are introduced, and this is no different for router configurations. Hand in hand with this goes the desire to formally document routing policy, not least as this is a requirement of many Internet exchanges and peering agreements; in particular, in Europe this is considered mandatory. Formal documentation will also allow sophisticated computerised analysis and verification of routing policy and compatibility between peers, and by compiling what is actually a specification down to actual configuration, many of the issues with the current state of affairs are avoided. A comprehensive early attempt at addressing some of these issues is RPSL [RFC2622], but over the years it has become clear that RPSL has several shortcomings and is too limited in scope. RPSL is arguably also tied too closely to route filtering details, focusing more on the "how" than the "what". RDL takes a whole new approach, and introduces a genuine high level abstraction from router configuration detail, providing a way to write a specification for a complete autonomous system. Specifically, RDL introduces formalisms for describing BGP topology (both internal and external) and how this relates to routing announcements and BGP attribute modifications. This specification can then be compiled to actual router configuration, much like eg a C compiler produces assembler output, and managing a network becomes much more a case of "programming an autonomous system" than "writing router configuration". RDL describes BGP and router topology using an intuitive "curly brace" syntax, and utilizes class-oriented, lexical scope to group, Bilse October 2014 [Page 3] Internet Draft Routing Documentation Language April 21, 2014 assign, and associate object attributes, including filter rules. This greatly reduces the outright text volume ("lines of code") needed to describe any given autonomous system, which in itself makes it much easier for operators to maintain a clear picture of their AS. In addition, by avoiding large amounts of detail, the risk of accidental errors is greatly reduced. 2. Elements of RDL RDL focuses on lists of objects and their relationships to each other. The syntax for RDL has been tuned to create the intuitive and familiar appearance of a "curly brace" scripting language, but the underlying structure is somewhat different, and an RDL specification is in fact a list of endlessly nested lists. It's useful to keep in mind that an RDL specification is just that, a specification, and there is no notion of execution or state in an RDL specification; it is a statement of facts, rules and relationships. Each object has a number of attributes which are known and meaningful to RDL, as well as any number of user-defined attributes whose meaning is left up to the network developer. Attributes are inherited from enclosing objects in a manner discussed later on, and need not be relevant for the object in which they are defined. A small number of attributes are mandatory, and these generally provide the smallest amount of information (eg AS numbers) needed for BGP peerings to be established. Where possible, mandatory attributes have reasonable defaults. Syntactically, lists are generally enclosed by curly braces and contain elements separated by semicolons or commas, depending on the type of list (see "RDL Objects" below). RDL uses the dot "." to merge components together, in the style of a concatenative language. Thus, given eg A = { 1, 2 } . { 3, 4 }; the reference "A" will identify a list "{ 1, 2, 3, 4 }". 3. RDL Objects RDL has four primary objects, namely zones, routers, peers, and policies (the policy object will be discussed in a later section), and additionally provides for a number of secondary objects, such as IP prefixes and addresses, numbers, and references. Primary objects are created by means of a constructor function, of which there are two: Bilse October 2014 [Page 4] Internet Draft Routing Documentation Language April 21, 2014 new(): this creates a new, empty object copy(): this will copy an existing object Using the "copy" constructor, one may duplicate part-assembled template objects and supply final details locally. Secondary objects require no constructor. Primary objects use semicolon to separate elements, while secondary objects use comma; a few examples later will make everything clear. 3.1. Zone The zone is the uppermost structure in an RDL specification, and has largely the same role as a file system directory. It specifies an area inside of which there is a degree of commonality, but how much or how little is entirely up to the network developer; overall, the rationale is to group together routers and peers that share policy. Zones may contain routers and nested zones, again in a manner appropriate for the particular network. In practice, for a multinational network, a zone may well be a continent, divided into one zone for each country or region, divided into one zone for each major city or POP, but it need not be like that at all. The zone structure describes the actual network, and it isn't so that the network must conform to any particular zone structure. Zones have two mandatory attributes: id: the name of the zone (automatically assigned at creation) ibgp: style of iBGP, described later (defaults to full mesh) The top level zone in a network will often also specify the "asn" attribute, which sets the AS number for the system; this will then be inherited by all objects below, and need not be repeated. Example: hibernia = new(zone) . { asn = 5580; }; The zone's "id" attribute will automatically get the value "hibernia"; the "ibgp" attribute will default to full mesh; the zone will also attain the "asn" attribute which, albeit of no meaning to the zone itself, will be inherited by all objects created inside the zone. 3.2. Router This identifies a router in the network, and will contain one or more BGP peer specifications if it's an edge router. Bilse October 2014 [Page 5] Internet Draft Routing Documentation Language April 21, 2014 Routers have three mandatory attributes: id: the name of the router (automatically assigned at creation) address: the router's iBGP peering address asn: the AS number for the router's BGP process The "asn" attribute will usually be inherited from a network's top level zone and need in that case not be specified explicitly. Example: ams1 = new(router) . { 10.0.0.26; }; This creates a new router object and sets the "address" attribute as shown; the router will normally inherit an AS number from an enclosing zone. RDL tries to be helpful whenever possible so that it isn't necessary to specify attributes explicitly, provided it is clear which attribute is being referred to. The above would read ams1 = new(router) . { address = 10.0.0.26; }; if this wasn't possible. 3.3. Peer The peer object specifies an external BGP peer, and has two mandatory attributes: address: the IP address of the remote peer asn: the remote peer's AS number Example, incorporating all three objects: hibernia = new(zone) . { asn = 5580; ams1 = new(router) . { 10.0.0.26; ripe = new(peer) . { 12.0.0.1; 3333; }; }; }; In the creation of the "ripe" peer, RDL is again able to be helpful and can ascertain from the attribute values which is the address and which is the AS number of the peer. 3.3.1. Internal Peers Bilse October 2014 [Page 6] Internet Draft Routing Documentation Language April 21, 2014 An RDL specification requires no details for internal BGP. All internal BGP is configured automatically based on the "ibgp" attribute, which can have one of several values: mesh: this is the default and indicates a full mesh localmesh: this indicates a full mesh from the point of specification and downwards (through inheritance) : this indicates a route reflector client setup The above may also take the form of a list, where this makes sense, eg: ibgp = { rr1, rr2, localmesh }; would take announcements from the two routers "rr1" and "rr2" (which would be configured for route reflector client peerings), and additionally set up a local mesh within the zone. 4. Lexical Scope, and Object and Attribute References As outlined above, objects inherit attributes from enclosing objects, much like nested procedures have access to (increasingly) global variables in languages that support nested procedures. The mechanism is automatic and need no explicit configuration, but all attributes may be explicitly specified if desired, and may be overriden in this fashion. Globally, all object attributes can be referenced via their enclosing objects using a file system like syntax. For instance, using the example from section 3.3, the AS number of the "ripe" peer may be referred to as any of the following (depending on location of reference): ripe.asn ams1/ripe.asn hibernia/ams1/ripe.asn /hibernia/ams1/ripe.asn ../../ams1/ripe.asn The final example would be the case where the reference came from inside something parallel to the "ams1" router object. It is also possible to refer to enclosing objects by generic reference to the object type; thus, again using the example from above, ripe.router.asn Bilse October 2014 [Page 7] Internet Draft Routing Documentation Language April 21, 2014 would refer to the AS number for the "ams1" router. 5. Setting Policy [This section is under active development and will see changes and enhancements.] The preceding sections describe a framework that describes a set of routers and peers, and how they relate to each other. The policy object uses these references to identify where policies should apply, and policies are in effect entirely separate from the network specification. An important aspect to understand is how the notion of a policy is something more comprehensive and abstract than route filtering, and it's handy to think of it as the three Ws: First, we have an action: What: is an action to take (eg filtering) If we now add criteria for taking the action, we have a rule: When: is the criteria for applying the action (eg prefix match) What: is an action to take (eg filtering) And if we now add network location, we have a policy: Where: is where in the network the rule should be applied When: is the criteria for applying the action (eg prefix match) What: is an action to take (eg filtering) An example will make this clear. Suppose a network has a policy saying it will not export bogons. This might look like the following: bogons = { 0.0.0.0/8^+, 10.0.0.0/8^+, 100.64.0.0/10^+, ... }; nobogons = new(policy) . { where = export peer.asn != peer.router.asn; when = nlri.prefix & bogons; what = reject; }; Here, "bogons" defines a list of IP prefixes that should be filtered. The prefix syntax comes from RPSL. As for the policy specification: where: states that the rule should be applied on outbound announcements Bilse October 2014 [Page 8] Internet Draft Routing Documentation Language April 21, 2014 where the "peer.asn" attribute differs from the "asn" attribute of the enclosing router object; this is in fact the definition (AS numbers differ) of an external peering (possibly except for BGP confederations which will be considered separately) when: states that if the prefix of a proposed announcement matches the "bogons" list, the action should be taken what: states that the annoucement should be rejected The syntax for the "where" and "when" sections follows well-known C syntax, with semantics adapted for the purpose. The syntax for the "what" section is either "reject" as shown, or "accept" followed by a list of BGP attribute modifications, eg: what = accept { metric = 200, path += "5800 5800" }; As noted at the top, the policy specification details are undergoing active development and are not complete at this time. 6. Security Considerations There are no security considerations relevant to this document. 7. IANA Considerations No actions are required from IANA as result of the publication of this document. 8. References [HUSTON] Geoff Huston: "BGP in 2013", IEPG Meeting at IETF 89, http://www.iepg.org/2014-03-02-ietf89/2014-03-02-bgp2013.pdf [RFC2622] C. Alaettinoglu, C. Villamizar, E. Gerich, D. Kessens, D. Meyer, T. Bates, D. Karrenberg, M. Terpstra: "Routing Policy Specification Language (RPSL)", RFC 2622, June 1999. Authors' Address Per Bilse BGP Innovations 5 Alphabet Square London E3 3RT United Kingdom EMail: pgb@bgpinnovations.com Bilse October 2014 [Page 9]