idnits 2.17.1 draft-dong-idr-node-target-ext-comm-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o If the target IPv4 or IPv6 address in any of the IPv4 or IPv6 Node Target extended community does not match with any local IP address, the receiving BGP speaker is not the target node of information in the Update, the information in the received Update message MUST not be used. -- The document date (July 8, 2019) is 1754 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) == Outdated reference: A later version (-27) exists of draft-ietf-idr-rfc5575bis-17 -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Dong 3 Internet-Draft S. Zhuang 4 Intended status: Standards Track Huawei Technologies 5 Expires: January 9, 2020 G. Van de Velde 6 Nokia 7 July 8, 2019 9 BGP Extended Community for Identifying the Target Node 10 draft-dong-idr-node-target-ext-comm-01 12 Abstract 14 BGP has been used to distribute different types of routing and policy 15 information in the network. In some cases, the information 16 distributed may be only intended for one or several particular 17 receiving BGP nodes in the network. However, BGP does not have a 18 general mechanism for designating the receiving node of the routing 19 information. This document defines a new type of BGP extended 20 community called "Node Target". The mechanism of using the Node 21 Target extended community to steer BGP route distribution to 22 particular BGP nodes is specified. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 9, 2020. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Node Target Extended Communities . . . . . . . . . . . . . . 3 66 2.1. IPv4 Node Target Extended Community . . . . . . . . . . . 3 67 2.2. IPv6 Node Target Extended Community . . . . . . . . . . . 4 68 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 74 7.2. Informative References . . . . . . . . . . . . . . . . . 6 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 BGP [RFC4271] has been used to distribute different types of routing 80 and policy information in the network. In some cases, the 81 information distributed may be only intended for one or several 82 particular receiving BGP nodes in the network. A typical use case is 83 the distribution of BGP FlowSpec [RFC5575] [I-D.ietf-idr-rfc5575bis] 84 policies to some particular BGP nodes. 86 However, BGP does not have a general mechanism for designating the 87 receiving nodes of the information to be distributed. Route Target 88 (RT) as defined in [RFC4364] is used for the distribution of VPN 89 routes into the target VPN Routing and Forwarding tables (VRFs) on a 90 set of PE nodes. Although it is possible to use RTs to control the 91 distribution of non VPN-specific information to a particular node, 92 such mechanism is not applicable when the information to be 93 distributed is VPN-specific and relies on RTs to match the target 94 VRF. Thus a mechanism which is independent from the control of VPN 95 route to VRF distribution is needed. 97 Another possible way is to configure, on each router, a community and 98 the corresponding policies to match the community to determine 99 whether to accept the received routes. Such mechanism relies on 100 manual configuration thus is considered error-prone. It is 101 preferable by operators that an automatic approach can be provided. 103 This document defines a new type of BGP extended community called 104 "Node Target". The mechanism of using the Node Target extended 105 community to steer BGP route distribution to particular BGP nodes is 106 also specified. 108 2. Node Target Extended Communities 110 2.1. IPv4 Node Target Extended Community 112 For IPv4 networks, this section defines a new BGP extended community 113 [RFC4360] called "IPv4 Node Target Extended Community". It is a 114 transitive extended community with type 0x01 and sub-type TBA. 116 The format of IPv4 Node Target Extended Community is shown in 117 Figure 1. 119 0 1 2 3 120 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Type (0x01) | Sub-Type (TBA)| Target IPv4 Address | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Target IPv4 Address (cont.) | Reserved | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 Figure 1. IPv4 Node Target extended community 128 Target IPv4 address field: A local IPv4 address of the target node. 129 When the target IPv4 address is set to 0.0.0.0, it means all the BGP 130 nodes in the network are the target nodes. 132 Reserved field: Reserved for future use, MUST be set to zero on 133 transmission and ignored on receipt. 135 One or more IPv4 Node Target extended communities may be carried in a 136 BGP Update message. 138 2.2. IPv6 Node Target Extended Community 140 For IPv6 networks, a new IPv6 Address Specific BGP Extended Community 141 [RFC5701] called "IPv6 Node Target extended community" is defined. 142 It is a transitive IPv6 address specific extended community with type 143 0x00 and sub-type TBA. 145 The format of this extended community is shown in Figure 2. 147 0 1 2 3 148 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Type (0x00) | Sub-Type (TBA)| Target IPv6 Address | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Target IPv6 Address (cont.) | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Target IPv6 Address (cont.) | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Target IPv6 Address (cont.) | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Target IPv6 Address (cont.) | Reserved | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 Figure 2. IPv6 Node Target extended community 162 Target IPv6 address field: A IPv6 address of the target node. When 163 the target IPv6 address is set to "0:0:0:0:0:0:0:0" ( :: ), it means 164 all the BGP nodes in the network are the target nodes. 166 Reserved field: Reserved for future use, MUST be set to zero on 167 transmission and ignored on receipt. 169 One or more IPv6 Node Target extended communities may be carried in a 170 BGP Update message. 172 3. Procedures 174 In this version only the usage of the proposed mechanism in the 175 intra-AS scenario is described, more details about the inter-AS 176 scenario is for further study. 178 When a controller or BGP speaker plans to advertise some BGP 179 information only to some particular BGP nodes in the network, it MUST 180 put the IPv4 or IPv6 address of each target node into the IPv4 or 181 IPv6 Node Target extended communities, and attach the IPv4 or IPv6 182 Node Target extended communities to the BGP Update message to be 183 advertised. 185 If a non-RR BGP speaker receives an Update message which contains one 186 or more IPv4 or IPv6 Node Target extended communities, it MUST check 187 the target IPv4 or IPv6 addresses carried in the extended 188 communities. 190 o If the target IPv4 or IPv6 address in any of the IPv4 or IPv6 Node 191 Target extended community matches with one of the local IP 192 addresses, the receiving BGP speaker is one of the target nodes of 193 the information in the Update, and the information in the Update 194 is eligible to be kept and installed by the receiving BGP speaker. 196 o If the target IPv4 or IPv6 address in any of the IPv4 or IPv6 Node 197 Target extended community does not match with any local IP 198 address, the receiving BGP speaker is not the target node of 199 information in the Update, the information in the received Update 200 message MUST not be used. 202 If a route-reflector (RR) receives an BGP Update message which 203 contains one or more IPv4 or IPv6 Node Target extended communities, 204 it MUST check the target IPv4 or IPv6 addresses carried in the IPv4 205 or IPv6 Node Target extended communities. 207 o If the target IPv4 or IPv6 address in any of the IPv4 or IPv6 Node 208 Target extended community matches with one of the local IP 209 addresses, this RR is one of the target nodes of information in 210 the Update, and such information is eligible to be kept and 211 installed by this RR. If there is no other IPv4 or IPv6 Node 212 Target extended communities in the Update, the RR MUST NOT 213 advertise the information in this Update further to its neighbors. 214 If there is other IPv4 or IPv6 Node Target extended communities, 215 the RR SHOULD first remove the local matched Node Target extended 216 community, then reflect the routes with the remaining Node Target 217 Extended Communities according to [RFC4456]. 219 o If the target IPv4 or IPv6 address in any of the IPv4 or IPv6 Node 220 target extended community does not match with any local IP 221 address, this RR is not the target node of routes in the Update, 222 the rules defined in [RFC4456] are used for the reflection of the 223 received route. 225 4. IANA Considerations 227 This document requests that IANA assigns one new sub-type for "IPv4 228 Node Target extended community" from the "Transitive IPv4-Address- 229 Specific Extended Community" registry of the "BGP extended 230 communities" registry. 232 This document requests that IANA assigns one new type for "IPv6 Node 233 Target extended community" from the "Transitive IPv6-Address-Specific 234 Extended Community" registry of the "BGP extended communities" 235 registry. 237 5. Security Considerations 239 This document does not change the security properties of BGP. 241 6. Acknowledgements 243 The authors would like to thank Zhenbin Li and Ercin Torun for the 244 discussion and review of this document. 246 7. References 248 7.1. Normative References 250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 251 Requirement Levels", BCP 14, RFC 2119, 252 DOI 10.17487/RFC2119, March 1997, 253 . 255 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 256 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 257 DOI 10.17487/RFC4271, January 2006, 258 . 260 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 261 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 262 February 2006, . 264 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 265 Reflection: An Alternative to Full Mesh Internal BGP 266 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 267 . 269 [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community 270 Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009, 271 . 273 7.2. Informative References 275 [I-D.ietf-idr-rfc5575bis] 276 Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 277 Bacher, "Dissemination of Flow Specification Rules", 278 draft-ietf-idr-rfc5575bis-17 (work in progress), June 279 2019. 281 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 282 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 283 2006, . 285 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 286 and D. McPherson, "Dissemination of Flow Specification 287 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 288 . 290 Authors' Addresses 292 Jie Dong 293 Huawei Technologies 294 Huawei Campus, No. 156 Beiqing Rd. 295 Beijing 100095 296 China 298 Email: jie.dong@huawei.com 300 Shunwan Zhuang 301 Huawei Technologies 302 Huawei Campus, No. 156 Beiqing Rd. 303 Beijing 100095 304 China 306 Email: zhuangshunwan@huawei.com 308 Gunter Van de Velde 309 Nokia 310 Antwerp 311 BE 313 Email: gunter.van_de_velde@nokia.com