The 'via' keyword in RPSL Policy Specifications
draft-snijders-rpsl-via-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Job Snijders , Nick Hilliard | ||
| Last updated | 2013-06-04 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-snijders-rpsl-via-00
Network Working Group J. Snijders
Internet-Draft Atrato IP Networks
Intended status: Informational N. Hilliard
Expires: December 4, 2013 INEX
June 4, 2013
The 'via' keyword in RPSL Policy Specifications
draft-snijders-rpsl-via-00
Abstract
This document defines the 'via' keyword which can be used in RPSL
policy specifications to publish desired routing policy regarding
non-adjacent networks.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 30, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Snijders & Hilliard Expires November 30, 2013 [Page 1]
Internet-Draft The 'via' keyword in RPSL May 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 2
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Import and Export Via Syntax and Semantics . . . . . . . . . 3
5. Example Usage . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Grammar Rules . . . . . . . . . . . . . . . . . . . 6
Appendix B. Support and Commitment . . . . . . . . . . . . . . . 6
Appendix C. Document Change Log . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
The Routing Policy Specification Language [RFC4012] allows operators
to specify routing policies regarding directly adjacent networks
through various import and export attributes. These attributes only
apply to directly adjacent networks.
This document proposes to extend RPSL according to the following
goals and requirements:
Provide a way to describe what an adjacent network could use as
routing policy towards its adjacent networks.
The extension should be backward compatible with minimal impact on
existing tools and processes, following Section 10 of [RFC2622].
The addition of a 'via' keyword in import and export related
attributes will especially help participants of Multi-Lateral Peering
services to inform the intermediate autonomous system what routing
policy should be applied towards other participants.
2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
3. Background
Snijders & Hilliard Expires November 30, 2013 [Page 2]
Internet-Draft The 'via' keyword in RPSL May 2013
The via keyword specifically benefits operators whom were assigned a
32 bit AS Number and transit providers when participating in Multi-
Lateral Peering Agreements facilitated by a Route Server.
Often Route Server operators overload BGP Communities [RFC1997]) to
facilitate signalling of desired routing policy between the
participants and the Route Server. Because BGP Communities have a
length of 32 bit, it is not possible to signal a 32 bit AS Number
coupled with an action. In practise this means Route Server
participants whom use a 32 bit AS Number cannot specifically be
included or excluded during path distribution calculations on the
Route Server unless a mapping system is applied.
Transit providers often uphold a routing policy which intents that
the transit provider does not want to exchange paths with its
downstream customers through Route Servers. The via keyword allows
transit providers to participate in Multi-Lateral Peering services
while instructing Route Server operators through a simple routing
policy specification that paths should not be distributed to
downstream customers and reducing the likelyhood of Path Hiding on
the Route Server.
4. Import and Export Via Syntax and Semantics
The via keyword can be used with the following policy attributes:
import:
export:
mp-import:
mp-export:
The syntax for these attributes is as follows:
Snijders & Hilliard Expires November 30, 2013 [Page 3]
Internet-Draft The 'via' keyword in RPSL May 2013
Attribute Value Type
import [protocol <protocol-1>] [into <protocol-2>] optional,
[via <peering-1>] optional,
from <peering-2> [action <action-1>]
. . .
[via <peering-3>] optional,
from <peering-N> [action <action-N>]
accept <filter>
export [protocol <protocol-1>] [into <protocol-2>] optional,
[via <peering-1>] optional,
to <peering-2> [action <action-1>]
. . .
[via <peering-3>] optional,
to <peering-N> [action <action-N>]
announce <filter>
mp-import [protocol <protocol-1>] [into <protocol-2>] optional,
[afi <afi-list>] multi-valued
[via <peering-1>] optional,
from <mp-peering-2> [action <action-1>; ... <action-N>;]
. . .
[via <peering-3>] optional,
from <mp-peering-M> [action <action-1>; ... <action-N>;]
accept <mp-filter> [;]
mp-export [protocol <protocol-1>] [into <protocol-2>] optional,
[afi <afi-list>] multi-valued
[via peering-1>] optional,
to <mp-peering-2> [action <action-1>; ... <action-N>;]
. . .
[via peering-3>] optional,
to <mp-peering-M> [action <action-1>; ... <action-N>;]
announce <mp-filter> [;]
Figure 1
The via keyword is optional, and should be ignored by implementations
which do not support interpretation of the via keyword.
In the above example <peering-1> and <peering-3> are directly
adjacent networks, for instance a Multi-Lateral Peering service.
<peering-2> is a non-adjacent network.
5. Example Usage
Putting it all together:
Snijders & Hilliard Expires November 30, 2013 [Page 4]
Internet-Draft The 'via' keyword in RPSL May 2013
aut-num: AS5580
import: via AS6777
from AS15562
action pref = 2;
accept AS-SNIJDERS
import: via AS6777
from AS5580:AS-CUSTOMERS
accept NOT ANY
import: via AS6777 from AS15562
from AS1
from AS2
via AS3 from AS4
accept PeerAS
mp-import: afi ipv6.unicast via AS6777
from AS15562 accept AS-SNIJDERS
mp-import: via AS6777
from AS65551 accept AS-SET-FROM-32BIT-ASN
export: via AS6777
to AS15562 action community.={5580:40};
announce AS-ATRATO
export: via AS5580:AS-ROUTESERVERS
to AS5580:AS-CUSTOMERS announce NOT ANY
mp-export: afi ipv6.unicast via AS6777
to AS15562 announce AS-ATRATO
mp-export: via AS6777
to AS65551 announce AS-ATRATO
Figure 2
In the above examples AS5580 and AS15562 are Route Server
participants. AS65551 is a participant whom has been assigned a 32
bit AS Number. AS6777 functions as a Route Server and AS-SET AS5580
:AS-ROUTESERVERS contains a list of Route Server AS Numbers. AS-SET
AS5580:AS-CUSTOMERS contains a list of downstream transit customers
from AS5580.
6. Security Considerations
There are no security considerations for this specification.
7. IANA Considerations
The new set of mechanisms for route servers does not require any new
allocations from IANA.
8. Acknowledgments
Snijders & Hilliard Expires November 30, 2013 [Page 5]
Internet-Draft The 'via' keyword in RPSL May 2013
The authors would like to thank Remko van Mook for confirming that
'via' is a better keyword than 'through' or 'thru'.
9. References
9.1. Normative References
[RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP
Communities Attribute", RFC 1997, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,
"Routing Policy Specification Language (RPSL)", RFC 2622,
June 1999.
[RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky,
"Routing Policy Specification Language next generation
(RPSLng)", RFC 4012, March 2005.
9.2. Informative References
[I-D.hilliard-ix-bgp-route-server-operations]
Hilliard, N., Jasinska, E., Raszuk, R., and N. Bakker,
"Internet Exchange Route Server Operations", draft-
hilliard-ix-bgp-route-server-operations-02 (work in
progress), December 2012.
Appendix A. Grammar Rules
HERE BE DRAGONS
Appendix B. Support and Commitment
(RFC Editor - this Appendix can be removed upon publication as RFC)
Route Server operators whom believe this is a viable solution:
o ECIX
o EQUINIX
Software projects which will receive patches to support the via
keyword:
o RADB
Snijders & Hilliard Expires November 30, 2013 [Page 6]
Internet-Draft The 'via' keyword in RPSL May 2013
o RIPE WHOIS
Software that might need a patch:
o irrtoolset
o rpsltools
Appendix C. Document Change Log
(RFC Editor - this Appendix can be removed upon publication as RFC)
1. Initial document.
2. Changes to draft-snijders-rpsl-via-01.txt
a. derp derp
Authors' Addresses
Job Snijders
Atrato IP Networks
Tupolevlaan 103a
Schiphol-Rijk 1119 PA
NL
Email: job.snijders@atrato.com
Nick Hilliard
INEX
4027 Kingswood Road
Dublin 24
IE
Email: nick@inex.ie
Snijders & Hilliard Expires November 30, 2013 [Page 7]