New revision of rpslng

[Joao Luis Silva Damas <]

[Note new email address: joao@localhost]

Below is a revised version of the RPSLng draft that I believ includes the
results of the discussions we have had regarding the extension of RPSL to
support IPv6 and multicast, including tunnel interfaces.

I appreaciate all comments. I would like to also present this draft at the
RIPE 43 meeting next week to have some more discussion

Regards,
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 RPSL language as described in RFC 2622 [RPSL] defines the language for
the IPv4 unicast routing protocols and a series of guidelines for
extending the language itself.

This document proposes to extend RPSL according to the following goals and
requirements:

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

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

- The extensions must be backwards compatible and minimise risk of
breaking existing tools: For example,
introducing a 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.

- clarity and non-ambiguity: RPSL information will be processed by tools
and also by humans.

- 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 a pure language modification. The capabilities and
established operational practices the users are familiar with when
interacting with the servers supporting IRR 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 (IPv4 {unicast|multicast}, IPv6
{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.

Use of existing import and export attributes is not a good option since it
breaks backward compatibility and could undermine clarity in the
expressions.

Keeping this in mind, the import: and export: attributes implicitly
specify ipv4
unicast policy and remain as defined previously in RPSL and new
"multi-protocol (mp)" attributes are introduced.


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


2.2 mp-import and mp-export

Two new policy attributes are introduced:

mp-import
mp-export

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>

mp-import: [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
mp-import : afi ipv6.unicast,ipv4 from AS1 action pref = 1; accept as-foo;
               except { afi ipv6.unicast,ipv4
                   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
mp-import: afi ipv6 from AS1 accept {193.0.0.0/22}

the filter should be evaluated as {NOT ANY}.


aut-num: AS2
mp-import: 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 mp-export attribute. The mexport is
defined in a symmetric way to the mp-import attribute.

2.3 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 using the traditional filtering mechanism in use in IRR systems
today.

2.4 Prefix/origin specification (route6)

2.4.1 Route and Route6 classes

An ipv6 interAS route has specific properties, such as prefix format, and
storage requirements that are different from the existing route class.

Additionally, IRR systems use filters to select which type of information
is returned to the requester. These filters are designed to operate by
receiving a class type as operand. In the case of route objects, the
attribute which is the class's primary key is where the route itself is
defined.

It is therefore preferable to create a new route6 class than a
multi-protocol class.

A new class, route6, is created allowing each interAS ipv6 route
originated by an AS to be specified using a route6 object.

route6:         [mandatory]  [single]     [primary/look-up key]


2.4.2 safi attribute

Though objects of the route classes (route and route6)  represent
prefixes announced in the Inetrnet, there is a need to tag them as
belonging to a particular subsequent address family (multicast, unicast,
anycast). This tag is used when collecting prefixes for a specific
routing policy. For instance, when building configuration for ipv6
multicast routing, only ipv6 prefixes marked as being multicast should
be used.

This attribute is optional and may appear in route and route6
objects.

Absence of this attribute defaults to "unicast".

safi: [single] [optional]

2.4.3 Examples


route6: 2001:610:240::/48
origin: AS3333

route: 224.0.1.0/24
safi: multicast
origin: AS3333


2.5 route-set


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

A new attribute mp-members is defined with the following syntax:

mp-members: afi <afi-list> list of <address-prefix-range> or
            afi <afi-list> <route-set-name> or
            afi <afi-list> <route-set-name><range-operator>.


route-set: rs-foo
mp-member: rs-bar		# common members
mp-member: afi ipv6 rs-foo2, 3FFE:FFFF::/35	# v6 only members...
mp-member: afi ipv4 rs-foo3, 128.9.0.0/16


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

mp-filter:      afi <afi> <filter>

<filter> is defined as in RFC2622.


The relevant parts of the new filter-set class are shown below:

filter-set: [mandatory] [ single] [class key]
mp-filter:  afi <afi> <filter> [optional [multiple]
filter: [optional] [multiple]

Note that according to this definition empty filters are possible and
should be handled accordingly.

3.5 peering-set

An mp-peering attribute is introduced in this class.

mp-peering: afi <afi> <peering>

peering-set: [mandatory] [single] [class key]
peering:     [optional]  [multiple]
mp-peering:  [optional]  [multiple]

Example:

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

3.6 inet-rtr Class

This class gets a new attribute "interface:" which allows the definition
of generic interfaces, including the information previously contained in
the ifaddr: attribute and new types such as tunnels.

interface: afi <afi> <address> masklen <mask> [ tunnel
<remote-endpoint-address>,<encapsulation> ]

The new syntax allows native IPv4 and IPv6 interface definitions as well
as the definition of tunnels as "virtual" interfaces.

Without the optional part, this attribute allows the same functionality as
the ifaddr attribute but extends it to allow IPv6 addresses.

In the case of the interface being a tunnel, the optional part describes
the tunnel configurationas follows:

remote-endpoint-address indicates the IP address of the remote endpoint of
the tunnel. The address family must match that of the local endpoint.

<encapsulation> denotes the encapsulation used in the tunnel and is one of
{GRE,IPv6inIPv4,IPinIP,DVMRP}

Routing policies for these routers should be described in the appropriate
classes (eg. peering and autnum).

References

[RPSL]  RFC 2622, Allaetinoglu, C. et al.