New attempt at extending rpsl

[Joao Luis Silva Damas <]

Hope this one incorporates what we have discussed earlier. It is a 
bit rough but I prefer to do the cleaning after (if) we agree on the 
direction

Cheers,
Joao


RPSL extensions for IPv6 and Multicast Routing Policies

Table of Contents

1.  Introduction
2.  Specifying routing policy for different address families
2.1 The afi dictionary attribute
2.2 mimport and mexport
3.  New classes and attributes to support the extensions
3.1 mroute class
3.2 as-set class
3.3 route-set class
3.4 filter-set class
3.5 peering-set class
3.6 inet-rtr class


1. Introduction

The RPSL language as described in RFC XXXX [RPSL] defines the 
language for the IPv4 unicast routing protocols and a series of 
guidelines for extending the language itself.

This document takes the mentioned RFC and attempts to extend RPSL 
according to the following goals and requirements:

- to provide RPSL extensibility in the dimension of address families
	specifically, to allow document routing policy for ipv6 and multicast

The following requirements for the extensions need to taken into account:

- Backwards compatibility and minimise risk of breaking existing 
tools. More obvious changes are better in this respect. For example, 
introducing a new class or attribute is less likely to break the 
tools than changing the format of an existing attribute.

- Clarity and non-ambiguity are the main requirements here.

- Minimise duplication of information. Duplication of information for 
the same entity opens the way for inconsistencies.

- Routing Registry system requirements. It is impossible to consider 
RPSL extensions as pure language modification. The capabilities of 
the database systems supporting RR should also be taken into account.

Taken these statements into account, the current proposal describes a 
new set of attributes and classes that allows for protocol 
independent description of the information AND keeps the currently 
available attributes in order to preserve correct operation of the 
current systems.

In this way, we propose to keep a route class, limited to describe 
IPv4 prefixes and introduce a new class mroute for Multiprotocol (or 
protocol independent) prefix description.

Taking into account human readability, the names of the new 
attributes and classes will the obtained by prepending the letter m 
(for multiprotocol, as in MBGP), to the names of the currently 
available attributes.

*** author's note: maybe m- is better or some of the names later on 
become a bit strange ***

2. Specifying routing policy for different address families

Routing policy is currently specified in the aut-num class using 
"import:" and "export:" attributes. Sometimes it is important to 
distinguish policy for different address families, as well as a 
unicast routing policy from multicast one.

Using existing import and export attributes is not feasible for 
several reasons:

- backwards compatibility: changing the syntax of an existing 
attribute is considered a last resort option in RPSL. This kind of 
modification will break the tools.
- clarity: it may be not clear whether import specifies ipv4 policy 
expression, or this is also valid for other address families.

2.1 The afi dictionary attribute

In this section we introduce a new dictionary attribute:

<afi> is an rpsl list of address families for which the policy 
expression should be evaluated. <afi> is mandatory.

The possible values for afi will be:

ipv4
ipv4.unicast (equivalent to ipv4)
ipv4.multicast
ipv6
ipv6.unicast (equivalent to ipv6)
ipv6.multicast
ipv6.anycast

2.2 mimport and mexport

Two new policy attributes are introduced:

mimport
mexport

These attributes incorporate the afi (address-family) specification.

The definition of these new attributes is as follows:

<import-factor> ::= from <peering-1> [action <action-1>] accept <filter>;

<import-term> ::= <import-factor> |
                      [
                      <import-factor>
                      . . .
                      <import-factor>
                      ]

<importexpression> ::= afi <afi> <import-term> |
               afi <afi> <import-term> EXCEPT <importexpression> |
               afi <afi> <import-term> REFINE <importexpression>

mimport: [protocol <protocol1>] [into <protocol2>]
           <importexpression>

Address family may be constrained at any level of nesting of 
<importexpression>, and is valid only within this <importexpression>. 
Thus in the example

aut-num:       AS65534
mimport : afi ipv6.unicast,ipv4 from AS1 action pref = 1; accept as-foo;
               except {
                   from AS2 action pref = 2; accept AS226;
                   except afi ipv6.unicast {
                       from AS3 action pref = 3; accept {3FFE:FFFF::/35};
                   }
               }

the last (rightmost) "except" is evaluated only for the ipv6 unicast 
address family, while other import-expressions are evaluated for both 
the ipv6 and ipv4 unicast address families.

The evaluation of an <importexpression> is done by evaluating all of 
its components. Evaluation of peering-sets and filter-sets is 
constrained by the address family. Such constraints may result in a 
{NOT ANY} <filter> or invalid <peering> depending on implicit or 
explicit definitions of the address family in the set. In the latter 
case an error is returned. {NOT ANY} filter may issue a warning.

Conflicts with explicit or implicit declarations are resolved at 
runtime, that is during evaluation of a policy expression. For 
example, when evaluating the following import policy:

aut-num: AS2
mimport: afi ipv6 from AS1 accept {193.0.0.0/22}

the filter will be evaluated as {NOT ANY}.


aut-num: AS2
mimport: afi ipv6.unicast {
   from AS-ANY action med = 0; accept {3FFE:FFFF::/35};
   } refine {
        from AS1 at 3FFE:FFFF::1 action pref = 1; accept AS-UPSTREAM;
        from prng6-ebgp-peers action pref = 2; accept AS1;
     }

In this example only ipv6 prefixes originated by AS1 will be 
collected, and while evaluating AS-UPSTREAM only ipv6 prefixes of the 
member ASes will be considered.

Export policy is specified in the mexport attribute. The mexport is 
defined in a symmetric way to the mimport attribute.


3. New classes and attributes to support the extensions

3.1 mroute Class

This class is equivalent to the route class but requires the 
following definition of the mroute attribute:

mroute: afi <afi> prefix

where afi is defined as above, but only permits one address family, 
instead of a list and the prefix must be a valid prefix for the 
address family specified.

*** Author note: I am not sure I like the overloading of the definition ***


3.2 as-set Class

The as-set class defines a set of ASNs, specified either directly by 
listing them in the members attribute, or indirectly by referring to 
another as-sets or using mbrs-by-ref facility. More importantly, "in 
a context that expects a route set (e.g.  members attribute of the 
route-set class), [...] an as-set AS- X defines the set of routes 
that are originated by the ASes in AS-X."

In this respect the as-set class is used to collect a set of route 
prefixes, which may be restricted to a specific address family.

The existing as-set class does not need any modifications. The 
evaluation of the class must be flagged to get prefixes belonging to 
a particular address family, however.

3.3 route-set

This class is  used in <filter> expressions to specify a set of route prefixes.

A new attribute mmember is defined with the following syntax:

mmember:	minet-rtr-name or
			mrtr-set-name
			afi <afi> <address>



3.4 filter-set

The mfilter attribute defines the set's policy filter.  A policy 
filter is a logical expression which when applied to a set of routes 
returns a subset of these routes.

mfilter:      <filter>      mandatory, single-valued

<filter> is defined as in RFC2622 but the dictionary is modified so that

filter_prefix_list_prefix:

accetps

afi <afi> <address>

rather than

TKN_PRFXV4

*** Author's note: this needs to be rewritten but the intention here 
is to express the general idea. after RIPE 42 details will be ironed 
out ****


3.5 peering-set

An mpeering attribute is introduced in this class.

mpeering: <aut-num> afi <afi> <address> at afi <afi> <address>

both values of the afi elements must be the same.

peering-set: prng-ebgp-peers
mpeering:    AS2 afi ipv6 3FFE:FFFF::1 at afi ipv6 3FFE:FFFF::2


TBD: Tunnels may go here as well.

3.6 inet-rtr Class


mifaddr: afi <afi> <address> masklen <integer> [action <action>]

mpeer: <protocol> afi <afi> <address> <options>
     | <protocol> <inet-rtr-name> <options>
     | <protocol> <rtr-set-name> <options>
     | <protocol> <peering-set-name> <options>



TBD. Tunnels should be considered here.
--