idnits 2.17.1 draft-hilliard-grow-no-export-via-rs-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC7947, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC1997, 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 (Using the creation date from RFC1997, updated by this document, for RFC5378 checks: 1996-04-10) -- 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 (October 8, 2017) is 2391 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GROW N. Hilliard 3 Internet-Draft INEX 4 Updates: 1997, 7947 (if approved) W. Hargrave 5 Intended status: Standards Track LONAP 6 Expires: April 11, 2018 October 8, 2017 8 The BGP NO_EXPORT_VIA_RS Community for Route Servers 9 draft-hilliard-grow-no-export-via-rs-00 11 Abstract 13 This document describes a BGP Well-known Community called 14 NO_EXPORT_VIA_RS. This community allows BGP route server clients to 15 instruct an Internet Exchange BGP Route Server to tag prefixes 16 destined for other route server clients with the NO_EXPORT Well-Known 17 Community. This mechanism allows route server clients to 18 transitively control distribution of their prefixes in other 19 Autonomous Systems connected to the Internet Exchange Route Server. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 11, 2018. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. The BGP NO_EXPORT_VIA_RS Community . . . . . . . . . . . . . 3 63 3. Operator Implementation Recommendations . . . . . . . . . . . 4 64 4. Vendor Implementation Recommendations . . . . . . . . . . . . 4 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 69 7.2. Informative References . . . . . . . . . . . . . . . . . 5 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 72 1. Introduction 74 Internet Exchange Route Servers [RFC7947] use BGP to broker network 75 reachability information among their clients. BGP operators often 76 wish to control distribution of their prefixes in adjacent autonomous 77 systems. When using bilateral BGP sessions, prefix distribution 78 control can be achieved using the BGP NO_EXPORT community defined in 79 [RFC1997]. 81 [RFC1997] states that the NO_EXPORT community must not be announced 82 outside a BGP confederation boundary, so all BGP speakers that 83 strictly interpret this document will refuse to forward prefixes 84 tagged with this community to a EBGP peer. 86 Some Internet Exchange route server operators ignored the strict 87 interpretation of [RFC1997] on this point because although it is 88 technically more correct to interpret the NO_EXPORT community on the 89 route server, the point of a route server is to act as a broker 90 rather than a router. Consequently it has been argued that it is 91 more useful for route server clients if prefixes tagged with the 92 NO_EXPORT community are passed unaltered through the route server 93 rather than being blocked. This approach gives route server clients 94 the flexibility of being able to use the NO_EXPORT community to 95 signal adjacent ASNs, even if this behaviour is not technically 96 correct according to [RFC1997]. 98 As there is no consensus among IXP route server operators about which 99 is the more appropriate behaviour, the Internet Exchange Route Server 100 [RFC7947] specification document stayed quiet on the issue, noting 101 only in Section 2.2.4 that a route server may interpret, modify or 102 remove specific BGP communities, as defined by local policy. This 103 formally allowed the practice of treating the NO_EXPORT community as 104 a transparent transitive attribute, but did not define whether 105 NO_EXPORT should be interpreted or passed through the route server. 107 This allowed an operational ambiguity to continue, namely that there 108 was no consistent way for a route server client to limit propagation 109 of any prefixes announced to a route server. 111 This document resolves this ambiguity by creating a new BGP Well- 112 Known Community called NO_EXPORT_VIA_RS, which allows BGP route 113 server clients to instruct an Internet Exchange BGP Route Server to 114 tag prefixes destined for other route server clients with the 115 NO_EXPORT Well-Known Community. This mechanism provides an 116 unambiguous and consistent way for route server clients to 117 transitively control distribution of their prefixes in other 118 Autonomous Systems connected to the Internet Exchange Route Server. 120 2. The BGP NO_EXPORT_VIA_RS Community 122 The BGP NO_EXPORT_VIA_RS Community is a community interpreted only by 123 [RFC7947] Internet Exchange Route Servers. If a route server client 124 announces a prefix tagged with NO_EXPORT_VIA_RS to a route server, 125 the route server MUST attach the [RFC1997] NO_EXPORT community to all 126 outbound announcements of that prefix to other route server clients. 127 The route server SHOULD strip the NO_EXPORT_VIA_RS community from the 128 outbound prefix announcement. 130 If a route server client announces a prefix tagged with both the 131 NO_EXPORT and NO_EXPORT_VIA_RS communities to a route server, the 132 route server MUST ignore the NO_EXPORT community, and otherwise MUST 133 handle the prefix and its attributes as specified in the previous 134 paragraph. 136 If a BGP speaker that is not a route server receives a prefix tagged 137 with NO_EXPORT_VIA_RS from a BGP peer, the BGP speaker MUST ignore 138 the NO_EXPORT_VIA_RS community, MUST NOT treat the UPDATE as an error 139 according to [RFC7606] and SHOULD strip the NO_EXPORT_VIA_RS 140 community from the prefix. 142 This document formally updates the NO_EXPORT definition in [RFC1997] 143 and overrides the ambiguity in Section 2.2.4 of [RFC7947] in respect 144 of this specific community. 146 3. Operator Implementation Recommendations 148 It is possible to implement the semantics described above in many BGP 149 implementations by using standard BGP policy language statements. 151 4. Vendor Implementation Recommendations 153 Route server implementations MUST provide a configuration switch to 154 implement the behaviour specified in Section 2. This configuration 155 switch SHOULD be enabled by default. 157 5. Security Considerations 159 The purpose of the NO_EXPORT_VIA_RS BGP Community is to control the 160 NO_EXPORT Community, so there are no additional security 161 considerations outside those associated with the NO_EXPORT community. 163 Network administrators should note the recommendations in Section 11 164 of BGP Operations and Security [RFC7454]. 166 6. IANA Considerations 168 IANA is requested to register NO_EXPORT_VIA_RS in the "BGP Well-known 169 Communities" registry. 171 NO_EXPORT_VIA_RS (= TBD) (IANA suggested: 0xFFFFFF05) 173 7. References 175 7.1. Normative References 177 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 178 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 179 . 181 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 182 Requirement Levels", BCP 14, RFC 2119, 183 DOI 10.17487/RFC2119, March 1997, 184 . 186 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 187 Patel, "Revised Error Handling for BGP UPDATE Messages", 188 RFC 7606, DOI 10.17487/RFC7606, August 2015, 189 . 191 [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 192 "Internet Exchange BGP Route Server", RFC 7947, 193 DOI 10.17487/RFC7947, September 2016, 194 . 196 7.2. Informative References 198 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 199 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 200 February 2015, . 202 Authors' Addresses 204 Nick Hilliard 205 Internet Neutral Exchange Association CLG 206 4027 Kingswood Road 207 Dublin 24 208 Ireland 210 Email: nick@inex.ie 212 Will Hargrave 213 LONAP Ltd 214 5 Fleet Place 215 London EC4M 7RD 216 United Kingdom 218 Email: will@lonap.net