Re: New attempt at extending rpsl

["William Rutherford" <]

Hi Joao

Is anything roughed out for :

 TBD: Tunnels may go here as well.

  TBD. Tunnels should be considered here.

Cheers!


Bill R.



                                                                                                                      
                    Joao Luis                                                                                         
                    Silva Damas                                                      
                    joao@localhost        cc:                                                                          
                    t>                   Subject:     New attempt at extending rpsl                                   
                    Sent by:                                                                                          
                    owner-rpslng@                                                                                     
                    ripe.net                                                                                          
                                                                                                                      
                                                                                                                      
                    04/26/2002                                                                                        
                    08:58 AM                                                                                          
                                                                                                                      
                                                                                                                      




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.
--