idnits 2.17.1 draft-liang-idr-bgp-flowspec-label-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 5, 2015) is 3212 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) 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: January 6, 2016 July 5, 2015 7 Carrying Label Information for BGP FlowSpec 8 draft-liang-idr-bgp-flowspec-label-00 10 Abstract 12 This document specifies a method in which the label mapping 13 information for a particular FlowSpec rule is piggybacked in the same 14 Border Gateway Protocol (BGP) Update message that is used to 15 distribute the FlowSpec rule. Based on the proposed method, the 16 Label Switching Routers (LSRs) (except the ingress LSR) on the Label 17 Switched Path (LSP) can use label to indentify the traffic matching a 18 particular FlowSpec rule; this facilitates monitoring and traffic 19 statistics for FlowSpec rules. Meanwhile, using label for FlowSpec 20 rule can improve forwarding performance in BGP VPN/MPLS networks. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 6, 2016. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 5 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 5. Security considerations . . . . . . . . . . . . . . . . . . . 6 67 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 6 68 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 [RFC5575] defines the flow specification (FlowSpec) that is an 74 n-tuple consisting of several matching criteria that can be applied 75 to IP traffic. The matching criteria can include elements such as 76 source and destination address prefixes, IP protocol, and transport 77 protocol port numbers. A given IP packet is said to match the 78 defined flow if it matches all the specified criteria. [RFC5575] 79 also defines filtering actions, such as rate limit, redirect, 80 marking, associated with each flow specification. A new Border 81 Gateway Protocol Network Layer Reachability Information (BGP NLRI) 82 (AFI/SAFI: 1/133 for IPv4, AFI/SAFI: 1/134 for VPNv4) encoding format 83 is used to distribute traffic flow specifications. 85 [RFC3107] specifies the way in which the label mapping information 86 for a particular route is piggybacked in the same Border Gateway 87 Protocol Update message that is used to distribute the route itself. 88 Label mapping information is carried as part of the Network Layer 89 Reachability Information (NLRI) in the Multiprotocol Extensions 90 attributes. The Network Layer Reachability Information is encoded as 91 one or more triples of the form . The NLRI 92 contains a label is indicated by using Subsequent Address Family 93 Identifier (SAFI) value 4. 95 [RFC4364] describes a method in which each route within a Virtual 96 Private Network (VPN) is assigned a Multiprotocol Label Switching 97 (MPLS) label. If the Address Family Identifier (AFI) field is set to 98 1, and the SAFI field is set to 128, the NLRI is an MPLS-labeled VPN- 99 IPv4 address. 101 In BGP VPN/MPLS networks, label switching is more efficient than IP 102 routing. As FlowSpec rules are used for packet processing and 103 forwarding, label-based forwarding can effectively improve the route 104 lookup performance in the data plane. When FlowSpec rules on 105 multiple forwarding devices in the network bound with labels form one 106 or more LSPs, only the ingress LSR (Label Switching Router) needs to 107 identify a particular traffic flow based on the matching criteria and 108 then steers the packet to a corresponding LSP (Label Switched Path). 109 Other LSRs of the LSP just need to forward the packet according to 110 the label carried in it. 112 Though the FlowSpec rule could use the label(s) bound with the best- 113 match unicast route for the destination prefix embedded in the 114 FlowSpec rule or the best-match route to the target IP in the 115 'redirect to IP' action, this way means that if two or more FlowSpec 116 rules have the same best-match unicast route for the embedded 117 destination prefix or the same best-match route to target IP in the 118 'redirect to IP' action; they would be mapped to the same label. 119 This would affect monitoring and traffic statistics facilities, 120 because each FlowSpec rule requires an independent statistic and log 121 data, which is described in Section 9 [RFC5575]. The LSRs (except 122 the ingress LSR) on the LSP can use label to indentify the traffic 123 matching a particular FlowSpec rule; this facilitates monitoring and 124 traffic statistics for FlowSpec rules. 126 So this document proposes that the BGP router supports to allocate a 127 unique label to a FlowSpec rule, the forwarding path is still decided 128 by the best-match unicast route for the embedded destination prefix 129 or the best-match route to target IP in the 'redirect to IP' action. 130 Figure 1 gives an example that FlowSpec rule bound with a label is 131 disseminated in the network. 133 Option-B inter-AS connection 134 |<------AS1----->| |<------AS2----->| 135 +-----+ +-----+ +-----+ +-----+ 136 VPN 1,IP1..| PE1 |====|ASBR1|----|ASBR2|====| PE2 |..VPN1,IP2 137 +-----+ +-----+ +-----+ +-----+ 138 | LDP LSP1 | | LDP LSP2 | 139 | -------> | | -------> | 140 |-------BGP VPN Flowspec LSP---->| 141 (Label1) (Label2) (Label3) (Label4) 142 Figure 1: Usage of FlowSpec with Label 144 FlowSpec rule1 (injected in PE2): 145 Filters: 146 destination ip prefix:IP2/32 147 source ip prefix:IP1/32 148 Actions: 149 traffic-marking: 1 151 Labels allocated for FlowSpec1: 152 Label4 allocated by PE2 153 Label3 allocated by ASBR2 154 Label2 allocated by ASBR1 155 Label1 allocated by PE1 157 PE2 disseminates the FlowSpec1 bound with Label4 to ASBR2. 158 ASBR2 disseminates the FlowSpec1 bound with Label3 to ASBR1. 159 ASBR1 disseminates the FlowSpec1 bound with Label2 to PE1. 161 Forwarding information for the traffic from IP1 to IP2 in the Routers: 162 PE1: in() --> out(Label2) 163 ASBR1: in(Label2) --> out(Label3) 164 ASBR2: in(Label3) --> out(Label4) 165 PE2: in(Label4) --> out(--) 167 So ASBR1 can do traffic statistics for FlowSpec rule 1 based on 168 Label2; ASBR2 can do it based on Label3; and PE2 can do it based on 169 Label4. 171 2. Terminology 173 This section contains definitions of terms used in this document. 175 Flow Specification (FlowSpec): A flow specification is an n-tuple 176 consisting of several matching criteria that can be applied to IP 177 traffic, including filters and actions. Each FlowSpec consists of 178 a set of filters and a set of actions. 180 3. Protocol Extensions 182 In this document, BGP is used to distribute the FlowSpec rule bound 183 with label(s). Two new SAFIs should be defined, i.e. SAFI: TBD1 for 184 IP FlowSpec rule bound with label(s), SAFI: TBD2 for VPN FlowSpec 185 rule bound with label(s). The Network Layer Reachability Information 186 for this FlowSpec rule is encoded as one or more triples of the form 187 , whose fields 188 are described below: 190 +---------------------------+ 191 | Length (1 or 2 octets) | 192 +---------------------------+ 193 | RD (8 octets, optional) | 194 +---------------------------+ 195 | Flow Filters (variable) | 196 +---------------------------+ 197 | Separator | 198 +---------------------------+ 199 | Label(s) | 200 +---------------------------+ 202 The use and the meaning of these fields are as follows: 204 Length: The Length field indicates the length in bytes of the flow 205 filters, the RD, the separator and the label(s). 207 RD: Route Distinguisher (8 bytes), when SAFI=TBD2. 209 Separator: This field is the constant bit pattern 0xfe (hex),which 210 indicates the separation between the flow filters field and 211 lable(s) field. This value should not be used by flow filters. 213 Label(s): This field carries zero or more labels (that corresponds 214 to the stack of labels [RFC3032]). Each label is encoded as 3 215 octets, where the high-order 20 bits contain the label value, and 216 the low order bit contains "Bottom of Stack" [RFC3032]. 218 Flow Filters: This field consists of several optional 219 subcomponents defined in section 4 [RFC5575]. The combination of 220 RD and Flow Filters is equal to the flow-spec NLRI defined in 221 [RFC5575]. 223 For the purpose of BGP route key processing, only the Route 224 Distinguisher, Flow Filters fields are considered to be part of the 225 prefix in the NLRI. 227 4. IANA Considerations 229 For the purpose of this work, IANA should allocate values for two 230 SAFIs: 232 SAFI TBD1 for IP FlowSpec rule bound with label(s). 234 SAFI TBD2 for VPN FlowSpec rule bound with label(s). 236 5. Security considerations 238 This extension to BGP does not change the underlying security issues 239 inherent in the existing BGP. 241 6. Acknowledgement 243 The authors would like to thank Shunwan Zhuang, Zhenbin Li and Peng 244 Zhou for their comments. 246 7. Normative References 248 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 249 Requirement Levels", BCP 14, RFC 2119, March 1997. 251 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 252 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 253 Encoding", RFC 3032, January 2001. 255 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 256 BGP-4", RFC 3107, May 2001. 258 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 259 Networks (VPNs)", RFC 4364, February 2006. 261 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 262 and D. McPherson, "Dissemination of Flow Specification 263 Rules", RFC 5575, August 2009. 265 Authors' Addresses 267 Qiandeng Liang 268 Huawei 269 101 Software Avenue, Yuhuatai District 270 Nanjing, 210012 271 China 273 Email: liangqiandeng@huawei.com 274 Jianjie You 275 Huawei 276 101 Software Avenue, Yuhuatai District 277 Nanjing, 210012 278 China 280 Email: youjianjie@huawei.com