idnits 2.17.1 draft-dong-idr-node-target-ext-comm-02.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 abstract seems to contain references ([RFC4271]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (March 9, 2020) is 1509 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-19 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-08 -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) Summary: 1 error (**), 0 flaws (~~), 4 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: September 10, 2020 G. Van de Velde 6 Nokia 7 March 9, 2020 9 BGP Extended Community for Identifying the Target Node 10 draft-dong-idr-node-target-ext-comm-02 12 Abstract 14 BGP [RFC4271] has been used to distribute different types of routing 15 and policy information in the network. In some cases, the 16 information distributed may be only intended for one or several 17 particular receiving BGP nodes in the network. However, BGP does not 18 have a general mechanism of designating the receiving node of the 19 routing information. This document defines a new type of BGP 20 Extended Community called "Node Target". The mechanism of using the 21 Node 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 September 10, 2020. 47 Copyright Notice 49 Copyright (c) 2020 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. Such a targeting mechanism 85 would be useful that it can save the amount of TCAM. 87 However, BGP does not have a general mechanism of designating the 88 receiving nodes of the information to be distributed. Route Target 89 (RT) as defined in [RFC4364] is used for the distribution of VPN 90 routes into the target VPN Routing and Forwarding tables (VRFs) on a 91 set of PE nodes. Although it is possible to use RTs to control the 92 distribution of non VPN-specific information to particular receiving 93 nodes, such mechanism is not applicable when the information to be 94 distributed is VPN-specific and relies on RTs to match the target 95 VRF. Thus a mechanism which is independent from the control of VPN 96 route to VRF distribution is needed. 98 Another possible way is to configure, on each router, a community and 99 the corresponding policies to match the community to determine 100 whether to accept the received routes. Such mechanism relies on 101 manual configuration thus is considered error-prone. It is 102 preferable by some operators that an automatic approach can be 103 provided, which would be much easier and less error-prone. 104 [I-D.ietf-idr-segment-routing-te-policy] has already introduced an 105 automatic approach, but it can only be used along with SR Policy 106 SAFI. 108 This document defines a new type of BGP Extended Community called 109 "Node Target". The mechanism of using the Node Target extended 110 community to steer BGP route distribution to particular BGP nodes is 111 also specified. 113 2. Node Target Extended Communities 115 2.1. IPv4 Node Target Extended Community 117 For IPv4 networks, this section defines a new BGP Extended Community 118 [RFC4360] called "IPv4 Node Target Extended Community". It is a 119 transitive extended community with type 0x01 and sub-type TBA. 121 The format of IPv4 Node Target Extended Community is shown in 122 Figure 1. 124 0 1 2 3 125 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 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Type (0x01) | Sub-Type (TBA)| Target IPv4 Address | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Target IPv4 Address (cont.) | Reserved | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 Figure 1. IPv4 Node Target extended community 133 Target IPv4 address field(4 octets): A local IPv4 address of the 134 target node, the loopback address is preferred. When the target IPv4 135 address is set to 0.0.0.0, it means all the BGP nodes in the network 136 are the target nodes. 138 Reserved field(2 octets): Reserved for future use, MUST be set to 139 zero on transmission and ignored on receipt. 141 One or more IPv4 Node Target extended communities may be carried in a 142 BGP Update message. 144 2.2. IPv6 Node Target Extended Community 146 For IPv6 networks, a new IPv6 Address Specific BGP Extended Community 147 [RFC5701] called "IPv6 Node Target extended community" is defined. 148 It is a transitive IPv6 address specific extended community with type 149 0x00 and sub-type TBA. 151 The format of this extended community is shown in Figure 2. 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Type (0x00) | Sub-Type (TBA)| Target IPv6 Address | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Target IPv6 Address (cont.) | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Target IPv6 Address (cont.) | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Target IPv6 Address (cont.) | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Target IPv6 Address (cont.) | Reserved | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 Figure 2. IPv6 Node Target extended community 168 Target IPv6 address field(16 octets): A IPv6 address of the target 169 node, the loopback address is preferred. When the target IPv6 170 address is set to "0:0:0:0:0:0:0:0" ( :: ), it means all the BGP 171 nodes in the network are the target nodes. 173 Reserved field(2 octets): Reserved for future use, MUST be set to 174 zero on transmission and ignored on receipt. 176 One or more IPv6 Node Target extended communities may be carried in a 177 BGP Update message. 179 3. Procedures 181 In this version only the usage of the proposed mechanism in the 182 intra-AS scenario is described, more details about the inter-AS 183 scenario is for further study. 185 When a controller or BGP speaker plans to advertise some BGP 186 information only to some particular BGP nodes in the network, it MUST 187 put the IPv4 or IPv6 address of each target node into the IPv4 or 188 IPv6 Node Target extended communities, and attach the IPv4 or IPv6 189 Node Target extended communities to the BGP Update message to be 190 advertised. 192 If a non-RR BGP speaker receives a BGP Update message which contains 193 one or more IPv4 or IPv6 Node Target extended communities, it MUST 194 check the target IPv4 or IPv6 addresses carried in the extended 195 communities. 197 o If the target IPv4 or IPv6 address in any of the IPv4 or IPv6 Node 198 Target extended community matches with one of the local IP 199 addresses, the receiving BGP speaker is one of the target nodes of 200 the information in the Update, and the information in the Update 201 is eligible to be kept and installed by the receiving BGP speaker. 203 o If the target IPv4 or IPv6 address in any of the IPv4 or IPv6 Node 204 Target extended community does not match with any local IP 205 address, the receiving BGP speaker is not the target node of 206 information in the Update, the information in the received Update 207 message MUST not be used. 209 If a route-reflector (RR) receives a BGP Update message which 210 contains one or more IPv4 or IPv6 Node Target extended communities, 211 it MUST check the target IPv4 or IPv6 addresses carried in the IPv4 212 or IPv6 Node Target extended communities. 214 o If the target IPv4 or IPv6 address in any of the IPv4 or IPv6 Node 215 Target extended community matches with one of the local IP 216 addresses, this RR is one of the target nodes of information in 217 the Update, and such information is eligible to be kept and 218 installed by this RR. If there is no other IPv4 or IPv6 Node 219 Target extended communities in the Update, the RR MUST NOT 220 advertise the information in this Update further to its neighbors. 221 If there is other IPv4 or IPv6 Node Target extended communities, 222 the RR SHOULD first remove the local matched Node Target extended 223 community, then reflect the routes with the remaining Node Target 224 Extended Communities according to [RFC4456]. 226 o If the target IPv4 or IPv6 address in any of the IPv4 or IPv6 Node 227 target extended community does not match with any local IP 228 address, this RR is not the target node of routes in the Update, 229 the rules defined in [RFC4456] are used for the reflection of the 230 received route. 232 4. IANA Considerations 234 This document requests that IANA assigns one new sub-type for "IPv4 235 Node Target Extended Community" from the "Transitive IPv4-Address- 236 Specific Extended Community" registry of the "BGP Eextended 237 Communities" registry. 239 This document requests that IANA assigns one new type for "IPv6 Node 240 Target Extended Community" from the "Transitive IPv6-Address-Specific 241 Extended Community" registry of the "BGP Extended Communities" 242 registry. 244 5. Security Considerations 246 This document does not change the security properties of BGP. 248 6. Acknowledgements 250 The authors would like to thank Zhenbin Li, Ercin Torun and Haibo 251 Wang for the discussion and review of this document. 253 7. References 255 7.1. Normative References 257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 258 Requirement Levels", BCP 14, RFC 2119, 259 DOI 10.17487/RFC2119, March 1997, 260 . 262 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 263 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 264 DOI 10.17487/RFC4271, January 2006, 265 . 267 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 268 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 269 February 2006, . 271 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 272 Reflection: An Alternative to Full Mesh Internal BGP 273 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 274 . 276 [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community 277 Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009, 278 . 280 7.2. Informative References 282 [I-D.ietf-idr-rfc5575bis] 283 Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 284 Bacher, "Dissemination of Flow Specification Rules", 285 draft-ietf-idr-rfc5575bis-19 (work in progress), January 286 2020. 288 [I-D.ietf-idr-segment-routing-te-policy] 289 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 290 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 291 Routing Policies in BGP", draft-ietf-idr-segment-routing- 292 te-policy-08 (work in progress), November 2019. 294 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 295 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 296 2006, . 298 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 299 and D. McPherson, "Dissemination of Flow Specification 300 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 301 . 303 Authors' Addresses 305 Jie Dong 306 Huawei Technologies 307 Huawei Campus, No. 156 Beiqing Rd. 308 Beijing 100095 309 China 311 Email: jie.dong@huawei.com 313 Shunwan Zhuang 314 Huawei Technologies 315 Huawei Campus, No. 156 Beiqing Rd. 316 Beijing 100095 317 China 319 Email: zhuangshunwan@huawei.com 321 Gunter Van de Velde 322 Nokia 323 Antwerp 324 BE 326 Email: gunter.van_de_velde@nokia.com