--- 1/draft-ietf-idr-rfc5575bis-21.txt 2020-04-17 01:13:05.726863419 -0700 +++ 2/draft-ietf-idr-rfc5575bis-22.txt 2020-04-17 01:13:05.802865334 -0700 @@ -1,25 +1,25 @@ IDR Working Group C. Loibl Internet-Draft next layer Telekom GmbH Obsoletes: 5575,7674 (if approved) S. Hares Intended status: Standards Track Huawei -Expires: October 18, 2020 R. Raszuk +Expires: October 19, 2020 R. Raszuk Bloomberg LP D. McPherson Verisign M. Bacher T-Mobile Austria - April 16, 2020 + April 17, 2020 Dissemination of Flow Specification Rules - draft-ietf-idr-rfc5575bis-21 + draft-ietf-idr-rfc5575bis-22 Abstract This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic Flow Specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. It also specifies BGP Extended Community encoding formats, that can @@ -50,21 +50,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on October 18, 2020. + This Internet-Draft will expire on October 19, 2020. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -779,21 +779,22 @@ string using the memcmp() function as defined by [ISO_IEC_9899]. For strings with equal lengths the lowest string (memcmp) has higher precedence. For strings of different lengths, the common prefix is compared. If the common prefix is not equal the string with the lowest prefix has higher precedence. If the common prefix is equal, the longest string is considered to have higher precedence than the shorter one. The code in Appendix A shows a Python3 implementation of the comparison algorithm. The full code was tested with Python 3.6.3 and - can be obtained at https://github.com/stoffi92/flowspec-cmp [1]. + can be obtained at + https://github.com/stoffi92/rfc5575bis/tree/master/flowspec-cmp [1]. 6. Validation Procedure Flow Specifications received from a BGP peer that are accepted in the respective Adj-RIB-In are used as input to the route selection process. Although the forwarding attributes of two routes for the same Flow Specification prefix may be the same, BGP is still required to perform its path selection algorithm in order to select the correct set of attributes to advertise. @@ -865,25 +866,25 @@ The neighboring AS is the immediate destination of the traffic described by the Flow Specification. If it requests these flows to be dropped, that request can be honored without concern that it represents a denial of service in itself. Supposedly, the traffic is being dropped by the downstream autonomous system, and there is no added value in carrying the traffic to it. 7. Traffic Filtering Actions This document defines a minimum set of Traffic Filtering Actions that - it standardizes as BGP extended community values [RFC7153]. This is - not meant to be an inclusive list of all the possible actions, but - only a subset that can be interpreted consistently across the - network. Additional actions can be defined as either requiring - standards or as vendor specific. + it standardizes as BGP extended communities [RFC4360]. This is not + meant to be an inclusive list of all the possible actions, but only a + subset that can be interpreted consistently across the network. + Additional actions can be defined as either requiring standards or as + vendor specific. The default action for a matching Flow Specification is to accept the packet (treat the packet according to the normal forwarding behaviour of the system). This document defines the following extended communities values shown in Table 2 in the form 0xttss where tt indicates the type and ss indicates the sub-type of the extended community. Encodings for these extended communities are described below. @@ -1539,21 +1540,21 @@ [RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect Extended Community", RFC 7674, DOI 10.17487/RFC7674, October 2015, . [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, . 15.3. URIs - [1] https://github.com/stoffi92/flowspec-cmp + [1] https://github.com/stoffi92/rfc5575bis/tree/master/flowspec-cmp Appendix A. Python code: flow_rule_cmp """ Copyright (c) 2020 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license