idnits 2.17.1 draft-dong-idr-node-target-ext-comm-04.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 (July 12, 2021) is 1019 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 278, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-11 -- 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 13, 2022 G. Van de Velde 6 Nokia 7 July 12, 2021 9 BGP Extended Community for Identifying the Target Nodes 10 draft-dong-idr-node-target-ext-comm-04 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 January 13, 2022. 46 Copyright Notice 48 Copyright (c) 2021 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 [RFC8955] [RFC8956] rules only to a particular group of 83 BGP nodes. Such a targeting mechanism is considered useful that it 84 can save the resources on nodes which do not need that information. 86 Currently BGP does not have a generic mechanism of designating the 87 set of nodes to which the information is to be distributed. Route 88 Target (RT) as defined in [RFC4364] was designed for the matching of 89 VPN routes into the target VPN Routing and Forwarding tables (VRFs) 90 on PE nodes. Although [I-D.ietf-idr-segment-routing-te-policy] 91 introduces the mechanism of steering the SR policy information to the 92 target head end node based on RT, it is only defined for the SR 93 Policy Address Family. Although it is possible to reuse RTs to 94 control the distribution of non-VPN information to one or a group of 95 receiving nodes, such mechanism is not applicable when the 96 information to be distributed is VPN-specific and is advertised with 97 a set of RTs for the VRF matching. In that case, the matching of any 98 of the VPN RTs in the Update will result in the information eligible 99 for installation, regardless of whether the RTs representing the 100 target nodes are matched or not. Thus a mechanism which is 101 independent from the control of VPN route to VRF distribution is 102 needed. 104 Another possible approach is to configure, on each router, a 105 community and the corresponding policies to match the community to 106 determine whether to accept the received routes. Such mechanism 107 relies on manual configuration thus is considered error-prone. It is 108 preferable by some operators that an automatic approach can be 109 provided, which would make the operation much easier. 111 This document defines a new type of BGP Extended Community called 112 "Node Target". The mechanism of using the Node Target extended 113 community to steer BGP route distribution to particular BGP nodes is 114 also specified. 116 2. Node Target Extended Communities 118 This section defines a new BGP Extended Community [RFC4360] called 119 "Node Target Extended Community". It can be a transitive extended 120 community with the high-order octect of the type set to 0x01, or a 121 non-transitive extended community with the high-order octect type set 122 to 0x41. The sub-type of the Node Target Extended Community is TBA. 124 The format of Node Target Extended Community is shown in Figure 1. 126 0 1 2 3 127 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 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | 0x01 or 0x41 | Sub-Type(TBA) | Target BGP Identifier | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Target BGP Identifier (cont.) | Reserved | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 Figure 1. Node Target extended community 136 Where: 138 Target BGP Identifier (4 octets): The BGP Identifier of a target 139 node. It is a 4-octet, unsigned, non-zero integer as defined in 140 [RFC6286]. 142 Reserved field (2 octets): Reserved for future use, MUST be set to 143 zero on transmission and ignored on receipt. 145 One or more Node Target extended communities MAY be carried in an 146 Update message to designate a group of target BGP nodes. 148 3. Procedures 150 In this section, the mechanism for intra-domain scenario is 151 described, the mechanism for inter-domain scenario is for further 152 study. The domain here refers to an administrative domain, which may 153 consists of one or multiple ASes managed by a single operator. 155 When a network controller or BGP speaker plans to advertise some BGP 156 routing or policy information only to one or a group of BGP nodes in 157 the network, it MUST put the BGP Identifier of each target node into 158 the Node Target extended communities, and attach the Node Target 159 extended communities to the routes or policies to be advertised. 161 When a BGP speaker receives a BGP Update which contains one or more 162 Node Target extended communities, it MUST check the target BGP 163 Identifiers carried in the Node Target extended communities of the 164 Update. 166 o If the target BGP Identifier in any of the Node Target extended 167 community matches with the local BGP Identifier, this node is one 168 of the target nodes of the Update, the information in the Update 169 is eligible to be kept and installed on this node. 171 * If this node is a Route Reflector, and in the Update there is 172 one or more Node Target extended communities which contains 173 non-local BGP Identifiers, information in the Update are 174 eligible be reflected to its peers according to the rules 175 defined in [RFC4456]. Depends on a configurable policy, the RR 176 MAY check the BGP Identifiers of its peers to determine the set 177 of peers which are the target nodes of the Update, and only 178 reflect the information in the Update to the matched BGP peers. 180 * If this node is an Autonomous System Border Router (ASBR), and 181 the BGP Identifiers of one or more of its EBGP peers match with 182 the Node Target extended communities in the Update, information 183 in the Update is eligible to be advertised to the matched EBGP 184 peers. 186 o If the target BGP Identifier in any of the Node target extended 187 community does not match with the local BGP Identifier, this node 188 is not the target node of Update, the information in the Update is 189 not eligible to be installed on this node. 191 * If this node is a Route Reflector, information in the Update is 192 eligible to be reflected to its peers according to the rules 193 defined in [RFC4456]. Depends on a configurable policy, the RR 194 MAY check the BGP Identifiers of its peers to determine the set 195 of peers which are the target nodes of the Update, and only 196 reflect the information in the Update to the matched BGP peers. 198 4. Compatibility Considerations 200 The Node Target extended community introduced in this document can be 201 deployed incrementally in the network. For BGP speakers which 202 understand the Node Target extended community, it is used to 203 determine whether the nodes are the target nodes of the Update. For 204 BGP speakers which do not understand the Node Target extended 205 community, it will be ignored and the information in the Update will 206 be processed and advertised based on normal BGP procedure. Although 207 this could ensure that the target nodes can always obtain the 208 information needed, this may result in unnecessary state maintained 209 on legacy BGP speakers. And if the information advertised is the 210 Flow Spec rules, the legacy BGP speakers may install unnecessary 211 flowspec rules, this may have impact on traffic which matches such 212 rules, thus may result in unexpected traffic steering or filtering 213 behaviors on such nodes. This may be mitigated by setting 214 appropriate routing policies on the legacy BGP nodes. 216 5. IANA Considerations 218 This document requests that IANA assigns one new sub-type for "Node 219 Target Extended Community" from the "Transitive IPv4-Address-Specific 220 Extended Community" registry of the "BGP Eextended Communities" 221 registry. 223 This document requests that IANA assigns the same sub-type for "Node 224 Target Extended Community" from the "Non-Transitive IPv4-Address- 225 Specific Extended Community" registry of the "BGP Eextended 226 Communities" registry. 228 6. Security Considerations 230 TBD 232 7. Contributors 234 Haibo Wang 235 Email: rainsword.wang@huawei.com 237 8. Acknowledgements 239 The authors would like to thank Zhenbin Li, Ercin Torun, Jeff Haas, 240 Robert Raszuk and John Scudder for the review and discussion of this 241 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-segment-routing-te-policy] 269 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 270 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 271 Routing Policies in BGP", draft-ietf-idr-segment-routing- 272 te-policy-11 (work in progress), November 2020. 274 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 275 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 276 2006, . 278 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 279 and D. McPherson, "Dissemination of Flow Specification 280 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 281 . 283 [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP 284 Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, 285 June 2011, . 287 [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 288 Bacher, "Dissemination of Flow Specification Rules", 289 RFC 8955, DOI 10.17487/RFC8955, December 2020, 290 . 292 [RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., 293 "Dissemination of Flow Specification Rules for IPv6", 294 RFC 8956, DOI 10.17487/RFC8956, December 2020, 295 . 297 Authors' Addresses 299 Jie Dong 300 Huawei Technologies 301 Huawei Campus, No. 156 Beiqing Rd. 302 Beijing 100095 303 China 305 Email: jie.dong@huawei.com 307 Shunwan Zhuang 308 Huawei Technologies 309 Huawei Campus, No. 156 Beiqing Rd. 310 Beijing 100095 311 China 313 Email: zhuangshunwan@huawei.com 315 Gunter Van de Velde 316 Nokia 317 Antwerp 318 BE 320 Email: gunter.van_de_velde@nokia.com