idnits 2.17.1 draft-ietf-grow-rpsl-via-00.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, 2014) is 3619 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 214 == 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 Independent 4 Updates: 4012 (if approved) May 23, 2014 5 Intended status: Standards Track 6 Expires: November 24, 2014 8 The "import-via" and "export-via" attributes in RPSL Policy 9 Specifications 10 draft-ietf-grow-rpsl-via-00 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, 2014. 35 Copyright Notice 37 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . 6 63 10.2. Informative References . . . . . . . . . . . . . . . . . 7 64 Appendix A. Grammar Rules . . . . . . . . . . . . . . . . . . . 7 65 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 9 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 The Routing Policy Specification Language [RFC4012] allows operators 71 to specify routing policies regarding directly adjacent networks 72 through various import and export attributes. These attributes only 73 apply to directly adjacent networks. 75 This document proposes to extend RPSL according to the following 76 goals and requirements: 78 o Provide a way for network (A) to describe what an adjacent network 79 (B) could use as routing policy towards its adjacent networks (C, 80 D, E .. N). 82 o The extension should be backward compatible with minimal impact on 83 existing tools and processes, following Section 10.2 of [RFC2622]. 85 The addition of the "import-via" and "export-via" attributes in the 86 aut-num Class will especially help participants of Multi-Lateral 87 Peering services to inform the intermediate autonomous system what 88 routing policy should be applied towards other participants. 90 2. Notational Conventions 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 94 "OPTIONAL" in this document are to be interpreted as described in 95 [RFC2119]. 97 3. Background 99 The via keyword specifically benefits operators who were assigned a 100 32 bit AS Number and transit providers when participating in Multi- 101 Lateral Peering Agreements facilitated by a Route Server. 103 Often Route Server operators overload BGP Communities [RFC1997]) to 104 facilitate signaling of desired routing policy between the 105 participants and the Route Server. Because BGP Communities have a 106 length of 32 bit, it is not possible to signal a 32 bit AS Number 107 coupled with an action. In practise this means Route Server 108 participants who use a 32 bit AS Number cannot specifically be 109 included or excluded during path distribution calculations on the 110 Route Server unless a mapping system is applied. 112 Transit providers often have a routing policy which states that the 113 transit provider does not want to exchange paths with its downstream 114 customers through Route Servers via public Internet Exchanges. The 115 import-via and export-via attributes allow transit providers to 116 participate in Multi-Lateral Peering services while instructing Route 117 Server operators through a simple routing policy specification that 118 paths should not be distributed to downstream customers and reducing 119 the likelihood of Path Hiding on the Route Server. 121 4. Import and Export Via Syntax and Semantics 123 The two attributes can be used within the aut-num class. 125 import-via: 127 export-via: 129 The syntax for these attributes is as follows: 131 Attribute Value Type 132 import-via [protocol ] [into ] optional, 133 [afi ] multi-valued 134 135 from [action ; ... ;] 136 . . . 137 138 from [action ; ... ;] 139 accept [;] 141 export-via [protocol ] [into ] optional, 142 [afi ] multi-valued 143 144 to [action ; ... ;] 145 . . . 146 147 to [action ; ... ;] 148 announce [;] 150 Figure 1 152 The import-via and export-via attributes are optional, and should be 153 ignored by implementations which do not support interpretation of 154 those attributes. The syntax closely mimics the mp-import and mp- 155 export attributes described in Section 2.5 of [RFC4012], with the 156 exception that before the "from" and "to" keywords an is 157 defined to indicate the common AS between two non-adjacent networks. 159 In the above example and are directly 160 adjacent networks, for instance a Multi-Lateral Peering service. 161 is a non-adjacent network. 163 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.={5580: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. 213 In these cases, implementations should follow the specification-order 214 rule as defined in Section 6.4 of RFC 2622 [1]. Operators should 215 take note that in order to break ambiguity, the action corresponding 216 to the first peering specification is used. 218 Consider the following example regarding ambiguity resolution. 220 aut-num: AS15562 221 export: to AS6777 195.69.144.255 announce AS15562 222 export-via: AS6777 195.69.144.255 to AS-AMS-IX-RS announce AS-SNIJDERS 224 Figure 3 226 As both policy specifications cover the same peering with AS6777, 227 specification-order rule is used and Route Server AS6777 228 195.69.144.255 should only accept AS15562, instead of AS-SNIJDERS, 229 even though the export-via specification is more specific. If the 230 intended policy was to announce all routes which can be resolved 231 through AS-SNIJDERS on this particular peering, the operator should 232 have specified: 234 aut-num: AS15562 235 export-via: AS6777 195.69.144.255 to AS-AMS-IX-RS announce AS-SNIJDERS 236 export: to AS6777 195.69.144.255 announce AS15562 238 Figure 4 240 7. Security Considerations 242 There are no security considerations for this specification. 244 8. IANA Considerations 246 This document has no IANA actions. 248 9. Acknowledgments 250 The author would like to thank Remko van Mook for confirming that 251 "via" is a better keyword than 'through' or 'thru', Nick Hilliard for 252 his unparalleled support, Jeffrey Haas for providing historic 253 perspective, David Croft and Martin Pels for nitpicking. 255 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 356 peering: as_expression opt_router_expression 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 Independent 395 Theodorus Majofskistraat 100 396 Amsterdam 1065 SZ 397 NL 399 Email: job@instituut.net