idnits 2.17.1 draft-snijders-rpsl-via-03.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 : ---------------------------------------------------------------------------- == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (March 10, 2014) is 3693 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 213 == Outdated reference: A later version (-12) exists of draft-ietf-idr-ix-bgp-route-server-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Snijders 3 Internet-Draft Hibernia Networks 4 Intended status: Informational March 10, 2014 5 Expires: September 11, 2014 7 The "import-via" and "export-via" attributes in RPSL Policy 8 Specifications 9 draft-snijders-rpsl-via-03 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 September 11, 2014. 34 Copyright Notice 36 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 2 53 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Import and Export Via Syntax and Semantics . . . . . . . . . 3 55 5. Example Usage . . . . . . . . . . . . . . . . . . . . . . . . 4 56 6. Ambiguity Resolution . . . . . . . . . . . . . . . . . . . . 5 57 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 58 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 59 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 60 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 62 10.2. Informative References . . . . . . . . . . . . . . . . . 7 63 Appendix A. Grammar Rules . . . . . . . . . . . . . . . . . . . 7 64 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 9 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 67 1. Introduction 69 The Routing Policy Specification Language [RFC4012] allows operators 70 to specify routing policies regarding directly adjacent networks 71 through various import and export attributes. These attributes only 72 apply to directly adjacent networks. 74 This document proposes to extend RPSL according to the following 75 goals and requirements: 77 o Provide a way for network (A) to describe what an adjacent network 78 (B) could use as routing policy towards its adjacent networks (C, 79 D, E .. N). 81 o The extension should be backward compatible with minimal impact on 82 existing tools and processes, following Section 10.2 of [RFC2622]. 84 The addition of the "import-via" and "export-via" attributes in the 85 aut-num Class will especially help participants of Multi-Lateral 86 Peering services to inform the intermediate autonomous system what 87 routing policy should be applied towards other participants. 89 2. Notational Conventions 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in 94 [RFC2119]. 96 3. Background 98 The via keyword specifically benefits operators who were assigned a 99 32 bit AS Number and transit providers when participating in Multi- 100 Lateral Peering Agreements facilitated by a Route Server. 102 Often Route Server operators overload BGP Communities [RFC1997]) to 103 facilitate signaling of desired routing policy between the 104 participants and the Route Server. Because BGP Communities have a 105 length of 32 bit, it is not possible to signal a 32 bit AS Number 106 coupled with an action. In practise this means Route Server 107 participants who use a 32 bit AS Number cannot specifically be 108 included or excluded during path distribution calculations on the 109 Route Server unless a mapping system is applied. 111 Transit providers often have a routing policy which states that the 112 transit provider does not want to exchange paths with its downstream 113 customers through Route Servers via public Internet Exchanges. The 114 import-via and export-via attributes allow transit providers to 115 participate in Multi-Lateral Peering services while instructing Route 116 Server operators through a simple routing policy specification that 117 paths should not be distributed to downstream customers and reducing 118 the likelihood of Path Hiding on the Route Server. 120 4. Import and Export Via Syntax and Semantics 122 The two attributes can be used within the aut-num class. 124 import-via: 126 export-via: 128 The syntax for these attributes is as follows: 130 Attribute Value Type 131 import-via [protocol ] [into ] optional, 132 [afi ] multi-valued 133 134 from [action ; ... ;] 135 . . . 136 137 from [action ; ... ;] 138 accept [;] 140 export-via [protocol ] [into ] optional, 141 [afi ] multi-valued 142 143 to [action ; ... ;] 144 . . . 145 146 to [action ; ... ;] 147 announce [;] 149 Figure 1 151 The import-via and export-via attributes are optional, and should be 152 ignored by implementations which do not support interpretation of 153 those attributes. The syntax closely mimics the mp-import and mp- 154 export attributes described in Section 2.5 of [RFC4012], with the 155 exception that before the "from" and "to" keywords an is 156 defined to indicate the common AS between two non-adjacent networks. 158 In the above example and are directly 159 adjacent networks, for instance a Multi-Lateral Peering service. 160 is a non-adjacent network. 162 5. Example Usage 164 Putting it all together: 166 aut-num: AS5580 167 import-via: AS6777 168 from AS15562 169 action pref = 2; 170 accept AS-SNIJDERS 171 export-via: AS6777 172 to AS15562 action community.={5580:40}; 173 announce AS-ATRATO 174 import-via: AS5580:AS-ROUTESERVERS 175 from AS5580:AS-CUSTOMERS 176 accept NOT ANY 177 export-via: AS5580:AS-ROUTESERVERS 178 to AS5580:AS-CUSTOMERS announce NOT ANY 179 import-via: AS6777 180 from AS4247483647 181 accept AS4247483647 182 export-via: AS6777 183 to AS4247483647 action community.={5580:40}; 184 announce AS-ATRATO 186 Figure 2 188 In the above examples AS5580 and AS15562 are Route Server 189 participants. AS4247483647 is a participant who has been assigned a 190 32 bit AS Number. AS6777 functions as a Route Server 191 [I-D.ietf-idr-ix-bgp-route-server] and AS-SET AS5580:AS-ROUTESERVERS 192 contains a list of Route Server AS Numbers. AS-SET AS5580:AS- 193 CUSTOMERS contains a list of downstream transit customers from 194 AS5580. 196 The intention of the above policy would be to enable the exchange of 197 NLRI's through AS6777 with two parties: AS15562 and AS4247483647, yet 198 prevent the Route Server from distributing NLRI's announced by AS5580 199 towards customers of said network. Publishing the policy that AS5580 200 will not accept customer routes through the Route Server can help 201 counteract the "path hiding" phenomenon as described in Section 2.3.1 202 of [I-D.ietf-idr-ix-bgp-route-server], as the Route Server now is 203 informed which NLRI's should not be considered in the best path 204 selection process. 206 6. Ambiguity Resolution 208 The same peering can be covered by more than one "via" policy 209 attribute or by a combination of multi-protocol policy attributes, or 210 multi-protocol policy attributes (when specifying IPv4 unicast 211 policy) and the previously defined IPv4 unicast policy attributes. 212 In these cases, implementations should follow the specification-order 213 rule as defined in Section 6.4 of RFC 2622 [1]. Operators should 214 take note that in order to break ambiguity, the action corresponding 215 to the first peering specification is used. 217 Consider the following example regarding ambiguity resolution. 219 aut-num: AS5580 220 export: to AS6777 195.69.144.255 announce AS5580 221 export-via: AS6777 195.69.144.255 to AS-AMS-IX-RS announce AS-ATRATO 223 Figure 3 225 As both policy specifications cover the same peering with AS6777, 226 specification-order rule is used and Route Server AS6777 227 195.69.144.255 should only accept AS5580, instead of AS-ATRATO, even 228 though the export-via specification is more specific. If the 229 intended policy was to announce all routes which can be resolved 230 through AS-ATRATO on this particular peering, the operator should 231 have specified: 233 aut-num: AS5580 234 export-via: AS6777 195.69.144.255 to AS-AMS-IX-RS announce AS-ATRATO 235 export: to AS6777 195.69.144.255 announce AS5580 237 Figure 4 239 7. Security Considerations 241 There are no security considerations for this specification. 243 8. IANA Considerations 245 This document has no IANA actions. 247 9. Acknowledgments 249 The author would like to thank Remko van Mook for confirming that 250 "via" is a better keyword than 'through' or 'thru', Nick Hilliard for 251 his unparalleled support, Jeffrey Haas for providing historic 252 perspective, David Croft and Martin Pels for nitpicking. 254 10. References 256 10.1. Normative References 258 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 259 Communities Attribute", RFC 1997, August 1996. 261 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 262 Requirement Levels", BCP 14, RFC 2119, March 1997. 264 [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 265 Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, 266 "Routing Policy Specification Language (RPSL)", RFC 2622, 267 June 1999. 269 [RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, 270 "Routing Policy Specification Language next generation 271 (RPSLng)", RFC 4012, March 2005. 273 10.2. Informative References 275 [I-D.ietf-idr-ix-bgp-route-server] 276 Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 277 "Internet Exchange Route Server", draft-ietf-idr-ix-bgp- 278 route-server-02 (work in progress), February 2013. 280 Appendix A. Grammar Rules 282 Note that only 'via' specific grammar rules have been listed. 283 Currently two routing registry whois daemons have support for the 284 'via' attributes: IRRd 3.0.7 and RIPE Whois Server 1.71. 286 %type line_autnum 287 %type attr_autnum 288 %type attr_import_via 289 %type attr_export_via 291 %token T_IV_KEY //*** import-via: *** 292 %token T_EV_KEY //*** export-via: *** 293 %token T_AFI T_PROTOCOL T_WORD T_INTO T_EXCEPT T_REFINE 294 %token T_ACCEPT T_ANNOUNCE T_TO T_FROM T_PRNGNAME 296 line_autnum: attr_autnum 297 | attr_import_via 298 | attr_export_via 300 attr_import_via: T_IV_KEY attr_import_syntax 302 attr_import_syntax: opt_protocol_from opt_protocol_into import_simple 303 | opt_protocol_from opt_protocol_into afi_import_exp 305 attr_export_via: T_EV_KEY attr_export_syntax 307 attr_export_syntax: opt_protocol_from opt_protocol_into export_simple 308 | opt_protocol_from opt_protocol_into afi_export_exp 310 opt_afi_specification: 311 | T_AFI afi_list 313 afi_list: afi_token 314 | afi_list ',' afi_token 316 afi_token: afi_name 318 opt_protocol_from: 319 | T_PROTOCOL T_WORD 321 opt_protocol_into: 322 | T_INTO T_WORD 324 import_simple: opt_afi_specification import_factor 326 export_simple: opt_afi_specification export_factor 328 afi_import_exp: opt_afi_specification import_exp 330 afi_export_exp: opt_afi_specification export_exp 332 import_exp: import_term 333 | import_term T_EXCEPT afi_import_exp 334 | import_term T_REFINE afi_import_exp 336 import_factor_list: import_factor ';' 337 | import_factor_list import_factor ';' 339 import_term: import_factor ';' 340 | '{' import_factor_list '}' 342 export_exp: export_term 343 | export_term T_EXCEPT afi_export_exp 344 | export_term T_REFINE afi_export_exp 346 export_factor_list: export_factor ';' 347 | export_factor_list export_factor ';' 349 export_term: export_factor ';' 350 | '{' export_factor_list '}' 352 import_factor: import_peering_action_list T_ACCEPT filter 354 export_factor: export_peering_action_list T_ANNOUNCE filter 355 peering: as_expression opt_router_expression \ 356 opt_router_expression_with_at 357 | T_PRNGNAME 359 // Below are two grammar rules that actually differ 360 // from mp-import: + mp-export: 362 import_peering_action_list: peering T_FROM peering opt_action 363 | import_peering_action_list peering T_FROM peering opt_action 365 export_peering_action_list: peering T_TO peering opt_action 366 | export_peering_action_list peering T_TO peering opt_action 368 Figure 5 370 Appendix B. Document Change Log 372 (RFC Editor - this Appendix can be removed upon publication as RFC) 374 1. Initial document. 376 2. Changes to draft-snijders-rpsl-via-01.txt 378 A. Moved from adding a new RPSL keyword to a new RPSL attribute 379 to improve backwards compatibility. 381 3. Changes to draft-snijders-rpsl-via-02.txt 383 A. Added grammar appendix. 385 B. Added section about Ambiguity Resolution. 387 4. Changes to draft-snijders-rpsl-via-03.txt 389 A. Updated current IRR implementations. 391 Author's Address 393 Job Snijders 394 Hibernia Networks 395 Tupolevlaan 103a 396 Schiphol-Rijk 1119 PA 397 NL 399 Email: job.snijders@hibernianetworks.com