idnits 2.17.1 draft-liang-idr-bgp-flowspec-label-02.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 (March 21, 2016) is 2958 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) ** Obsolete normative reference: RFC 7674 (Obsoleted by RFC 8955) == Outdated reference: A later version (-15) exists of draft-ietf-idr-bgp-flowspec-oid-02 == Outdated reference: A later version (-22) exists of draft-ietf-idr-flow-spec-v6-07 == Outdated reference: A later version (-23) exists of draft-ietf-idr-flowspec-l2vpn-03 -- No information found for draft-yong-idr-flowspec-mpls-match - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Idr Working Group Q. Liang 3 Internet-Draft S. Hares 4 Intended status: Standards Track J. You 5 Expires: September 22, 2016 Huawei 6 R. Raszuk 7 Nozomi 8 D. Ma 9 Cisco Systems 10 March 21, 2016 12 Carrying Label Information for BGP FlowSpec 13 draft-liang-idr-bgp-flowspec-label-02 15 Abstract 17 This document specifies a method in which the label mapping 18 information for a particular FlowSpec rule is piggybacked in the same 19 Border Gateway Protocol (BGP) Update message that is used to 20 distribute the FlowSpec rule. Based on the proposed method, the 21 Label Switching Routers (LSRs) (except the ingress LSR) on the Label 22 Switched Path (LSP) can use label to indentify the traffic matching a 23 particular FlowSpec rule; this facilitates monitoring and traffic 24 statistics for FlowSpec rules. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 22, 2016. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.2. MPLS Flow Specification Deployment . . . . . . . . . . . 3 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. Overview of Proposal . . . . . . . . . . . . . . . . . . . . 3 71 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 5 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 73 6. Security considerations . . . . . . . . . . . . . . . . . . . 7 74 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 77 8.2. Informative References . . . . . . . . . . . . . . . . . 8 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 80 1. Introduction 82 This section provides the background for proposing a new action for 83 BGP Flow specification that push/pops MPLS or swaps MPLS tags. For 84 those familiar with BGP Flow specification ([RFC5575], [RFC7674], 85 [I-D.ietf-idr-flow-spec-v6], [I-D.ietf-idr-flowspec-l2vpn], 86 [I-D.ietf-idr-bgp-flowspec-oid] and MPLS ([RFC3107]) can skip this 87 background section. 89 1.1. Background 91 [RFC5575] defines the flow specification (FlowSpec) that is an 92 n-tuple consisting of several matching criteria that can be applied 93 to IP traffic. The matching criteria can include elements such as 94 source and destination address prefixes, IP protocol, and transport 95 protocol port numbers. A given IP packet is said to match the 96 defined flow if it matches all the specified criteria. [RFC5575] 97 also defines a set of filtering actions, such as rate limit, 98 redirect, marking, associated with each flow specification. A new 99 Border Gateway Protocol Network Layer Reachability Information (BGP 100 NLRI) (AFI/SAFI: 1/133 for IPv4, AFI/SAFI: 1/134 for VPNv4) encoding 101 format is used to distribute traffic flow specifications. 103 [RFC3107] specifies the way in which the label mapping information 104 for a particular route is piggybacked in the same Border Gateway 105 Protocol Update message that is used to distribute the route itself. 106 Label mapping information is carried as part of the Network Layer 107 Reachability Information (NLRI) in the Multiprotocol Extensions 108 attributes. The Network Layer Reachability Information is encoded as 109 one or more triples of the form . The NLRI 110 contains a label is indicated by using Subsequent Address Family 111 Identifier (SAFI) value 4. 113 [RFC4364] describes a method in which each route within a Virtual 114 Private Network (VPN) is assigned a Multiprotocol Label Switching 115 (MPLS) label. If the Address Family Identifier (AFI) field is set to 116 1, and the SAFI field is set to 128, the NLRI is an MPLS-labeled VPN- 117 IPv4 address. 119 1.2. MPLS Flow Specification Deployment 121 In BGP VPN/MPLS networks when flow specification policy rules exist 122 on multiple forwarding devices in the network bound with labels from 123 one or more LSPs, only the ingress LSR (Label Switching Router) needs 124 to identify a particular traffic flow based on the matching criteria 125 for flow. Once the flow is match by the ingress LSR, the ingress LSR 126 steers the packet to a corresponding LSP (Label Switched Path). 127 Other LSRs of the LSP just need to forward the packet according to 128 the label carried in it. 130 2. Terminology 132 This section contains definitions of terms used in this document. 134 Flow Specification (FlowSpec): A flow specification is an n-tuple 135 consisting of several matching criteria that can be applied to IP 136 traffic, including filters and actions. Each FlowSpec consists of 137 a set of filters and a set of actions. 139 3. Overview of Proposal 141 This document proposes adding a BGP-FS action in an extended 142 community alters the label switch path associated with a matched 143 flow. If the match does not have a label switch path, this action is 144 skipped. 146 The BGP flow specification (BGP-FS) policy rule could match on the 147 destination prefix and then utilize a BGP-FS action to adjust the 148 label path associated with it (push/pop/swap tags.) Or a BGP-FS 149 policy rule could match on any set of BGP-FS match conditions 150 associated with a BGP-FS action that adjust the label switch path 151 (push/pop/swap). 153 [I-D.yong-idr-flowspec-mpls-match] provides a match BGP-FS that may 154 be used with this action to match and direct MPLS packets. 156 Example of Use: 158 Forwarding information for the traffic from IP1 to IP2 in the 159 Routers: 161 PE1: in() --> out(Label2) 162 ASBR1: in(Label2) --> out(Label3) 163 ASBR2: in(Label3) --> out(Label4) 164 PE2: in(Label4) --> out(--) 166 Labels allocated by flow policy process: 168 Label4 allocated by PE2 169 Label3 allocated by ASBR2 170 Label2 allocated by ASBR1 172 |<------AS1----->| |<------AS2----->| 173 +-----+ +-----+ +-----+ +-----+ 174 VPN 1,IP1..| PE1 |====|ASBR1|----|ASBR2|====| PE2 |..VPN1,IP2 175 +-----+ +-----+ +-----+ +-----+ 176 | LDP LSP1 | | LDP LSP2 | 177 | -------> | | -------> | 178 |-------BGP VPN Flowspec LSP---->| 179 (Label1) (Label2) (Label3) (Label4) 181 Figure 1: Usage of FlowSpec with Label 183 BGP-FS rule1 (locally configured): 185 Filters: 186 destination ip prefix:IP2/32 187 source ip prefix:IP1/32 189 Actions: Extended Communities 190 traffic-marking: 1 191 MPLS POP 193 Note: 195 The following Extended Communities are added/deleted 197 [rule-1a] BGP-FS action MPLS POP [used on PE2] 198 [rule-1b] BGP-FS action SWAP 4 [used on ASBR-2] 199 [rule-1c] BGP-FS action SWAP 3 [used on ASBR-1] 200 [rule-1d] BGP-FS action push 2 [used on PE1] 202 PE-2 Changes BGP-FS rule-1a to rule-1b prior to sending 203 Clears Extended Community: BGP-FS action MPLS POP 204 Adds Extended Community: BGP-FS action MPLS SWAP 4 206 ASBR-2 receives BGP-FS rule-1b (NRLI + 2 Extended Community) 207 Installs the BGP-FS rule-1b (MPLS SWAP 4, traffic-marking) 208 Changes BGP-FS rule-1b to rule-1c prior to sending to ASBR1 209 Clear Extended Community: BGP-FS action MPLS SWAP 4 210 Adds Extended Community: BGP-FS action MPLS SWAP 3 212 ASBR-1 Receives BGP-FS rule-1c (NLRI + 2 Extended Community) 213 Installs the BGP-FS rule-1c (MPLS SWAP 3, traffic-marking 214 Changes BGP-FS rule-1c to rule-1d prior to sending to PE-2 215 Clear Extended Community: BGP-FS action MPLS SWAP 3 216 Adds Extended Community: BGP-FS action MPLS SWAP 2 218 PE-1 Receives BGP-FS rule-1d (NLRI + 2 Extended Communities) 219 Installs BGP-FS rule-1d action [MPLS SWAP 2, traffic-marking] 221 4. Protocol Extensions 223 In this document, BGP is used to distribute the FlowSpec rule bound 224 with label(s). A new label-action is defined as BGP extended 225 community value based on Section 7 of [RFC5575]. 227 +--------+--------------------+--------------------------+ 228 | type | extended community | encoding | 229 +--------+--------------------+--------------------------+ 230 | TBD1 | label-action | MPLS tag | 231 +--------+--------------------+--------------------------+ 233 Label-action is described below: 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Type (TBD1 | OpCode|Reserve| order | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label 240 | Label | Exp |S| TTL | Stack 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry 242 The use and the meaning of these fields are as follows: 244 Type: the same as defined in [RFC4360] 246 OpCode: Operation code 248 +------+------------------------------------------------------------+ 249 |OpCode| Function | 250 +------+------------------------------------------------------------+ 251 | 0 | Push the MPLS tag | 252 +------+------------------------------------------------------------+ 253 | 1 | Pop the outermost MPLS tag in the packet | 254 +------+------------------------------------------------------------+ 255 | 2 | Swap the MPLS tag with the outermost MPLS tag in the packet| 256 +------+------------------------------------------------------------+ 257 | 3~15 | Reserved | 258 +------+------------------------------------------------------------+ 260 When the Opcode field is set to 0, the label stack entry Should 261 be pushed on the MPLS label stack. 263 When the OpCode field is set to 1, the label stack entry is 264 invalid, and the router SHOULD pop the existing outermost MPLS 265 tag in the packet. 267 When the OpCode field is set to 2, the router SHOULD swap the 268 label stack entry with the existing outermost MPLS tag in the 269 packet. If the packet has no MPLS tag, it just pushes the 270 label stack entry. 272 The OpCode 0 or 1 may be used in some SDN networks, such as the 273 scenario described in 274 [I-D.filsfils-spring-segment-routing-central-epe]. 276 The OpCode 2 can be used in traditional BGP MPLS/VPN networks. 278 Reserved: all zeros. 280 Order: A FlowSpec rule MAY include one or more ordering label- 281 action(s). If multiple label action extended communities are 282 associated with a BGP-FS Rule, this gives the order of this in the 283 list. The Last action received for an order will be used. 285 Label: the same as defined in [RFC3032]. 287 Bottom of Stack (S): the same as defined in [RFC3032]. It SHOULD 288 be invalid, and set to zero by default. It MAY be modified by the 289 forwarding router locally. 291 Time to Live (TTL): the same as defined in[RFC3032]. It MAY be 292 modified by the forwarding router locally. 294 Experimental Use (Exp): the same as defined in [RFC3032]. It MAY 295 be modified by the forwarding router according to the local 296 routing policy. 298 5. IANA Considerations 300 For the purpose of this work, IANA should allocate the following 301 Extended community: 303 TBD1 for label-action 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 The authors would like to thank Shunwan Zhuang, Zhenbin Li, Peng Zhou 313 and Jeff Haas for their comments. 315 8. References 317 8.1. Normative References 319 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 320 Requirement Levels", BCP 14, RFC 2119, 321 DOI 10.17487/RFC2119, March 1997, 322 . 324 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 325 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 326 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 327 . 329 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 330 BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, 331 . 333 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 334 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 335 February 2006, . 337 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 338 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 339 2006, . 341 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 342 and D. McPherson, "Dissemination of Flow Specification 343 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 344 . 346 [RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect 347 Extended Community", RFC 7674, DOI 10.17487/RFC7674, 348 October 2015, . 350 8.2. Informative References 352 [I-D.filsfils-spring-segment-routing-central-epe] 353 Filsfils, C., Previdi, S., Patel, K., Shaw, S., Ginsburg, 354 D., and D. Afanasiev, "Segment Routing Centralized Egress 355 Peer Engineering", draft-filsfils-spring-segment-routing- 356 central-epe-05 (work in progress), August 2015. 358 [I-D.ietf-idr-bgp-flowspec-oid] 359 Uttaro, J., Filsfils, C., Smith, D., Alcaide, J., and P. 360 Mohapatra, "Revised Validation Procedure for BGP Flow 361 Specifications", draft-ietf-idr-bgp-flowspec-oid-02 (work 362 in progress), January 2014. 364 [I-D.ietf-idr-flow-spec-v6] 365 McPherson, D., Raszuk, R., Pithawala, B., Andy, A., and S. 366 Hares, "Dissemination of Flow Specification Rules for 367 IPv6", draft-ietf-idr-flow-spec-v6-07 (work in progress), 368 March 2016. 370 [I-D.ietf-idr-flowspec-l2vpn] 371 Weiguo, H., Litkowski, S., and S. Zhuang, "Dissemination 372 of Flow Specification Rules for L2 VPN", draft-ietf-idr- 373 flowspec-l2vpn-03 (work in progress), November 2015. 375 [I-D.yong-idr-flowspec-mpls-match] 376 Yong , L., Liang , Q., and J. You , "Dissemination of Flow 377 Specification Rules for MPLS Label", March 2016. 379 Authors' Addresses 380 Qiandeng Liang 381 Huawei 382 101 Software Avenue, Yuhuatai District 383 Nanjing, 210012 384 China 386 Email: liangqiandeng@huawei.com 388 Susan Hares 389 Huawei 390 7453 Hickory Hill 391 Saline, MI 48176 392 USA 394 Email: shares@ndzh.com 396 Jianjie You 397 Huawei 398 101 Software Avenue, Yuhuatai District 399 Nanjing, 210012 400 China 402 Email: youjianjie@huawei.com 404 Robert Raszuk 405 Nozomi 407 Email: robert@raszuk.net 409 Dan Ma 410 Cisco Systems 412 Email: danma@cisco.com