idnits 2.17.1 draft-ietf-grow-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC4012, but the abstract doesn't seem to mention this, which it should. 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. (Using the creation date from RFC4012, updated by this document, for RFC5378 checks: 2003-05-08) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 23, 2015) is 3233 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 215 == Outdated reference: A later version (-12) exists of draft-ietf-idr-ix-bgp-route-server-02 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Snijders 3 Internet-Draft NTT 4 Updates: 4012 (if approved) May 23, 2015 5 Intended status: Standards Track 6 Expires: November 24, 2015 8 The "import-via" and "export-via" attributes in RPSL Policy 9 Specifications 10 draft-ietf-grow-rpsl-via-01 12 Abstract 14 This document defines two attributes in the aut-num Class which can 15 be used in RPSL policy specifications to publish desired routing 16 policy regarding non-adjacent networks. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on November 24, 2015. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 2 54 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Import and Export Via Syntax and Semantics . . . . . . . . . 3 56 5. Example Usage . . . . . . . . . . . . . . . . . . . . . . . . 4 57 6. Ambiguity Resolution . . . . . . . . . . . . . . . . . . . . 5 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 60 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 61 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 63 10.2. Informative References . . . . . . . . . . . . . . . . . 7 64 Appendix A. Grammar Rules . . . . . . . . . . . . . . . . . . . 7 65 Appendix B. TODO . . . . . . . . . . . . . . . . . . . . . . . . 9 66 Appendix C. Document Change Log . . . . . . . . . . . . . . . . 9 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 69 1. Introduction 71 The Routing Policy Specification Language [RFC4012] allows operators 72 to specify routing policies regarding directly adjacent networks 73 through various import and export attributes. These attributes only 74 apply to directly adjacent networks. 76 This document proposes to extend RPSL according to the following 77 goals and requirements: 79 o Provide a way for network (A) to describe what an adjacent network 80 (B) could use as routing policy towards its adjacent networks (C, 81 D, E .. N). 83 o The extension should be backward compatible with minimal impact on 84 existing tools and processes, following Section 10.2 of [RFC2622]. 86 The addition of the "import-via" and "export-via" attributes in the 87 aut-num Class will especially help participants of Multi-Lateral 88 Peering services to inform the intermediate autonomous system what 89 routing policy should be applied towards other participants. 91 2. Notational Conventions 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 95 "OPTIONAL" in this document are to be interpreted as described in 96 [RFC2119]. 98 3. Background 100 The via keyword specifically benefits operators who were assigned a 101 32 bit AS Number and transit providers when participating in Multi- 102 Lateral Peering Agreements facilitated by a Route Server. 104 Often Route Server operators overload BGP Communities [RFC1997]) to 105 facilitate signaling of desired routing policy between the 106 participants and the Route Server. Because BGP Communities have a 107 length of 32 bit, it is not possible to signal a 32 bit AS Number 108 coupled with an action. In practise this means Route Server 109 participants who use a 32 bit AS Number cannot specifically be 110 included or excluded during path distribution calculations on the 111 Route Server unless a mapping system is applied. 113 Transit providers often have a routing policy which states that the 114 transit provider does not want to exchange paths with its downstream 115 customers through Route Servers via public Internet Exchanges. The 116 import-via and export-via attributes allow transit providers to 117 participate in Multi-Lateral Peering services while instructing Route 118 Server operators through a simple routing policy specification that 119 paths should not be distributed to downstream customers and reducing 120 the likelihood of Path Hiding on the Route Server. 122 4. Import and Export Via Syntax and Semantics 124 The two attributes can be used within the aut-num class. 126 import-via: 128 export-via: 130 The syntax for these attributes is as follows: 132 Attribute Value Type 133 import-via [protocol ] [into ] optional, 134 [afi ] multi-valued 135 136 from [action ; ... ;] 137 . . . 138 139 from [action ; ... ;] 140 accept [;] 142 export-via [protocol ] [into ] optional, 143 [afi ] multi-valued 144 145 to [action ; ... ;] 146 . . . 147 148 to [action ; ... ;] 149 announce [;] 151 Figure 1 153 The import-via and export-via attributes are optional, and should be 154 ignored by implementations which do not support interpretation of 155 those attributes. The syntax closely mimics the mp-import and mp- 156 export attributes described in Section 2.5 of [RFC4012], with the 157 exception that before the "from" and "to" keywords an is 158 defined to indicate the common AS between two non-adjacent networks. 160 In the above example and are directly 161 adjacent networks, for instance a Multi-Lateral Peering service. 162 is a non-adjacent network. 164 5. Example Usage 165 Putting it all together: 167 aut-num: AS15562 168 import-via: AS6777 169 from AS15562 170 action pref = 2; 171 accept AS-SNIJDERS 172 export-via: AS6777 173 to AS15562 action community.={15562:40}; 174 announce AS-SNIJDERS 175 import-via: AS15562:AS-ROUTESERVERS 176 from AS15562:AS-CUSTOMERS 177 accept NOT ANY 178 export-via: AS15562:AS-ROUTESERVERS 179 to AS15562:AS-CUSTOMERS announce NOT ANY 180 import-via: AS6777 181 from AS4247483647 182 accept AS4247483647 183 export-via: AS6777 184 to AS4247483647 action community.={15562:40}; 185 announce AS-SNIJDERS 187 Figure 2 189 In the above examples AS15562 and AS15562 are Route Server 190 participants. AS4247483647 is a participant who has been assigned a 191 32 bit AS Number. AS6777 functions as a Route Server 192 [I-D.ietf-idr-ix-bgp-route-server] and AS-SET AS15562:AS-ROUTESERVERS 193 contains a list of Route Server AS Numbers. AS-SET AS15562:AS- 194 CUSTOMERS contains a list of downstream transit customers from 195 AS15562. 197 The intention of the above policy would be to enable the exchange of 198 NLRI's through AS6777 with two parties: AS15562 and AS4247483647, yet 199 prevent the Route Server from distributing NLRI's announced by 200 AS15562 towards customers of said network. Publishing the policy 201 that AS15562 will not accept customer routes through the Route Server 202 can help counteract the "path hiding" phenomenon as described in 203 Section 2.3.1 of [I-D.ietf-idr-ix-bgp-route-server], as the Route 204 Server now is informed which NLRI's should not be considered in the 205 best path selection process. 207 6. Ambiguity Resolution 209 The same peering can be covered by more than one "via" policy 210 attribute or by a combination of multi-protocol policy attributes, or 211 multi-protocol policy attributes (when specifying IPv4 unicast 212 policy) and the previously defined IPv4 unicast policy attributes. 214 In these cases, implementations should follow the specification-order 215 rule as defined in Section 6.4 of RFC 2622 [1]. Operators should 216 take note that in order to break ambiguity, the action corresponding 217 to the first peering specification is used. 219 Consider the following example regarding ambiguity resolution. 221 aut-num: AS15562 222 export: to AS6777 195.69.144.255 announce AS15562 223 export-via: AS6777 195.69.144.255 to AS-AMS-IX-RS announce AS-SNIJDERS 225 Figure 3 227 As both policy specifications cover the same peering with AS6777, 228 specification-order rule is used and Route Server AS6777 229 195.69.144.255 should only accept AS15562, instead of AS-SNIJDERS, 230 even though the export-via specification is more specific. If the 231 intended policy was to announce all routes which can be resolved 232 through AS-SNIJDERS on this particular peering, the operator should 233 have specified: 235 aut-num: AS15562 236 export-via: AS6777 195.69.144.255 to AS-AMS-IX-RS announce AS-SNIJDERS 237 export: to AS6777 195.69.144.255 announce AS15562 239 Figure 4 241 7. Security Considerations 243 There are no security considerations for this specification. 245 8. IANA Considerations 247 This document has no IANA actions. 249 9. Acknowledgments 251 The author would like to thank Remko van Mook for confirming that 252 "via" is a better keyword than 'through' or 'thru', Nick Hilliard for 253 his unparalleled support, Jeffrey Haas for providing historic 254 perspective, David Croft and Martin Pels for nitpicking. 256 10. References 257 10.1. Normative References 259 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 260 Communities Attribute", RFC 1997, August 1996. 262 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 263 Requirement Levels", BCP 14, RFC 2119, March 1997. 265 [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 266 Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, 267 "Routing Policy Specification Language (RPSL)", RFC 2622, 268 June 1999. 270 [RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, 271 "Routing Policy Specification Language next generation 272 (RPSLng)", RFC 4012, March 2005. 274 10.2. Informative References 276 [I-D.ietf-idr-ix-bgp-route-server] 277 Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 278 "Internet Exchange Route Server", draft-ietf-idr-ix-bgp- 279 route-server-02 (work in progress), February 2013. 281 Appendix A. Grammar Rules 283 Note that only 'via' specific grammar rules have been listed. 284 Currently two routing registry whois daemons have support for the 285 'via' attributes: IRRd 3.0.7 and RIPE Whois Server 1.71. 287 %type line_autnum 288 %type attr_autnum 289 %type attr_import_via 290 %type attr_export_via 292 %token T_IV_KEY // *** import-via: *** 293 %token T_EV_KEY // *** export-via: *** 294 %token T_AFI T_PROTOCOL T_WORD T_INTO T_EXCEPT T_REFINE 295 %token T_ACCEPT T_ANNOUNCE T_TO T_FROM T_PRNGNAME 297 line_autnum: attr_autnum 298 | attr_import_via 299 | attr_export_via 301 attr_import_via: T_IV_KEY attr_import_syntax 303 attr_import_syntax: opt_protocol_from opt_protocol_into import_simple 304 | opt_protocol_from opt_protocol_into afi_import_exp 306 attr_export_via: T_EV_KEY attr_export_syntax 308 attr_export_syntax: opt_protocol_from opt_protocol_into export_simple 309 | opt_protocol_from opt_protocol_into afi_export_exp 311 opt_afi_specification: 312 | T_AFI afi_list 314 afi_list: afi_token 315 | afi_list ',' afi_token 317 afi_token: afi_name 319 opt_protocol_from: 320 | T_PROTOCOL T_WORD 322 opt_protocol_into: 323 | T_INTO T_WORD 325 import_simple: opt_afi_specification import_factor 327 export_simple: opt_afi_specification export_factor 329 afi_import_exp: opt_afi_specification import_exp 331 afi_export_exp: opt_afi_specification export_exp 333 import_exp: import_term 334 | import_term T_EXCEPT afi_import_exp 335 | import_term T_REFINE afi_import_exp 337 import_factor_list: import_factor ';' 338 | import_factor_list import_factor ';' 340 import_term: import_factor ';' 341 | '{' import_factor_list '}' 343 export_exp: export_term 344 | export_term T_EXCEPT afi_export_exp 345 | export_term T_REFINE afi_export_exp 347 export_factor_list: export_factor ';' 348 | export_factor_list export_factor ';' 350 export_term: export_factor ';' 351 | '{' export_factor_list '}' 353 import_factor: import_peering_action_list T_ACCEPT filter 355 export_factor: export_peering_action_list T_ANNOUNCE filter 357 peering: as_expression opt_router_expression opt_router_expression_with_at 358 | T_PRNGNAME 360 // Below are two grammar rules that actually differ 361 // from mp-import: + mp-export: 363 import_peering_action_list: peering T_FROM peering opt_action 364 | import_peering_action_list peering T_FROM peering opt_action 366 export_peering_action_list: peering T_TO peering opt_action 367 | export_peering_action_list peering T_TO peering opt_action 369 Figure 5 371 Appendix B. TODO 373 (RFC Editor - this Appendix can be removed upon publication as RFC) 375 1. Add python parser example based on Grako EBNF. 377 Appendix C. Document Change Log 379 (RFC Editor - this Appendix can be removed upon publication as RFC) 381 1. Initial document. 383 2. Changes to draft-snijders-rpsl-via-01.txt 385 A. Moved from adding a new RPSL keyword to a new RPSL attribute 386 to improve backwards compatibility. 388 3. Changes to draft-snijders-rpsl-via-02.txt 390 A. Added grammar appendix. 392 B. Added section about Ambiguity Resolution. 394 4. Changes to draft-snijders-rpsl-via-03.txt 396 A. Updated current IRR implementations. 398 5. Changes to draft-grow-rpsl-via-01.txt 399 A. Bump version - add TODO. 401 Author's Address 403 Job Snijders 404 NTT 405 Theodorus Majofskistraat 100 406 Amsterdam 1065 SZ 407 NL 409 Email: job@ntt.net