Internet DRAFT - draft-bilse-rdl
draft-bilse-rdl
Internet Draft Per Bilse
<draft-bilse-rdl-00.txt> BGP Innovations
Category: Informational NLnetLabs
Expires October 2014 April 21, 2014
Routing Documentation Language
<draft-bilse-rdl-00.txt>
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)
<router id>: 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]
