idnits 2.17.1 draft-li-idr-flowspec-srv6-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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 11, 2019) is 1873 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) == Unused Reference: 'RFC5575' is defined on line 278, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-16 == Outdated reference: A later version (-23) exists of draft-ietf-idr-flowspec-l2vpn-09 ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) Summary: 3 errors (**), 0 flaws (~~), 5 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 L. Li 4 Intended status: Standards Track Huawei 5 Expires: September 12, 2019 March 11, 2019 7 BGP Flow Specification for SRv6 8 draft-li-idr-flowspec-srv6-00 10 Abstract 12 This draft proposes BGP flow specification rules that are used to 13 filter SRv6 packets. 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 https://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 September 12, 2019. 38 Copyright Notice 40 Copyright (c) 2019 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 (https://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 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3 57 3. The Flow Specification Encoding for SRv6 . . . . . . . . . . 3 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 59 5. IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 61 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 BGP Flow Specification (BGP-FS) [RFC5575]defines a new BGP NLRI to 68 distribute traffic flow specification rules via BGP ([RFC4271]). 69 BGP-FS policies have a match condition that may be n-tuple match in a 70 policy, and an action that modifies the packet and forwards/drops the 71 packet. Via BGP, new filter rules can be sent to all BGP peers 72 simultaneously without changing router configuration, and the BGP 73 peer can install these routes in the forwarding table. BGP-FS 74 defines Network Layer Reachability Information (NLRI) format used to 75 distribute traffic flow specification rules. NLRI (AFI=1, SAFI=133) 76 is for IPv4 unicast filtering. NLRI (AFI=1, SAFI=134)is for BGP/MPLS 77 VPN filtering.[I-D.ietf-idr-flowspec-l2vpn][I-D.ietf-idr-flowspec- 78 l2vpn] extends the flow-spec rules for layer 2 Ethernet packets. 80 Segment Routing (SR) for unicast traffic has been proposed to cope 81 with the usecases in traffic engineering, fast re-reroute, service 82 chain, etc. SR architecture can be implemented over an IPv6 data 83 plane using a new type of Segment Routing Header 84 (SRH)[I-D.ietf-6man-segment-routing-header] . SRv6 Network 85 Programming[I-D.filsfils-spring-srv6-network-programming] defined the 86 SRv6 network programming concept and its most basic functions. SRv6 87 SID will have the form LOC:FUNCT:ARGS::. 89 LOC: Each operator is free to use the locator length it chooses. 90 Most often the LOC part of the SID is routable and leads to the node 91 which instantiates that SID 93 FUNCT: The FUNCT part of the SID is an opaque identification of a 94 local function bound to the SID. (e.g. End: Endpoint, End.X, End.T, 95 End.DX2 etc.) 96 ARGS: A function may require additional arguments that would be 97 placed immediately after the FUNCT 99 This document specifies a new subset of BGP-FS component types to 100 support Segment Routing over IPv6 data plane (SRv6) filtering. 102 2. Definitions and Acronyms 104 o FS: Flow Specification 106 o SR: Segment Routing 108 o SRv6: IPv6 Segment Routing, SRv6 is a method of forwarding IPv6 109 packets on the network based on the concept of source routing. 111 o SID: Segment Identifier 113 o BSID: Binding SID 115 3. The Flow Specification Encoding for SRv6 117 This document proposes new flow specifications rules that is encoded 118 in NLRI. The following new component types are defined 120 o Whole SID 122 Type TBD1 - Whole SID 124 Encoding: 126 Contains a set of {operator, value} pairs that are used to match the 127 SID/binding SID or a range of whole SID. 129 The operator byte is encoded as: 131 0 1 2 3 4 5 6 7 132 +---+---+---+---+---+---+---+---+ 133 | e | a |lt |gt |eq | reserve | 134 +---+---+---+---+---+---+---+---+ 136 Where: 138 e - end-of-list bit. Set in the last {op, value} pair in the list. 140 a - AND bit. If unset, the previous term is logically ORed with the 141 current one. If set, the operation is a logical AND. It should be 142 unset in the first operator byte of a sequence. The AND operator has 143 higher priority than OR for the purposes of evaluating logical 144 expressions. 146 lt - less than comparison between data and value. 148 gt - greater than comparison between data and value. 150 eq - equality between data and value. 152 The bits lt, gt, and eq can be combined to produce match the SID or a 153 range of SID(e.g. less than SID1 and greater than SID2). 155 The value field is encoded as: 157 0 1 2 3 158 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 159 +---------------------------------------------------------------+ 160 ~ SID(128bits) ~ 161 +---------------------------------------------------------------+ 163 The format of SID is described in 164 [I-D.ietf-6man-segment-routing-header] and 165 [I-D.filsfils-spring-srv6-network-programming] 167 o Some bits of SID to match 169 For some scenarios route policy with the whole128 bits SID matching 170 is too long and not necessary. 171 [I-D.filsfils-spring-srv6-network-programming] defined the format of 172 SID is LOC:FUNCT:ARGS::. In some scenarios, traffic packets can just 173 match Locator, Function ID, Argument or combine of these different 174 fields rather than whole 128 bits SID. This document defines a set 175 of new component type TBD2 to reduce the length of matching. 177 Type TBD2 - Some bits of SID 179 Encoding: 181 Contains a set of {operator, value} pairs that are used to match some 182 bits of SID. 184 The operator byte is encoded as: 186 0 1 2 3 4 5 6 7 187 +---+---+---+---+---+---+---+---+ 188 | e | a | type |reserve| 189 +---+---+---+---+---+---+---+---+ 191 Where: 193 e - end-of-list bit. Set in the last {op, value} pair in the list. 195 a - AND bit. If unset, the previous term is logically ORed with the 196 current one. If set, the operation is a logical AND. It should be 197 unset in the first operator byte of a sequence. The AND operator has 198 higher priority than OR for the purposes of evaluating logical 199 expressions. 201 type: 203 0000 : SID's LOC bits 205 0001 : SID's FUNCT bits 207 0010 : SID's LOC:FUNCT bits 209 0011 : SID's FUNCT:ARGS bits 211 The value field is encoded as SID with mask to match bits as type 212 defined: 214 0 1 2 3 215 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 216 +---------------------------------------------------------------+ 217 ~ SID(128bits) ~ 218 +---------------------------------------------------------------+ 219 ~ Mask ~ 220 +---------------------------------------------------------------+ 222 4. Security Considerations 224 No new security issues are introduced to the BGP protocol by this 225 specification. 227 5. IANA 229 IANA is requested to a new entry in "Flow Spec component types 230 registry" with the following values: 232 +--------------------------------------------+ 233 | Type | RFC or Draft | Description | 234 +--------------------------------------------+ 235 | TBD1 | This Draft | SID | 236 +--------------------------------------------+ 237 | TBD2 | This Draft | Some bits of SID | 238 +--------------------------------------------+ 240 6. Contributors 242 TBD 244 7. Acknowledgments 246 TBD 248 8. References 250 [I-D.filsfils-spring-srv6-network-programming] 251 Filsfils, C., Camarillo, P., Leddy, J., 252 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 253 Network Programming", draft-filsfils-spring-srv6-network- 254 programming-07 (work in progress), February 2019. 256 [I-D.ietf-6man-segment-routing-header] 257 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 258 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 259 (SRH)", draft-ietf-6man-segment-routing-header-16 (work in 260 progress), February 2019. 262 [I-D.ietf-idr-flowspec-l2vpn] 263 Weiguo, H., Eastlake, D., Uttaro, J., Litkowski, S., and 264 S. Zhuang, "BGP Dissemination of L2VPN Flow Specification 265 Rules", draft-ietf-idr-flowspec-l2vpn-09 (work in 266 progress), January 2019. 268 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 269 Requirement Levels", BCP 14, RFC 2119, 270 DOI 10.17487/RFC2119, March 1997, 271 . 273 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 274 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 275 DOI 10.17487/RFC4271, January 2006, 276 . 278 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 279 and D. McPherson, "Dissemination of Flow Specification 280 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 281 . 283 Authors' Addresses 284 Zhenbin Li 285 Huawei 286 156 Beiqing Road 287 Beijing, 100095 288 P.R. China 290 Email: lizhenbin@huawei.com 292 Lei Li 293 Huawei 294 156 Beiqing Road 295 Beijing 100095 296 P.R. China 298 Email: lily.lilei@huawei.com