< draft-blunk-rpslng-07.txt   draft-blunk-rpslng-08.txt >
Network Working Group L. Blunk Network Working Group L. Blunk
Internet-Draft Merit Network Internet-Draft Merit Network
Updates: 2622, 2725 (if approved) J. Damas Updates: 2622, 2725 (if approved) J. Damas
Expires: January 13, 2005 Internet Software Consortium Expires: January 21, 2005 Internet Software Consortium
F. Parent F. Parent
Viagenie Viagenie
A. Robachevsky A. Robachevsky
RIPE NCC RIPE NCC
July 15, 2004 July 23, 2004
Routing Policy Specification Language next generation (RPSLng) Routing Policy Specification Language next generation (RPSLng)
draft-blunk-rpslng-07.txt draft-blunk-rpslng-08.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 13, 2005. This Internet-Draft will expire on January 21, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This memo presents a new set of simple extensions to the Routing This memo presents a new set of simple extensions to the Routing
Policy Specification Language (RPSL) enabling the language to also Policy Specification Language (RPSL) enabling the language to also
document routing policies for the IPv6 and multicast address families document routing policies for the IPv6 and multicast address families
skipping to change at page 6, line 19 skipping to change at page 6, line 19
The syntax for the mp-default attribute and the basic policy The syntax for the mp-default attribute and the basic policy
specification of the mp-import and mp-export attributes is as specification of the mp-import and mp-export attributes is as
follows: follows:
Attribute Value Type Attribute Value Type
mp-import [protocol <protocol-1>] [into <protocol-2>] optional, mp-import [protocol <protocol-1>] [into <protocol-2>] optional,
[afi <afi-list>] multi-valued [afi <afi-list>] multi-valued
from <mp-peering-1> [action <action-1>; ... <action-N>;] from <mp-peering-1> [action <action-1>; ... <action-N>;]
. . . . . .
from <mp-peering-M> [action <action-1>; ... <action-N>;] from <mp-peering-M> [action <action-1>; ... <action-N>;]
accept <mp-filter> accept <mp-filter> [;]
mp-export [protocol <protocol-1>] [into <protocol-2>] optional, mp-export [protocol <protocol-1>] [into <protocol-2>] optional,
[afi <afi-list>] multi-valued [afi <afi-list>] multi-valued
to <mp-peering-1> [action <action-1>; ... <action-N>;] to <mp-peering-1> [action <action-1>; ... <action-N>;]
. . . . . .
to <mp-peering-M> [action <action-1>; ... <action-N>;] to <mp-peering-M> [action <action-1>; ... <action-N>;]
announce <mp-filter> announce <mp-filter> [;]
mp-default [afi <afi-list>] to <mp-peering> optional, mp-default [afi <afi-list>] to <mp-peering> optional,
[action <action-1>; ... <action-N>;] multi-valued [action <action-1>; ... <action-N>;] multi-valued
[networks <mp-filter>] [networks <mp-filter>]
The mp-import and mp-export policies can be structured. As with RFC The mp-import and mp-export policies can be structured. As with RFC
2622 [1], structured policies are recommended only to advanced RPSL 2622 [1], structured policies are recommended only to advanced RPSL
users. The mp-import structured policy syntax is defined below. users. The mp-import structured policy syntax is defined below.
Please note the semicolon at the end of an <import-factor> is Please note the semicolon at the end of an <import-factor> is
mandatory for structured policy expressions, while being optional on mandatory for structured policy expressions, while being optional on
skipping to change at page 7, line 41 skipping to change at page 7, line 41
<mp-peering> ::= <as-expression> [<mp-router-expression-1>] <mp-peering> ::= <as-expression> [<mp-router-expression-1>]
[at <mp-router-expression-2>] | <peering-set-name> [at <mp-router-expression-2>] | <peering-set-name>
where <as-expression> is an expression over AS numbers and AS sets where <as-expression> is an expression over AS numbers and AS sets
using operators AND, OR, and EXCEPT, and <mp-router-expression> is an using operators AND, OR, and EXCEPT, and <mp-router-expression> is an
expression over router ipv4-addresses or ipv6-addresses, inet-rtr expression over router ipv4-addresses or ipv6-addresses, inet-rtr
names, and rtr-set names using operators AND, OR, and EXCEPT. The names, and rtr-set names using operators AND, OR, and EXCEPT. The
binary "EXCEPT" operator is the set subtraction operator and has the binary "EXCEPT" operator is the set subtraction operator and has the
same precedence as the operator AND (it is semantically equivalent to same precedence as the operator AND (it is semantically equivalent to
"AND NOT" combination). That is "(AS1 OR AS2) EXCEPT AS2" equals "AND NOT" combination). That is "(AS65001 OR AS65002) EXCEPT
"AS1". AS65002" equals "AS65001".
2.5.2 <mp-filter> 2.5.2 <mp-filter>
The <mp-filter> policy filter expression is derived from the RPSL The <mp-filter> policy filter expression is derived from the RPSL
<filter> policy filter expression defined in section 5.4 of RFC 2622 <filter> policy filter expression defined in section 5.4 of RFC 2622
[1]. <mp-filter> extends the <filter> expression to allow the [1]. <mp-filter> extends the <filter> expression to allow the
specification of IPv6 prefixes and prefix ranges. In particular, an specification of IPv6 prefixes and prefix ranges. In particular, an
Address-Prefix Set expression in an <mp-filter> expression may Address-Prefix Set expression in an <mp-filter> expression may
include both IPv4 and IPv6 prefixes or prefix ranges. <mp-filter> is include both IPv4 and IPv6 prefixes or prefix ranges. <mp-filter> is
otherwise identical to the RPSL <filter> expression. Address-Prefix otherwise identical to the RPSL <filter> expression. Address-Prefix
Sets are enclosed in braces '{' and '}'. The policy filter matches Sets are enclosed in braces '{' and '}'. The policy filter matches
the set of routes whose destination address-prefix is in the set. the set of routes whose destination address-prefix is in the set.
For example: For example:
{ 198.108.0.0/16, 3ffe:ffff:240::/48 } { 192.0.2.0/24, 2001:0DB8::/32 }
{ 3ffe:ffff:580::/48^+, 3ffe:ffff:600::/48^64 } { 2001:0DB8:0100::/48^+, 2001:0DB8:0200::/48^64 }
2.5.3 Policy examples 2.5.3 Policy examples
The address family may be specified in subsequent refine or except The address family may be specified in subsequent refine or except
policy expression's, and is valid only within the policy expression policy expression's, and is valid only within the policy expression
that contains it. that contains it.
Therefore in the example: Therefore in the example:
aut-num: AS65534 aut-num: AS65534
mp-import: afi any.unicast from AS65001 accept as-foo; mp-import: afi any.unicast from AS65001 accept as-foo;
except afi any.unicast { except afi any.unicast {
from AS65002 accept AS65226; from AS65002 accept AS65226;
} except afi ipv6.unicast { } except afi ipv6.unicast {
from AS65003 accept {3FFE:FFFF::/32}; from AS65003 accept {2001:0DB8::/32};
} }
the last "except" is evaluated only for the IPv6 unicast address the last "except" is evaluated only for the IPv6 unicast address
family, while other import-expressions are evaluated for both the family, while other import-expressions are evaluated for both the
IPv6 and IPv4 unicast address families. IPv6 and IPv4 unicast address families.
The evaluation of a policy expression is done by evaluating all of The evaluation of a policy expression is done by evaluating all of
its components. Evaluation of peering-sets and filter-sets is its components. Evaluation of peering-sets and filter-sets is
constrained by the address family. Such constraints may result in a constrained by the address family. Such constraints may result in a
"NOT ANY" <mp-filter> or invalid <mp-peering> depending on implicit "NOT ANY" <mp-filter> or invalid <mp-peering> depending on implicit
or explicit definitions of the address family in the set. Conflicts or explicit definitions of the address family in the set. Conflicts
with explicit or implicit declarations are resolved at runtime, that with explicit or implicit declarations are resolved at runtime, that
is, during the evaluation of a policy expression. An RPSL evaluation is, during the evaluation of a policy expression. An RPSL evaluation
implementation may wish to issue a warning in the case of a "NOT ANY" implementation may wish to issue a warning in the case of a "NOT ANY"
<mp-filter>. The following mp-import policy contains an example of <mp-filter>. The following mp-import policy contains an example of
an <mp-filter> that should be evaluated as "NOT ANY". an <mp-filter> that should be evaluated as "NOT ANY".
aut-num: AS65002 aut-num: AS65002
mp-import: afi ipv6.unicast from AS65001 accept {193.0.0.0/22} mp-import: afi ipv6.unicast from AS65001 accept {192.0.2.0/24}
3. route6 Class 3. route6 Class
The route6 class is the IPv6 equivalent of the route class. As with The route6 class is the IPv6 equivalent of the route class. As with
the route class, the class key for the route6 class is specified by the route class, the class key for the route6 class is specified by
the route6 and origin attribute pair. Other than the route6 the route6 and origin attribute pair. Other than the route6
attribute, the route6 class shares the same attribute names with the attribute, the route6 class shares the same attribute names with the
route class. While the attribute names remain identical, the inject, route class. While the attribute names remain identical, the inject,
components, exports-comps, holes, and mnt-routes attributes must components, exports-comps, holes, and mnt-routes attributes must
specify IPv6 prefixes and addresses rather than IPv4 prefixes and specify IPv6 prefixes and addresses rather than IPv4 prefixes and
skipping to change at page 9, line 45 skipping to change at page 9, line 45
aggr-mtd inbound or outbound optional, single-valued aggr-mtd inbound or outbound optional, single-valued
[<as-expression>] [<as-expression>]
export-comps <ipv6-filter> optional, single-valued export-comps <ipv6-filter> optional, single-valued
holes list of <ipv6-address-prefix> optional, multi-valued holes list of <ipv6-address-prefix> optional, multi-valued
mnt-lower list of <mntner-name> optional, multi-valued mnt-lower list of <mntner-name> optional, multi-valued
mnt-routes list of <mntner-name> optional, multi-valued mnt-routes list of <mntner-name> optional, multi-valued
[{list of <ipv6-address-prefix-range>} or ANY] [{list of <ipv6-address-prefix-range>} or ANY]
Example: Example:
route6: 3ffe:ffff:240::/48 route6: 2001:0DB8::/32
origin: AS65001 origin: AS65001
4. Updates to existing Classes to support the extensions 4. Updates to existing Classes to support the extensions
4.1 as-set Class 4.1 as-set Class
The as-set class defines a set of Autonomous Systems (AS), specified The as-set class defines a set of Autonomous Systems (AS), specified
either directly by listing them in the members attribute, or either directly by listing them in the members attribute, or
indirectly by referring to another as-sets or using the mbrs-by-ref indirectly by referring to another as-sets or using the mbrs-by-ref
facility. More importantly, "In a context that expects a route set facility. More importantly, "In a context that expects a route set
skipping to change at page 10, line 43 skipping to change at page 10, line 43
Attribute Value Type Attribute Value Type
mp-members list of (<ipv4-address-prefix-range> optional, multi-valued mp-members list of (<ipv4-address-prefix-range> optional, multi-valued
or <ipv6-address-prefix-range> or <ipv6-address-prefix-range>
or <route-set-name> or <route-set-name>
or <route-set-name><range-operator>) or <route-set-name><range-operator>)
Example: Example:
route-set: rs-foo route-set: rs-foo
mp-members: rs-bar mp-members: rs-bar
mp-members: 3FFE:FFFF::/32 # v6 member mp-members: 2001:0DB8::/32 # v6 member
mp-members: 128.9.0.0/16 # v4 member mp-members: 192.0.2.0/24 # v4 member
4.3 filter-set Class 4.3 filter-set Class
The new "mp-filter:" attribute defines the set's policy filter. A The new "mp-filter:" attribute defines the set's policy filter. A
policy filter is a logical expression which when applied to a set of policy filter is a logical expression which when applied to a set of
routes returns a subset of these routes. The relevant parts of the routes returns a subset of these routes. The relevant parts of the
updated filter-set class are shown below: updated filter-set class are shown below:
Attribute Value Type Attribute Value Type
filter-set <object-name> mandatory, single-valued, class key filter-set <object-name> mandatory, single-valued, class key
skipping to change at page 11, line 30 skipping to change at page 11, line 30
Attribute Value Type Attribute Value Type
peering-set <object-name> mandatory, single-valued, class key peering-set <object-name> mandatory, single-valued, class key
peering <peering> optional, multi-valued peering <peering> optional, multi-valued
mp-peering <mp-peering> optional, multi-valued mp-peering <mp-peering> optional, multi-valued
... ...
Example: Example:
peering-set: prng-ebgp-peers peering-set: prng-ebgp-peers
mp-peering: AS65002 3FFE:FFFF::1 at 3FFE:FFFF::2 mp-peering: AS65002 2001:0DB8::1 at 2001:0DB8::2
With <mp-peering> defined as above in Section 2.5.1. While the With <mp-peering> defined as above in Section 2.5.1. While the
"peering:" and "mp-peering:" attributes are of type "optional", a "peering:" and "mp-peering:" attributes are of type "optional", a
peering-set must contain at least one of these two attributes. peering-set must contain at least one of these two attributes.
4.5 inet-rtr Class 4.5 inet-rtr Class
Two new attributes are introduced to the inet-rtr class -- Two new attributes are introduced to the inet-rtr class --
"interface:" which allows the definition of generic interfaces, "interface:" which allows the definition of generic interfaces,
including the information previously contained in the "ifaddr:" including the information previously contained in the "ifaddr:"
skipping to change at page 13, line 37 skipping to change at page 13, line 37
Attribute Value Type Attribute Value Type
aut-num <as-number> mandatory, class key, aut-num <as-number> mandatory, class key,
single-valued single-valued
mnt-routes list of <mntner-name> optional, multi-valued mnt-routes list of <mntner-name> optional, multi-valued
[{list of (<ipv6-address-prefix-range> or [{list of (<ipv6-address-prefix-range> or
<ipv4-address-prefix-range>)} or ANY] <ipv4-address-prefix-range>)} or ANY]
... ...
The following is an example of mnt-routes usage. This example The following is an example of mnt-routes usage. This example
authorizes MAINT-65001 to create route6 objects with an origin AS of authorizes MAINT-65001 to create route6 objects with an origin AS of
65002 for IPv6 address prefixes within the 3ffe:ffff::/32^+ range, 65002 for IPv6 address prefixes within the 2001:0DB8::/32^+ range,
and route objects with origin AS 65002 for IPv4 prefixes within the and route objects with origin AS 65002 for IPv4 prefixes within the
35.42.0.0/16^+ range. 192.0.2.0/24^+ range.
aut-num: AS65002 aut-num: AS65002
mnt-routes: MAINT-AS65001 {3ffe:ffff::/32^+, 35.42.0.0/16^+} mnt-routes: MAINT-AS65001 {2001:0DB8::/32^+, 192.0.2.0/24^+}
Note, the inclusion of IPv6 prefix ranges within a mnt-routes Note, the inclusion of IPv6 prefix ranges within a mnt-routes
attribute in an aut-num object may conflict with existing attribute in an aut-num object may conflict with existing
implementations of RPSL which support only IPv4 prefix ranges. implementations of RPSL which support only IPv4 prefix ranges.
However, given the perceived lack of implementation of this optional However, given the perceived lack of implementation of this optional
prefix range list, it was considered acceptable to extend the prefix range list, it was considered acceptable to extend the
existing definition of the mnt-routes attribute in the aut-num class existing definition of the mnt-routes attribute in the aut-num class
rather than creating a new attribute type. rather than creating a new attribute type.
Attribute Value Type Attribute Value Type
skipping to change at page 19, line 8 skipping to change at page 19, line 8
EMail: Florent.Parent@viagenie.qc.ca EMail: Florent.Parent@viagenie.qc.ca
Andrei Robachevsky Andrei Robachevsky
RIPE NCC RIPE NCC
EMail: andrei@ripe.net EMail: andrei@ripe.net
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 24 change blocks. 
58 lines changed or deleted 50 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/