idnits 2.17.00 (12 Aug 2021) /tmp/idnits27118/draft-liang-idr-bgp-flowspec-route-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 -- The document date (October 20, 2014) is 2770 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 normative reference: RFC 3107 (Obsoleted by RFC 8277) ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) == Outdated reference: A later version (-02) exists of draft-ietf-idr-flowspec-redirect-ip-01 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Idr Working Group Q. Liang 3 Internet-Draft J. You 4 Intended status: Standards Track Huawei 5 Expires: April 23, 2015 October 20, 2014 7 BGP FlowSpec based Multi-dimensional Route Distribution 8 draft-liang-idr-bgp-flowspec-route-00 10 Abstract 12 This document proposes a BGP FlowSpec (Border Gateway Protocol Flow 13 Specification) based multi-dimensional routes distribution method. 15 Requirements Language 17 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 18 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 19 document are to be interpreted as described in [RFC2119]. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 23, 2015. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Network Load Balancing . . . . . . . . . . . . . . . . . 3 57 1.2. Network Diagnostics . . . . . . . . . . . . . . . . . . . 3 58 1.3. Flow-based Policy Deployment . . . . . . . . . . . . . . 3 59 1.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. BGP FlowSpec based Multi-dimensional Route . . . . . . . . . 4 62 3.1. Nexthop Information . . . . . . . . . . . . . . . . . . . 4 63 3.2. Carrying Label Mapping Information . . . . . . . . . . . 5 64 4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.1. FlowSpec Route Preference . . . . . . . . . . . . . . . . 6 66 4.2. FlowSpec Route Conflict . . . . . . . . . . . . . . . . . 7 67 4.3. Multicast for Multi-dimensional Route . . . . . . . . . . 7 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 6. Security considerations . . . . . . . . . . . . . . . . . . . 7 70 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 8.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 [RFC5575] defines the flow specification (FlowSpec) that is an 79 n-tuple consisting of several matching criteria that can be applied 80 to IP traffic. The matching criteria can include elements such as 81 source and destination address prefixes, IP protocol, and transport 82 protocol port numbers. A given IP packet is said to match the 83 defined flow if it matches all the specified criteria. [RFC5575] 84 also defines filtering actions, such as rate limit, redirect, 85 marking, associated with each flow specification. A new Border 86 Gateway Protocol Network Layer Reachability Information (BGP NLRI) 87 (AFI/SAFI: 1/133 for IPv4, AFI/SAFI: 1/134 for VPNv4) encoding format 88 is used to distribute traffic flow specifications. 90 Actually, flow specification can precisely identify a particular 91 traffic flow. It is quite appropriate to describe a multi- 92 dimensional route. In the following subsections, we discuss the use 93 cases for FlowSpec based multi-dimensional route. 95 1.1. Network Load Balancing 97 Traditional routers forward traffic according to destination IP 98 address or MAC address. The operational granularity on the traffic 99 is coarse and limited. However, by using multi-dimensional route, 100 multiple fields of the packet header (such as source and destination 101 address prefixes, IP protocol, and transport protocol port numbers) 102 can be used to identify an operational flow. For example, routers 103 can hash the multi-dimensional routes with the same destination 104 through different paths. Therefore, the traffic can be 105 differentiated or managed in a finer granularity. For example, when 106 the congestion is detected at some link, it can transfer some traffic 107 to other links by adjusting the multi-dimensional routes. This can 108 optimize the network load balancing. 110 1.2. Network Diagnostics 112 Traditional IP prefix or MAC based routes may aggregate the traffic 113 that has different sources or service classes to the same link. This 114 is difficult for traffic statistics for a particular flow in the 115 network. However, multi-dimensional route can solve these issues 116 such as packet loss location, traffic tracking, as it can precisely 117 identify a particular flow. 119 1.3. Flow-based Policy Deployment 121 When using FlowSpec based multi-dimensional routes, it is more 122 flexible and precise to deploy the flow-based policies in the 123 network. For example, if router X wants to specify an explicit path 124 for a particular traffic (e.g. source address = A, destination 125 address = B), and to reserve the bandwidth through this path, this 126 can be implemented by using multi-dimensional routes. 128 1.4. Summary 130 Especially in the data center network, campus network and service 131 provider networks, it's more and more important for the refined 132 management of the network traffic. 134 The BGP FlowSpec based multi-dimensional route method proposed in 135 this document can make use of the current widely deployed BGP 136 protocol. As the multi-dimensional route usually cannot aggregate, 137 meanwhile it has long matching key and consumes more space in the 138 forwarding table, it is not meant to substitute the IP prefix/MAC 139 based route. It can be regarded as a complementary routing tool for 140 the traffic flow that having special requirements. Besides, using a 141 dynamic multi-dimensional route distribution method can replace the 142 traditional management approach (i.e. configuring policy-based routes 143 on the associated nodes in the network). It helps the automatic 144 deployments for the policy-based routes and facilitates the route 145 management. 147 Similar to IP prefix based L3 routing table, or MAC address based L2 148 forwarding table, FlowSpec can be regarded as a special network 149 reachability information identity, which can be distributed by BGP. 150 Such multi-dimensional route in this document also can be called as 151 FlowSpec route. 153 2. Terminology 155 This section contains definitions of terms used in this document. 157 Flow Specification (FlowSpec): A flow specification is an n-tuple 158 consisting of several matching criteria that can be applied to IP 159 traffic, including filters and actions. Each FlowSpec consists of 160 a set of filters and a set of actions. 162 3. BGP FlowSpec based Multi-dimensional Route 164 3.1. Nexthop Information 166 [RFC5575] defines a "Flow Specification" NLRI type that is encoded 167 using MP_REACH_NLRI and MP_UNREACH_NLRI attributes as defined in 168 [RFC4760]. Whenever the corresponding application does not require 169 Next-Hop information, this shall be encoded as a 0-octet length Next 170 Hop in the MP_REACH_NLRI attribute and ignored on receipt. 172 However, for FlowSpec route defined in this document, nexthop 173 information is required to be included. When included, the filtering 174 actions [RFC5575] standardized as BGP extended community values 175 [RFC4360] are also valid. Besides, if the FlowSpec route is the 176 preferred one, it also determines the forwarding path of the packet 177 that matches this FlowSpec route. Therefore, several forwarding 178 paths from one node or multi ingress nodes to one egress node would 179 be generated by distributing the FlowSpec routes on the forwarding 180 devices in the network. 182 The nexthop information contains the network address (expressed as an 183 IP address) of the next router on the path to the destination system. 184 The FlowSpec routes received from a BGP peer and that are accepted in 185 the respective Adj-RIB-In are used as input to the route selection 186 process. The selected FlowSpec routes will be added into the 187 FlowSpec routing table as new entries that are used to steer the 188 packets in the data plane. Meanwhile, the routers also can do 189 network traffic statistics based on FlowSpec routes. 191 [RFC5575] defines a redirect action that allows the traffic to be 192 redirected to a VRF (virtual routing and forwarding) routing instance 193 that lists the specified route-target in its import policy. 194 [I-D.ietf-idr-flowspec-redirect-ip] defines a redirect-to-IP FlowSpec 195 action that provides a method of policy-based forwarding. If a 196 FlowSpec route carries a combination of 'redirect to IP' and 197 'redirect to VRF' extended communities, the BGP speaker SHOULD apply 198 the 'redirect to IP' actions in the context of the 'target VRF', i.e. 199 the BGP speaker redirects the matching packets or copies them towards 200 the IPv4 or IPv6 address in the extended community's global 201 administrator field (the 'target address'). 203 The difference of the redirect and nexthop is that the former 204 specifies the termination point however the latter specifies the next 205 processing node. The redirect information is transitive but not 206 changeable normally, i.e. the packets that match the FlowSpec routes 207 on the different routers will be redirected to the same remote 208 device. The nexthop information [RFC4760] is usually the local IP 209 address of the router that disseminates this FlowSpec route, or the 210 IP address of some remote forwarding device. The receiving router 211 will do route iteration based on the nexthop information for 212 obtaining the actual nexthop information. The next-hop can be 213 changed according to the local explicit or default route policy. 215 3.2. Carrying Label Mapping Information 217 [RFC3107] specifies the way in which the label mapping information 218 for a particular route is piggybacked in the same Border Gateway 219 Protocol Update message that is used to distribute the route itself. 220 Label mapping information is carried as part of the Network Layer 221 Reachability Information (NLRI) in the Multiprotocol Extensions 222 attributes. The Network Layer Reachability Information is encoded as 223 one or more triples of the form . The fact 224 that the NLRI contains a label is indicated by using SAFI value 4. 226 [RFC4364] describes a method in which each route within a VPN is 227 assigned a Multiprotocol Label Switching (MPLS) label. If the 228 Address Family Identifier (AFI) field is set to 1, and the Subsequent 229 Address Family Identifier (SAFI) field is set to 128, the NLRI is an 230 MPLS-labeled VPN-IPv4 address. 232 In this document, BGP is used to distribute a particular FlowSpec 233 route, it can also be used to distribute one or more MPLS labels that 234 are mapped to that FlowSpec route. The Network Layer Reachability 235 Information for FlowSpec route is encoded as one or more triples of 236 the form , whose fields are described below. 238 The values for AFI/SAFI used to indicate the NLRI containing a label 239 associated with a FlowSpec route are TBD. For example, SAFI Code 240 (TBD1) for FlowSpec mapping label(s), and SAFI Code (TBD2) for VPN 241 FlowSpec mapping label(s). 243 +---------------------------+ 244 | Length (1 octet) | 245 +---------------------------+ 246 | Label (3 octets) | 247 +---------------------------+ 248 ............................. 249 +---------------------------+ 250 | FlowSpec (variable) | 251 +---------------------------+ 253 The use and the meaning of these fields are as follows: 255 Length: The Length field indicates the length in bits of the flow 256 filters plus the label(s). 258 Label: The Label field carries one or more labels (that 259 corresponds to the stack of labels [RFC3032]). Each label is 260 encoded as 3 octets, where the high-order 20 bits contain the 261 label value, and the low order bit contains "Bottom of Stack" 262 [RFC3032]. 264 FlowSpec: The FlowSpec field is the same as "flow-spec NLRI value" 265 defined in [RFC5575]. When SAFI value is TBD1, the field contains 266 flow filters, and when SAFI value is TBD2, the field contains a 267 route distinguisher and flow filters. 269 For FlowSpec route which is associated with multiple fields of the 270 packet header, label-based forwarding can effectively improve the 271 route lookup performance in the data plane. When FlowSpec routes on 272 multiple forwarding devices in the network binding the labels which 273 makes up one or more LSPs, only the ingress LSR (Label Switching 274 Router) needs to identify a particular traffic flow based on the 275 matching criteria and then steer the packet to a corresponding LSP 276 (Label Switched Path). Other LSRs of the LSP just need to forward 277 the packet according to the label carried in it. 279 4. Open Issues 281 4.1. FlowSpec Route Preference 283 The route preference for FlowSpec route is separate from the 284 traditional IP prefix/MAC route. When the IP packet matching both 285 the FlowSpec route and traditional IP prefix/MAC route, then the 286 FlowSpec route would have higher preference. 288 4.2. FlowSpec Route Conflict 290 The FlowSpec route is compliant with [RFC5575], including the 291 constraint description for FlowSpec features. If the feature value 292 space of the different FlowSpec routes overlaps, then it is an error. 294 4.3. Multicast for Multi-dimensional Route 296 TBD 298 5. IANA Considerations 300 The values for AFI/SAFI used to indicate the NLRI containing a label 301 associated with a FlowSpec route need to be allocated by IANA. For 302 example, SAFI Code (TBD1) for FlowSpec mapping label(s), and SAFI 303 Code (TBD2) for VPN FlowSpec mapping label(s). 305 6. Security considerations 307 This extension to BGP does not change the underlying security issues 308 inherent in the existing BGP. 310 7. Acknowledgement 312 TBD. 314 8. References 316 8.1. Normative References 318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 319 Requirement Levels", BCP 14, RFC 2119, March 1997. 321 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 322 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 323 Encoding", RFC 3032, January 2001. 325 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 326 BGP-4", RFC 3107, May 2001. 328 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 329 Communities Attribute", RFC 4360, February 2006. 331 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 332 Networks (VPNs)", RFC 4364, February 2006. 334 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 335 "Multiprotocol Extensions for BGP-4", RFC 4760, January 336 2007. 338 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 339 and D. McPherson, "Dissemination of Flow Specification 340 Rules", RFC 5575, August 2009. 342 8.2. Informative References 344 [I-D.ietf-idr-flowspec-redirect-ip] 345 Uttaro, J., Haas, J., Texier, M., Andy, A., Simpson, A., 346 and W. Henderickx, "BGP Flow-Spec Redirect to IP Action", 347 draft-ietf-idr-flowspec-redirect-ip-01 (work in progress), 348 April 2014. 350 Authors' Addresses 352 Qiandeng Liang 353 Huawei 354 101 Software Avenue, Yuhuatai District 355 Nanjing, 210012 356 China 358 Email: liuweihang@huawei.com 360 Jianjie You 361 Huawei 362 101 Software Avenue, Yuhuatai District 363 Nanjing, 210012 364 China 366 Email: youjianjie@huawei.com