Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095401200F7 for ; Fri, 20 Sep 2019 05:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.851 X-Spam-Level: ** X-Spam-Status: No, score=2.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, KHOP_HELO_FCRDNS=0.399, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSg7Po7J_LFG for ; Fri, 20 Sep 2019 05:12:01 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FF621200D5 for ; Fri, 20 Sep 2019 05:12:01 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=97.112.17.31; From: "Susan Hares" To: "'idr@ietf. org'" References: In-Reply-To: Date: Fri, 20 Sep 2019 08:11:46 -0400 Message-ID: <009e01d56fac$93673410$ba359c30$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009F_01D56F8B.0C7725D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJLQJSF5123l/3BN1uxfGjpfGIeQ6ZI09Qg Content-Language: en-us X-Antivirus: AVG (VPS 190920-0, 09/20/2019), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] AD Review of draft-ietf-idr-rfc5575bis-17 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2019 12:12:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_009F_01D56F8B.0C7725D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable John:=20 =20 =20 The author team is close to finishing its work on RFC5575bis. Alvaro = asks one clear questions of the chairs =E2=80=93should we include the v6 = portion into the revision of RFC5575bis. In my earlier discussion on = the list as WG Chair, I indicated that the WG had asked that the = RFC5575bis would not include the v6 version. =20 =20 Alvaro has clearly indicated that the RFC5575bis would appear at the = IESG with the v6 version. =20 =20 I would that you query the WG regarding: =C2=B7 RFC5575bis + draft-ietf-idr-flow-spec-v6-09.txt=20 =C2=B7 RFC5575bis with the v6 specification included.=20 Thank you,=20 Susan Hares=20 =20 =20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Alvaro Retana Sent: Tuesday, September 10, 2019 12:09 PM To: draft-ietf-idr-rfc5575bis@ietf.org Cc: idr@ietf. org; idr-chairs@ietf.org Subject: [Idr] AD Review of draft-ietf-idr-rfc5575bis-17 =20 Dear authors: =20 I just finished reading this document. Thank you for the work in = clarifying and updating rfc5575! Many of my comments (see below) are = related to what I think is still missing clarity, or lack of it in some = of the new text. =20 Besides the specific comments, I have some larger issues that I want to = detail here. The first 2 are directed at the Shepherd and Chairs. =20 (A) IPR =20 The Shepherd report, the datatracker and the WGLC thread [1] all point = at no existing IPR. However, several declarations do exist...for = rfc5575 [2]. IMO, the changes between rfc5575 and this document are not = that significant to assume that the declarations don't apply.. I also = note that none of the original authors mentioned as "contributing = authors" (=C2=A715) replied to the IPR call during the WGLC.. =20 Jie: As Shepherd, can you please file a third-party disclosure [3] = pointing at the rfc5575 disclosures? Once that is done I will send a = message to the WG to consider the information -- I don't expect any = issues, but it has to be done. I'll need you to also update the Shepherd = writeup. Thanks! =20 =20 (B) Support for IPv6 =20 I understand why this document only focuses on IPv4. While the text = points at draft-ietf-idr-flow-spec-v6, that draft has been expired for = over a year! What is the plan to move that work forward? It looks like = there may already be implementations in place [4]. =20 We all know this question will come up during IESG Evaluation, specially = in light of the IAB Statement on IPv6 [5] and the fact that there was a = related DISCUSS when rfc5575 was first processed [6] -- at that time = (2009!) the objection was cleared with the promise that an IPv6 document = would be forthcoming. =20 We should have a plan in place by the time this document makes it to the = IESG Telechat. It would have been ideal to publish both at the same = time, but I'll settle for the ability to (at least) point at the WGLC = (which has been brought up before [7]). =20 =20 (C) IANA Considerations =20 (C1) traffic-rate-packets =20 The instructions to IANA for the assignment of the traffic-rate-packets = sub-type are not clear. The existing assignments and the requirement = that "traffic actions are processed in ascending order of the sub-type" = (=C2=A77) seem to imply that a specific order for this new action may be = intended. Unless explicitly instructed, IANA may not assign a value = that aligns with that intent. [See related comments in =C2=A77.2.] =20 (C2) Experimental Use Ranges =20 This document uses ranges from the "BGP Transitive Extended Community = Types" registry which are reserved for Experimental Use. While the = history of this use is not clear, we should take the opportunity to = clean the registry. [See more in =C2=A712.3.] =20 =20 (D) Document organization =20 This document kept most of the Introduction text, but then added related = and, in some cases, overlapping and redundant text in =C2=A75 (not = =C2=A75.1) and =C2=A79. Please combine the information from =C2=A71 and = =C2=A75, and the background from =C2=A79 into an updated Introduction. = =C2=A76 seems to belong right after the definition of the NLRI = (=C2=A74), and before the next part of the specification (filtering) = starts with =C2=A75.1, then =C2=A77... =20 Most of the old text is about justification, some from the specific = point of view of the then-authors. Please reconsider whether that still = applies. =20 =20 I will wait for the major issues/comments to be addressed before = starting the IETF Last Call. =20 Thanks! =20 Alvaro. =20 =20 [1] = https://mailarchive.ietf.org/arch/msg/idr/0WQW0pdqq1ae31GYZ7-dk3_Wqv8 [2] https://datatracker.ietf.org/ipr/search/?rfc=3D5575 = = &submit=3Drfc [3] https://datatracker.ietf.org/ipr/new-third-party/ [4] = https://mailarchive.ietf.org/arch/msg/idr/VH0mYVgT39ueJapb0axMgfgcAN8 [5] https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ [6] https://datatracker.ietf.org/doc/rfc5575/history/ [7] = https://mailarchive.ietf.org/arch/msg/idr/0J6gWHgBx33u8WpTa0B73mI6rIM =20 =20 =20 [Line numbers from idnits.] =20 ... 17 Abstract =20 [nit] It is interesting to me that the Abstract was significantly = rewritten while the Introduction was mostly left unchanged. I assume = this was done to reflect the changes in the document upfront...but it = then results in, what I think, is an Abstract that is too long, and an = incomplete Introduction. =20 19 This document defines a Border Gateway Protocol Network = Layer 20 Reachability Information (BGP NLRI) encoding format that = can be used 21 to distribute traffic Flow Specifications. This allows the = routing 22 system to propagate information regarding more specific = components of 23 the traffic aggregate defined by an IP destination prefix. =20 25 It specifies IPv4 traffic Flow Specifications via a BGP = NLRI which 26 carries traffic Flow Specification filter, and an Extended = community 27 value which encodes actions a routing system can take if = the packet 28 matches the traffic flow filters. The flow filters and the = actions 29 are processed in a fixed order. Other drafts specify IPv6, = MPLS 30 addresses, L2VPN addresses, and NV03 encapsulation of IP = addresses. =20 [nit] s/carries traffic Flow Specification filter/carries a traffic Flow = Specification filter =20 [minor] I think that this paragraph, or something like it, belongs in = the Introduction (and not the Abstract), because it provides information = that could benefit from references: =20 - the two parts of the NLRI; BTW, the community is not even mentioned in = the Introduction. =20 - other drafts... The Introduction only mentions and provides a = reference to the IPv6 work. =20 32 This document obsoletes RFC5575 and RFC7674 to correct = unclear 33 specifications in the flow filters. =20 [major] Please add a similar statement in the Introduction, with = references to both RFCs. There should be an Informative reference to = both. =20 [minor] Appendix A talks about the difference of this document with = respect to rfc5575. What about rfc7674? It looks like any updates from = rfc7674 have been incorporated in this document. It would be very nice, = even if just for completion, if there was an Appendix that talked about = rfc7674 -- I even think that a sub-section of Appendix A would be = enough. =20 35 Applications which use the bgp Flow Specification are: 1) = application 36 which automate inter-domain coordination of traffic = filtering, such 37 as what is required in order to mitigate (distributed) = denial-of- 38 service attacks; 2) applications which control traffic = filtering in 39 the context of a BGP/MPLS VPN service, and 3) applications = with 40 centralized control of traffic in a SDN or NFV context. = Some 41 deployments of these three applications can be handled by = the strict 42 ordering of the BGP NLRI traffic flow filters, and the = strict actions 43 encoded in the extended community Flow Specification = actions. =20 [minor] Please move this paragraph to the Introduction. =20 [nit] s/extended community/Extended Community/g =20 =20 ... 133 1. Introduction ... 149 This document defines a general procedure to encode flow 150 specification rules for aggregated traffic flows so that = they can be 151 distributed as a BGP [RFC4271] NLRI. Additionally, we = define the 152 required mechanisms to utilize this definition to the = problem of 153 immediate concern to the authors: intra- and inter-provider 154 distribution of traffic filtering rules to filter = (distributed) 155 denial-of-service (DoS) attacks. =20 [minor] The document uses "Flow Specification" and "flow specification" = to refer to the same thing...right? Or are there differences due to the = capitalization? Please be consistent. =20 [style nit] Using "we" is not the best for a consensus document. s/we = define/it defines =20 [nit] "problem of immediate concern to the authors" Only the authors? = This piece of text was also present in rfc5575 -- having a different set = of authors, I would assume we can safely say that the = concern/application goes beyond the authors...right? Please reword. =20 [minor] Given that this is a bis, is the motivation still the same? I = think in part it is, but in part there may be other drivers. Just = asking... =20 [minor] This seems to be a good place to move the text from the Abstract = that describes applications... =20 ... 164 A Flow Specification received from an external autonomous = system will 165 need to be validated against unicast routing before being = accepted. 166 If the aggregate traffic flow defined by the unicast = destination 167 prefix is forwarded to a given BGP peer, then the local = system can 168 install more specific flow rules that may result in = different 169 forwarding behavior, as requested by this system. =20 [major] "A Flow Specification received from an external autonomous = system will need to be validated against unicast routing before being = accepted." What about if received internally? =20 171 The key technology components required to address the class = of 172 problems targeted by this document are: =20 174 1. Efficient point-to-multipoint distribution of control = plane 175 information. =20 177 2. Inter-domain capabilities and routing policy support. =20 179 3. Tight integration with unicast routing, for verification 180 purposes. =20 182 Items 1 and 2 have already been addressed using BGP for = other types 183 of control plane information. Close integration with BGP = also makes 184 it feasible to specify a mechanism to automatically verify = flow 185 information against unicast routing. These factors are = behind the 186 choice of BGP as the carrier of Flow Specification = information. =20 [nit] I don't think that we need to keep justifying... Just a nit... =20 188 As with previous extensions to BGP, this specification makes = it 189 possible to add additional information to Internet routers. = These 190 are limited in terms of the maximum number of data elements = they can 191 hold as well as the number of events they are able to = process in a 192 given unit of time. The authors believe that, as with = previous 193 extensions, service providers will be careful to keep = information 194 levels below the maximum capacity of their devices. =20 196 Experience with previous BGP extensions has also shown that = the 197 maximum capacity of BGP speakers has been gradually = increased 198 according to expected loads. For example Internet unicast = routing as 199 well as other BGP applications increased their maximum = capacity as 200 they gain popularity. =20 [minor] This is the same text from 10 years ago. Many things, including = hardware processing/storage, has changed. Is this text still necessary? = If so, then I would like to see explicit operational considerations on = what an operator should look for when being "careful". =20 =20 ... 214 In current deployments, the information distributed by the = flow-spec 215 extension is originated both manually as well as = automatically. The 216 latter by systems that are able to detect malicious flows. = When 217 automated systems are used, care should be taken to ensure = their 218 correctness as well as to limit the number and advertisement = rate of 219 flow routes. =20 [major] An automated system that is not "correct", because it may not be = properly programmed, the algorithms used are not performing as expected, = or simply because it is rogue, are all vulnerabilities that should be = called out in the Security Considerations section. =20 221 This specification defines required protocol extensions to = address 222 most common applications of IPv4 unicast and VPNv4 unicast = filtering. 223 The same mechanism can be reused and new match criteria = added to 224 address similar filtering needs for other BGP address = families such 225 as IPv6 families [I-D.ietf-idr-flow-spec-v6], =20 [nit] s/[I-D.ietf-idr-flow-spec-v6],/[I-D.ietf-idr-flow-spec-v6]. =20 =20 227 2. Definitions of Terms Used in This Memo ... 233 Loc-RIB - Local RIB. =20 [major] This simple definition doesn't match the one in = =C2=A71.1/rfc4271. =20 =20 .. 247 3. Flow Specifications ... 266 BGP itself treats the NLRI as an key to an entry in its = databases. 267 Entries that are placed in the Loc-RIB are then associated = with a 268 given set of semantics, which is application dependent. = This is 269 consistent with existing BGP applications. For instance, IP = unicast 270 routing (AFI=3D1, SAFI=3D1) and IP multicast reverse-path = information 271 (AFI=3D1, SAFI=3D2) are handled by BGP without any = particular semantics 272 being associated with them until installed in the Loc-RIB. =20 [nit] s/an key/a key =20 274 Standard BGP policy mechanisms, such as UPDATE filtering by = NLRI 275 prefix as well as community matching and manipulation, MUST = apply to 276 the Flow Specification defined NLRI-type, especially in an = inter- 277 domain environment. Network operators can also control = propagation 278 of such routing updates by enabling or disabling the = exchange of a 279 particular (AFI, SAFI) pair on a given BGP peering session. =20 [major] The point of NLRIs all being treated the same is made above, to = reinforce the default BGP behavior...and this paragraph tries to bring = home the point by Normatively enforcing it (MUST). However, because the = behavior is what BGP specifies by default, then this document cannot be = Normative in it (unless it specified an exception). s/MUST/must =20 281 4. Dissemination of IPv4 FLow Specification Information ... 287 This NLRI information is encoded using MP_REACH_NLRI and 288 MP_UNREACH_NLRI attributes as defined in [RFC4760]. = Whenever the 289 corresponding application does not require Next-Hop = information, this 290 shall be encoded as a 0-octet length Next Hop in the = MP_REACH_NLRI 291 attribute and ignored on receipt. =20 [minor] s/Next-Hop/Next Hop rfc4760 uses "Next Hop" =20 [nit] "...shall be encoded as a 0-octet length Next Hop in the = MP_REACH_NLRI attribute and ignored on receipt." What is ignored? The = Next Hop? If it doesn't exist (length =3D 0), then it can't be = ignored... Perhaps delete " and ignored on receipt". =20 ... 297 +------------------------------+ 298 | length (0xnn or 0xfn nn) | 299 +------------------------------+ 300 | NLRI value (variable) | 301 +------------------------------+ =20 [minor] s/0xfn nn/0xfnnn =20 =20 ... 312 4.1. Length Encoding =20 314 o If the NLRI length value is smaller than 240 (0xf0 hex), = the 315 length field can be encoded as a single octet. =20 [nit] s/240/240 octets =20 317 o Otherwise, it is encoded as an extended-length 2-octet = value in 318 which the most significant nibble of the first byte is = all ones. =20 320 In figure 1 above, values less-than 240 are encoded using = two hex 321 digits (0xnn). Values above 239 are encoded using 3 hex = digits 322 (0xfnnn). The highest value that can be represented with = this 323 encoding is 4095. The value 241 is encoded as 0xf0f1. =20 [nit] It may make more sense to show the encoding for 240. =20 =20 325 4.2. NLRI Value Encoding ... 332 The encoding of each of the NLRI components begins with a = type field 333 (1 octet) followed by a variable length parameter. Section = 4.2.1 to 334 Section 4.2.12 define component types and parameter = encodings for the 335 IPv4 IP layer and transport layer headers. IPv6 NLRI = component types 336 are described in [I-D.ietf-idr-flow-spec-v6]. =20 [minor] "followed by a variable length parameter" Only the first two = types have a variable length parameter... =20 338 Flow Specification components must follow strict type = ordering by 339 increasing numerical order. A given component type may = (exactly 340 once) or may not be present in the specification. If = present, it 341 MUST precede any component of higher numeric type value. =20 [major] What should happen if a component appears more than once? =20 [major] What should happen if the order is not maintained? =20 343 All combinations of component types within a single NLRI are = allowed, 344 even if the combination makes no sense from a semantical = perspective. 345 If a given component type within a prefix in unknown, the = prefix in 346 question cannot be used for traffic filtering purposes by = the 347 receiver. Since a Flow Specification has the semantics of a = logical 348 AND of all components, if a component is FALSE, by = definition it 349 cannot be applied. However, for the purposes of BGP route 350 propagation, this prefix should still be transmitted since = BGP route 351 distribution is independent on NLRI semantics. =20 [nit] s/prefix in unknown/prefix is unknown =20 [nit] s/independent on NLRI/independent of NLRI =20 [major] "...for the purposes of BGP route propagation, this prefix = should still be transmitted since BGP route distribution is independent = on NLRI semantics." I think this is a vulnerability: a (large) set of = meaningless Flow Specifications may be injected in the routing system... =20 [major] Also, propagating these unknown components may result in a = router down the line, which understands them, reacting. While the = reaction shouldn't result in reset adjacencies, it may result in = inconsistent forwarding or other unexpected outcomes... =20 [major] This treatment of unknown extensions is in conflict with the = text in =C2=A711. See my comments there. =20 =20 353 4.2.1. Type 1 - Destination Prefix =20 355 Encoding: =20 357 Defines: the destination prefix to match. Prefixes are = encoded as 358 in BGP UPDATE messages, a length in bits is followed by = enough 359 octets to contain the prefix information. =20 [nit] s/Defines: the destination prefix/Defines the destination prefix =20 [major] rfc4271: "The Prefix field contains an IP address prefix, = followed by the minimum number of trailing bits needed to make the end = of the field fall on an octet boundary." The text above makes it sound = as if the prefix field may not end in an octet boundary, which is what = rfc4271 specifies. =20 NEW (suggestion)> Defines the destination prefix to match. The length and prefix = fields are encoded as in BGP UPDATE messages [rfc4271]. =20 =20 361 4.2.2. Type 2 - Source Prefix =20 363 Encoding: =20 365 Defines the source prefix to match. =20 [minor] "... The length and prefix fields are encoded as in BGP UPDATE = messages [rfc4271]." =20 =20 367 4.2.3. Type 3 - IP Protocol =20 369 Encoding: =20 371 Contains a set of {operator, value} pairs that are used = to match 372 the IP protocol value byte in IP packets. =20 [minor] Include a reference to the protocol numbers.. =20 [major] Are all protocol numbers valid? I guess that in theory anything = is -- what should a receiver do with Flow Specifications that cover = protocols that are not supported? I'm wondering if sending Flow = Specifications for every protocol under the sun is a vulnerability -- = knowing that only a few will ever be present in the Internet. Is there = any guidance that you can provide in =C2=A714 (or a separate Operational = Considerations section)? I also point this out because the rest of the = types focus on TCP/UDP...what about other transport layer protocols? =20 [major] Related question: even for "valid" protocols, should all be = accepted from eBGP peers? I think that it is probably ok...asking for = completeness. =20 374 The operator byte is encoded as: =20 376 0 1 2 3 4 5 6 7 377 +---+---+---+---+---+---+---+---+ 378 | e | a | len | 0 |lt |gt |eq | 379 +---+---+---+---+---+---+---+---+ =20 381 Numeric operator =20 [nit] Center the figure... =20 [clarity] Please describe the operators independent of one of the Types. = As defined, it looks like they only apply to one type...it is much = later that the reader realizes that there is a reason for the = "complexity". Along the same lines, I think that the "set of {operator, = value} pairs" phrase could use some more text to explain that the = operator is the whole octet, with a corresponding value... =20 383 e - end-of-list bit. Set in the last {op, value} pair in = the 384 list. =20 [major] What action should be taken if a received flow spec has this bit = not set anywhere, or is set somewhere other than the last pair? =20 386 a - AND bit. If unset, the previous term is logically = ORed with 387 the current one. If set, the operation is a logical AND. = In the 388 first operator byte of a sequence it SHOULD be encoded as = unset 389 and and MUST be treated as always unset on decoding. The = AND 390 operator has higher priority than OR for the purposes of 391 evaluating logical expressions. =20 393 len - length of the value field for this operator given = as (1 << 394 len). This encodes 1 (00) - 8 (11) bytes. Type 3 flow = component 395 values SHOULD be encoded as single byte (len =3D 00). =20 [major] Please expand on the meaning of "1 << len". =20 =20 ... 406 The bits lt, gt, and eq can be combined to produce common = relational 407 operators such as "less or equal", "greater or equal", and = "not equal 408 to". =20 [minor] "...as shown in Table 1." =20 410 +----+----+----+----------------------------------+ 411 | lt | gt | eq | Resulting operation | 412 +----+----+----+----------------------------------+ 413 | 0 | 0 | 0 | false (independent of the value) | 414 | 0 | 0 | 1 | =3D=3D (equal) = | 415 | 0 | 1 | 0 | > (greater than) | 416 | 0 | 1 | 1 | >=3D (greater than or equal) = | 417 | 1 | 0 | 0 | < (less than) | 418 | 1 | 0 | 1 | <=3D (less than or equal) = | 419 | 1 | 1 | 0 | !=3D (not equal value) = | 420 | 1 | 1 | 1 | true (independent of the value) | 421 +----+----+----+----------------------------------+ =20 423 Table 1: Comparison operation combinations =20 425 4.2.4. Type 4 - Port =20 427 Encoding: =20 429 Defines a list of {operator, value} pairs that matches = source OR 430 destination TCP/UDP ports. This list is encoded using = the numeric 431 operator format defined in Section 4.2.3. Values SHOULD = be 432 encoded as 1- or 2-byte quantities. =20 [minor] A reference to TCP/UDP header/ports would be nice. =20 [major] "matches source OR destination TCP/UDP ports" Which one? Both? = Either? How does the receiver know which one? =20 [minor] What is the interaction/relationship between this type and Types = 5 and 6? The text in =C2=A74.2 allows for all 3 types to be present, = and have an influence in the action taken...they seem redundant. =20 =20 434 Port, source port, and destination port components = evaluate to 435 FALSE if the IP protocol field of the packet has a value = other 436 than TCP or UDP, if the packet is fragmented and this is = not the 437 first fragment, or if the system in unable to locate the = transport 438 header. Different implementations may or may not be able = to 439 decode the transport header in the presence of IP options = or 440 Encapsulating Security Payload (ESP) NULL [RFC4303] = encryption. =20 [minor] "Port, source port, and destination port components..." This = section only talks about the port; please duplicate this text in the = other sections, or put a reference to it there, or put a forward = reference here... =20 [major] "...evaluate to FALSE if the IP protocol field of the packet has = a value other than TCP or UDP, if the packet is fragmented and this is = not the first fragment, or if the system in unable to locate the = transport header." This sentence seems to mix the applicability of the = Flow Specification (FALSE is first introduced in =C2=A74.2 to describe = the effect of a component on the rule), and the application to a = specific packet. Please separate the two aspects. I do have some = specific questions/comments. =20 (1) The text starts by talking about the "protocol field of the packet" = (not the protocol value in the Type 3 parameter)... I assume that a = Flow Specification would only apply to a packet if the protocol matches = the Type 3 parameter...but the statement seems to say that it wouldn't = apply regardless of the Type 3 (see my question there about valid = protocols)...or maybe even if a Type 3 is not present.... =20 (2) "...evaluate to FALSE...if the packet is fragmented and this is not = the first fragment..." Type 12 specifically includes values for other = cases. How is the interaction expected? =20 =20 ... 460 4.2.7. Type 7 - ICMP type =20 462 Encoding: =20 464 Defines a list of {operator, value} pairs used to match = the type 465 field of an ICMP packet. This list is encoded using the = numeric 466 operator format defined in Section 4.2.3. Values SHOULD = be 467 encoded using a single byte. =20 [minor] A reference to ICMP would be nice. =20 469 The ICMP type specifiers evaluate to FALSE whenever the = protocol 470 value is not ICMP. =20 472 4.2.8. Type 8 - ICMP code =20 474 Encoding: =20 476 Defines a list of {operator, value} pairs used to match = the code 477 field of an ICMP packet. This list is encoded using the = numeric 478 operator format defined in Section 4.2.3. Values SHOULD = be 479 encoded using a single byte. =20 481 The ICMP code specifiers evaluate to FALSE whenever the = protocol 482 value is not ICMP. =20 [minor] I guess that it should also evaluate FALSE if the ICMP code is = not relevant for the Type. ?? =20 484 4.2.9. Type 9 - TCP flags =20 486 Encoding: =20 [minor] The operator (described below) is called "bitmask", which is a = little confusing with the bitmask itself... =20 488 Bitmask values can be encoded as a 1- or 2-byte bitmask. = When a 489 single byte is specified, it matches byte 13 of the TCP = header 490 [RFC0793], which contains bits 8 though 15 of the 4th = 32-bit word. 491 When a 2-byte encoding is used, it matches bytes 12 and = 13 of the 492 TCP header with the data offset field having a "don't = care" value. =20 [minor] Identifying the right octets is more important than counting the = number of bytes... The interesting bytes are identified above as "bytes = 12 and 13"; however, work from the Transport Area talks about "bytes 13 = and 14": https://tools.ietf.org/html/rfc3168#section-6.1 It would be = nice if this was aligned or if any ambiguity could be avoided. =20 [minor] "...with the data offset field having a "don't care" value." = What does that mean? To me, it sounds as if the bitmask values can't be = used to match on the offset....is that the right interpretation? Some = clarity would avoid guessing.. =20 494 This component evaluates to FALSE for packets that are = not TCP 495 packets. =20 [major] As mentioned before, this sentence also seems to mix/confuse the = applicability of the component (whether it can be used at all) and the = application of it to match a specific packet. In this case, the text = seems to simply say that a Flow Specification which uses Type 9 can only = be used to match TCP packets... =20 [major] Should the Flow Specification evaluate to FALSE if this Type is = used *and* Type 3 doesn't include TCP *only* in it's description? =20 497 This type uses the bitmask operator format, which differs = from the 498 numeric operator format in the lower nibble. =20 [minor] As with the numeric operator, I think it would be clearer if it = was introduced before the types. =20 500 0 1 2 3 4 5 6 7 501 +---+---+---+---+---+---+---+---+ 502 | e | a | len | 0 | 0 |not| m | 503 +---+---+---+---+---+---+---+---+ =20 505 Bitmask operator =20 [nit] Center the figure... =20 507 e, a, len - Most significant nibble: (end-of-list bit, AND = bit, and 508 length field), as defined for in the numeric operator = format in 509 Section 4.2.3. =20 [] See the questions about the e bit above. =20 =20 ... 542 4.2.12. Type 12 - Fragment =20 544 Encoding: =20 546 Uses bitmask operator format defined in Section 4.2.9. =20 [major] No, it doesn't. The new one is defined below. =20 [clarity] Again, please introduce the operators before the types. In = this case, this operator seems to also carry the bitmask name, which can = be confusing with the one introduced in =C2=A74.2.9 and the name of the = value field... =20 548 0 1 2 3 4 5 6 7 549 +---+---+---+---+---+---+---+---+ 550 | 0 | 0 | 0 | 0 |LF |FF |IsF|DF | 551 +---+---+---+---+---+---+---+---+ =20 [nit] Center the figure... =20 [nit] Please add Figure numbers. =20 553 Bitmask values: =20 555 Bit 7 - Don't fragment (DF) =20 557 Bit 6 - Is a fragment (IsF) =20 559 Bit 5 - First fragment (FF) =20 561 Bit 4 - Last fragment (LF) =20 563 Bit 0-3 - SHOULD be set to 0 on NLRI encoding, and = MUST be 564 ignored during decoding =20 [major] The operation is not specified. Is this also an = (operator,bitmask) pair, or just 8 bits indicating the values? Can = multiple bits be set at the same time? What fields in the IP header do = these map to? =20 566 4.3. Examples of Encodings =20 568 An example of a Flow Specification encoding for: "all = packets to 569 10.0.1/24 and TCP port 25". =20 [nit] For clarity, include the whole subnet: s/ 10.0.1/24 / 10.0.1.0/24 =20 [major] Use IP addresses from the documentation pool [rfc5737] in all = examples. =20 571 +------------------+----------+----------+ 572 | destination | proto | port | 573 +------------------+----------+----------+ 574 | 0x01 18 0a 00 01 | 03 81 06 | 04 81 19 | 575 +------------------+----------+----------+ =20 [minor] It would be nice if the examples show the the whole Flow-spec = NLRI, and not just the NLRI value. Also, it would be great if one of = the examples required more than 240 bytes. =20 577 Decode for protocol: =20 [minor] Please show the decodes for all the fields. =20 579 +-------+----------+------------------------------+ 580 | Value | | | 581 +-------+----------+------------------------------+ 582 | 0x03 | type | | 583 | 0x81 | operator | end-of-list, value size=3D1, =3D | 584 | 0x06 | value | | 585 +-------+----------+------------------------------+ =20 [minor] For completion, indicate that Protocol 6 is TCP. =20 587 An example of a Flow Specification encoding for: "all = packets to 588 10.1.1/24 from 192/8 and port {range [137, 139] or 8080}". =20 [] Ah...NETBIOS... =20 [nit] It might be a good idea to number the examples... =20 =20 ... 612 5. Traffic Filtering =20 614 Traffic filtering policies have been traditionally = considered to be 615 relatively static. Limitations of the static mechanisms = caused this 616 mechanism to be designed for the three new applications of = traffic 617 filtering (prevention of traffic-based, denial-of-service = (DOS) 618 attacks, traffic filtering in the context of BGP/MPLS VPN = service, 619 and centralized traffic control for SDN/NFV networks) = requires 620 coordination among service providers and/or coordination = among the AS 621 within a service provider. Section 9 has details on the = limitation 622 of previous mechanisms and why BGP Flow Specification = provides a 623 solution for to prevent DOS and aid BGP/MPLS VPN filtering = rules. =20 [minor] This sentence, without the parenthesis, doesn't seem to make = sense: "Limitations of the static mechanisms caused this mechanism to be = designed for the three new applications of traffic filtering requires = coordination among service providers and/or coordination among the AS = within a service provider." =20 [nit] s/solution for to prevent/solution to prevent =20 625 This Flow Specification NLRI defined above to convey = information 626 about traffic filtering rules for traffic that should be = discarded or 627 handled in manner specified by a set of pre-defined actions = (which 628 are defined in BGP Extended Communities). This mechanism is 629 primarily designed to allow an upstream autonomous system to = perform 630 inbound filtering in their ingress routers of traffic that a = given 631 downstream AS wishes to drop. =20 [nit] s/This Flow Specification NLRI/The Flow Specification NLRI =20 =20 ... 645 Distribution of the IPv4 Flow Specification is described in 646 Section 6, and distibution of BGP/MPLS traffic Flow = Specification is 647 described in Section 8. The traffic filtering actions are = described 648 in Section 7. =20 [minor] Section 6 talks about validation, not distribution. =20 [nit] s/distibution/distribution =20 =20 650 5.1. Ordering of Traffic Filtering Rules =20 652 With traffic filtering rules, more than one rule may match a 653 particular traffic flow. Thus, it is necessary to define = the order 654 at which rules get matched and applied to a particular = traffic flow. 655 This ordering function must be such that it must not depend = on the 656 arrival order of the Flow Specification's rules and must be 657 consistent in the network. =20 [clarification] Are "traffic filtering rules" the same thing as "traffic = filtering actions", or are they more like "Flow Specification's rules"? = You also mention (below) "Flow Specification rules" in the context of = ordering, so my guess is that "traffic filtering rules" and "Flow = Specification rules" are equivalent...are they? In my opinion, there = are too many ways to refer to the same, or very similar things. Please = take advantage of =C2=A72 to help the reader, or at least simplify the = terminology. =20 659 The relative order of two Flow Specification rules is = determined by 660 comparing their respective components. The algorithm starts = by 661 comparing the left-most components of the rules. If the = types 662 differ, the rule with lowest numeric type value has higher = precedence 663 (and thus will match before) than the rule that doesn't = contain that 664 component type. If the component types are the same, then a = type- 665 specific comparison is performed (see below) if the types = are equal 666 the algorithm continues with the next component. =20 [minor] To be clear: the comparison is done between the component types = defined in =C2=A74.2...and "left-most" means "first"... =20 668 For IP prefix values (IP destination or source prefix): If = the 669 prefixes overlap, the one with the longer prefix-length has = higher 670 precedence. If they do not overlap the one with the lowest = IP value 671 has higher precedence. =20 [minor] I need you to be more specific when talking about "overlap". = Clearly 10.1..0.0/16 and 10.1.1.0/24 overlap, then = the higher precedence would be for the /24, right? Do 130.0.0.0/16 and = 150..1.1.0/24 overlap (they have the first 3 bits = in common)? rfc5575 talks about a "common prefix", which is not = completely clear either, but it could mean at least what is covered by = the shortest mask (which would be my guess)... =20 [minor] "prefix-length" is used here, but "prefix length" is used in = =C2=A74.2.1. Please be consistent. =20 [minor] The "-" confused me a little. By "For IP prefix values...the = longer prefix-length" do you mean the value of the prefix length, or the = length of the prefix field? rfc5575 talks about "more specific", which = may be easier to understand in this case... =20 673 For all other component types, unless otherwise specified, = the 674 comparison is performed by comparing the component data as a = binary 675 string using the memcmp() function as defined by the ISO C = standard. 676 For strings with equal lengths the lowest string (memcmp) = has higher 677 precedence. For strings of different lengths, the common = prefix is 678 compared. If the common prefix is not equal the string with = the 679 lowest prefix has higher precedence. If the common prefix = is equal, 680 the longest string is considered to have higher precedence = than the 681 shorter one. =20 [major] Please add a Normative reference for "the memcmp() function as = defined by the ISO C standard". =20 [minor] What is the "common prefix"? Is it the bits that correspond to = the shorter length? In this case I think that using "prefix" may be = confusing. =20 [minor] If my interpretation is correct, given a common set of rules, = the longer the Flow Specification the most preferred, right? Using one = of the examples in =C2=A74.3, "all packets to 10.1.1/24 from 192/8 and = port {range [137, 139] or 8080}" would be preferred over "all packets to = 10.1.1/24 from 192/8 and port range [137, 139]"...because when comparing = the common prefix for the port, the second rule would have the e bit = set, resulting in a higher prefix, right? =20 [major] I would like to see some discussion about the management of Flow = Specifications and their advertisement order from an operational point = of view. In the case above, if an operator uses the first rule (only), = but later decides to allow web traffic and the system advertises the = second rule, it won't take effect until the first one is withdrawn. = This type of operational consideration is not explained in this = document. =20 683 The code below shows a Python3 implementation of the = comparison 684 algorithm. The full code was tested with Python 3.6.3 and = can be 685 obtained at https://github.com/stoffi92/flowspec-cmp [1]. =20 [minor] I would prefer to see the code in an Appendix. =20 [major] We need to include template text about the licensing in the Code = Component below. Please take a look at the IETF Trust Legal Provisions = and add the appropriate text: = https://trustee.ietf.org/license-info/IETF-TLP-5.pdf =20 687 688 import itertools 689 import ipaddress =20 691 def flow_rule_cmp(a, b): 692 for comp_a, comp_b in = itertools.zip_longest(a.components, 693 b.components): 694 # If a component type does not exist in one rule 695 # this rule has lower precedence 696 if not comp_a: 697 return B_HAS_PRECEDENCE 698 if not comp_b: 699 return A_HAS_PRECEDENCE =20 [] What if the component is not in either? The lines above look like = the wrong outcome could be obtained. Disclaimer: I don't know Python... =20 =20 ... 742 6. Validation Procedure ... 757 The concept can be extended, in the case of Flow = Specification NLRI, 758 to allow other validation procedures. =20 [nit] s/of Flow Specification NLRI/of the Flow Specification NLRI =20 760 A Flow Specification NLRI must be validated such that it is 761 considered feasible if and only if all of the below is true: =20 [major] There is no Normative language above, but I think there is a = contradiction of sorts with the new text below ("Rule a) MAY be = relaxed..."). The introductory text to the rules is "must = be...considered feasible if and only if all of the below is true", which = sounds very strict and specific...but then the Normative exception comes = in ("MAY be relaxed...rules b) and c)...MUST be disregarded") saying = that it doesn't matter. Please reword...perhaps something like: "If a = destination is present...a Flow Specification MUST be validated this = way...otherwise..." =20 763 a) A destination prefix component is embedded in the Flow 764 Specification. =20 766 b) The originator of the Flow Specification matches the = originator 767 of the best-match unicast route for the destination = prefix 768 embedded in the Flow Specification. =20 [major] What is the "best-match unicast route"? Please be specific. =20 770 c) There are no more specific unicast routes, when = compared with 771 the flow destination prefix, that has been received from = a 772 different neighboring AS than the best-match unicast = route, which 773 has been determined in rule b). =20 775 Rule a) MAY be relaxed by configuration, permitting Flow 776 Specifications that include no destination prefix component. = If such 777 is the case, rules b) and c) are moot and MUST be = disregarded. =20 [major] This action opens the door to all sorts of things. I note that = the Security Considerations section simply mentions it without going = into more details. =20 779 By originator of a BGP route, we mean either the BGP = originator path 780 attribute, as used by route reflection, or the transport = address of 781 the BGP peer, if this path attribute is not present. =20 [major] s/BGP originator path attribute, as used by route = reflection/address of the originator in the ORIGINATOR_ID Attribute = [RFC4456] The reference to rfc4456 should be Normative. =20 [minor] rfc4271 doesn't talk about a "transport addresses". Instead, it = talks about the "source IP address". I know it is the same thing, but = please be consistent. =20 783 BGP implementations MUST also enforce that the AS_PATH = attribute of a 784 route received via the External Border Gateway Protocol = (eBGP) 785 contains the neighboring AS in the left-most position of the = AS_PATH 786 attribute. While this rule is optional in the BGP = specification, it 787 becomes necessary to enforce it for security reasons. =20 [major] Is this requirement only for the Flow Specification AFI/SAFI = pairs, or for all address families (IPv4 in the case of this document)? = Why? =20 [major] [Assuming that the answer to the last question is: "Yes, for all = AFs"...] Should all the border routers in the AS enforce the first ASN, = or is the requirement only for routers receiving Flow Specifications? =20 [major] In the case of receiving Flow Specifications from a neighbor in = an IXP, it may not be possible to enforce the rule above if a = "transparent ASN" is being used. Please include some text/guidance = about that type of case. Include it either here or in the Security = Considerations. =20 [nit] The mention of security above makes me want to see related = considerations in =C2=A713/14. =20 789 The best-match unicast route may change over the time = independently 790 of the Flow Specification NLRI. Therefore, a revalidation = of the 791 Flow Specification NLRI MUST be performed whenever unicast = routes 792 change. Revalidation is defined as retesting that clause a = and 793 clause b above are true. =20 [major] What about the case where a destination prefix is not included? = Besides enforcing the first AS, there isn't any verification specified. = What are the consideration about using that option? =20 795 Explanation: =20 797 The underlying concept is that the neighboring AS that = advertises the 798 best unicast route for a destination is allowed to advertise = flow- 799 spec information that conveys a more or equally specific = destination 800 prefix. Thus, as long as there are no more specific unicast = routes, 801 received from a different neighboring AS, which would be = affected by 802 that filtering rule. =20 804 The neighboring AS is the immediate destination of the = traffic 805 described by the Flow Specification. If it requests these = flows to 806 be dropped, that request can be honored without concern that = it 807 represents a denial of service in itself. Supposedly, the = traffic is 808 being dropped by the downstream autonomous system, and there = is no 809 added value in carrying the traffic to it. =20 [major] A rogue router may request the traffic to be dropped. While the = local AS is simply reacting to the neighbor's request, the action can = still result in a DoS. I would like to see rogue router scenarios = reflected in the Security Considerations. =20 [major] All this section seems to assume that flows are controlled = (dropped/redirected) between ASes...but the actions can also be = triggered from inside an AS. What are the considerations in that case? = Why isn't iBGP explicitly considered? =20 =20 811 7. Traffic Filtering Actions ... 820 Implementations SHOULD provide mechanisms that map an = arbitrary BGP 821 community value (normal or extended) to filtering actions = that 822 require different mappings in different systems in the = network. For 823 instance, providing packets with a worse-than-best-effort, = per-hop 824 behavior is a functionality that is likely to be implemented 825 differently in different systems and for which no standard = behavior 826 is currently known. Rather than attempting to define it = here, this 827 can be accomplished by mapping a user-defined community = value to 828 platform-/network-specific behavior via user configuration. =20 [major] While this paragraph sounds technically correct, I think it = doesn't belong in this document because it (randomly) talks about a = different, yet tangentially related, topic. Also, it basically says = "SHOULD provide a mechanism to take arbitrary actions...which are not = defined here", so it is not complete from a Normative point of view. I = would prefer if we took this paragraph out. =20 830 The default action for a traffic filtering Flow = Specification is to 831 accept IP traffic that matches that particular rule. =20 833 This document defines the following extended communities = values shown 834 in Table 2 in the form 0x8xnn where nn indicates the = sub-type. 835 Encodings for these extended communities are described = below. =20 [minor] The "0x8xnn" format doesn't explain what x indicates. Perhaps = it would be better for the format to match the IANA section and include, = for example, 0xttss for type and sub-type...with the corresponding = change in Table 2. =20 837 = +-----------+----------------------+--------------------------------+ 838 | community | action | encoding = | 839 = +-----------+----------------------+--------------------------------+ 840 | 0x8006 | traffic-rate-bytes | 2-byte ASN, 4-byte = float | 841 | TBD | traffic-rate-packets | 2-byte ASN, 4-byte = float | 842 | 0x8007 | traffic-action | bitmask = | 843 | 0x8008 | rt-redirect AS-2byte | 2-octet AS, 4-octet = value | 844 | 0x8108 | rt-redirect IPv4 | 4-octet IPv4 addres, = 2-octet | 845 | | | value = | 846 | 0x8208 | rt-redirect AS-4byte | 4-octet AS, 2-octet = value | 847 | 0x8009 | traffic-marking | DSCP value = | 848 = +-----------+----------------------+--------------------------------+ =20 850 Table 2: Traffic Action Extended Communities =20 [minor] The Table contains terms that have not been defined... It would = be ideal if the Table contained a forward reference to the section where = each action is discussed....or at least a general statement about the = details in the upcoming sub-sections... =20 852 Some traffic action communities may interfere with each = other. 853 Section 7.6 of this specification provides general = considerations on 854 such traffic action interference. Any additional definition = of a 855 traffic actions specified by additional standards documents = or vendor 856 documents MUST specify if the traffic action interacts with = an 857 existing traffic actions, and provide error handling per = [RFC7606]. =20 [nit] s/definition of a traffic actions/definition of traffic actions =20 [major] "Any additional definition of a traffic actions specified by = additional standards documents or vendor documents MUST specify..." We = really can't mandate what vendor documents say. s/additional = definition of a traffic actions specified by additional standards = documents or vendor documents MUST specify/additional definition of a = traffic action MUST specify =20 [major] "MUST specify if the traffic action interacts with an existing = traffic actions" I think you meant something like: "MUST specify the = action to take if..." =20 [major] "Any additional definition of a traffic actions...MUST...provide = error handling per [RFC7606]." rfc7606 already indicates what to do = about a malformed Extended Community attribute, which is how other = actions would presumably be specified. rfc7606 only mandates error = specifications for new attributes. What are your expectations here? =20 859 Multiple traffic actions may be present for a single NLRI. = The 860 traffic actions are processed in ascending order of the = sub-type 861 found in the BGP Extended Communities. If not all of them = can be 862 processed the filter SHALL NOT be applied at all (for = example: if for 863 a given flow there are the action communities = rate-limit-bytes and 864 traffic-marking attached, and the plattform does not support = one of 865 them also the other shall not be applied for that flow). =20 [minor] This paragraph is related to =C2=A77.6 (Considerations on = Traffic Action Interference). Consider putting all the related = information together. =20 [major] "traffic actions are processed in ascending order of the = sub-type" Several of the communities have the same sub-type; if more = than one is present, which one should be processed first? =20 [major] What should a receiver do if multiple of the same community = (type and sub-type) are included in the UPDATE? Would that be also = considered interference? =20 [major] What does "processed" mean? Let me explain... The example is = about not being able to support an action. What about not being able to = apply the action because, for example, the next hop is not reachable? = Would that qualify as not being able to "process" the action? If other = redirect traffic rules are included (with perhaps an alternate next = hop), would the answer be different? =20 [nit] Make the example a sentence on it's own: eliminate the = parenthesis. =20 [minor] s/rate-limit-bytes/traffic-rate-bytes (0x8006) =20 [minor] s/traffic-marking/traffic-marking (0x8009) =20 [nit] s/plattform/platform =20 [major] "If not all of them can be processed the filter SHALL NOT be = applied..." Should they be forwarded? Is this an example of = "interfering flow actions" (=C2=A77.6)? =20 867 All traffic actions are specified as transitive BGP Extended 868 Communities. =20 870 7.1. Traffic Rate in Bytes (traffic-rate-bytes) sub-type 0x06 ... 888 Interferes with: No other BGP Flow Specification traffic = action in 889 this document. =20 [minor] The definition of interference (=C2=A77.6) uses "more than one = conflicting traffic-rate action" as part of it. So it seems that = traffic-rate-bytes and traffic-rate-packets may interfere with each = other. =20 891 7.2. Traffic Rate in Packets (traffic-rate-packets) sub-type = TBD =20 [major] Because the "traffic actions are processed in ascending order of = the sub-type" (=C2=A77), what is the intent for this action? How should = IANA assign it? I assume that the intent might be to process it instead = of traffic-rate-bytes (assuming only one might be present)... Please be = clear in the instructions to IANA (in =C2=A712.3). Note that Table 7 = requests the assignment from the "Generic Transitive Experimental Use = Extended Community Sub-Types" registry, which seems to limit the = assignment choices. Having said all that, I would have assumed that = this action would be a variation of the 0x06 sub-type, but with a = different type... =20 =20 ... 901 Interferes with: No other BGP Flow Specification traffic = action in 902 this document. =20 [minor] The definition of interference (=C2=A77.6) uses "more than one = conflicting traffic-rate action" as part of it. So it seems that = traffic-rate-bytes and traffic-rate-packets may interfere with each = other. =20 904 7.3. Traffic-action (traffic-action) sub-type 0x07 =20 906 The traffic-action extended community consists of 6 bytes of = which 907 only the 2 least significant bits of the 6th byte (from left = to 908 right) are currently defined. =20 910 40 41 42 43 44 45 46 47 911 +---+---+---+---+---+---+---+---+ 912 | reserved | S | T | 913 +---+---+---+---+---+---+---+---+ =20 [minor] s/reserved/Traffic Action Fields It would be nice if the = Figure showed that all the bits (not just the ones in the last octet) = are part of the same field. =20 [nit] Please add a Figure number.. =20 915 where S and T are defined as: =20 917 o T: Terminal Action (bit 47): When this bit is set, the = traffic 918 filtering engine will apply any subsequent filtering = rules (as 919 defined by the ordering procedure). If not set, the = evaluation of 920 the traffic filter stops when this rule is applied. =20 [minor] According to the processing order and the values from Table 2, = not setting the bit would effectively cause only the traffic-rate-bytes = (0x8006) to ever be applied. Is that the correct interpretation? =20 [minor] If the T bit is not set, can a router drop the communities that = are not going to be applied...or should they all be propagated? =20 [major] Clearly, a rogue router could unset the bit before = propagating... =20 922 o S: Sample (bit 46): Enables traffic sampling and logging = for this 923 Flow Specification. =20 [major] If the bit is not set, would sampling/logging be disabled? IOW, = is this an on/off switch, or is just the on action valid? =20 925 o reserved: should always be set to 0 by the originator and = not be 926 evaluated by the receiving BGP speaker. =20 [major] There is a registry for these bits. s/reserved/Traffic Action = Fields =20 =20 ... 934 Interferes with: No other BGP Flow Specification traffic = action in 935 this document. =20 [minor] Based on the definition in =C2=A77.6, I would have thought that = this action, with the T bit unset, would interfere with other actions = that will now not be applied. =20 =20 937 7.4. RT Redirect (rt-redirect) sub-type 0x08 ... 948 It should be noted that the low-order nibble of the = Redirect's Type 949 field corresponds to the Route Target Extended Community = format field 950 (Type). (See Sections 3.1, 3.2, and 4 of [RFC4360] plus = Section 2 of 951 [RFC5668].) The low-order octet (Sub-Type) of the Redirect = Extended 952 Community remains 0x08 for all three encodings of the BGP = Extended 953 Communities (AS 2-byte, AS 4-byte, and IPv4 address). =20 [nit] I think that this whole paragraph is not needed....and it actually = may confuse people. I recommend deleting it. =20 955 Interferes with: All other redirect functions. =20 [minor] What other redirect functions? The only ones defined are in = this section. =20 =20 957 7.5. Traffic Marking (traffic-marking) sub-type 0x09 =20 959 The traffic marking extended community instructs a system to = modify 960 the DSCP bits of a transiting IP packet to the corresponding = value. 961 This extended community is encoded as a sequence of 5 zero = bytes 962 followed by the DSCP value encoded in the 6 least = significant bits of 963 6th byte. =20 [major] What action (if any) should a receiver take if the "5 zero = bytes" are not (all) set to 0? Maybe include something like: "MUST be = ignored when received...". =20 965 Interferes with: No other BGP Flow Specification traffic = action in 966 this document. =20 968 7.6. Considerations on Traffic Action Interference =20 970 Since traffic actions are represented as BGP extended = community 971 values, traffic actions may interfere with each other (ie. = there may 972 be more than one conflicting traffic-rate action associated = with a 973 single flow-filter). Traffic action interference has no = impact on 974 BGP propagation of flow filters (all communities are = propagated 975 according to policies). =20 [nit] s/ie./e.g. I'm assuming it is an example and not the only case. =20 [minor] Is "Traffic action interference" only the case when actions = describe conflicting actions? For example, different traffic rates. = Specifically, are actions that can't be applied (as described on = =C2=A77), also considered as interference? =20 977 If a flow filter associated with interfering flow actions is = selected 978 for packet forwarding, it is a implementation decision which = of the 979 interfering traffic actions are selected. Implementors of = this 980 specification SHOULD document the behaviour of their = implementation 981 in such cases. =20 [major] IOW, deployment of a set of "interfering flow actions" could = result in inconsistent behavior in the network. Could a rogue BGP = speaker advertise (or even add/delete) actions to a Flow Specification = and cause unexpected results? I guess that depending on what the action = is, there could be a significant effect. I think this is a = vulnerability that should be called out explicitly. Thinking a little = bit more...there are two vulnerabilities: (1) add/delete in the normal = case (even with consistent behavior), and (2) add/delete to exploit a = specific behavior of a node in the network. =20 983 If required, operators are encouraged to make use of the BGP = policy 984 framework supported by their implementation in order to = achieve a 985 predictable behaviour (ie. match - replace - delete = communities on 986 administrative boundaries). =20 [minor] "If required..." When it is not required? IOW, I think that = those two words are not needed. =20 =20 988 8. Dissemination of Traffic Filtering in BGP/MPLS VPN = Networks =20 990 Provider-based Layer 3 VPN networks, such as the ones using = a BGP/ 991 MPLS IP VPN [RFC4364] control plane, may have different = traffic 992 filtering requirements than Internet service providers. But = also 993 Internet service providers may use those VPNs for scenarios = like 994 having the Internet routing table in a VRF, resulting in the = same 995 traffic filtering requirements as defined for the global = routing 996 table environment within this document. This document = proposes an 997 additional BGP NLRI type (AFI=3D1, SAFI=3D134) value, which = can be used 998 to propagate traffic filtering information in a BGP/MPLS VPN 999 environment. =20 [nit] s/proposes/defines (or maybe specifies) =20 1001 The NLRI format for this address family consists of a = fixed-length 1002 Route Distinguisher field (8 bytes) followed by a Flow = Specification, 1003 following the encoding defined above in Section 4.2 of this = document. 1004 The NLRI length field shall include both the 8 bytes of the = Route 1005 Distinguisher as well as the subsequent Flow Specification. =20 [minor] s/Flow Specification, following the encoding defined above in = Section 4.2 of this document./Flow Specification (Section 4.2). =20 =20 ... 1017 Propagation of this NLRI is controlled by matching Route = Target 1018 extended communities associated with the BGP path = advertisement with 1019 the VRF import policy, using the same mechanism as described = in "BGP/ 1020 MPLS IP VPNs" [RFC4364].. =20 [nit] s/"BGP/MPLS IP VPNs"/BGP/MPLS IP VPNs =20 1022 Flow Specification rules received via this NLRI apply only to = traffic 1023 that belongs to the VRF(s) in which it is imported. By = default, 1024 traffic received from a remote PE is switched via an MPLS = forwarding 1025 decision and is not subject to filtering. =20 1027 Contrary to the behavior specified for the non-VPN NLRI, flow = rules 1028 are accepted by default, when received from remote PE = routers. =20 [major] The only other mention of "flow rule" is in the Introduction = when referring to the validation of external Flow Specifications, which = seems to then map to =C2=A76...but the next sub-section says that those = procedures apply. What am I missing? =20 =20 1030 8.1. Validation Procedures for BGP/MPLS VPNs =20 1032 The validation procedures are the same as for IPv4. =20 1034 8.2. Traffic Actions Rules =20 1036 The traffic action rules are the same as for IPv4. =20 [nit] These 2 sub-sections could simply be covered by a couple of = sentences... =20 =20 1038 9. Limitations of Previous Traffic Filtering Efforts =20 [major] This section reads like a justification... I think it would be = a better fit as a subsection of the Introduction. =20 1040 9.1. Limitations in Previous DDoS Traffic Filtering Efforts ... 1052 Several techniques are currently used to control traffic = filtering of 1053 DoS attacks. Among those, one of the most common is to = inject 1054 unicast route advertisements corresponding to a destination = prefix 1055 being attacked (commonly known as remote triggered blackhole = RTBH). 1056 One variant of this technique marks such route advertisements = with a 1057 community that gets translated into a discard Next-Hop by the 1058 receiving router. Other variants attract traffic to a = particular 1059 node that serves as a deterministic drop point. =20 [minor] Please add Informative references to rfc3882, rfc5635, = rfc7999... =20 =20 ... 1103 10. Traffic Monitoring =20 1105 Traffic filtering applications require monitoring and traffic 1106 statistics facilities. While this is an = implementation-specific 1107 choice, implementations SHOULD provide: =20 1109 o A mechanism to log the packet header of filtered traffic. =20 1111 o A mechanism to count the number of matches for a given = flow 1112 specification rule. =20 [minor] Is there any relationship between this section and the S bit in = =C2=A77.3? =20 =20 1114 11. Error-Handling and Future NLRI Extensions =20 [major] Suggestion: this section should be limited to describing what a = malformed traffic action extended community is, and then simply point to = rfc7606, which already covers the rest. See more comments below. =20 [nit] The two topics covered here seem unrelated... =20 1116 In case BGP encounters an error in a Flow Specification = UPDATE 1117 message it SHOULD treat this message as Treat-as-withdraw = according 1118 to [RFC7606] Section 2. =20 [major] The SHOULD above with the communities-related errors described = below are in conflict with rfc7606, which says this: "An UPDATE message = with a malformed Extended Community attribute SHALL be handled using the = approach of "treat-as-withdraw"." =20 1120 Possible reasons for an error are (for more reasons see also 1121 [RFC7606]): =20 1123 o Incorrect implementation of this specification - the = encoding/ 1124 decoding of the NLRI or traffic action = extended-communities do not 1125 comply with this specification. =20 [major] Related to the NLRI, rfc7606 says that "in order to use the = approach of "treat-as-withdraw", the entire NLRI field and/or the = MP_REACH_NLRI and MP_UNREACH_NLRI attributes need to be successfully = parsed... If this is not possible...that the "session reset" approach = (or the "AFI/SAFI disable" approach) MUST be followed." =20 [major] For the Extended Communities... The "incorrect implementation" = basically means that the encoding is wrong, right? But is the part = about "comply with this specification" necessary? Other traffic action = extended communities (defined elsewhere) might be received. I would = rather if the text above talked about malformed (to match the language = in rfc7606) traffic action extended communities in general (not just the = ones in this specification). =20 1127 o Unknown Flow Specification extensions - The sending party = has 1128 implemented a Flow Specification NLRI extension unknown to = the 1129 receiving party. =20 [major] This treatment of unknown extensions is in conflict with the = text in =C2=A74.2: "If a given component type within a prefix in = unknown, the prefix in question cannot be used for traffic filtering = purposes by the receiver... However, for the purposes of BGP route = propagation, this prefix should still be transmitted since BGP route = distribution is independent on NLRI semantics." IOW, = "treat-as-withdraw" is not compatible with forwarding UPDATES. =20 1131 In order to facilitate future extensions of the Flow = Specification 1132 NLRI, such extensions SHOULD specify a way to encode a = "always-true" 1133 match condition within the newly introduced components.. = This match 1134 condition can be used to propagate (and apply) certain = filters only 1135 if a specific extension is known to the implemenation. =20 [nit] s/a "always-true"/an "always-true" =20 [minor] What does "always-true" mean? =20 [major] How come this document doesn't follow the advice about the = "always-true" match condition? =20 [nit] s/implemenation/implementation =20 =20 ... 1141 12.1. AFI/SAFI Definitions =20 1143 IANA maintains a registry entitled "SAFI Values". For the = purpose of 1144 this work, IANA updated the registry and allocated two = additional 1145 SAFIs: =20 [nit] Even though the text will probably end up as written, it doesn't = ask IANA for anything: it assumes that the work is done. I would prefer = it if the text was worded as a request. It may not be an issue for = IANA, so there's no need to change anything, unless they say so. =20 1147 = +-------+------------------------------------------+----------------+ 1148 | Value | Name | = Reference | 1149 = +-------+------------------------------------------+----------------+ 1150 | 133 | IPv4 dissemination of Flow Specification | [this = | 1151 | | rules | = document] | 1152 | 134 | VPNv4 dissemination of Flow | [this = | 1153 | | Specification rules | = document] | 1154 = +-------+------------------------------------------+----------------+ =20 [major] It's not clear to me (because there's no explicit request) if = the intent is to add this document as a reference, or to replace the one = to rfc5575. I would like you to be explicit. =20 1156 Table 3: Registry: SAFI Values =20 1158 12.2. Flow Component Definitions ... 1184 In order to manage the limited number space and accommodate = several 1185 usages, the following policies defined by [RFC8126] used: =20 [nit] s/[RFC8126] used/[RFC8126] are used =20 1187 +--------------+-------------------------------+ 1188 | Range | Policy | 1189 +--------------+-------------------------------+ 1190 | 0 | Invalid value | 1191 | [1 .. 12] | Defined by this specification | 1192 | [13 .. 127] | Specification required | 1193 | [128 .. 255] | First Come First Served | 1194 +--------------+-------------------------------+ =20 [major] 0 is not really a range...and it's Invalid, so it shouldn't be = part of the Table detailing the registration policies. BTW, I couldn't = find the text where 0 is declared Invalid -- please add some text to = =C2=A74.2. Move 0 to Table 4. =20 [minor] Besides the fact that "Defined by this specification" is not a = Policy, this table doesn't change anything in the current registry; it = is not needed. =20 1196 Table 5: Flow Spec Component Types Policies =20 1198 The specification of a particular "Flow Spec Component Type" = must 1199 clearly identify what the criteria used to match packets = forwarded by 1200 the router is. This criteria should be meaningful across = router hops 1201 and not depend on values that change hop-by-hop such as TTL = or Layer 1202 2 encapsulation. =20 [minor] This paragraph doesn't belong in the IANA section. It seems to = be laying out the groundwork for new components...so it belongs = somewhere else. Should any of the language be Normative? =20 =20 1204 12.3. Extended Community Flow Specification Actions =20 1206 The Extended Community Flow Specification Action types = defined in 1207 this document consist of two parts: =20 1209 Type (BGP Transitive Extended Community Type) =20 1211 Sub-Type =20 1213 For the type-part, IANA maintains a registry entitled "BGP = Transitive 1214 Extended Community Types". For the purpose of this work = (Section 7), 1215 IANA updated the registry to contain the values listed below: =20 [major] The range is defined in the registry as "0x80-0x8f = Reserved for Experimental Use". According to rfc8126, "IANA does not = record assignments from registries or ranges with this policy". =20 I don't know why 0x80 was the first value chosen; it looks like it was = first used in draft-marques-idr-flow-spec-01 (2004), while the = corresponding Extended Communities draft = (draft-ietf-idr-bgp-ext-communities-07) already indicated that the range = was for Experimental Use. I guess just lack of sync... But then I also = don't understand how/why IANA ended up with the information in the = Registry....maybe because the sub-types are not for Experimental Use -- = hmmm, which sounds contradictory to me. =20 The reason/history doesn't matter anymore, but the current use does. = The mechanism described in this document is clearly not experimental. = Given that changing the Type values is not an option because of the = deployed base, etc.., then I think we should clean up the Registry and = move 0x80-0x82 from the Experimental Use range to the FCFS range. This = change would mean an Update to rfc7153. =20 To simplify the process, the Update can be done in this document. = However, I think that there's some confusion with these types apparently = being associated only with Flow Specifications, when they are labeled as = Generic. IOW, ideally the issue would be corrected independently... =20 =20 1217 = +-------+-----------------------------------------------+-----------+ 1218 | Type | Name | = Reference | 1219 | Value | | = | 1220 = +-------+-----------------------------------------------+-----------+ 1221 | 0x80 | Generic Transitive Experimental Use Extended | = [RFC7153] | 1222 | | Community (Sub-Types are defined in the | = | 1223 | | "Generic Transitive Experimental Use Extended | = | 1224 | | Community Sub-Types" registry) | = | 1225 | 0x81 | Generic Transitive Experimental Use Extended | = [this | 1226 | | Community Part 2 (Sub-Types are defined in | = document] | 1227 | | the "Generic Transitive Experimental Use | = [See | 1228 | | Extended Community Part 2 Sub-Types" | = Note-1] | 1229 | | Registry) | = | 1230 | 0x82 | Generic Transitive Experimental Use Extended | = [this | 1231 | | Community Part 3 (Sub-Types are defined in | = document] | 1232 | | the "Generic Transitive Experimental Use | = [See | 1233 | | Extended Community Part 3 Sub-Types" | = Note-1] | 1234 | | Registry) | = | 1235 = +-------+-----------------------------------------------+-----------+ =20 1237 Table 6: Registry: Generic Transitive Experimental Use = Extended 1238 Community Types =20 [major] In line with Updating the registry and the intent, the names of = the Types/Registries should not include the word "experimental" to avoid = any further confusion. =20 1240 Note-1: This document obsoletes RFC7674. =20 [minor] Putting the reference to this note in the Table seems to be = asking IANA to add a note there too...which I would think is not the = case. This goes back to the intent of whether the reference to this = document should replace what is there or simply be added. =20 =20 ... 1292 The "traffic-action" extended community (Section 7.3) defined = in this 1293 document has 46 unused bits, which can be used to convey = additional 1294 meaning. IANA created and maintains a new registry entitled: 1295 "Traffic Action Fields". These values should be assigned via = IETF 1296 Review rules only. The following traffic-action fields have = been 1297 allocated: =20 [major] It needs to be mentioned somewhere that the reference for the = whole registry (not just the values below) should be moved to this = document. =20 =20 ... 1308 13. Security Considerations =20 1310 Inter-provider routing is based on a web of trust. = Neighboring 1311 autonomous systems are trusted to advertise valid = reachability 1312 information. If this trust model is violated, a neighboring 1313 autonomous system may cause a denial-of-service attack by = advertising 1314 reachability information for a given prefix for which it does = not 1315 provide service. =20 [major] References to Origin Validation (rfc6811) and BGPSec (rfc8205) = should be mentioned as possible mitigation...with maybe a comment about = the current deployment status. =20 1317 As long as traffic filtering rules are restricted to match = the 1318 corresponding unicast routing paths for the relevant = prefixes, the 1319 security characteristics of this proposal are equivalent to = the 1320 existing security properties of BGP unicast routing. = However, this 1321 document also specifies traffic filtering actions that may = need 1322 custom additional verification on the receiver side. See = Section 14. =20 [major] In general, Flow Specifications have a one-AS-hop propagation = model, right? This means that the security properties are different = because (1) unicast routing propagates multiple hops, and (2) the intent = of the "Route Origin ASN" (rfc6811) is not reflected in the request to = rate-limit, or even drop (!) traffic to a destination. Yes, it is all = based on trust...but different. For example, Origin Validation wouldn't = be available for Flow Specifications. =20 1324 Where it is not the case, this would open the door to further = denial- 1325 of-service attacks. =20 [major] Like what? What are possible mitigations? Just saying that the = door is open is not enough. =20 =20 ... 1337 14. Operational Security Considerations =20 [minor] If you ask me, this section should be rolled into the last one: = I think all the considerations (in both sections) are really = operational... =20 1339 While the general verification of the traffic filter NLRI is 1340 specified in this document (Section 6) the traffic filtering = actions 1341 received by a third party may need custom verification or = filtering. 1342 In particular all non traffic-rate actions may allow a third = party to 1343 modify packet forwarding properties and potentially gain = access to 1344 other routing-tables/VPNs or undesired queues. This can be = avoided 1345 by proper filtering of action communities at network borders = and by 1346 mapping user-defined communities (see Section 7) to expose = certain 1347 forwarding properties to third parties. =20 [minor] I didn't get this last part... I understand filtering, but = didn't quite understand how the mapping of communities would help. =20 1349 Since verfication of the traffic filtering NLRI is tied to = the 1350 announcement of the best unicast route, a unfiltered address = space 1351 hijack (e.g. advertisement of a more specific route) may = cause this 1352 verification to fail and consequently prevent Flow = Specification 1353 filters from being accepted by a peer. =20 [nit] s/verfication/verification =20 [nit] s/a unfiltered/an unfiltered =20 [minor] Again, mention Origin Validation as possible mitigation. =20 1355 15. Original authors =20 1357 Barry Greene, Pedro Marques, Jared Mauch, Danny McPherson, = and 1358 Nischal Sheth were authors on RFC5575, and therefore are = contributing 1359 authors on this document. =20 [minor] To be in line with rfc7322, this section should be renamed to = "Contributors". =20 =20 1361 16. Acknowledgements ... 1370 A packet rate flowspec action was also discribed in a = flowspec 1371 extention draft and the authors like to thank Wesley Eddy, = Justin 1372 Dailey and Gilbert Clark for their work. =20 [nit] This is the first time that "flowspec" is used. Not a bad = thing...just an observation that we went through the whole document = without using the colloquial name flowspec. =20 [nit] s/discribed/described =20 [nit] s/extention/extension =20 1374 Additional the authors would like to thank Alexander = Mayrhofer, 1375 Nicolas Fevrier, Job Snijders, Jeffrey Haas and Adam Chappell = for 1376 their comments and review. =20 [nit] s/Additional/Additionally, =20 =20 1378 17. References =20 1380 17.1. Normative References =20 1382 [IEEE.754.1985] 1383 IEEE, "Standard for Binary Floating-Point = Arithmetic", 1384 IEEE 754-1985, August 1985. =20 [minor] IEEE has revised this spec twice, the most current revision was = published earlier this year. Should the reference to the 1985 version = be kept? Is there a reason not to point generically to IEEE 754, = instead of to a specific version? =20 =20 ... 1419 [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet = AS 1420 Specific BGP Extended Community", RFC 5668, 1421 DOI 10.17487/RFC5668, October 2009, 1422 . =20 [minor] I don't think this needs to be a Normative reference. =20 =20 ... 1458 Appendix A. Comparison with RFC 5575 ... 1464 Section 1 introduces the Flow Specification NLRI. In = RFC5575 this 1465 NLRI was defined as an opaque-key in BGPs database. This 1466 specification has removed all references to a opaque-key = property. 1467 BGP is able understand the NLRI encoding. This change = also 1468 resulted in a new section regarding error-handling and 1469 extensibility (Section 11). =20 [nit] s/able understand/able to understand =20 =20 ------=_NextPart_000_009F_01D56F8B.0C7725D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

John:

 

<author hat on>

The author team is close to finishing its work on = RFC5575bis.=C2=A0=C2=A0 Alvaro asks one clear questions of the chairs = =E2=80=93should we include the v6 portion into the revision of = RFC5575bis. =C2=A0=C2=A0=C2=A0In my earlier discussion on the list as WG = Chair, I indicated that the WG had asked that the RFC5575bis would not = include the v6 version.=C2=A0 =C2=A0=C2=A0

 

Alvaro has clearly indicated that the RFC5575bis would appear at the = IESG with the v6 version.=C2=A0=C2=A0

 

I would that you query the WG regarding:

=C2=B7         = RFC5575bis + draft-ietf-idr-flow-spec-v6-09.txt =

=C2=B7         = RFC5575bis with the v6 specification included. =

Thank = you,

Susan = Hares

 

 

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Alvaro = Retana
Sent: Tuesday, September 10, 2019 12:09 = PM
To: draft-ietf-idr-rfc5575bis@ietf.org
Cc: = idr@ietf. org; idr-chairs@ietf.org
Subject: [Idr] AD Review of = draft-ietf-idr-rfc5575bis-17

 

Dear = authors:

&nbs= p;

I just = finished reading this document.  Thank you for the work in = clarifying and updating rfc5575!  Many of my comments (see below) = are related to what I think is still missing clarity, or lack of it in = some of the new text.

&nbs= p;

Besides = the specific comments, I have some larger issues that I want to detail = here.  The first 2 are directed at the Shepherd and = Chairs.

&nbs= p;

(A) = IPR

&nbs= p;

The = Shepherd report, the datatracker and the WGLC thread [1] all point at no = existing IPR.  However, several declarations do exist...for rfc5575 = [2].  IMO, the changes between rfc5575 and this document are not = that significant to assume that the declarations don't apply..  I = also note that none of the original authors mentioned as = "contributing authors" (=C2=A715) replied to the IPR call = during the WGLC..

&nbs= p;

Jie: As = Shepherd, can you please file a third-party disclosure [3] pointing at = the rfc5575 disclosures?  Once that is done I will send a message = to the WG to consider the information -- I don't expect any issues, but = it has to be done. I'll need you to also update the Shepherd = writeup.  Thanks!

&nbs= p;

&nbs= p;

(B) = Support for IPv6

&nbs= p;

I = understand why this document only focuses on IPv4.  While the text = points at draft-ietf-idr-flow-spec-v6, that draft has been expired for = over a year!  What is the plan to move that work forward?  It = looks like there may already be implementations in place = [4].

&nbs= p;

We all = know this question will come up during IESG Evaluation, specially in = light of the IAB Statement on IPv6 [5] and the fact that there was a = related DISCUSS when rfc5575 was first processed [6] -- at that time = (2009!) the objection was cleared with the promise that an IPv6 document = would be forthcoming.

&nbs= p;

We = should have a plan in place by the time this document makes it to the = IESG Telechat.  It would have been ideal to publish both at the = same time, but I'll settle for the ability to (at least) point at the = WGLC (which has been brought up before = [7]).

&nbs= p;

&nbs= p;

(C) IANA = Considerations

&nbs= p;

(C1) = traffic-rate-packets

&nbs= p;

The = instructions to IANA for the assignment of the traffic-rate-packets = sub-type are not clear.  The existing assignments and the = requirement that "traffic actions are processed in ascending order = of the sub-type" (=C2=A77) seem to imply that a specific order for = this new action may be intended.  Unless explicitly instructed, = IANA may not assign a value that aligns with that intent.  [See = related comments in =C2=A77.2.]

&nbs= p;

(C2) = Experimental Use Ranges

&nbs= p;

This = document uses ranges from the "BGP Transitive Extended Community = Types" registry which are reserved for Experimental Use.  = While the history of this use is not clear, we should take the = opportunity to clean the registry.  [See more in = =C2=A712.3.]

&nbs= p;

&nbs= p;

(D) = Document organization

&nbs= p;

This = document kept most of the Introduction text, but then added related and, = in some cases, overlapping and redundant text in =C2=A75 (not =C2=A75.1) = and =C2=A79.  Please combine the information from =C2=A71 and = =C2=A75, and the background from =C2=A79 into an updated Introduction. =  =C2=A76 seems to belong right after the definition of the NLRI = (=C2=A74), and before the next part of the specification (filtering) = starts with =C2=A75.1, then = =C2=A77...

&nbs= p;

Most of = the old text is about justification, some from the specific point of = view of the then-authors.  Please reconsider whether that still = applies.

&nbs= p;

&nbs= p;

I will = wait for the major issues/comments to be addressed before starting the = IETF Last Call.

&nbs= p;

Thanks!

&nbs= p;

Alvaro.

&nbs= p;

&nbs= p;

[5] https://ww= w.iab.org/2016/11/07/iab-statement-on-ipv6/

&nbs= p;

&nbs= p;

&nbs= p;

[Line = numbers from idnits.]

&nbs= p;

...<= /o:p>

17=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Abstract

&nbs= p;

[nit] It = is interesting to me that the Abstract was significantly rewritten while = the Introduction was mostly left unchanged.  I assume this was done = to reflect the changes in the document upfront...but it then results in, = what I think, is an Abstract that is too long, and an incomplete = Introduction.

&nbs= p;

19=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   This document defines a Border Gateway Protocol Network = Layer

20=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Reachability Information (BGP NLRI) encoding format that = can be used

21=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   to distribute traffic Flow Specifications.  This = allows the routing

22=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   system to propagate information regarding more specific = components of

23=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   the traffic aggregate defined by an IP destination = prefix.

&nbs= p;

25=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   It specifies IPv4 traffic Flow Specifications via a BGP = NLRI which

26=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   carries traffic Flow Specification filter, and an = Extended community

27=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   value which encodes actions a routing system can take if = the packet

28=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   matches the traffic flow filters.  The flow filters = and the actions

29=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   are processed in a fixed order.  Other drafts = specify IPv6, MPLS

30=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   addresses, L2VPN addresses, and NV03 encapsulation of IP = addresses.

&nbs= p;

[nit] = s/carries traffic Flow Specification filter/carries a traffic Flow = Specification filter

&nbs= p;

[minor] = I think that this paragraph, or something like it, belongs in the = Introduction (and not the Abstract), because it provides information = that could benefit from references:

&nbs= p;

- the = two parts of the NLRI; BTW, the community is not even mentioned in the = Introduction.

&nbs= p;

- other = drafts... The Introduction only mentions and provides a reference to the = IPv6 work.

&nbs= p;

32=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   This document obsoletes RFC5575 and RFC7674 to correct = unclear

33=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   specifications in the flow = filters.

&nbs= p;

[major] = Please add a similar statement in the Introduction, with references to = both RFCs.  There should be an Informative reference to = both.

&nbs= p;

[minor] = Appendix A talks about the difference of this document with respect to = rfc5575.  What about rfc7674?  It looks like any updates from = rfc7674 have been incorporated in this document.  It would be very = nice, even if just for completion, if there was an Appendix that talked = about rfc7674 -- I even think that a sub-section of Appendix A would be = enough.

&nbs= p;

35=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Applications which use the bgp Flow Specification are: 1) = application

36=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   which automate inter-domain coordination of traffic = filtering, such

37=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   as what is required in order to mitigate (distributed) = denial-of-

38=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   service attacks; 2) applications which control traffic = filtering in

39=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   the context of a BGP/MPLS VPN service, and 3) = applications with

40=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   centralized control of traffic in a SDN or NFV = context.  Some

41=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   deployments of these three applications can be handled by = the strict

42=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   ordering of the BGP NLRI traffic flow filters, and the = strict actions

43=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   encoded in the extended community Flow Specification = actions.

&nbs= p;

[minor] = Please move this paragraph to the = Introduction.

&nbs= p;

[nit] = s/extended community/Extended = Community/g

&nbs= p;

&nbs= p;

...<= /o:p>

133=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 1.  Introduction

...<= /o:p>

149=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   This document defines a general procedure to encode = flow

150=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   specification rules for aggregated traffic flows so that they can = be

151=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   distributed as a BGP [RFC4271] NLRI.  Additionally, we = define the

152=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   required mechanisms to utilize this definition to the problem = of

153=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   immediate concern to the authors: intra- and = inter-provider

154=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   distribution of traffic filtering rules to filter = (distributed)

155=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   denial-of-service (DoS) = attacks.

&nbs= p;

[minor] = The document uses "Flow Specification" and "flow = specification" to refer to the same thing...right?  Or are = there differences due to the capitalization?  Please be = consistent.

&nbs= p;

[style = nit] Using "we" is not the best for a consensus document. =  s/we define/it defines

&nbs= p;

[nit] = "problem of immediate concern to the authors"  Only the = authors?  This piece of text was also present in rfc5575 -- having = a different set of authors, I would assume we can safely say that the = concern/application goes beyond the authors...right?  Please = reword.

&nbs= p;

[minor] = Given that this is a bis, is the motivation still the same?  I = think in part it is, but in part there may be other drivers.  Just = asking...

&nbs= p;

[minor] = This seems to be a good place to move the text from the Abstract that = describes applications...

&nbs= p;

...<= /o:p>

164=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   A Flow Specification received from an external autonomous system = will

165=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   need to be validated against unicast routing before being = accepted.

166=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   If the aggregate traffic flow defined by the unicast = destination

167=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   prefix is forwarded to a given BGP peer, then the local system = can

168=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   install more specific flow rules that may result in = different

169=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   forwarding behavior, as requested by this = system.

&nbs= p;

[major] = "A Flow Specification received from an external autonomous system = will need to be validated against unicast routing before being = accepted."  What about if received = internally?

&nbs= p;

171=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   The key technology components required to address the class = of

172=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   problems targeted by this document = are:

&nbs= p;

174=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   1.  Efficient point-to-multipoint distribution of control = plane

175=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =       information.

&nbs= p;

177=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   2.  Inter-domain capabilities and routing policy = support.

&nbs= p;

179=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   3.  Tight integration with unicast routing, for = verification

180=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =       purposes.

&nbs= p;

182=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Items 1 and 2 have already been addressed using BGP for other = types

183=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   of control plane information.  Close integration with BGP = also makes

184=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   it feasible to specify a mechanism to automatically verify = flow

185=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   information against unicast routing.  These factors are = behind the

186=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   choice of BGP as the carrier of Flow Specification = information.

&nbs= p;

[nit] I = don't think that we need to keep justifying...  Just a = nit...

&nbs= p;

188=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   As with previous extensions to BGP, this specification makes = it

189=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   possible to add additional information to Internet routers.  = These

190=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   are limited in terms of the maximum number of data elements they = can

191=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   hold as well as the number of events they are able to process in = a

192=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   given unit of time.  The authors believe that, as with = previous

193=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   extensions, service providers will be careful to keep = information

194=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   levels below the maximum capacity of their = devices.

&nbs= p;

196=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Experience with previous BGP extensions has also shown that = the

197=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   maximum capacity of BGP speakers has been gradually = increased

198=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   according to expected loads.  For example Internet unicast = routing as

199=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   well as other BGP applications increased their maximum capacity = as

200=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   they gain popularity.

&nbs= p;

[minor] = This is the same text from 10 years ago.  Many things, including = hardware processing/storage, has changed.  Is this text still = necessary?  If so, then I would like to see explicit operational = considerations on what an operator should look for when being = "careful".

&nbs= p;

&nbs= p;

...<= /o:p>

214=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   In current deployments, the information distributed by the = flow-spec

215=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   extension is originated both manually as well as = automatically.  The

216=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   latter by systems that are able to detect malicious flows.  = When

217=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   automated systems are used, care should be taken to ensure = their

218=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   correctness as well as to limit the number and advertisement rate = of

219=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   flow routes.

&nbs= p;

[major] = An automated system that is not "correct", because it may not = be properly programmed, the algorithms used are not performing as = expected, or simply because it is rogue, are all vulnerabilities that = should be called out in the Security Considerations = section.

&nbs= p;

221=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   This specification defines required protocol extensions to = address

222=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   most common applications of IPv4 unicast and VPNv4 unicast = filtering.

223=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   The same mechanism can be reused and new match criteria added = to

224=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   address similar filtering needs for other BGP address families = such

225=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   as IPv6 families = [I-D.ietf-idr-flow-spec-v6],

&nbs= p;

[nit] = s/[I-D.ietf-idr-flow-spec-v6],/[I-D.ietf-idr-flow-spec-v6].

&nbs= p;

&nbs= p;

227=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 2.  Definitions of Terms Used in This = Memo

...<= /o:p>

233=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Loc-RIB -   Local RIB.

&nbs= p;

[major] = This simple definition doesn't match the one in = =C2=A71.1/rfc4271.

&nbs= p;

&nbs= p;

..

247=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 3.  Flow Specifications

...<= /o:p>

266=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   BGP itself treats the NLRI as an key to an entry in its = databases.

267=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Entries that are placed in the Loc-RIB are then associated with = a

268=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   given set of semantics, which is application dependent.  = This is

269=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   consistent with existing BGP applications.  For instance, IP = unicast

270=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   routing (AFI=3D1, SAFI=3D1) and IP multicast reverse-path = information

271=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   (AFI=3D1, SAFI=3D2) are handled by BGP without any particular = semantics

272=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   being associated with them until installed in the = Loc-RIB.

&nbs= p;

[nit] = s/an key/a key

&nbs= p;

274=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Standard BGP policy mechanisms, such as UPDATE filtering by = NLRI

275=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   prefix as well as community matching and manipulation, MUST apply = to

276=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   the Flow Specification defined NLRI-type, especially in an = inter-

277=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   domain environment.  Network operators can also control = propagation

278=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   of such routing updates by enabling or disabling the exchange of = a

279=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   particular (AFI, SAFI) pair on a given BGP peering = session.

&nbs= p;

[major] = The point of NLRIs all being treated the same is made above, to = reinforce the default BGP behavior...and this paragraph tries to bring = home the point by Normatively enforcing it (MUST).  However, = because the behavior is what BGP specifies by default, then this = document cannot be Normative in it (unless it specified an exception). =  s/MUST/must

&nbs= p;

281=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 4.  Dissemination of IPv4 FLow Specification = Information

...<= /o:p>

287=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   This NLRI information is encoded using MP_REACH_NLRI = and

288=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   MP_UNREACH_NLRI attributes as defined in [RFC4760].  = Whenever the

289=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   corresponding application does not require Next-Hop information, = this

290=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   shall be encoded as a 0-octet length Next Hop in the = MP_REACH_NLRI

291=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   attribute and ignored on = receipt.

&nbs= p;

[minor] = s/Next-Hop/Next Hop       rfc4760 uses "Next = Hop"

&nbs= p;

[nit] = "...shall be encoded as a 0-octet length Next Hop in the = MP_REACH_NLRI attribute and ignored on receipt."  What is = ignored?  The Next Hop?  If it doesn't exist (length =3D 0), = then it can't be ignored...  Perhaps delete " and ignored on = receipt".

&nbs= p;

...<= /o:p>

297=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =       = +------------------------------+

298=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =       |    length (0xnn or 0xfn nn) =  |

299=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =       = +------------------------------+

300=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =       |    NLRI value  (variable)   =  |

301=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =       = +------------------------------+

&nbs= p;

[minor] = s/0xfn nn/0xfnnn

&nbs= p;

&nbs= p;

...<= /o:p>

312=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 4.1.  Length Encoding

&nbs= p;

314=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   o  If the NLRI length value is smaller than 240 (0xf0 hex), = the

315=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      length field can be encoded as a single = octet.

&nbs= p;

[nit] = s/240/240 octets

&nbs= p;

317=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   o  Otherwise, it is encoded as an extended-length 2-octet = value in

318=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      which the most significant nibble of the first byte = is all ones.

&nbs= p;

320=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   In figure 1 above, values less-than 240 are encoded using two = hex

321=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   digits (0xnn).  Values above 239 are encoded using 3 hex = digits

322=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   (0xfnnn).  The highest value that can be represented with = this

323=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   encoding is 4095.  The value 241 is encoded as = 0xf0f1.

&nbs= p;

[nit] It = may make more sense to show the encoding for = 240.

&nbs= p;

&nbs= p;

325=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 4.2.  NLRI Value Encoding

...<= /o:p>

332=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   The encoding of each of the NLRI components begins with a type = field

333=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   (1 octet) followed by a variable length parameter.  Section = 4.2.1 to

334=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Section 4.2.12 define component types and parameter encodings for = the

335=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   IPv4 IP layer and transport layer headers.  IPv6 NLRI = component types

336=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   are described in = [I-D.ietf-idr-flow-spec-v6].

&nbs= p;

[minor] = "followed by a variable length parameter"   Only the = first two types have a variable length = parameter...

&nbs= p;

338=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Flow Specification components must follow strict type ordering = by

339=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   increasing numerical order.  A given component type may = (exactly

340=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   once) or may not be present in the specification.  If = present, it

341=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   MUST precede any component of higher numeric type = value.

&nbs= p;

[major] = What should happen if a component appears more than = once?

&nbs= p;

[major] = What should happen if the order is not = maintained?

&nbs= p;

343=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   All combinations of component types within a single NLRI are = allowed,

344=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   even if the combination makes no sense from a semantical = perspective.

345=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   If a given component type within a prefix in unknown, the prefix = in

346=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   question cannot be used for traffic filtering purposes by = the

347=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   receiver.  Since a Flow Specification has the semantics of a = logical

348=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   AND of all components, if a component is FALSE, by definition = it

349=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   cannot be applied.  However, for the purposes of BGP = route

350=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   propagation, this prefix should still be transmitted since BGP = route

351=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   distribution is independent on NLRI = semantics.

&nbs= p;

[nit] = s/prefix in unknown/prefix is unknown

&nbs= p;

[nit] = s/independent on NLRI/independent of = NLRI

&nbs= p;

[major] = "...for the purposes of BGP route propagation, this prefix should = still be transmitted since BGP route distribution is independent on NLRI = semantics."  I think this is a vulnerability: a (large) set of = meaningless Flow Specifications may be injected in the routing = system...

&nbs= p;

[major] = Also, propagating these unknown components may result in a router down = the line, which understands them, reacting.  While the reaction = shouldn't result in reset adjacencies, it may result in inconsistent = forwarding or other unexpected = outcomes...

&nbs= p;

[major] = This treatment of unknown extensions is in conflict with the text in = =C2=A711.  See my comments = there.

&nbs= p;

&nbs= p;

353=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 4.2.1.  Type 1 - Destination = Prefix

&nbs= p;

355=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      Encoding: <type (1 octet), prefix length (1 = octet), prefix>

&nbs= p;

357=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      Defines: the destination prefix to match.  = Prefixes are encoded as

358=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      in BGP UPDATE messages, a length in bits is followed = by enough

359=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      octets to contain the prefix = information.

&nbs= p;

[nit] = s/Defines: the destination prefix/Defines the destination = prefix

&nbs= p;

[major] = rfc4271: "The Prefix field contains an IP address prefix, followed = by the minimum number of trailing bits needed to make the end of the = field fall on an octet boundary."   The text above makes it = sound as if the prefix field may not end in an octet boundary, which is = what rfc4271 specifies.

&nbs= p;

NEW = (suggestion)>

  =  Defines the destination prefix to match.  The length and = prefix fields are

  =  encoded as in BGP UPDATE messages = [rfc4271].

&nbs= p;

&nbs= p;

361=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 4.2.2.  Type 2 - Source = Prefix

&nbs= p;

363=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      Encoding: <type (1 octet), prefix-length (1 = octet), prefix>

&nbs= p;

365=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      Defines the source prefix to = match.

&nbs= p;

[minor] = "... The length and prefix fields are encoded as in BGP UPDATE = messages [rfc4271]."

&nbs= p;

&nbs= p;

367=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 4.2.3.  Type 3 - IP = Protocol

&nbs= p;

369=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      Encoding:<type (1 octet), [op, = value]+>

&nbs= p;

371=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      Contains a set of {operator, value} pairs that are = used to match

372=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      the IP protocol value byte in IP = packets.

&nbs= p;

[minor] = Include a reference to the protocol = numbers..

&nbs= p;

[major] = Are all protocol numbers valid?  I guess that in theory anything is = -- what should a receiver do with Flow Specifications that cover = protocols that are not supported?  I'm wondering if sending Flow = Specifications for every protocol under the sun is a vulnerability -- = knowing that only a few will ever be present in the Internet.  Is = there any guidance that you can provide in =C2=A714 (or a separate = Operational Considerations section)?  I also point this out because = the rest of the types focus on TCP/UDP...what about other transport = layer protocols?

&nbs= p;

[major] = Related question: even for "valid" protocols, should all be = accepted from eBGP peers?  I think that it is probably ok...asking = for completeness.

&nbs= p;

374=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      The operator byte is encoded = as:

&nbs= p;

376=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =     0   1   2   3   4   5   6 =   7

377=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   = +---+---+---+---+---+---+---+---+

378=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   | e | a |  len  | 0 |lt |gt |eq = |

379=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   = +---+---+---+---+---+---+---+---+

&nbs= p;

381=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =        Numeric = operator

&nbs= p;

[nit] = Center the figure...

&nbs= p;

[clarity]= Please describe the operators independent of one of the Types.  As = defined, it looks like they only apply to one type...it is much later = that the reader realizes that there is a reason for the = "complexity".  Along the same lines, I think that the = "set of {operator, value} pairs" phrase could use some more = text to explain that the operator is the whole octet, with a = corresponding value...

&nbs= p;

383=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      e - end-of-list bit.  Set in the last {op, = value} pair in the

384=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      list.

&nbs= p;

[major] = What action should be taken if a received flow spec has this bit not set = anywhere, or is set somewhere other than the last = pair?

&nbs= p;

386=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      a - AND bit.  If unset, the previous term is = logically ORed with

387=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      the current one.  If set, the operation is a = logical AND.  In the

388=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      first operator byte of a sequence it SHOULD be = encoded as unset

389=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      and and MUST be treated as always unset on = decoding.  The AND

390=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      operator has higher priority than OR for the = purposes of

391=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      evaluating logical = expressions.

&nbs= p;

393=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      len - length of the value field for this operator = given as (1 <<

394=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      len).  This encodes 1 (00) - 8 (11) = bytes.  Type 3 flow component

395=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      values SHOULD be encoded as single byte (len =3D = 00).

&nbs= p;

[major] = Please expand on the meaning of "1 << = len".

&nbs= p;

&nbs= p;

...<= /o:p>

406=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   The bits lt, gt, and eq can be combined to produce common = relational

407=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   operators such as "less or equal", "greater or = equal", and "not equal

408=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   to".

&nbs= p;

[minor] = "...as shown in Table 1."

&nbs= p;

410=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =           =  +----+----+----+----------------------------------+

411=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =            | lt | gt | eq | Resulting = operation             =  |

412=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =           =  +----+----+----+----------------------------------+

413=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =            | 0  | 0  | 0  | = false (independent of the value) |

414=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =            | 0  | 0  | 1  | = =3D=3D (equal)                 =       |

415=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =            | 0  | 1  | 0  | = > (greater than)               =   |

416=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =            | 0  | 1  | 1  | = >=3D (greater than or equal)       = |

417=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =            | 1  | 0  | 0  | = < (less than)                 =    |

418=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =            | 1  | 0  | 1  | = <=3D (less than or equal)         =  |

419=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =            | 1  | 1  | 0  | = !=3D (not equal value)             = |

420=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =            | 1  | 1  | 1  | = true (independent of the value) =  |

421=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =           =  +----+----+----+----------------------------------+

&nbs= p;

423=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =                Table 1: = Comparison operation combinations

&nbs= p;

425=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 4.2.4.  Type 4 - Port

&nbs= p;

427=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      Encoding:<type (1 octet), [op, = value]+>

&nbs= p;

429=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      Defines a list of {operator, value} pairs that = matches source OR

430=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      destination TCP/UDP ports.  This list is = encoded using the numeric

431=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      operator format defined in Section 4.2.3.  = Values SHOULD be

432=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      encoded as 1- or 2-byte = quantities.

&nbs= p;

[minor] = A reference to TCP/UDP header/ports would be = nice.

&nbs= p;

[major] = "matches source OR destination TCP/UDP ports"  Which = one?  Both?  Either?  How does the receiver know which = one?

&nbs= p;

[minor] = What is the interaction/relationship between this type and Types 5 and = 6?  The text in =C2=A74.2 allows for all 3 types to be present, and = have an influence in the action taken...they seem = redundant.

&nbs= p;

&nbs= p;

434=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      Port, source port, and destination port components = evaluate to

435=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      FALSE if the IP protocol field of the packet has a = value other

436=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      than TCP or UDP, if the packet is fragmented and = this is not the

437=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      first fragment, or if the system in unable to locate = the transport

438=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      header.  Different implementations may or may = not be able to

439=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      decode the transport header in the presence of IP = options or

440=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      Encapsulating Security Payload (ESP) NULL [RFC4303] = encryption.

&nbs= p;

[minor] = "Port, source port, and destination port components..." =  This section only talks about the port; please duplicate this text = in the other sections, or put a reference to it there, or put a forward = reference here...

&nbs= p;

[major] = "...evaluate to FALSE if the IP protocol field of the packet has a = value other than TCP or UDP, if the packet is fragmented and this is not = the first fragment, or if the system in unable to locate the transport = header."  This sentence seems to mix the applicability of the = Flow Specification (FALSE is first introduced in =C2=A74.2 to describe = the effect of a component on the rule), and the application to a = specific packet.  Please separate the two aspects. I do have some = specific questions/comments.

&nbs= p;

(1) The = text starts by talking about the "protocol field of the = packet" (not the protocol value in the Type 3 parameter)...  I = assume that a Flow Specification would only apply to a packet if the = protocol matches the Type 3 parameter...but the statement seems to say = that it wouldn't apply regardless of the Type 3 (see my question there = about valid protocols)...or maybe even if a Type 3 is not = present....

&nbs= p;

(2) = "...evaluate to FALSE...if the packet is fragmented and this is not = the first fragment..."  Type 12 specifically includes values = for other cases.  How is the interaction = expected?

&nbs= p;

&nbs= p;

...<= /o:p>

460=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 4.2.7.  Type 7 - ICMP = type

&nbs= p;

462=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      Encoding:<type (1 octet), [op, = value]+>

&nbs= p;

464=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      Defines a list of {operator, value} pairs used to = match the type

465=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      field of an ICMP packet.  This list is encoded = using the numeric

466=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      operator format defined in Section 4.2.3.  = Values SHOULD be

467=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      encoded using a single = byte.

&nbs= p;

[minor] = A reference to ICMP would be nice.

&nbs= p;

469=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      The ICMP type specifiers evaluate to FALSE whenever = the protocol

470=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      value is not = ICMP.

&nbs= p;

472=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 4.2.8.  Type 8 - ICMP = code

&nbs= p;

474=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      Encoding:<type (1 octet), [op, = value]+>

&nbs= p;

476=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      Defines a list of {operator, value} pairs used to = match the code

477=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      field of an ICMP packet.  This list is encoded = using the numeric

478=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      operator format defined in Section 4.2.3.  = Values SHOULD be

479=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      encoded using a single = byte.

&nbs= p;

481=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      The ICMP code specifiers evaluate to FALSE whenever = the protocol

482=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      value is not = ICMP.

&nbs= p;

[minor] = I guess that it should also evaluate FALSE if the ICMP code is not = relevant for the Type.  ??

&nbs= p;

484=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 4.2.9.  Type 9 - TCP = flags

&nbs= p;

486=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      Encoding:<type (1 octet), [op, = bitmask]+>

&nbs= p;

[minor] = The operator (described below) is called "bitmask", which is a = little confusing with the bitmask = itself...

&nbs= p;

488=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      Bitmask values can be encoded as a 1- or 2-byte = bitmask.  When a

489=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      single byte is specified, it matches byte 13 of the = TCP header

490=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      [RFC0793], which contains bits 8 though 15 of the = 4th 32-bit word.

491=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      When a 2-byte encoding is used, it matches bytes 12 = and 13 of the

492=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      TCP header with the data offset field having a = "don't care" value.

&nbs= p;

[minor] = Identifying the right octets is more important than counting the number = of bytes...  The interesting bytes are identified above as = "bytes 12 and 13"; however, work from the Transport Area talks = about "bytes 13 and 14": https://tools.ie= tf.org/html/rfc3168#section-6.1  It would be nice if this was = aligned or if any ambiguity could be = avoided.

&nbs= p;

[minor] = "...with the data offset field having a "don't care" = value."  What does that mean?  To me, it sounds as if the = bitmask values can't be used to match on the offset....is that the right = interpretation?  Some clarity would avoid = guessing..

&nbs= p;

494=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      This component evaluates to FALSE for packets that = are not TCP

495=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      packets.

&nbs= p;

[major] = As mentioned before, this sentence also seems to mix/confuse the = applicability of the component (whether it can be used at all) and the = application of it to match a specific packet.  In this case, the = text seems to simply say that a Flow Specification which uses Type 9 can = only be used to match TCP packets...

&nbs= p;

[major] = Should the Flow Specification evaluate to FALSE if this Type is used = *and* Type 3 doesn't include TCP *only* in it's = description?

&nbs= p;

497=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      This type uses the bitmask operator format, which = differs from the

498=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      numeric operator format in the lower = nibble.

&nbs= p;

[minor] = As with the numeric operator, I think it would be clearer if it was = introduced before the types.

&nbs= p;

500=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =    0   1   2   3   4   5   6 =   7

501=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   = +---+---+---+---+---+---+---+---+

502=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   | e | a |  len  | 0 | 0 |not| m = |

503=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   = +---+---+---+---+---+---+---+---+

&nbs= p;

505=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      Bitmask operator

&nbs= p;

[nit] = Center the figure...

&nbs= p;

507=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   e, a, len - Most significant nibble:  (end-of-list bit, AND = bit, and

508=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      length field), as defined for in the numeric = operator format in

509=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      Section 4.2.3.

&nbs= p;

[] See = the questions about the e bit above.

&nbs= p;

&nbs= p;

...<= /o:p>

542=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 4.2.12.  Type 12 - = Fragment

&nbs= p;

544=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      Encoding:<type (1 octet), [op, = bitmask]+>

&nbs= p;

546=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      Uses bitmask operator format defined in Section = 4.2.9.

&nbs= p;

[major] = No, it doesn't.  The new one is defined = below.

&nbs= p;

[clarity]= Again, please introduce the operators before the types.  In this = case, this operator seems to also carry the bitmask name, which can be = confusing with the one introduced in =C2=A74.2.9 and the name of the = value field...

&nbs= p;

548=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      0   1   2   3   4   5 =   6   7

549=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   =  +---+---+---+---+---+---+---+---+

<= p class=3DMsoNormal>550=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =    | 0 | 0 | 0 | 0 |LF |FF |IsF|DF = |

551=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   =  +---+---+---+---+---+---+---+---+

<= p class=3DMsoNormal>&nbs= p;

[nit] = Center the figure...

&nbs= p;

[nit] = Please add Figure numbers.

&nbs= p;

553=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      Bitmask values:

&nbs= p;

555=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =         Bit 7 - Don't fragment = (DF)

&nbs= p;

557=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =         Bit 6 - Is a fragment = (IsF)

&nbs= p;

559=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =         Bit 5 - First fragment = (FF)

&nbs= p;

561=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =         Bit 4 - Last fragment = (LF)

&nbs= p;

563=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =         Bit 0-3 - SHOULD be set to 0 on NLRI = encoding, and MUST be

564=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =         ignored during = decoding

&nbs= p;

[major] = The operation is not specified.  Is this also an (operator,bitmask) = pair, or just 8 bits indicating the values?  Can multiple bits be = set at the same time?  What fields in the IP header do these map = to?

&nbs= p;

566=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 4.3.  Examples of = Encodings

&nbs= p;

568=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   An example of a Flow Specification encoding for: "all = packets to

569=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   10.0.1/24 and TCP port = 25".

&nbs= p;

[nit] = For clarity, include the whole subnet: s/ 10.0.1/24 / 10.0.1.0/24

&nbs= p;

[major] = Use IP addresses from the documentation pool [rfc5737] in all = examples.

&nbs= p;

571=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =     =  +------------------+----------+----------+

572=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      | destination      | proto   =  | port     |

573=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =     =  +------------------+----------+----------+

574=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      | 0x01 18 0a 00 01 | 03 81 06 | 04 81 19 = |

575=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =     =  +------------------+----------+----------+

&nbs= p;

[minor] = It would be nice if the examples show the the whole Flow-spec NLRI, and = not just the NLRI value.  Also, it would be great if one of the = examples required more than 240 = bytes.

&nbs= p;

577=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Decode for protocol:

&nbs= p;

[minor] = Please show the decodes for all the = fields.

&nbs= p;

579=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =     =  +-------+----------+------------------------------+

580=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      | Value |          |   =                     =        |

581=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =     =  +-------+----------+------------------------------+

582=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      |  0x03 | type     |     =                     =      |

583=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      |  0x81 | operator | end-of-list, value = size=3D1, =3D |

584=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      |  0x06 | value    |     =                     =      |

585=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =     =  +-------+----------+------------------------------+

&nbs= p;

[minor] = For completion, indicate that Protocol 6 is = TCP.

&nbs= p;

587=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   An example of a Flow Specification encoding for: "all = packets to

588=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   10.1.1/24 from 192/8 and port {range [137, 139] or = 8080}".

&nbs= p;

[] = Ah...NETBIOS...

&nbs= p;

[nit] It = might be a good idea to number the = examples...

&nbs= p;

&nbs= p;

...<= /o:p>

612=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 5.  Traffic Filtering

&nbs= p;

614=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Traffic filtering policies have been traditionally considered to = be

615=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   relatively static.  Limitations of the static mechanisms = caused this

616=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   mechanism to be designed for the three new applications of = traffic

617=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   filtering (prevention of traffic-based, denial-of-service = (DOS)

618=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   attacks, traffic filtering in the context of BGP/MPLS VPN = service,

619=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   and centralized traffic control for SDN/NFV networks) = requires

620=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   coordination among service providers and/or coordination among = the AS

621=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   within a service provider.  Section 9 has details on the = limitation

622=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   of previous mechanisms and why BGP Flow Specification provides = a

623=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   solution for to prevent DOS and aid BGP/MPLS VPN filtering = rules.

&nbs= p;

[minor] = This sentence, without the parenthesis, doesn't seem to make sense: = "Limitations of the static mechanisms caused this mechanism to be = designed for the three new applications of traffic filtering requires = coordination among service providers and/or coordination among the AS = within a service provider."

&nbs= p;

[nit] = s/solution for to prevent/solution to = prevent

&nbs= p;

625=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   This Flow Specification NLRI defined above to convey = information

626=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   about traffic filtering rules for traffic that should be = discarded or

627=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   handled in manner specified by a set of pre-defined actions = (which

628=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   are defined in BGP Extended Communities).  This mechanism = is

629=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   primarily designed to allow an upstream autonomous system to = perform

630=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   inbound filtering in their ingress routers of traffic that a = given

631=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   downstream AS wishes to drop.

&nbs= p;

[nit] = s/This Flow Specification NLRI/The Flow Specification = NLRI

&nbs= p;

&nbs= p;

...<= /o:p>

645=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Distribution of the IPv4 Flow Specification is described = in

646=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Section 6, and distibution of BGP/MPLS traffic Flow Specification = is

647=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   described in Section 8.  The traffic filtering actions are = described

648=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   in Section 7.

&nbs= p;

[minor] = Section 6 talks about validation, not = distribution.

&nbs= p;

[nit] = s/distibution/distribution

&nbs= p;

&nbs= p;

650=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 5.1.  Ordering of Traffic Filtering = Rules

&nbs= p;

652=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   With traffic filtering rules, more than one rule may match = a

653=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   particular traffic flow.  Thus, it is necessary to define = the order

654=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   at which rules get matched and applied to a particular traffic = flow.

655=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   This ordering function must be such that it must not depend on = the

656=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   arrival order of the Flow Specification's rules and must = be

657=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   consistent in the network.

&nbs= p;

[clarific= ation] Are "traffic filtering rules" the same thing as = "traffic filtering actions", or are they more like "Flow = Specification's rules"?   You also mention (below) "Flow = Specification rules" in the context of ordering, so my guess is = that "traffic filtering rules" and "Flow Specification = rules" are equivalent...are they?   In my opinion, there are = too many ways to refer to the same, or very similar things.  Please = take advantage of =C2=A72 to help the reader, or at least simplify the = terminology.

&nbs= p;

659=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   The relative order of two Flow Specification rules is determined = by

660=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   comparing their respective components.  The algorithm starts = by

661=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   comparing the left-most components of the rules.  If the = types

662=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   differ, the rule with lowest numeric type value has higher = precedence

663=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   (and thus will match before) than the rule that doesn't contain = that

664=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   component type.  If the component types are the same, then a = type-

665=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   specific comparison is performed (see below) if the types are = equal

666=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   the algorithm continues with the next = component.

&nbs= p;

[minor] = To be clear: the comparison is done between the component types defined = in =C2=A74.2...and "left-most" means = "first"...

&nbs= p;

668=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   For IP prefix values (IP destination or source prefix): If = the

669=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   prefixes overlap, the one with the longer prefix-length has = higher

670=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   precedence.  If they do not overlap the one with the lowest = IP value

671=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   has higher precedence.

&nbs= p;

[minor] = I need you to be more specific when talking about = "overlap".  Clearly 10.1..0.0/16 and 10.1.1.0/24 overlap, then the higher = precedence would be for the /24, right?  Do 130.0.0.0/16 and 150..1.1.0/24 overlap (they have the = first 3 bits in common)?  rfc5575 talks about a "common = prefix", which is not completely clear either, but it could mean at = least what is covered by the shortest mask (which would be my = guess)...

&nbs= p;

[minor] = "prefix-length" is used here, but "prefix length" is = used in =C2=A74.2.1.  Please be = consistent.

&nbs= p;

[minor] = The "-" confused me a little.  By "For IP prefix = values...the longer prefix-length" do you mean the value of the = prefix length, or the length of the prefix field?  rfc5575 talks = about "more specific", which may be easier to understand in = this case...

&nbs= p;

673=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   For all other component types, unless otherwise specified, = the

674=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   comparison is performed by comparing the component data as a = binary

675=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   string using the memcmp() function as defined by the ISO C = standard.

676=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   For strings with equal lengths the lowest string (memcmp) has = higher

677=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   precedence.  For strings of different lengths, the common = prefix is

678=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   compared.  If the common prefix is not equal the string with = the

679=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   lowest prefix has higher precedence.  If the common prefix = is equal,

680=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   the longest string is considered to have higher precedence than = the

681=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   shorter one.

&nbs= p;

[major] = Please add a Normative reference for "the memcmp() function as = defined by the ISO C standard".

&nbs= p;

[minor] = What is the "common prefix"?  Is it the bits that = correspond to the shorter length?  In this case I think that using = "prefix" may be confusing.

&nbs= p;

[minor] = If my interpretation is correct, given a common set of rules, the longer = the Flow Specification the most preferred, right?  Using one of the = examples in =C2=A74.3, "all packets to 10.1.1/24 from 192/8 and = port {range [137, 139] or 8080}" would be preferred over "all = packets to 10.1.1/24 from 192/8 and port range [137, = 139]"...because when comparing the common prefix for the port, the = second rule would have the e bit set, resulting in a higher prefix, = right?

&nbs= p;

[major] = I would like to see some discussion about the management of Flow = Specifications and their advertisement order from an operational point = of view.  In the case above, if an operator uses the first rule = (only), but later decides to allow web traffic and the system advertises = the second rule, it won't take effect until the first one is = withdrawn.  This type of operational consideration is not explained = in this document.

&nbs= p;

683=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   The code below shows a Python3 implementation of the = comparison

684=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   algorithm.  The full code was tested with Python 3.6.3 and = can be

685=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   obtained at https://github.com/stof= fi92/flowspec-cmp [1].

&nbs= p;

[minor] = I would prefer to see the code in an = Appendix.

&nbs= p;

[major] = We need to include template text about the licensing in the Code = Component below.  Please take a look at the IETF Trust Legal = Provisions and add the appropriate text: https://tru= stee.ietf.org/license-info/IETF-TLP-5.pdf

=

&nbs= p;

687=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   <CODE BEGINS>

688=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   import itertools

689=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   import ipaddress

&nbs= p;

691=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   def flow_rule_cmp(a, b):

692=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =       for comp_a, comp_b in = itertools.zip_longest(a.components,

693=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =                     =                     =      b.components):

694=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =           # If a component type does not exist = in one rule

695=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =           # this rule has lower = precedence

696=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =           if not = comp_a:

697=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =               return = B_HAS_PRECEDENCE

698=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =           if not = comp_b:

699=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =               return = A_HAS_PRECEDENCE

&nbs= p;

[] What = if the component is not in either?  The lines above look like the = wrong outcome could be obtained.  Disclaimer: I don't know = Python...

&nbs= p;

&nbs= p;

...<= /o:p>

742=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 6.  Validation Procedure

...<= /o:p>

757=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   The concept can be extended, in the case of Flow Specification = NLRI,

758=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   to allow other validation = procedures.

&nbs= p;

[nit] = s/of Flow Specification NLRI/of the Flow Specification = NLRI

&nbs= p;

760=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   A Flow Specification NLRI must be validated such that it = is

761=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   considered feasible if and only if all of the below is = true:

&nbs= p;

[major] = There is no Normative language above, but I think there is a = contradiction of sorts with the new text below ("Rule a) MAY be = relaxed...").  The introductory text to the rules is = "must be...considered feasible if and only if all of the below is = true", which sounds very strict and specific...but then the = Normative exception comes in ("MAY be relaxed...rules b) and = c)...MUST be disregarded") saying that it doesn't matter.  = Please reword...perhaps something like: "If a destination is = present...a Flow Specification MUST be validated this = way...otherwise..."

&nbs= p;

763=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      a) A destination prefix component is embedded in the = Flow

764=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      Specification.

&nbs= p;

766=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      b) The originator of the Flow Specification matches = the originator

767=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      of the best-match unicast route for the destination = prefix

768=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      embedded in the Flow = Specification.

&nbs= p;

[major] = What is the "best-match unicast route"?  Please be = specific.

&nbs= p;

770=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      c) There are no more specific unicast routes, when = compared with

771=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      the flow destination prefix, that has been received = from a

772=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      different neighboring AS than the best-match unicast = route, which

773=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      has been determined in rule = b).

&nbs= p;

775=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Rule a) MAY be relaxed by configuration, permitting = Flow

776=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Specifications that include no destination prefix = component.  If such

777=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   is the case, rules b) and c) are moot and MUST be = disregarded.

&nbs= p;

[major] = This action opens the door to all sorts of things.  I note that the = Security Considerations section simply mentions it without going into = more details.

&nbs= p;

779=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   By originator of a BGP route, we mean either the BGP originator = path

780=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   attribute, as used by route reflection, or the transport address = of

781=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   the BGP peer, if this path attribute is not = present.

&nbs= p;

[major] = s/BGP originator path attribute, as used by route reflection/address of = the originator in the ORIGINATOR_ID Attribute [RFC4456]   The = reference to rfc4456 should be = Normative.

&nbs= p;

[minor] = rfc4271 doesn't talk about a "transport addresses".  = Instead, it talks about the "source IP address".  I know = it is the same thing, but please be = consistent.

&nbs= p;

783=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   BGP implementations MUST also enforce that the AS_PATH attribute = of a

784=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   route received via the External Border Gateway Protocol = (eBGP)

785=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   contains the neighboring AS in the left-most position of the = AS_PATH

786=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   attribute.  While this rule is optional in the BGP = specification, it

787=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   becomes necessary to enforce it for security = reasons.

&nbs= p;

[major] = Is this requirement only for the Flow Specification AFI/SAFI pairs, or = for all address families (IPv4 in the case of this document)?  = Why?

&nbs= p;

[major] = [Assuming that the answer to the last question is: "Yes, for all = AFs"...] Should all the border routers in the AS enforce the first = ASN, or is the requirement only for routers receiving Flow = Specifications?

&nbs= p;

[major] = In the case of receiving Flow Specifications from a neighbor in an IXP, = it may not be possible to enforce the rule above if a "transparent = ASN" is being used.  Please include some text/guidance about = that type of case.  Include it either here or in the Security = Considerations.

&nbs= p;

[nit] = The mention of security above makes me want to see related = considerations in =C2=A713/14.

&nbs= p;

789=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   The best-match unicast route may change over the time = independently

790=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   of the Flow Specification NLRI.  Therefore, a revalidation = of the

791=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Flow Specification NLRI MUST be performed whenever unicast = routes

792=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   change.  Revalidation is defined as retesting that clause a = and

793=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   clause b above are true.

&nbs= p;

[major] = What about the case where a destination prefix is not included?  = Besides enforcing the first AS, there isn't any verification = specified.  What are the consideration about using that = option?

&nbs= p;

795=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Explanation:

&nbs= p;

797=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   The underlying concept is that the neighboring AS that advertises = the

798=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   best unicast route for a destination is allowed to advertise = flow-

799=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   spec information that conveys a more or equally specific = destination

800=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   prefix.  Thus, as long as there are no more specific unicast = routes,

801=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   received from a different neighboring AS, which would be affected = by

802=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   that filtering rule.

&nbs= p;

804=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   The neighboring AS is the immediate destination of the = traffic

805=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   described by the Flow Specification.  If it requests these = flows to

806=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   be dropped, that request can be honored without concern that = it

807=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   represents a denial of service in itself.  Supposedly, the = traffic is

808=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   being dropped by the downstream autonomous system, and there is = no

809=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   added value in carrying the traffic to = it.

&nbs= p;

[major] = A rogue router may request the traffic to be dropped.  While the = local AS is simply reacting to the neighbor's request, the action can = still result in a DoS.  I would like to see rogue router scenarios = reflected in the Security = Considerations.

&nbs= p;

[major] = All this section seems to assume that flows are controlled = (dropped/redirected) between ASes...but the actions can also be = triggered from inside an AS.  What are the considerations in that = case?  Why isn't iBGP explicitly = considered?

&nbs= p;

&nbs= p;

811=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 7.  Traffic Filtering = Actions

...<= /o:p>

820=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Implementations SHOULD provide mechanisms that map an arbitrary = BGP

821=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   community value (normal or extended) to filtering actions = that

822=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   require different mappings in different systems in the = network.  For

823=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   instance, providing packets with a worse-than-best-effort, = per-hop

824=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   behavior is a functionality that is likely to be = implemented

825=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   differently in different systems and for which no standard = behavior

826=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   is currently known.  Rather than attempting to define it = here, this

827=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   can be accomplished by mapping a user-defined community value = to

828=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   platform-/network-specific behavior via user = configuration.

&nbs= p;

[major] = While this paragraph sounds technically correct, I think it doesn't = belong in this document because it (randomly) talks about a different, = yet tangentially related, topic.  Also, it basically says = "SHOULD provide a mechanism to take arbitrary actions...which are = not defined here", so it is not complete from a Normative point of = view.  I would prefer if we took this paragraph = out.

&nbs= p;

830=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   The default action for a traffic filtering Flow Specification is = to

831=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   accept IP traffic that matches that particular = rule.

&nbs= p;

833=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   This document defines the following extended communities values = shown

834=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   in Table 2 in the form 0x8xnn where nn indicates the = sub-type.

835=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Encodings for these extended communities are described = below.

&nbs= p;

[minor] = The "0x8xnn" format doesn't explain what x indicates.  = Perhaps it would be better for the format to match the IANA section and = include, for example, 0xttss for type and sub-type...with the = corresponding change in Table 2.

&nbs= p;

837=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   = +-----------+----------------------+--------------------------------+

838=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   | community | action             =   | encoding               =         |

839=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   = +-----------+----------------------+--------------------------------+

840=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   | 0x8006    | traffic-rate-bytes   | 2-byte ASN, = 4-byte float       |

841=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   | TBD       | traffic-rate-packets | 2-byte ASN, = 4-byte float       |

842=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   | 0x8007    | traffic-action       | = bitmask                   =      |

843=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   | 0x8008    | rt-redirect AS-2byte | 2-octet AS, = 4-octet value      |

844=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   | 0x8108    | rt-redirect IPv4     | 4-octet = IPv4 addres, 2-octet   |

845=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   |           |       =                | value   =                     =    |

846=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   | 0x8208    | rt-redirect AS-4byte | 4-octet AS, = 2-octet value      |

847=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   | 0x8009    | traffic-marking      | = DSCP value                 =     |

848=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   = +-----------+----------------------+--------------------------------+

&nbs= p;

850=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =               Table 2: Traffic Action = Extended Communities

&nbs= p;

[minor] = The Table contains terms that have not been defined...  It would be = ideal if the Table contained a forward reference to the section where = each action is discussed....or at least a general statement about the = details in the upcoming = sub-sections...

&nbs= p;

852=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Some traffic action communities may interfere with each = other.

853=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Section 7.6 of this specification provides general considerations = on

854=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   such traffic action interference.  Any additional definition = of a

855=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   traffic actions specified by additional standards documents or = vendor

856=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   documents MUST specify if the traffic action interacts with = an

857=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   existing traffic actions, and provide error handling per = [RFC7606].

&nbs= p;

[nit] = s/definition of a traffic actions/definition of traffic = actions

&nbs= p;

[major] = "Any additional definition of a traffic actions specified by = additional standards documents or vendor documents MUST specify..." =  We really can't mandate what vendor documents say.   = s/additional definition of a traffic actions specified by additional = standards documents or vendor documents MUST specify/additional = definition of a traffic action MUST = specify

&nbs= p;

[major] = "MUST specify if the traffic action interacts with an existing = traffic actions"  I think you meant something like: "MUST = specify the action to take = if..."

&nbs= p;

[major] = "Any additional definition of a traffic actions...MUST...provide = error handling per [RFC7606]."  rfc7606 already indicates what = to do about a malformed Extended Community attribute, which is how other = actions would presumably be specified.   rfc7606 only mandates = error specifications for new attributes.  What are your = expectations here?

&nbs= p;

859=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Multiple traffic actions may be present for a single NLRI.  = The

860=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   traffic actions are processed in ascending order of the = sub-type

861=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   found in the BGP Extended Communities.  If not all of them = can be

862=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   processed the filter SHALL NOT be applied at all (for example: if = for

863=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   a given flow there are the action communities rate-limit-bytes = and

864=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   traffic-marking attached, and the plattform does not support one = of

865=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   them also the other shall not be applied for that = flow).

&nbs= p;

[minor] = This paragraph is related to =C2=A77.6 (Considerations on Traffic Action = Interference).  Consider putting all the related information = together.

&nbs= p;

[major] = "traffic actions are processed in ascending order of the = sub-type"  Several of the communities have the same sub-type; = if more than one is present, which one should be processed = first?

&nbs= p;

[major] = What should a receiver do if multiple of the same community (type and = sub-type) are included in the UPDATE?  Would that be also = considered interference?

&nbs= p;

[major] = What does "processed" mean?  Let me explain... The = example is about not being able to support an action.  What about = not being able to apply the action because, for example, the next hop is = not reachable?  Would that qualify as not being able to = "process" the action?  If other redirect traffic rules = are included (with perhaps an alternate next hop), would the answer be = different?

&nbs= p;

[nit] = Make the example a sentence on it's own: eliminate the = parenthesis.

&nbs= p;

[minor] = s/rate-limit-bytes/traffic-rate-bytes = (0x8006)

&nbs= p;

[minor] = s/traffic-marking/traffic-marking = (0x8009)

&nbs= p;

[nit] = s/plattform/platform

&nbs= p;

[major] = "If not all of them can be processed the filter SHALL NOT be = applied..."  Should they be forwarded?  Is this an = example of "interfering flow actions" = (=C2=A77.6)?

&nbs= p;

867=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   All traffic actions are specified as transitive BGP = Extended

868=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Communities.

&nbs= p;

870=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 7.1.  Traffic Rate in Bytes (traffic-rate-bytes) sub-type = 0x06

...<= /o:p>

888=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Interferes with: No other BGP Flow Specification traffic action = in

889=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   this document.

&nbs= p;

[minor] = The definition of interference (=C2=A77.6) uses "more than one = conflicting traffic-rate action" as part of it.  So it seems = that traffic-rate-bytes and traffic-rate-packets may interfere with each = other.

&nbs= p;

891=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 7.2.  Traffic Rate in Packets (traffic-rate-packets) = sub-type TBD

&nbs= p;

[major] = Because the "traffic actions are processed in ascending order of = the sub-type" (=C2=A77), what is the intent for this action?  = How should IANA assign it?  I assume that the intent might be to = process it instead of traffic-rate-bytes (assuming only one might be = present)...  Please be clear in the instructions to IANA (in = =C2=A712.3).  Note that Table 7 requests the assignment from the = "Generic Transitive Experimental Use Extended Community = Sub-Types" registry, which seems to limit the assignment = choices.  Having said all that, I would have assumed that this = action would be a variation of the 0x06 sub-type, but with a different = type...

&nbs= p;

&nbs= p;

...<= /o:p>

901=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Interferes with: No other BGP Flow Specification traffic action = in

902=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   this document.

&nbs= p;

[minor] = The definition of interference (=C2=A77.6) uses "more than one = conflicting traffic-rate action" as part of it.  So it seems = that traffic-rate-bytes and traffic-rate-packets may interfere with each = other.

&nbs= p;

904=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 7.3.  Traffic-action (traffic-action) sub-type = 0x07

&nbs= p;

906=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   The traffic-action extended community consists of 6 bytes of = which

907=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   only the 2 least significant bits of the 6th byte (from left = to

908=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   right) are currently defined.

&nbs= p;

910=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =        40  41  42  43  44 =  45  46  47

911=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =       = +---+---+---+---+---+---+---+---+

912=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =       |        reserved     =   | S | T |

913=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =       = +---+---+---+---+---+---+---+---+

&nbs= p;

[minor] = s/reserved/Traffic Action Fields   It would be nice if the Figure = showed that all the bits (not just the ones in the last octet) are part = of the same field.

&nbs= p;

[nit] = Please add a Figure number..

&nbs= p;

915=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   where S and T are defined as:

&nbs= p;

917=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   o  T: Terminal Action (bit 47): When this bit is set, the = traffic

918=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      filtering engine will apply any subsequent filtering = rules (as

919=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      defined by the ordering procedure).  If not = set, the evaluation of

920=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      the traffic filter stops when this rule is = applied.

&nbs= p;

[minor] = According to the processing order and the values from Table 2, not = setting the bit would effectively cause only the traffic-rate-bytes = (0x8006) to ever be applied.  Is that the correct = interpretation?

&nbs= p;

[minor] = If the T bit is not set, can a router drop the communities that are not = going to be applied...or should they all be = propagated?

&nbs= p;

[major] = Clearly, a rogue router could unset the bit before = propagating...

&nbs= p;

922=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   o  S: Sample (bit 46): Enables traffic sampling and logging = for this

923=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      Flow = Specification.

&nbs= p;

[major] = If the bit is not set, would sampling/logging be disabled?  IOW, is = this an on/off switch, or is just the on action = valid?

&nbs= p;

925=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   o  reserved: should always be set to 0 by the originator and = not be

926=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =      evaluated by the receiving BGP = speaker.

&nbs= p;

[major] = There is a registry for these bits.  s/reserved/Traffic Action = Fields

&nbs= p;

&nbs= p;

...<= /o:p>

934=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Interferes with: No other BGP Flow Specification traffic action = in

935=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   this document.

&nbs= p;

[minor] = Based on the definition in =C2=A77.6, I would have thought that this = action, with the T bit unset, would interfere with other actions that = will now not be applied.

&nbs= p;

&nbs= p;

937=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 7.4.  RT Redirect (rt-redirect) sub-type = 0x08

...<= /o:p>

948=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   It should be noted that the low-order nibble of the Redirect's = Type

949=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   field corresponds to the Route Target Extended Community format = field

950=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   (Type).  (See Sections 3.1, 3.2, and 4 of [RFC4360] plus = Section 2 of

951=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   [RFC5668].)  The low-order octet (Sub-Type) of the Redirect = Extended

952=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Community remains 0x08 for all three encodings of the BGP = Extended

953=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Communities (AS 2-byte, AS 4-byte, and IPv4 = address).

&nbs= p;

[nit] I = think that this whole paragraph is not needed....and it actually may = confuse people.  I recommend deleting = it.

&nbs= p;

955=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Interferes with: All other redirect = functions.

&nbs= p;

[minor] = What other redirect functions?  The only ones defined are in this = section.

&nbs= p;

&nbs= p;

957=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 7.5.  Traffic Marking (traffic-marking) sub-type = 0x09

&nbs= p;

959=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   The traffic marking extended community instructs a system to = modify

960=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   the DSCP bits of a transiting IP packet to the corresponding = value.

961=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   This extended community is encoded as a sequence of 5 zero = bytes

962=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   followed by the DSCP value encoded in the 6 least significant = bits of

963=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   6th byte.

&nbs= p;

[major] = What action (if any) should a receiver take if the "5 zero = bytes" are not (all) set to 0?  Maybe include something like: = "MUST be ignored when = received...".

&nbs= p;

965=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Interferes with: No other BGP Flow Specification traffic action = in

966=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   this document.

&nbs= p;

968=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 7.6.  Considerations on Traffic Action = Interference

&nbs= p;

970=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Since traffic actions are represented as BGP extended = community

971=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   values, traffic actions may interfere with each other (ie. there = may

972=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   be more than one conflicting traffic-rate action associated with = a

973=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   single flow-filter).  Traffic action interference has no = impact on

974=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   BGP propagation of flow filters (all communities are = propagated

975=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   according to policies).

&nbs= p;

[nit] = s/ie./e.g.   I'm assuming it is an example and not the only = case.

&nbs= p;

[minor] = Is "Traffic action interference" only the case when actions = describe conflicting actions?  For example, different traffic = rates.  Specifically, are actions that can't be applied (as = described on =C2=A77), also considered as = interference?

&nbs= p;

977=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   If a flow filter associated with interfering flow actions is = selected

978=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   for packet forwarding, it is a implementation decision which of = the

979=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   interfering traffic actions are selected.  Implementors of = this

980=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   specification SHOULD document the behaviour of their = implementation

981=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   in such cases.

&nbs= p;

[major] = IOW, deployment of a set of "interfering flow actions" could = result in inconsistent behavior in the network.  Could a rogue BGP = speaker advertise (or even add/delete) actions to a Flow Specification = and cause unexpected results?  I guess that depending on what the = action is, there could be a significant effect.  I think this is a = vulnerability that should be called out explicitly.  Thinking a = little bit more...there are two vulnerabilities: (1) add/delete in the = normal case (even with consistent behavior), and (2) add/delete to = exploit a specific behavior of a node in the = network.

&nbs= p;

983=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   If required, operators are encouraged to make use of the BGP = policy

984=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   framework supported by their implementation in order to achieve = a

985=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   predictable behaviour (ie. match - replace - delete communities = on

986=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   administrative boundaries).

&nbs= p;

[minor] = "If required..."  When it is not required?  IOW, I = think that those two words are not = needed.

&nbs= p;

&nbs= p;

988=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 8.  Dissemination of Traffic Filtering in BGP/MPLS VPN = Networks

&nbs= p;

990=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Provider-based Layer 3 VPN networks, such as the ones using a = BGP/

991=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   MPLS IP VPN [RFC4364] control plane, may have different = traffic

992=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   filtering requirements than Internet service providers.  But = also

993=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   Internet service providers may use those VPNs for scenarios = like

994=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   having the Internet routing table in a VRF, resulting in the = same

995=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   traffic filtering requirements as defined for the global = routing

996=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   table environment within this document.  This document = proposes an

997=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   additional BGP NLRI type (AFI=3D1, SAFI=3D134) value, which can = be used

998=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   to propagate traffic filtering information in a BGP/MPLS = VPN

999=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =   environment.

&nbs= p;

[nit] = s/proposes/defines (or maybe = specifies)

&nbs= p;

1001=C2=A0=C2=A0=C2=A0=C2=A0   The NLRI = format for this address family consists of a = fixed-length

1002=C2=A0=C2=A0=C2=A0=C2=A0   Route = Distinguisher field (8 bytes) followed by a Flow = Specification,

1003=C2=A0=C2=A0=C2=A0=C2=A0   = following the encoding defined above in Section 4.2 of this = document.

1004=C2=A0=C2=A0=C2=A0=C2=A0   The NLRI = length field shall include both the 8 bytes of the = Route

1005=C2=A0=C2=A0=C2=A0=C2=A0   = Distinguisher as well as the subsequent Flow = Specification.

&nbs= p;

[minor] = s/Flow Specification, following the encoding defined above in Section = 4.2 of this document./Flow Specification (Section = 4.2).

&nbs= p;

&nbs= p;

...<= /o:p>

1017=C2=A0=C2=A0=C2=A0=C2=A0   = Propagation of this NLRI is controlled by matching Route = Target

1018=C2=A0=C2=A0=C2=A0=C2=A0   extended = communities associated with the BGP path advertisement = with

1019=C2=A0=C2=A0=C2=A0=C2=A0   the VRF = import policy, using the same mechanism as described in = "BGP/

1020=C2=A0=C2=A0=C2=A0=C2=A0   MPLS IP = VPNs" [RFC4364]..

&nbs= p;

[nit] = s/"BGP/MPLS IP VPNs"/BGP/MPLS IP = VPNs

&nbs= p;

1022=C2=A0=C2=A0=C2=A0=C2=A0   Flow = Specification rules received via this NLRI apply only to = traffic

1023=C2=A0=C2=A0=C2=A0=C2=A0   that = belongs to the VRF(s) in which it is imported.  By = default,

1024=C2=A0=C2=A0=C2=A0=C2=A0   traffic = received from a remote PE is switched via an MPLS = forwarding

1025=C2=A0=C2=A0=C2=A0=C2=A0   decision = and is not subject to filtering.

&nbs= p;

1027=C2=A0=C2=A0=C2=A0=C2=A0   Contrary = to the behavior specified for the non-VPN NLRI, flow = rules

1028=C2=A0=C2=A0=C2=A0=C2=A0   are = accepted by default, when received from remote PE = routers.

&nbs= p;

[major] = The only other mention of "flow rule" is in the Introduction = when referring to the validation of external Flow Specifications, which = seems to then map to =C2=A76...but the next sub-section says that those = procedures apply.  What am I = missing?

&nbs= p;

&nbs= p;

1030=C2=A0=C2=A0=C2=A0=C2=A0 8.1.  = Validation Procedures for BGP/MPLS = VPNs

&nbs= p;

1032=C2=A0=C2=A0=C2=A0=C2=A0   The = validation procedures are the same as for = IPv4.

&nbs= p;

1034=C2=A0=C2=A0=C2=A0=C2=A0 8.2.  = Traffic Actions Rules

&nbs= p;

1036=C2=A0=C2=A0=C2=A0=C2=A0   The = traffic action rules are the same as for = IPv4.

&nbs= p;

[nit] = These 2 sub-sections could simply be covered by a couple of = sentences...

&nbs= p;

&nbs= p;

1038=C2=A0=C2=A0=C2=A0=C2=A0 9.  = Limitations of Previous Traffic Filtering = Efforts

&nbs= p;

[major] = This section reads like a justification...  I think it would be a = better fit as a subsection of the = Introduction.

&nbs= p;

1040=C2=A0=C2=A0=C2=A0=C2=A0 9.1.  = Limitations in Previous DDoS Traffic Filtering = Efforts

...<= /o:p>

1052=C2=A0=C2=A0=C2=A0=C2=A0   Several = techniques are currently used to control traffic filtering = of

1053=C2=A0=C2=A0=C2=A0=C2=A0   DoS = attacks.  Among those, one of the most common is to = inject

1054=C2=A0=C2=A0=C2=A0=C2=A0   unicast = route advertisements corresponding to a destination = prefix

1055=C2=A0=C2=A0=C2=A0=C2=A0   being = attacked (commonly known as remote triggered blackhole = RTBH).

1056=C2=A0=C2=A0=C2=A0=C2=A0   One = variant of this technique marks such route advertisements with = a

1057=C2=A0=C2=A0=C2=A0=C2=A0   = community that gets translated into a discard Next-Hop by = the

1058=C2=A0=C2=A0=C2=A0=C2=A0   = receiving router.  Other variants attract traffic to a = particular

1059=C2=A0=C2=A0=C2=A0=C2=A0   node = that serves as a deterministic drop = point.

&nbs= p;

[minor] = Please add Informative references to rfc3882, rfc5635, = rfc7999...

&nbs= p;

&nbs= p;

...<= /o:p>

1103=C2=A0=C2=A0=C2=A0=C2=A0 10.  = Traffic Monitoring

&nbs= p;

1105=C2=A0=C2=A0=C2=A0=C2=A0   Traffic = filtering applications require monitoring and = traffic

1106=C2=A0=C2=A0=C2=A0=C2=A0   = statistics facilities.  While this is an = implementation-specific

1107=C2=A0=C2=A0=C2=A0=C2=A0   choice, = implementations SHOULD provide:

&nbs= p;

1109=C2=A0=C2=A0=C2=A0=C2=A0   o =  A mechanism to log the packet header of filtered = traffic.

&nbs= p;

1111=C2=A0=C2=A0=C2=A0=C2=A0   o =  A mechanism to count the number of matches for a given = flow

1112=C2=A0=C2=A0=C2=A0=C2=A0     =  specification rule.

&nbs= p;

[minor] = Is there any relationship between this section and the S bit in = =C2=A77.3?

&nbs= p;

&nbs= p;

1114=C2=A0=C2=A0=C2=A0=C2=A0 11.  = Error-Handling and Future NLRI = Extensions

&nbs= p;

[major] = Suggestion: this section should be limited to describing what a = malformed traffic action extended community is, and then simply point to = rfc7606, which already covers the rest.  See more comments = below.

&nbs= p;

[nit] = The two topics covered here seem = unrelated...

&nbs= p;

1116=C2=A0=C2=A0=C2=A0=C2=A0   In case = BGP encounters an error in a Flow Specification = UPDATE

1117=C2=A0=C2=A0=C2=A0=C2=A0   message = it SHOULD treat this message as Treat-as-withdraw = according

1118=C2=A0=C2=A0=C2=A0=C2=A0   to = [RFC7606] Section 2.

&nbs= p;

[major] = The SHOULD above with the communities-related errors described below are = in conflict with rfc7606, which says this: "An UPDATE message with = a malformed Extended Community attribute SHALL be handled using the = approach of = "treat-as-withdraw"."

&nbs= p;

1120=C2=A0=C2=A0=C2=A0=C2=A0   Possible = reasons for an error are (for more reasons see = also

1121=C2=A0=C2=A0=C2=A0=C2=A0   = [RFC7606]):

&nbs= p;

1123=C2=A0=C2=A0=C2=A0=C2=A0   o =  Incorrect implementation of this specification - the = encoding/

1124=C2=A0=C2=A0=C2=A0=C2=A0     =  decoding of the NLRI or traffic action extended-communities do = not

1125=C2=A0=C2=A0=C2=A0=C2=A0     =  comply with this specification.

&nbs= p;

[major] = Related to the NLRI, rfc7606 says that "in order to use the = approach of "treat-as-withdraw", the entire NLRI field and/or = the MP_REACH_NLRI and MP_UNREACH_NLRI attributes need to be successfully = parsed...  If this is not possible...that the "session = reset" approach (or the "AFI/SAFI disable" approach) MUST = be followed."

&nbs= p;

[major] = For the Extended Communities...  The "incorrect = implementation" basically means that the encoding is wrong, = right?  But is the part about "comply with this = specification" necessary?  Other traffic action extended = communities (defined elsewhere) might be received.  I would rather = if the text above talked about malformed (to match the language in = rfc7606) traffic action extended communities in general (not just the = ones in this specification).

&nbs= p;

1127=C2=A0=C2=A0=C2=A0=C2=A0   o =  Unknown Flow Specification extensions - The sending party = has

1128=C2=A0=C2=A0=C2=A0=C2=A0     =  implemented a Flow Specification NLRI extension unknown to = the

1129=C2=A0=C2=A0=C2=A0=C2=A0     =  receiving party.

&nbs= p;

[major] = This treatment of unknown extensions is in conflict with the text in = =C2=A74.2: "If a given component type within a prefix in unknown, = the prefix in question cannot be used for traffic filtering purposes by = the receiver... However, for the purposes of BGP route propagation, this = prefix should still be transmitted since BGP route distribution is = independent on NLRI semantics."  IOW, = "treat-as-withdraw" is not compatible with forwarding = UPDATES.

&nbs= p;

1131=C2=A0=C2=A0=C2=A0=C2=A0   In order = to facilitate future extensions of the Flow = Specification

1132=C2=A0=C2=A0=C2=A0=C2=A0   NLRI, = such extensions SHOULD specify a way to encode a = "always-true"

1133=C2=A0=C2=A0=C2=A0=C2=A0   match = condition within the newly introduced components..  This = match

1134=C2=A0=C2=A0=C2=A0=C2=A0   = condition can be used to propagate (and apply) certain filters = only

1135=C2=A0=C2=A0=C2=A0=C2=A0   if a = specific extension is known to the = implemenation.

&nbs= p;

[nit] = s/a "always-true"/an = "always-true"

&nbs= p;

[minor] = What does "always-true" = mean?

&nbs= p;

[major] = How come this document doesn't follow the advice about the = "always-true" match = condition?

&nbs= p;

[nit] = s/implemenation/implementation

&nbs= p;

&nbs= p;

...<= /o:p>

1141=C2=A0=C2=A0=C2=A0=C2=A0 12.1.  = AFI/SAFI Definitions

&nbs= p;

1143=C2=A0=C2=A0=C2=A0=C2=A0   IANA = maintains a registry entitled "SAFI Values".  For the = purpose of

1144=C2=A0=C2=A0=C2=A0=C2=A0   this = work, IANA updated the registry and allocated two = additional

1145=C2=A0=C2=A0=C2=A0=C2=A0   = SAFIs:

&nbs= p;

[nit] = Even though the text will probably end up as written, it doesn't ask = IANA for anything: it assumes that the work is done.  I would = prefer it if the text was worded as a request.  It may not be an = issue for IANA, so there's no need to change anything, unless they say = so.

&nbs= p;

1147=C2=A0=C2=A0=C2=A0=C2=A0   = +-------+------------------------------------------+----------------+

1148=C2=A0=C2=A0=C2=A0=C2=A0   | Value = | Name                   =                   | = Reference      |

1149=C2=A0=C2=A0=C2=A0=C2=A0   = +-------+------------------------------------------+----------------+

1150=C2=A0=C2=A0=C2=A0=C2=A0   | 133 =   | IPv4 dissemination of Flow Specification | [this     =      |

1151=C2=A0=C2=A0=C2=A0=C2=A0   |   =     | rules               =                     =  | document]     =  |

1152=C2=A0=C2=A0=C2=A0=C2=A0   | 134 =   | VPNv4 dissemination of Flow           =    | [this         =  |

1153=C2=A0=C2=A0=C2=A0=C2=A0   |   =     | Specification rules           =            | document]     =  |

1154=C2=A0=C2=A0=C2=A0=C2=A0   = +-------+------------------------------------------+----------------+

&nbs= p;

[major] = It's not clear to me (because there's no explicit request) if the intent = is to add this document as a reference, or to replace the one to = rfc5575.  I would like you to be = explicit.

&nbs= p;

1156=C2=A0=C2=A0=C2=A0=C2=A0     =                  Table 3: = Registry: SAFI Values

&nbs= p;

1158=C2=A0=C2=A0=C2=A0=C2=A0 12.2.  Flow = Component Definitions

...<= /o:p>

1184=C2=A0=C2=A0=C2=A0=C2=A0   In order = to manage the limited number space and accommodate = several

1185=C2=A0=C2=A0=C2=A0=C2=A0   usages, = the following policies defined by [RFC8126] = used:

&nbs= p;

[nit] = s/[RFC8126] used/[RFC8126] are used

&nbs= p;

1187=C2=A0=C2=A0=C2=A0=C2=A0     =         = +--------------+-------------------------------+

1188=C2=A0=C2=A0=C2=A0=C2=A0     =         | Range        | Policy =                     =    |

1189=C2=A0=C2=A0=C2=A0=C2=A0     =         = +--------------+-------------------------------+

1190=C2=A0=C2=A0=C2=A0=C2=A0     =         | 0           =  | Invalid value               =   |

1191=C2=A0=C2=A0=C2=A0=C2=A0     =         | [1 .. 12]    | Defined by this = specification |

1192=C2=A0=C2=A0=C2=A0=C2=A0     =         | [13 .. 127]  | Specification required =        |

1193=C2=A0=C2=A0=C2=A0=C2=A0     =         | [128 .. 255] | First Come First Served =       |

1194=C2=A0=C2=A0=C2=A0=C2=A0     =         = +--------------+-------------------------------+

&nbs= p;

[major] = 0 is not really a range...and it's Invalid, so it shouldn't be part of = the Table detailing the registration policies.  BTW, I couldn't = find the text where 0 is declared Invalid -- please add some text to = =C2=A74.2.  Move 0 to Table 4.

&nbs= p;

[minor] = Besides the fact that "Defined by this specification" is not a = Policy, this table doesn't change anything in the current registry; it = is not needed.

&nbs= p;

1196=C2=A0=C2=A0=C2=A0=C2=A0     =            Table 5: Flow Spec Component = Types Policies

&nbs= p;

1198=C2=A0=C2=A0=C2=A0=C2=A0   The = specification of a particular "Flow Spec Component Type" = must

1199=C2=A0=C2=A0=C2=A0=C2=A0   clearly = identify what the criteria used to match packets forwarded = by

1200=C2=A0=C2=A0=C2=A0=C2=A0   the = router is.  This criteria should be meaningful across router = hops

1201=C2=A0=C2=A0=C2=A0=C2=A0   and not = depend on values that change hop-by-hop such as TTL or = Layer

1202=C2=A0=C2=A0=C2=A0=C2=A0   2 = encapsulation.

&nbs= p;

[minor] = This paragraph doesn't belong in the IANA section.  It seems to be = laying out the groundwork for new components...so it belongs somewhere = else.  Should any of the language be = Normative?

&nbs= p;

&nbs= p;

1204=C2=A0=C2=A0=C2=A0=C2=A0 12.3.  = Extended Community Flow Specification = Actions

&nbs= p;

1206=C2=A0=C2=A0=C2=A0=C2=A0   The = Extended Community Flow Specification Action types defined = in

1207=C2=A0=C2=A0=C2=A0=C2=A0   this = document consist of two parts:

&nbs= p;

1209=C2=A0=C2=A0=C2=A0=C2=A0     =  Type (BGP Transitive Extended Community = Type)

&nbs= p;

1211=C2=A0=C2=A0=C2=A0=C2=A0     =  Sub-Type

&nbs= p;

1213=C2=A0=C2=A0=C2=A0=C2=A0   For the = type-part, IANA maintains a registry entitled "BGP = Transitive

1214=C2=A0=C2=A0=C2=A0=C2=A0   Extended = Community Types".  For the purpose of this work (Section = 7),

1215=C2=A0=C2=A0=C2=A0=C2=A0   IANA = updated the registry to contain the values listed = below:

&nbs= p;

[major] = The range is defined in the registry as "0x80-0x8f =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Reserved for Experimental Use".  According to = rfc8126, "IANA does not record assignments from registries or = ranges with this policy".

&nbs= p;

I don't = know why 0x80 was the first value chosen; it looks like it was first = used in draft-marques-idr-flow-spec-01 (2004), while the corresponding = Extended Communities draft (draft-ietf-idr-bgp-ext-communities-07) = already indicated that the range was for Experimental Use.  I guess = just lack of sync...  But then I also don't understand how/why IANA = ended up with the information in the Registry....maybe because the = sub-types are not for Experimental Use -- hmmm, which sounds = contradictory to me.

&nbs= p;

The = reason/history doesn't matter anymore, but the current use does.  = The mechanism described in this document is clearly not = experimental.  Given that changing the Type values is not an option = because of the deployed base, etc.., then I think we should clean up the = Registry and move 0x80-0x82 from the Experimental Use range to the FCFS = range.  This change would mean an Update to = rfc7153.

&nbs= p;

To = simplify the process, the Update can be done in this document.  = However, I think that there's some confusion with these types apparently = being associated only with Flow Specifications, when they are labeled as = Generic.  IOW, ideally the issue would be corrected = independently...

&nbs= p;

&nbs= p;

1217=C2=A0=C2=A0=C2=A0=C2=A0   = +-------+-----------------------------------------------+-----------+

1218=C2=A0=C2=A0=C2=A0=C2=A0   | Type =  | Name                 =                     =      | Reference |

1219=C2=A0=C2=A0=C2=A0=C2=A0   | Value = |                     =                     =       |           = |

1220=C2=A0=C2=A0=C2=A0=C2=A0   = +-------+-----------------------------------------------+-----------+

1221=C2=A0=C2=A0=C2=A0=C2=A0   | 0x80 =  | Generic Transitive Experimental Use Extended  | [RFC7153] = |

1222=C2=A0=C2=A0=C2=A0=C2=A0   |   =     | Community (Sub-Types are defined in the     =   |           = |

1223=C2=A0=C2=A0=C2=A0=C2=A0   |   =     | "Generic Transitive Experimental Use Extended | =           |

1224=C2=A0=C2=A0=C2=A0=C2=A0   |   =     | Community Sub-Types" registry)       =          |           = |

1225=C2=A0=C2=A0=C2=A0=C2=A0   | 0x81 =  | Generic Transitive Experimental Use Extended  | [this =     |

1226=C2=A0=C2=A0=C2=A0=C2=A0   |   =     | Community Part 2 (Sub-Types are defined in   =  | document] |

1227=C2=A0=C2=A0=C2=A0=C2=A0   |   =     | the "Generic Transitive Experimental Use   =    | [See     =  |

1228=C2=A0=C2=A0=C2=A0=C2=A0   |   =     | Extended Community Part 2 Sub-Types"     =      | Note-1]   = |

1229=C2=A0=C2=A0=C2=A0=C2=A0   |   =     | Registry)             =                     =     |           = |

1230=C2=A0=C2=A0=C2=A0=C2=A0   | 0x82 =  | Generic Transitive Experimental Use Extended  | [this =     |

1231=C2=A0=C2=A0=C2=A0=C2=A0   |   =     | Community Part 3 (Sub-Types are defined in   =  | document] |

1232=C2=A0=C2=A0=C2=A0=C2=A0   |   =     | the "Generic Transitive Experimental Use   =    | [See     =  |

1233=C2=A0=C2=A0=C2=A0=C2=A0   |   =     | Extended Community Part 3 Sub-Types"     =      | Note-1]   = |

1234=C2=A0=C2=A0=C2=A0=C2=A0   |   =     | Registry)             =                     =     |           = |

1235=C2=A0=C2=A0=C2=A0=C2=A0   = +-------+-----------------------------------------------+-----------+

&nbs= p;

1237=C2=A0=C2=A0=C2=A0=C2=A0     =  Table 6: Registry: Generic Transitive Experimental Use = Extended

1238=C2=A0=C2=A0=C2=A0=C2=A0     =                     =      Community Types

&nbs= p;

[major] = In line with Updating the registry and the intent, the names of the = Types/Registries should not include the word "experimental" to = avoid any further confusion.

&nbs= p;

1240=C2=A0=C2=A0=C2=A0=C2=A0   Note-1: = This document obsoletes RFC7674.

&nbs= p;

[minor] = Putting the reference to this note in the Table seems to be asking IANA = to add a note there too...which I would think is not the case.  = This goes back to the intent of whether the reference to this document = should replace what is there or simply be = added.

&nbs= p;

&nbs= p;

...<= /o:p>

1292=C2=A0=C2=A0=C2=A0=C2=A0   The = "traffic-action" extended community (Section 7.3) defined in = this

1293=C2=A0=C2=A0=C2=A0=C2=A0   document = has 46 unused bits, which can be used to convey = additional

1294=C2=A0=C2=A0=C2=A0=C2=A0   = meaning.  IANA created and maintains a new registry = entitled:

1295=C2=A0=C2=A0=C2=A0=C2=A0   = "Traffic Action Fields".  These values should be assigned = via IETF

1296=C2=A0=C2=A0=C2=A0=C2=A0   Review = rules only.  The following traffic-action fields have = been

1297=C2=A0=C2=A0=C2=A0=C2=A0   = allocated:

&nbs= p;

[major] = It needs to be mentioned somewhere that the reference for the whole = registry (not just the values below) should be moved to this = document.

&nbs= p;

&nbs= p;

...<= /o:p>

1308=C2=A0=C2=A0=C2=A0=C2=A0 13.  = Security Considerations

&nbs= p;

1310=C2=A0=C2=A0=C2=A0=C2=A0   = Inter-provider routing is based on a web of trust.  = Neighboring

1311=C2=A0=C2=A0=C2=A0=C2=A0   = autonomous systems are trusted to advertise valid = reachability

1312=C2=A0=C2=A0=C2=A0=C2=A0   = information.  If this trust model is violated, a = neighboring

1313=C2=A0=C2=A0=C2=A0=C2=A0   = autonomous system may cause a denial-of-service attack by = advertising

1314=C2=A0=C2=A0=C2=A0=C2=A0   = reachability information for a given prefix for which it does = not

1315=C2=A0=C2=A0=C2=A0=C2=A0   provide = service.

&nbs= p;

[major] = References to Origin Validation (rfc6811) and BGPSec (rfc8205) should be = mentioned as possible mitigation...with maybe a comment about the = current deployment status.

&nbs= p;

1317=C2=A0=C2=A0=C2=A0=C2=A0   As long = as traffic filtering rules are restricted to match = the

1318=C2=A0=C2=A0=C2=A0=C2=A0   = corresponding unicast routing paths for the relevant prefixes, = the

1319=C2=A0=C2=A0=C2=A0=C2=A0   security = characteristics of this proposal are equivalent to = the

1320=C2=A0=C2=A0=C2=A0=C2=A0   existing = security properties of BGP unicast routing.  However, = this

1321=C2=A0=C2=A0=C2=A0=C2=A0   document = also specifies traffic filtering actions that may = need

1322=C2=A0=C2=A0=C2=A0=C2=A0   custom = additional verification on the receiver side.  See Section = 14.

&nbs= p;

[major] = In general, Flow Specifications have a one-AS-hop propagation model, = right?  This means that the security properties are different = because (1) unicast routing propagates multiple hops, and (2) the intent = of the "Route Origin ASN" (rfc6811) is not reflected in the = request to rate-limit, or even drop (!) traffic to a destination.  = Yes, it is all based on trust...but different.  For example, Origin = Validation wouldn't be available for Flow = Specifications.

&nbs= p;

1324=C2=A0=C2=A0=C2=A0=C2=A0   Where it = is not the case, this would open the door to further = denial-

1325=C2=A0=C2=A0=C2=A0=C2=A0   = of-service attacks.

&nbs= p;

[major] = Like what?  What are possible mitigations?  Just saying that = the door is open is not enough.

&nbs= p;

&nbs= p;

...<= /o:p>

1337=C2=A0=C2=A0=C2=A0=C2=A0 14.  = Operational Security Considerations

&nbs= p;

[minor] = If you ask me, this section should be rolled into the last one: I think = all the considerations (in both sections) are really = operational...

&nbs= p;

1339=C2=A0=C2=A0=C2=A0=C2=A0   While = the general verification of the traffic filter NLRI = is

1340=C2=A0=C2=A0=C2=A0=C2=A0   = specified in this document (Section 6) the traffic filtering = actions

1341=C2=A0=C2=A0=C2=A0=C2=A0   received = by a third party may need custom verification or = filtering.

1342=C2=A0=C2=A0=C2=A0=C2=A0   In = particular all non traffic-rate actions may allow a third party = to

1343=C2=A0=C2=A0=C2=A0=C2=A0   modify = packet forwarding properties and potentially gain access = to

1344=C2=A0=C2=A0=C2=A0=C2=A0   other = routing-tables/VPNs or undesired queues.  This can be = avoided

1345=C2=A0=C2=A0=C2=A0=C2=A0   by = proper filtering of action communities at network borders and = by

1346=C2=A0=C2=A0=C2=A0=C2=A0   mapping = user-defined communities (see Section 7) to expose = certain

1347=C2=A0=C2=A0=C2=A0=C2=A0   = forwarding properties to third = parties.

&nbs= p;

[minor] = I didn't get this last part...  I understand filtering, but didn't = quite understand how the mapping of communities would = help.

&nbs= p;

1349=C2=A0=C2=A0=C2=A0=C2=A0   Since = verfication of the traffic filtering NLRI is tied to = the

1350=C2=A0=C2=A0=C2=A0=C2=A0   = announcement of the best unicast route, a unfiltered address = space

1351=C2=A0=C2=A0=C2=A0=C2=A0   hijack = (e.g. advertisement of a more specific route) may cause = this

1352=C2=A0=C2=A0=C2=A0=C2=A0   = verification to fail and consequently prevent Flow = Specification

1353=C2=A0=C2=A0=C2=A0=C2=A0   filters = from being accepted by a peer.

&nbs= p;

[nit] = s/verfication/verification

&nbs= p;

[nit] = s/a unfiltered/an unfiltered

&nbs= p;

[minor] = Again, mention Origin Validation as possible = mitigation.

&nbs= p;

1355=C2=A0=C2=A0=C2=A0=C2=A0 15.  = Original authors

&nbs= p;

1357=C2=A0=C2=A0=C2=A0=C2=A0   Barry = Greene, Pedro Marques, Jared Mauch, Danny McPherson, = and

1358=C2=A0=C2=A0=C2=A0=C2=A0   Nischal = Sheth were authors on RFC5575, and therefore are = contributing

1359=C2=A0=C2=A0=C2=A0=C2=A0   authors = on this document.

&nbs= p;

[minor] = To be in line with rfc7322, this section should be renamed to = "Contributors".

&nbs= p;

&nbs= p;

1361=C2=A0=C2=A0=C2=A0=C2=A0 16.  = Acknowledgements

...<= /o:p>

1370=C2=A0=C2=A0=C2=A0=C2=A0   A packet = rate flowspec action was also discribed in a = flowspec

1371=C2=A0=C2=A0=C2=A0=C2=A0   = extention draft and the authors like to thank Wesley Eddy, = Justin

1372=C2=A0=C2=A0=C2=A0=C2=A0   Dailey = and Gilbert Clark for their work.

&nbs= p;

[nit] = This is the first time that "flowspec" is used.  Not a = bad thing...just an observation that we went through the whole document = without using the colloquial name = flowspec.

&nbs= p;

[nit] = s/discribed/described

&nbs= p;

[nit] = s/extention/extension

&nbs= p;

1374=C2=A0=C2=A0=C2=A0=C2=A0   = Additional the authors would like to thank Alexander = Mayrhofer,

1375=C2=A0=C2=A0=C2=A0=C2=A0   Nicolas = Fevrier, Job Snijders, Jeffrey Haas and Adam Chappell = for

1376=C2=A0=C2=A0=C2=A0=C2=A0   their = comments and review.

&nbs= p;

[nit] = s/Additional/Additionally,

&nbs= p;

&nbs= p;

1378=C2=A0=C2=A0=C2=A0=C2=A0 17.  = References

&nbs= p;

1380=C2=A0=C2=A0=C2=A0=C2=A0 17.1.  = Normative References

&nbs= p;

1382=C2=A0=C2=A0=C2=A0=C2=A0   = [IEEE.754.1985]

1383=C2=A0=C2=A0=C2=A0=C2=A0     =          IEEE, "Standard for Binary = Floating-Point Arithmetic",

1384=C2=A0=C2=A0=C2=A0=C2=A0     =          IEEE 754-1985, August = 1985.

&nbs= p;

[minor] = IEEE has revised this spec twice, the most current revision was = published earlier this year.  Should the reference to the 1985 = version be kept?  Is there a reason not to point generically to = IEEE 754, instead of to a specific = version?

&nbs= p;

&nbs= p;

...<= /o:p>

1419=C2=A0=C2=A0=C2=A0=C2=A0   = [RFC5668]  Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet = AS

1420=C2=A0=C2=A0=C2=A0=C2=A0     =          Specific BGP Extended Community", = RFC 5668,

1421=C2=A0=C2=A0=C2=A0=C2=A0     =          DOI 10.17487/RFC5668, October = 2009,

1422=C2=A0=C2=A0=C2=A0=C2=A0     =          <https://www.rfc-editor.o= rg/info/rfc5668>.

&nbs= p;

[minor] = I don't think this needs to be a Normative = reference.

&nbs= p;

&nbs= p;

...<= /o:p>

1458=C2=A0=C2=A0=C2=A0=C2=A0 Appendix = A.  Comparison with RFC 5575

...<= /o:p>

1464=C2=A0=C2=A0=C2=A0=C2=A0     =  Section 1 introduces the Flow Specification NLRI.  In RFC5575 = this

1465=C2=A0=C2=A0=C2=A0=C2=A0     =  NLRI was defined as an opaque-key in BGPs database.  = This

1466=C2=A0=C2=A0=C2=A0=C2=A0     =  specification has removed all references to a opaque-key = property.

1467=C2=A0=C2=A0=C2=A0=C2=A0     =  BGP is able understand the NLRI encoding.  This change = also

1468=C2=A0=C2=A0=C2=A0=C2=A0     =  resulted in a new section regarding error-handling = and

1469=C2=A0=C2=A0=C2=A0=C2=A0     =  extensibility (Section 11).

&nbs= p;

[nit] = s/able understand/able to understand

&nbs= p;

&nbs= p;

------=_NextPart_000_009F_01D56F8B.0C7725D0--