idnits 2.17.1 draft-dong-idr-node-target-ext-comm-03.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 -- The document date (November 2, 2020) is 1264 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) == Unused Reference: 'RFC5575' is defined on line 289, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-idr-flow-spec-v6-18 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-09 -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) Summary: 0 errors (**), 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: May 6, 2021 G. Van de Velde 6 Nokia 7 November 2, 2020 9 BGP Extended Community for Identifying the Target Nodes 10 draft-dong-idr-node-target-ext-comm-03 12 Abstract 14 BGP has been used to distribute different types of routing and policy 15 information. In some cases, the information distributed may be only 16 intended for one or a particular group of BGP nodes in the network. 17 Currently BGP does not have a generic mechanism of designating the 18 target nodes of the routing information. This document defines a new 19 type of BGP Extended Community called "Node Target". The mechanism 20 of using the Node Target Extended Community to steer BGP route 21 distribution to particular BGP nodes is specified. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 6, 2021. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Node Target Extended Communities . . . . . . . . . . . . . . 3 65 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Compatibility Considerations . . . . . . . . . . . . . . . . 5 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 69 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 5 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 73 9.2. Informative References . . . . . . . . . . . . . . . . . 6 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 76 1. Introduction 78 BGP [RFC4271] has been used to distribute different types of routing 79 and policy information. In some cases, the information distributed 80 may be only intended for one or a particular group receiving BGP 81 nodes in the network. One typical use case is the distribution of 82 BGP Flow Spec [I-D.ietf-idr-rfc5575bis] [I-D.ietf-idr-flow-spec-v6] 83 rules only to a particular group of BGP nodes. Such a targeting 84 mechanism is considered useful that it can save the resources on 85 nodes which do not need that information. 87 Currently BGP does not have a generic mechanism of designating the 88 set of nodes to which the information is to be distributed. Route 89 Target (RT) as defined in [RFC4364] was designed for the matching of 90 VPN routes into the target VPN Routing and Forwarding tables (VRFs) 91 on PE nodes. Although [I-D.ietf-idr-segment-routing-te-policy] 92 introduces the mechanism of steering the SR policy information to the 93 target head end node based on RT, it is only defined for the SR 94 Policy Address Family. Although it is possible to reuse RTs to 95 control the distribution of non-VPN information to one or a group of 96 receiving nodes, such mechanism is not applicable when the 97 information to be distributed is VPN-specific and is advertised with 98 a set of RTs for the VRF matching. In that case, the matching of any 99 of the VPN RTs in the Update will result in the information eligible 100 for installation, regardless of whether the RTs representing the 101 target nodes are matched or not. Thus a mechanism which is 102 independent from the control of VPN route to VRF distribution is 103 needed. 105 Another possible approach is to configure, on each router, a 106 community and the corresponding policies to match the community to 107 determine whether to accept the received routes. Such mechanism 108 relies on manual configuration thus is considered error-prone. It is 109 preferable by some operators that an automatic approach can be 110 provided, which would make the operation much easier. 112 This document defines a new type of BGP Extended Community called 113 "Node Target". The mechanism of using the Node Target extended 114 community to steer BGP route distribution to particular BGP nodes is 115 also specified. 117 2. Node Target Extended Communities 119 This section defines a new BGP Extended Community [RFC4360] called 120 "Node Target Extended Community". It can be a transitive extended 121 community with the high-order octect of the type set to 0x01, or a 122 non-transitive extended community with the high-order octect type set 123 to 0x41. The sub-type of the Node Target Extended Community is TBA. 125 The format of Node Target Extended Community is shown in Figure 1. 127 0 1 2 3 128 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 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | 0x01 or 0x41 | Sub-Type(TBA) | Target BGP Identifier | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Target BGP Identifier (cont.) | Reserved | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 Figure 1. Node Target extended community 137 Where: 139 Target BGP Identifier (4 octets): The BGP Identifier of a target 140 node. It is a 4-octet, unsigned, non-zero integer as defined in 141 [RFC6286]. 143 Reserved field (2 octets): Reserved for future use, MUST be set to 144 zero on transmission and ignored on receipt. 146 One or more Node Target extended communities MAY be carried in an 147 Update message to designate a group of target BGP nodes. 149 3. Procedures 151 In this section, the mechanism for intra-domain scenario is 152 described, the mechanism for inter-domain scenario is for further 153 study. The domain here refers to an administrative domain, which may 154 consists of one or multiple ASes managed by a single operator. 156 When a network controller or BGP speaker plans to advertise some BGP 157 routing or policy information only to one or a group of BGP nodes in 158 the network, it MUST put the BGP Identifier of each target node into 159 the Node Target extended communities, and attach the Node Target 160 extended communities to the routes or policies to be advertised. 162 When a BGP speaker receives a BGP Update which contains one or more 163 Node Target extended communities, it MUST check the target BGP 164 Identifiers carried in the Node Target extended communities of the 165 Update. 167 o If the target BGP Identifier in any of the Node Target extended 168 community matches with the local BGP Identifier, this node is one 169 of the target nodes of the Update, the information in the Update 170 is eligible to be kept and installed on this node. 172 * If this node is a Route Reflector, and in the Update there is 173 one or more Node Target extended communities which contains 174 non-local BGP Identifiers, information in the Update are 175 eligible be reflected to its peers according to the rules 176 defined in [RFC4456]. The RR may check the BGP Identifiers of 177 its peers to determine the set of peers which are the target 178 nodes of the Update, and only reflect the information in the 179 Update to the matched BGP peers. 181 * If this node is an Autonomous System Border Router (ASBR), and 182 the BGP Identifiers of one or more of its EBGP peers match with 183 the Node Target extended communities in the Update, information 184 in the Update is eligible to be advertised to the matched EBGP 185 peers. 187 o If the target BGP Identifier in any of the Node target extended 188 community does not match with the local BGP Identifier, this node 189 is not the target node of Update, the information in the Update is 190 not eligible to be installed on this node. 192 * If this node is a Route Reflector, information in the Update is 193 eligible to be reflected to its peers according to the rules 194 defined in [RFC4456]. The RR may check the BGP Identifiers of 195 its peers to determine the set of peers which are the target 196 nodes of the Update, and only reflect the information in the 197 Update to the matched BGP peers. 199 4. Compatibility Considerations 201 The Node Target extended community introduced in this document can be 202 deployed incrementally in the network. For BGP speakers which 203 understand the Node Target extended community, it is used to 204 determine whether the nodes are the target nodes of the Update. For 205 BGP speakers which do not understand the Node Target extended 206 community, it will be ignored and the information in the Update will 207 be processed and advertised based on normal BGP procedure. Although 208 this could ensure that the target nodes can always obtain the 209 information needed, this may result in unnecessary state maintained 210 on legacy BGP speakers. And if the information advertised is the 211 Flow Spec rules, the legacy BGP speakers may install unnecessary 212 flowspec rules, this may have impact on traffic which matches such 213 rules, thus may result in unexpected traffic steering or filtering 214 behaviors on such nodes. This may be mitigated by setting 215 appropriate routing policies on the legacy BGP nodes. 217 5. IANA Considerations 219 This document requests that IANA assigns one new sub-type for "Node 220 Target Extended Community" from the "Transitive IPv4-Address-Specific 221 Extended Community" registry of the "BGP Eextended Communities" 222 registry. 224 This document requests that IANA assigns the same sub-type for "Node 225 Target Extended Community" from the "Non-Transitive IPv4-Address- 226 Specific Extended Community" registry of the "BGP Eextended 227 Communities" registry. 229 6. Security Considerations 231 This document does not change the security properties of BGP. 233 7. Contributors 235 Haibo Wang 236 Email: rainsword.wang@huawei.com 238 8. Acknowledgements 240 The authors would like to thank Zhenbin Li, Ercin Torun, Jeff Haas 241 and Robert Raszuk for the review and discussion of this document. 243 9. References 245 9.1. Normative References 247 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 248 Requirement Levels", BCP 14, RFC 2119, 249 DOI 10.17487/RFC2119, March 1997, 250 . 252 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 253 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 254 DOI 10.17487/RFC4271, January 2006, 255 . 257 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 258 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 259 February 2006, . 261 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 262 Reflection: An Alternative to Full Mesh Internal BGP 263 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 264 . 266 9.2. Informative References 268 [I-D.ietf-idr-flow-spec-v6] 269 Loibl, C., Raszuk, R., and S. Hares, "Dissemination of 270 Flow Specification Rules for IPv6", draft-ietf-idr-flow- 271 spec-v6-18 (work in progress), November 2020. 273 [I-D.ietf-idr-rfc5575bis] 274 Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 275 Bacher, "Dissemination of Flow Specification Rules", 276 draft-ietf-idr-rfc5575bis-27 (work in progress), October 277 2020. 279 [I-D.ietf-idr-segment-routing-te-policy] 280 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 281 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 282 Routing Policies in BGP", draft-ietf-idr-segment-routing- 283 te-policy-09 (work in progress), May 2020. 285 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 286 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 287 2006, . 289 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 290 and D. McPherson, "Dissemination of Flow Specification 291 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 292 . 294 [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP 295 Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, 296 June 2011, . 298 Authors' Addresses 300 Jie Dong 301 Huawei Technologies 302 Huawei Campus, No. 156 Beiqing Rd. 303 Beijing 100095 304 China 306 Email: jie.dong@huawei.com 308 Shunwan Zhuang 309 Huawei Technologies 310 Huawei Campus, No. 156 Beiqing Rd. 311 Beijing 100095 312 China 314 Email: zhuangshunwan@huawei.com 316 Gunter Van de Velde 317 Nokia 318 Antwerp 319 BE 321 Email: gunter.van_de_velde@nokia.com