[no subject]

[Joao Luis Silva Damas <]

The following text reflects the output of a brainstorm session at the RIPE NCC.
As you may notice it describes TWO and not ONE option to represent 
ipv6 and multicast policies. We felt that at this early stage it is 
preferable to put all ideas on the table for analysis.

So here goes a draft.

Andrei actually produced this and I have just done some minor editing.

See you all in Minneapolis

Joao


RPSL extensions for IPv6 and Multicast Routing Policies

Table of Contents

1.  Introduction
2.  Specifying routing policy for different address families
2.1 Using address family specific policy attributes
2.2 Using generic policy attributes
3. New classes and attributes to support the extensions
3.1 route6 class
3.2 as-set class
3.3 route6-set class
3.4 filter6-set classs
3.5 peering6-set class
3.6 inet-rtr class


1. Introduction

The goals:
- to support generation of configuration files for routers for ipv6/m-cast
- to allow document routing policy for ipv6 and multicast
- to provide RPSL extensibility in the dimension of address families

The following requirements for the extensions can be formulated:
- Assuming that such documentation will be processed by tools and also by
humans, clarity and non-ambiguity are the main requirements here.
- To preserve backwards compatibility and minimise risk of breaking existing
tools. More obvious changes are better in this respect. For example,
introducing new class or attribute will less probably break the tools than
changing the format of an existing attribute. Section 10 of [RPSL]
provides good guidelines. Another requirement in this area is to allow
smooth transition to RPSL extensions.
- To minimise duplication of information. Duplication of information for the
same entity opens the way for inconsistencies.
- RR system requirements. It is impossible to consider RPSL extensions as
pure language modification. Capabilities of the database systems supporting
RR should also be taken into account.

An important point is to note the fact that there are two address 
families, corresponding to the two versions of the IP protocol 
currently in use in the Internet, but there are at least **four 
distinct routing policies** that need to be described (v4 
{unicast|multicast}, v6 {unicast|multicast}).



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 syntax of an existing attribute is
considered as a last resort option in RPSL. This will require modification
to the tools.
- policy documentation: it may be not clear whether import specifies ipv4
policy expression, or this is also valid for other address families.

Two alternatives are considered in this proposal:
- To define separate policy (import/export) attributes for each address
family/unicast/multicast combination.
- To define a new dictionary attribute - afi, and new generic policy
attributes.

In both approaches import: and export: attributes implicitly specify ipv4
unicast policy.

2.1. Using address family specific policy attributes

A new attribute is defined for each combination of address
family/unicast/multicast:
import6-ucast:
import6-mcast:
import4-mcast:

export6-ucast:
export6-mcast:
export4-mcast:

Semantics of these attributes is similar to existing import/export
attributes.

The name of an attribute indicates what address family this policy should be
evaluated for. Mixing of address families is not allowed and all components
of the policy should be evaluated without conflicts. For example, specifying
a filter6-set as a <filter> in import4-mcast: policy is considered a syntax
error.

The following example demonstrates how policies for different address
families can be specified:

aut-num:       AS65534
import:        from AS1 action pref = 1; accept as-foo;
               except {
                   from AS2 action pref = 2; accept AS226;
               }
import4-mcast: from AS1 action pref = 1; accept as-foo;
               except {
                   from AS2 action pref = 2; accept AS226;
               }
import6-ucast: from AS1 action pref = 1; accept as-foo;
               except {
                   from AS2 action pref = 2; accept AS226;
                   except {
                       from AS3 action pref = 3; accept {3FFE:FFFF::/35};
                   }
               }

In this example the ipv4 policy is the same for multicast and unicast, while
the policy for ipv6 unicast is different.


2.2. Using generic policy attributes


Two new policy attributes are introducted:
import-policy
export-policy
These attributes incorporate afi (address-family) specification. The afi is a
new attribute introduced in the dictionary class, see section 7.

The definition of these new attributes is as follwos:

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

<import-term> ::= <import-factor> |
                      LEFT-BRACE
                      <import-factor>
                      . . .
                      <import-factor>
                      RIGHT-BRACE

<importexpression> ::= afi <afi>[.<safi>] <import-term> |
               afi <afi>[.<safi>] <import-term> EXCEPT <importexpression> |
               afi <afi>[.<safi>] <import-term> REFINE <importexpression>

import-policy: [protocol <protocol1>] [into <protocol2>]
           <importexpression>




<afi> is a rpsl list of address families for which the policy expression
should be evaluated. <afi> is mandatory, <safi> is optional. When it is
omitted, all possible safi for this afi are iterated trough.

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
import-policy: 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 (the rightmost) "except" is evaluated only for ipv6 unicast address
family, while other import-expressions are also evaluated for ipv6 and ipv4
address family, including multicast.

Evaluation of an <imporexpression> is done by evaluating all of its
components. Evaluation of peering-sets and filter-sets is constrained by the
address family. Such constraint may result in {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
import-policy: afi ipv6 from AS1 accept {193.0.0.0/22}

the filter will be evaluated as {NOT ANY}.


aut-num: AS2
import-policy: 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.

3. New classes and attributes to support the extensions

3.1 route6 Class

An ipv6 interAS route has specific properties, such as prefix format, storage
requirements that are different from the existing route class. Also this
simplifies server operation when filtering routes for a particular address
family is needed.

Each interAS ipv6 route originated by an AS is specified using a route6
object.

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 route6-set

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

The "member:" attribute of the route6-set class defines the members of the
set which may be ipv6 prefixes, or ipv6 range operators, or other route6-sets.

The name of the route6-set must start with RS6- prefix.

3.4 filter6-set
"The filter 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".

"filter6:" attribute is introduced as well.

filter6-set  <object-name> mandatory, single-valued, class key
filter6      <filter>      mandatory, single-valued

filter6-set name should start with FLTR6- prefix.


3.5 peering6-set

Though sometimes it makes sense to define peerings for different address
families in the same set (for example, someone would like to define all (ipv4
and ipv6) his peers in one set) it is not possible because of the way RPSL
defines templates. A peering6 attribute is introduced is this class.

peering6-set name should start with PRNG6- prefix.

peering6-set: prng6-ebgp-peers
peering6:    AS2 3FFE:FFFF::1 at 3FFE:FFFF::2

TBD: Tunnels may go here as well.

3.6 inet-rtr Class

TBD. Tunnels should be considered here.
--