idnits 2.17.1 draft-snijders-rpsl-via-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 7, 2013) is 3915 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-idr-ix-bgp-route-server-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Snijders 3 Internet-Draft Atrato IP Networks 4 Intended status: Informational August 7, 2013 5 Expires: February 8, 2014 7 The "import-via" and "export-via" attributes in RPSL Policy 8 Specifications 9 draft-snijders-rpsl-via-01 11 Abstract 13 This document defines two attributes in the aut-num Class which can 14 be used in RPSL policy specifications to publish desired routing 15 policy regarding non-adjacent networks. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on February 8, 2014. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 53 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Import and Export Via Syntax and Semantics . . . . . . . . . . 4 55 5. Example Usage . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 58 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 59 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 61 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 62 Appendix A. Grammar Rules . . . . . . . . . . . . . . . . . . . . 7 63 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 7 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 The Routing Policy Specification Language [RFC4012] allows operators 69 to specify routing policies regarding directly adjacent networks 70 through various import and export attributes. These attributes only 71 apply to directly adjacent networks. 73 This document proposes to extend RPSL according to the following 74 goals and requirements: 76 o Provide a way to describe what an adjacent network could use as 77 routing policy towards its adjacent networks. 79 o The extension should be backward compatible with minimal impact on 80 existing tools and processes, following Section 10.2 of [RFC2622]. 82 The addition of the 'via-import' and 'via-export' attributes in the 83 aut-num Class will especially help participants of Multi-Lateral 84 Peering services to inform the intermediate autonomous system what 85 routing policy should be applied towards other participants. 87 2. Notational Conventions 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 91 "OPTIONAL" in this document are to be interpreted as described in 92 [RFC2119]. 94 3. Background 96 The via keyword specifically benefits operators whom were assigned a 97 32 bit AS Number and transit providers when participating in Multi- 98 Lateral Peering Agreements facilitated by a Route Server. 100 Often Route Server operators overload BGP Communities [RFC1997]) to 101 facilitate signalling of desired routing policy between the 102 participants and the Route Server. Because BGP Communities have a 103 length of 32 bit, it is not possible to signal a 32 bit AS Number 104 coupled with an action. In practise this means Route Server 105 participants whom use a 32 bit AS Number cannot specifically be 106 included or excluded during path distribution calculations on the 107 Route Server unless a mapping system is applied. 109 Transit providers often uphold a routing policy which intents that 110 the transit provider does not want to exchange paths with its 111 downstream customers through Route Servers. The via keyword allows 112 transit providers to participate in Multi-Lateral Peering services 113 while instructing Route Server operators through a simple routing 114 policy specification that paths should not be distributed to 115 downstream customers and reducing the likelyhood of Path Hiding on 116 the Route Server. 118 4. Import and Export Via Syntax and Semantics 120 The two attributes can be used within the aut-num class. 122 import-via: 124 export-via: 126 The syntax for these attributes is as follows: 128 Attribute Value Type 129 import-via [protocol ] [into ] optional, 130 [afi ] multi-valued 131 132 from [action ; ... ;] 133 . . . 134 �mp-peering-3> 135 from [action ; ... ;] 136 accept [;] 138 export-via [protocol ] [into ] optional, 139 [afi ] multi-valued 140 141 to [action ; ... ;] 142 . . . 143 144 to [action ; ... ;] 145 announce [;] 147 Figure 1 149 The import-via and export-via attributes are optional, and should be 150 ignored by implementations which do not support interpretation of 151 those attributes. The syntax closely mimicks the mp-import and mp- 152 export attributes described in Section 2.5 of [RFC4012], with the 153 exception that before the "from" and "to" keywords an &klt;mp- 154 peering> is defined to indicate the common AS between two non- 155 adjacent networks. 157 In the above example and are directly 158 adjacent networks, for instance a Multi-Lateral Peering service. 159 is a non-adjacent network. 161 5. Example Usage 163 Putting it all together: 165 aut-num: AS5580 166 import-via: AS6777 167 from AS15562 168 action pref = 2; 169 accept AS-SNIJDERS 170 export-via: AS6777 171 to AS15562 action community.={5580:40}; 172 announce AS-ATRATO 173 import-via: AS5580:AS-ROUTESERVERS 174 from AS5580:AS-CUSTOMERS 175 accept NOT ANY 176 export-via: AS5580:AS-ROUTESERVERS 177 to AS5580:AS-CUSTOMERS announce NOT ANY 178 import-via: AS6777 179 from AS4247483647 180 accept AS4247483647 181 export-via: AS6777 182 to AS4247483647 action community.={5580:40}; 183 announce AS-ATRATO 185 Figure 2 187 In the above examples AS5580 and AS15562 are Route Server 188 participants. AS4247483647 is a participant whom has been assigned a 189 32 bit AS Number. AS6777 functions as a Route Server 190 [I-D.ietf-idr-ix-bgp-route-server] and AS-SET AS5580:AS-ROUTESERVERS 191 contains a list of Route Server AS Numbers. AS-SET AS5580:AS- 192 CUSTOMERS contains a list of downstream transit customers from 193 AS5580. 195 The intention of the above policy would be to enable the exchange of 196 NLRI's through AS6777 with two parties: AS15562 and AS4247483647, yet 197 prevent the Route Server from distributing NLRI's announced by AS5580 198 towards customers of said network. Publishing the policy that AS5580 199 will not accept customer routes through the Route Server can help 200 counteract the "path hiding" phenomenon as described in Section 2.3.1 201 of [I-D.ietf-idr-ix-bgp-route-server], as the Route Server now is 202 informed which NLRI's should not be considered in the best path 203 selection process. 205 6. Security Considerations 207 There are no security considerations for this specification. 209 7. IANA Considerations 211 This document has no IANA actions. 213 8. Acknowledgments 215 The authors would like to thank Remko van Mook for confirming that 216 'via' is a better keyword than 'through' or 'thru', Nick Hilliard for 217 his unparalleled support and Jeffrey Haas for providing historic 218 perspective. 220 9. References 222 9.1. Normative References 224 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 225 Communities Attribute", RFC 1997, August 1996. 227 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 228 Requirement Levels", BCP 14, RFC 2119, March 1997. 230 [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 231 Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, 232 "Routing Policy Specification Language (RPSL)", RFC 2622, 233 June 1999. 235 [RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, 236 "Routing Policy Specification Language next generation 237 (RPSLng)", RFC 4012, March 2005. 239 9.2. Informative References 241 [I-D.ietf-idr-ix-bgp-route-server] 242 Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 243 "Internet Exchange Route Server", 244 draft-ietf-idr-ix-bgp-route-server-02 (work in progress), 245 February 2013. 247 Appendix A. Grammar Rules 249 HERE BE DRAGONS 251 Appendix B. Document Change Log 253 (RFC Editor - this Appendix can be removed upon publication as RFC) 255 1. Initial document. 257 2. Changes to draft-snijders-rpsl-via-01.txt 259 A. Moved from adding a new RPSL keyword to a new RPSL attribute 260 to improve backwards compatibility. 262 Author's Address 264 Job Snijders 265 Atrato IP Networks 266 Tupolevlaan 103a 267 Schiphol-Rijk 1119 PA 268 NL 270 Email: job.snijders@atrato.com