idnits 2.17.1 draft-li-idr-flowspec-redirect-generalized-sid-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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 2955 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) == Missing Reference: 'RFC 5575' is mentioned on line 246, but not defined ** Obsolete undefined reference: RFC 5575 (Obsoleted by RFC 8955) == Unused Reference: 'I-D.ietf-isis-segment-routing-extensions' is defined on line 274, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 301, but no explicit reference was found in the text == Unused Reference: 'RFC4760' is defined on line 306, but no explicit reference was found in the text == Unused Reference: 'RFC5492' is defined on line 311, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-idr-bgp-flowspec-oid-03 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-06 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-07 ** Downref: Normative reference to an Informational draft: draft-li-spring-segment-path-programming (ref. 'I-D.li-spring-segment-path-programming') == Outdated reference: A later version (-02) exists of draft-li-spring-tunnel-segment-01 ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft S. Zhuang 4 Intended status: Standards Track N. Wu 5 Expires: September 22, 2016 Huawei Technologies 6 March 21, 2016 8 BGP FlowSpec Redirect to Generalized Segment ID Action 9 draft-li-idr-flowspec-redirect-generalized-sid-00 11 Abstract 13 This document defines a new type of the redirect extended community, 14 called as Redirect to Generalized Segment ID Extended Community. 15 When activated, the Redirect to Generalized Segment ID Extended 16 Community is used by BGP FlowSpec Controller to signal the specific 17 redirecting action to BGP Flowspec Client, and then the BGP Flowspec 18 Client will use the Generalized Segment ID and the Segment Type to 19 find a local forwarding entity in a local mapping table. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 22, 2016. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3 63 3. Redirect to Generalized Segment ID Extended Community . . . . 3 64 4. Using Redirect to Generalized Segment ID Extended Community . 5 65 5. Validation Procedures . . . . . . . . . . . . . . . . . . . . 6 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 Segment Routing [I-D.ietf-spring-segment-routing] for unicast traffic 75 has been proposed to cope with the usecases in traffic engineering, 76 fast re-reroute, service chain, etc. Segment Path Programming (SPP) 77 [I-D.li-spring-segment-path-programming] generalizes more use cases 78 based on segment and proposes the concept of Segment Path 79 Programming. In the field of Segment Path Programming: 1. The 80 Segment used in the programmed segment path is not only used in the 81 forwarding plane, but also used in the control plane. 2. The 82 programmed segment path is not only used in the transport layer, but 83 also used in the service layer. 85 [RFC5575] defines the flow specification (FlowSpec) that allows to 86 convey flow specifications and traffic Action/Rules associated (rate- 87 limiting, redirect, remark ...). BGP Flow specifications are encoded 88 within the MP_REACH_NLRI and MP_UNREACH_NLRI attributes. Rules 89 (Actions associated) are encoded in Extended Community attribute. 90 The BGP Flow Specification function allows BGP Flow Specification 91 routes that carry traffic policies to be transmitted to BGP Flow 92 Specification peers to control attack traffic. 94 Now the drafts of BGP Flowspec for redirecting to VRF/IP/Tunnel keep 95 the traditional way to extend BGP FlowSpec to redirect to an entity 96 with explicit meaning which has been defined clearly in the existing 97 work. 99 We can reuse some work of segment routing and generalize the concept 100 of Segment, and then it can provide a base for the abstracted view of 101 different forwarding entities. Since now segment ID can be the 102 indicator of interface, node, tunnel, if we do not map segment ID to 103 MPLS label or IPv6 address, it can be an identifier of all kinds of 104 forwarding entities in the control plane which can be used outside. 106 This document defines a new type of the redirect extended community, 107 called as Redirect to Generalized Segment ID Extended Community. 108 When activated, the Redirect to Generalized Segment ID Extended 109 Community is used by BGP FlowSpec Controller to signal the specific 110 redirecting action to BGP Flowspec Client, and then the BGP Flowspec 111 Client will use the Generalized Segment ID and Segment Type to find a 112 local forwarding entity in a local mapping table. 114 Existing technologies (BGP, IGP, LDP, SR, RSVP, Manual-Config, etc... 115 ) can be used to setup the mapping tables per segment type. 117 2. Definitions and Acronyms 119 o FS: Flow Specification 121 o SR: Segment Routing 123 o SID: Segment Identifier 125 o GSID: Generalized Segment ID 127 o SPP: Segment Path Programming 129 3. Redirect to Generalized Segment ID Extended Community 131 This document defines a new type of the redirect extended community, 132 called as Redirect to Generalized Segment ID Extended Community. 133 This extended community is a new transitive extended community with 134 the Type is TBD1 and the Sub-Type field is TBD2. 136 This document defines the following Redirect to Generalized Segment 137 ID Extended Community: 139 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 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Type=TBD1 | Sub-Type=TBD2 | Flags(1 octet)| Segment Type | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Generalized Segment ID | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 Figure 1: Redirect to Generalized Segment ID Extended Community Format 148 Where: 150 Type: 1 octet, to be assigned by IANA 152 Sub-Type: 1 octet, to be assigned by IANA 154 Flags: 1 octet field, TBD 156 Segment Type: 1 octet, Per [I-D.li-spring-segment-path-programming], 157 the Segment Type includes: 159 o 1 - Node Segment 161 o 2 - Agency Segment 163 o 3 - AS (Autonomous System) Segment 165 o 4 - Anycast Segment 167 o 5 - Multicast Segment 169 o 6 - Tunnel Segment (Tunnel Binding Segment ) 171 o 7 - VPN Segment 173 o 8 - OAM Segment 175 o 9 - ECMP (Equal Cost Multi-Path) Segment 177 o 10 - QoS Segment 179 o 11 - Bandwidth-Guarantee Segment 181 o 12 - Security Segment 183 o 13 - Multi-Topology Segment 185 o etc. 187 Generalized Segment ID: 4 octets, it can be used to find a local 188 forwarding entity in the mapping table designated by the Segment 189 Type. 191 4. Using Redirect to Generalized Segment ID Extended Community 193 In the transport layers, there can be multiple tunnels with different 194 constraints to one specific destination. In the traditional way, the 195 tunnel is set up by the distributed forwarding nodes. As the PCE- 196 initiated LSP setup [I-D.ietf-pce-pce-initiated-lsp]is introduced, 197 the tunnel setup can be triggered by the central controlled way. In 198 order to satisfy the different service requirements, it is necessary 199 to provide the capability to flexibly map the service to different 200 tunnels. Since the central control point has enough information 201 based on the whole network view, it can be an effective way to map 202 the service to the tunnel by the central point and advertise the 203 mapping information to the end-points of the service to guide the 204 mapping in the forwarding node. 206 The method to implement mapping service to tunnels can directly 207 introduce the tunnel attribute to specify the tunnel proposed by [I- 208 D.li-idr-mpls-path-programming]. [I-D.li-spring-tunnel-segment] 209 proposes one new type of segment, Tunnel Segment, which can provide 210 an alternative way to implement mapping service to tunnels. In the 211 following figure, the central controller can trigger to set up the 212 MPLS TE tunnels through PCE-initiated LSP and allocate Segment ID for 213 the tunnel in the Node-1. 215 +------------+ 216 | Central | 217 | Controller | 218 +------------+ 219 ^ Tunnel Binding 220 | SID (Z) 221 | .-----. 222 | ( ) 223 V .--( )--. 224 +-------+ ( ) +-------+ 225 | |_( IP/MPLS Network )_| | 226 |Node-1 | ( ================> ) |Node-2 | 227 +-------+ (MPLS TE/IP Tunnel) +-------+ 228 '--( )--' 229 ( ) 230 '-----' 232 Figure 2: Using Tunnel Segment for Mapping Service to Tunnel 234 The central controller can send a flowspec route to Node-1 with a 235 'Redirect to Generalized Segment ID' Extended Community to map a 236 specfic service to the tunnel segment identified by the Segment Type 237 and Generalized Segment ID. 239 When Node-1 receives a flowspec route with a 'Redirect to Generalized 240 Segment ID' Extended Community. It installs a traffic filtering rule 241 that matches the packets described by the NLRI field and redirects 242 them to the tunnel with the Generalized Segment ID. 244 5. Validation Procedures 246 The validation check described in [RFC 5575] and revised in 247 [I-D.ietf-idr-bgp-flowspec-oid] SHOULD be applied by default to 248 received flowspec routes with a Redirect to Generalized Segment ID 249 Extended Community. This means that a flowspec route with a 250 destination prefix subcomponent SHOULD NOT be accepted from an EBGP 251 peer unless that peer also advertised the best path for the matching 252 unicast route. 254 6. IANA Considerations 256 TBD. 258 7. Security Considerations 260 TBD. 262 8. Acknowledgements 264 TBD. 266 9. References 268 [I-D.ietf-idr-bgp-flowspec-oid] 269 Uttaro, J., Filsfils, C., Smith, D., Alcaide, J., and P. 270 Mohapatra, "Revised Validation Procedure for BGP Flow 271 Specifications", draft-ietf-idr-bgp-flowspec-oid-03 (work 272 in progress), March 2016. 274 [I-D.ietf-isis-segment-routing-extensions] 275 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 276 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 277 Extensions for Segment Routing", draft-ietf-isis-segment- 278 routing-extensions-06 (work in progress), December 2015. 280 [I-D.ietf-spring-segment-routing] 281 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 282 and R. Shakir, "Segment Routing Architecture", draft-ietf- 283 spring-segment-routing-07 (work in progress), December 284 2015. 286 [I-D.li-spring-segment-path-programming] 287 Li, Z. and I. Milojevic, "Segment Path Programming (SPP)", 288 draft-li-spring-segment-path-programming-00 (work in 289 progress), October 2015. 291 [I-D.li-spring-tunnel-segment] 292 Li, Z. and N. Wu, "Tunnel Segment in Segment Routing", 293 draft-li-spring-tunnel-segment-01 (work in progress), 294 March 2016. 296 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 297 Requirement Levels", BCP 14, RFC 2119, 298 DOI 10.17487/RFC2119, March 1997, 299 . 301 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 302 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 303 DOI 10.17487/RFC4271, January 2006, 304 . 306 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 307 "Multiprotocol Extensions for BGP-4", RFC 4760, 308 DOI 10.17487/RFC4760, January 2007, 309 . 311 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 312 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 313 2009, . 315 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 316 and D. McPherson, "Dissemination of Flow Specification 317 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 318 . 320 Authors' Addresses 321 Zhenbin Li 322 Huawei Technologies 323 Huawei Bld., No.156 Beiqing Rd. 324 Beijing 100095 325 China 327 Email: lizhenbin@huawei.com 329 Shunwan Zhuang 330 Huawei Technologies 331 Huawei Bld., No.156 Beiqing Rd. 332 Beijing 100095 333 China 335 Email: zhuangshunwan@huawei.com 337 Nan Wu 338 Huawei Technologies 339 Huawei Bld., No.156 Beiqing Rd. 340 Beijing 100095 341 China 343 Email: eric.wu@huawei.com