idnits 2.17.1 draft-liang-idr-bgp-flowspec-label-01.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 (September 29, 2015) is 3126 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) ** Downref: Normative reference to an Informational draft: draft-filsfils-spring-segment-routing-central-epe (ref. 'I-D.filsfils-spring-segment-routing-central-epe') ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 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 1, 2016 R. Raszuk 6 Nozomi 7 D. Ma 8 Cisco Systems 9 September 29, 2015 11 Carrying Label Information for BGP FlowSpec 12 draft-liang-idr-bgp-flowspec-label-01 14 Abstract 16 This document specifies a method in which the label mapping 17 information for a particular FlowSpec rule is piggybacked in the same 18 Border Gateway Protocol (BGP) Update message that is used to 19 distribute the FlowSpec rule. Based on the proposed method, the 20 Label Switching Routers (LSRs) (except the ingress LSR) on the Label 21 Switched Path (LSP) can use label to indentify the traffic matching a 22 particular FlowSpec rule; this facilitates monitoring and traffic 23 statistics for FlowSpec rules. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 1, 2016. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 5. Security considerations . . . . . . . . . . . . . . . . . . . 6 70 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 6 71 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 [RFC5575] defines the flow specification (FlowSpec) that is an 77 n-tuple consisting of several matching criteria that can be applied 78 to IP traffic. The matching criteria can include elements such as 79 source and destination address prefixes, IP protocol, and transport 80 protocol port numbers. A given IP packet is said to match the 81 defined flow if it matches all the specified criteria. [RFC5575] 82 also defines a set of filtering actions, such as rate limit, 83 redirect, marking, associated with each flow specification. A new 84 Border Gateway Protocol Network Layer Reachability Information (BGP 85 NLRI) (AFI/SAFI: 1/133 for IPv4, AFI/SAFI: 1/134 for VPNv4) encoding 86 format is used to distribute traffic flow specifications. 88 [RFC3107] specifies the way in which the label mapping information 89 for a particular route is piggybacked in the same Border Gateway 90 Protocol Update message that is used to distribute the route itself. 91 Label mapping information is carried as part of the Network Layer 92 Reachability Information (NLRI) in the Multiprotocol Extensions 93 attributes. The Network Layer Reachability Information is encoded as 94 one or more triples of the form . The NLRI 95 contains a label is indicated by using Subsequent Address Family 96 Identifier (SAFI) value 4. 98 [RFC4364] describes a method in which each route within a Virtual 99 Private Network (VPN) is assigned a Multiprotocol Label Switching 100 (MPLS) label. If the Address Family Identifier (AFI) field is set to 101 1, and the SAFI field is set to 128, the NLRI is an MPLS-labeled VPN- 102 IPv4 address. 104 In BGP VPN/MPLS networks, when FlowSpec rules on multiple forwarding 105 devices in the network bound with labels form one or more LSPs, only 106 the ingress LSR (Label Switching Router) needs to identify a 107 particular traffic flow based on the matching criteria and then 108 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 label to one or more FlowSpec rule(s), the forwarding path is still 128 decided by the best-match unicast route for the embedded destination 129 prefix or the best-match route to target IP in the 'redirect to IP' 130 action. Figure 1 gives an example that FlowSpec rule bound with a 131 label is 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). A new label-action is defined as BGP extended 184 community value based on Section 7 of [RFC5575]. 186 +--------+--------------------+--------------------------+ 187 | type | extended community | encoding | 188 +--------+--------------------+--------------------------+ 189 | TBD1 | label-action | MPLS tag | 190 +--------+--------------------+--------------------------+ 192 Label-action is described below: 194 0 1 2 3 195 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 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Type (TBD1) |OpCode | Reserved | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label 199 | Label | Exp |S| TTL | Stack 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry 202 The use and the meaning of these fields are as follows: 204 Type: the same as defined in [RFC4360] 206 OpCode: Operation code 208 +------+------------------------------------------------------------+ 209 |OpCode| Function | 210 +------+------------------------------------------------------------+ 211 | 0 | Push the MPLS tag | 212 +------+------------------------------------------------------------+ 213 | 1 | Pop the outermost MPLS tag in the packet | 214 +------+------------------------------------------------------------+ 215 | 2 | Swap the MPLS tag with the outermost MPLS tag in the packet| 216 +------+------------------------------------------------------------+ 217 | 3~15 | Reserved | 218 +------+------------------------------------------------------------+ 220 When the OpCode field is set to 1, the label stack entry is 221 invalid, and the router SHOULD pop the existing outermost MPLS 222 tag in the packet. 224 When the OpCode field is set to 2, the router SHOULD swap the 225 label stack entry with the existing outermost MPLS tag in the 226 packet. If the packet has no MPLS tag, it just pushes the 227 label stack entry. 229 The OpCode 0 or 1 may be used in some SDN networks, such as the 230 scenario described in 231 [I-D.filsfils-spring-segment-routing-central-epe]. 233 The OpCode 2 can be used in traditional BGP MPLS/VPN networks. 235 Bottom of Stack (S): the same as defined in [RFC3032]. It SHOULD 236 be invalid, and set to zero by default. It MAY be modified by the 237 forwarding router locally. 239 Time to Live (TTL): the same as defined in[RFC3032]. It MAY be 240 modified by the forwarding router locally. 242 Experimental Use (Exp): the same as defined in [RFC3032]. It MAY 243 be modified by the forwarding router according to the local 244 routing policy. 246 Label: the same as defined in [RFC3032]. 248 A FlowSpec rule MAY include one or more ordering label-action(s). 249 The arrival order of the label-actions decides the action order. 251 If the BGP router allocates a label for a FlowSpec rule and 252 disseminates the labeled FlowSpec rule to the upstream peers, it can 253 use the label to match the traffic identified by the FlowSpec rule in 254 the forwarding plane. 256 4. IANA Considerations 258 For the purpose of this work, IANA should allocate value for the type 259 of label-action: 261 TBD1 for label-action 263 5. Security considerations 265 This extension to BGP does not change the underlying security issues 266 inherent in the existing BGP. 268 6. Acknowledgement 270 The authors would like to thank Shunwan Zhuang, Zhenbin Li, Peng Zhou 271 and Jeff Haas for their comments. 273 7. Normative References 275 [I-D.filsfils-spring-segment-routing-central-epe] 276 Filsfils, C., Previdi, S., Patel, K., Shaw, S., Ginsburg, 277 D., and D. Afanasiev, "Segment Routing Centralized Egress 278 Peer Engineering", draft-filsfils-spring-segment-routing- 279 central-epe-05 (work in progress), August 2015. 281 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 282 Requirement Levels", BCP 14, RFC 2119, 283 DOI 10.17487/RFC2119, March 1997, 284 . 286 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 287 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 288 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 289 . 291 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 292 BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, 293 . 295 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 296 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 297 February 2006, . 299 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 300 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 301 2006, . 303 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 304 and D. McPherson, "Dissemination of Flow Specification 305 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 306 . 308 Authors' Addresses 310 Qiandeng Liang 311 Huawei 312 101 Software Avenue, Yuhuatai District 313 Nanjing, 210012 314 China 316 Email: liangqiandeng@huawei.com 318 Jianjie You 319 Huawei 320 101 Software Avenue, Yuhuatai District 321 Nanjing, 210012 322 China 324 Email: youjianjie@huawei.com 326 Robert Raszuk 327 Nozomi 329 Email: robert@raszuk.net 330 Dan Ma 331 Cisco Systems 333 Email: danma@cisco.com