idnits 2.17.1 draft-dong-idr-node-target-ext-comm-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 : ---------------------------------------------------------------------------- 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 (March 5, 2018) is 2244 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) -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) Summary: 0 errors (**), 0 flaws (~~), 2 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 6, 2018 G. Van de Velde 6 Nokia 7 March 5, 2018 9 BGP Extended Community for Identifying the Target Node 10 draft-dong-idr-node-target-ext-comm-00 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. BGP does not have a general 18 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 and 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 September 6, 2018. 47 Copyright Notice 49 Copyright (c) 2018 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 . . . . . . . . . . . 3 68 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 74 7.2. Informative References . . . . . . . . . . . . . . . . . 6 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 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] policies to some 84 particular BGP nodes. 86 BGP does not have a general mechanism for designating the receiving 87 nodes of the information to be distributed. Route Target (RT) as 88 defined in [RFC4364] is used for the distribution of VPN routes into 89 the target VPN Routing and Forwarding tables (VRFs) on a set of PE 90 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 new mechanism is needed to control the distribution of 95 BGP information to particular BGP nodes, which is independent from 96 the control of VPN route distribution to VRF. 98 2. Node Target Extended Communities 100 2.1. IPv4 Node Target Extended Community 102 For IPv4 networks, this section defines a new BGP extended community 103 [RFC4360] called "IPv4 Node Target Extended Community". It is a 104 transitive extended community with type 0x01 and sub-type TBA. 106 The format of IPv4 Node Target Extended Community is shown in 107 Figure 1. 109 0 1 2 3 110 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 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Type (0x01) | Sub-Type (TBA)| Target IPv4 Address | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | Target IPv4 Address (cont.) | Reserved | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 Figure 1. IPv4 Node Target extended community 118 Target IPv4 address field: A local IPv4 address of the target node. 119 When the target IPv4 address is set to 0.0.0.0, it means all the BGP 120 nodes in the network are the target nodes. 122 Reserved field: Reserved for future use, MUST be set to zero on 123 transmission and ignored on receipt. 125 One or more IPv4 Node Target extended communities may be carried in a 126 BGP Update message. 128 2.2. IPv6 Node Target Extended Community 130 For IPv6 networks, a new IPv6 Address Specific BGP Extended Community 131 [RFC5701] called "IPv6 Node Target extended community" is defined. 132 It is a transitive IPv6 address specific extended community with type 133 0x00 and sub-type TBA. 135 The format of this extended community is shown in Figure 2. 137 0 1 2 3 138 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 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Type (0x00) | Sub-Type (TBA)| Target IPv6 Address | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Target IPv6 Address (cont.) | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Target IPv6 Address (cont.) | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Target IPv6 Address (cont.) | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Target IPv6 Address (cont.) | Reserved | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 Figure 2. IPv6 Node Target extended community 152 Target IPv6 address field: A IPv6 address of the target node. When 153 the target IPv6 address is set to "0:0:0:0:0:0:0:0" ( :: ), it means 154 all the BGP nodes in the network are the target nodes. 156 Reserved field: Reserved for future use, MUST be set to zero on 157 transmission and ignored on receipt. 159 One or more IPv6 Node Target extended communities may be carried in a 160 BGP Update message. 162 3. Procedures 164 In this version only the usage of the proposed mechanism in the 165 intra-AS scenario is described, more details about the inter-AS 166 scenario is for further study. 168 When a controller or BGP speaker plans to advertise some BGP 169 information only to some particular BGP nodes in the network, it MUST 170 put the IPv4 or IPv6 address of each target node into the IPv4 or 171 IPv6 Node Target extended communities, and attach the IPv4 or IPv6 172 Node Target extended communities to the BGP Update message to be 173 advertised. 175 If a non-RR BGP speaker receives an Update message which contains one 176 or more IPv4 or IPv6 Node Target extended communities, it MUST check 177 the target IPv4 or IPv6 addresses carried in the extended 178 communities. 180 o If the target IPv4 or IPv6 address in any of the IPv4 or IPv6 Node 181 Target extended community matches with one of the local IP 182 addresses, the receiving BGP speaker is one of the target nodes of 183 the information in the Update, and the information in the Update 184 is eligible to be kept and installed by the receiving BGP speaker. 186 o If the target IPv4 or IPv6 address in any of the IPv4 or IPv6 Node 187 Target extended community does not match with any local IP 188 address, the receiving BGP speaker is not the target node of 189 information in the Update, the information in the received Update 190 message MUST not be used. 192 If a route-reflector (RR) receives an BGP Update message which 193 contains one or more IPv4 or IPv6 Node Target extended communities, 194 it MUST check the target IPv4 or IPv6 addresses carried in the IPv4 195 or IPv6 Node Target extended 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, this RR is one of the target nodes of information in 200 the Update, and such information is eligible to be kept and 201 installed by this RR. If there is no other IPv4 or IPv6 Node 202 Target extended communities in the Update, the RR MUST NOT 203 advertise the information in this Update further to its neighbors. 204 If there is other IPv4 or IPv6 Node Target extended communities, 205 the RR SHOULD first remove the local matched Node Target extended 206 community, then reflect the routes with the remaining Node Target 207 Extended Communities according to [RFC4456]. 209 o If the target IPv4 or IPv6 address in any of the IPv4 or IPv6 Node 210 target extended community does not match with any local IP 211 address, this RR is not the target node of routes in the Update, 212 the rules defined in [RFC4456] are used for the reflection of the 213 received route. 215 4. IANA Considerations 217 This document requests that IANA assigns one new sub-type for "IPv4 218 Node Target extended community" from the "Transitive IPv4-Address- 219 Specific Extended Community" registry of the "BGP extended 220 communities" registry. 222 This document requests that IANA assigns one new type for "IPv6 Node 223 Target extended community" from the "Transitive IPv6-Address-Specific 224 Extended Community" registry of the "BGP extended communities" 225 registry. 227 5. Security Considerations 229 This document does not change the security properties of BGP. 231 6. Acknowledgements 233 The authors would like to thank Zhenbin Li for the discussion and 234 review of this document. 236 7. References 238 7.1. Normative References 240 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 241 Requirement Levels", BCP 14, RFC 2119, 242 DOI 10.17487/RFC2119, March 1997, 243 . 245 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 246 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 247 DOI 10.17487/RFC4271, January 2006, 248 . 250 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 251 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 252 February 2006, . 254 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 255 Reflection: An Alternative to Full Mesh Internal BGP 256 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 257 . 259 [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community 260 Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009, 261 . 263 7.2. Informative References 265 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 266 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 267 2006, . 269 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 270 and D. McPherson, "Dissemination of Flow Specification 271 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 272 . 274 Authors' Addresses 275 Jie Dong 276 Huawei Technologies 277 Huawei Campus, No. 156 Beiqing Rd. 278 Beijing 100095 279 China 281 Email: jie.dong@huawei.com 283 Shunwan Zhuang 284 Huawei Technologies 285 Huawei Campus, No. 156 Beiqing Rd. 286 Beijing 100095 287 China 289 Email: zhuangshunwan@huawei.com 291 Gunter Van de Velde 292 Nokia 293 Antwerp 294 BE 296 Email: gunter.van_de_velde@nokia.com