--- 1/draft-ietf-idr-rfc5575bis-24.txt 2020-05-21 00:13:05.400540354 -0700 +++ 2/draft-ietf-idr-rfc5575bis-25.txt 2020-05-21 00:13:05.452541015 -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 30, 2020 R. Raszuk +Expires: November 21, 2020 R. Raszuk Bloomberg LP D. McPherson Verisign M. Bacher T-Mobile Austria - April 28, 2020 + May 20, 2020 Dissemination of Flow Specification Rules - draft-ietf-idr-rfc5575bis-24 + draft-ietf-idr-rfc5575bis-25 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 30, 2020. + This Internet-Draft will expire on November 21, 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 @@ -95,32 +95,32 @@ 7.3. Traffic-action (traffic-action) sub-type 0x07 . . . . . . 21 7.4. RT Redirect (rt-redirect) sub-type 0x08 . . . . . . . . . 22 7.5. Traffic Marking (traffic-marking) sub-type 0x09 . . . . . 23 7.6. Interaction with other Filtering Mechanisms in Routers . 23 7.7. Considerations on Traffic Filtering Action Interference . 24 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks . 24 9. Traffic Monitoring . . . . . . . . . . . . . . . . . . . . . 25 10. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 25 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 11.1. AFI/SAFI Definitions . . . . . . . . . . . . . . . . . . 25 - 11.2. Flow Component Definitions . . . . . . . . . . . . . . . 26 - 11.3. Extended Community Flow Specification Actions . . . . . 27 + 11.2. Flow Component Definitions . . . . . . . . . . . . . . . 27 + 11.3. Extended Community Flow Specification Actions . . . . . 28 12. Security Considerations . . . . . . . . . . . . . . . . . . . 30 - 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 - 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 + 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 + 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 15.1. Normative References . . . . . . . . . . . . . . . . . . 32 15.2. Informative References . . . . . . . . . . . . . . . . . 34 - 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 34 + 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Appendix A. Example Python code: flow_rule_cmp . . . . . . . . . 35 - Appendix B. Comparison with RFC 5575 . . . . . . . . . . . . . . 37 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 + Appendix B. Comparison with RFC 5575 . . . . . . . . . . . . . . 38 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 1. Introduction This document obsoletes "Dissemination of Flow Specification Rules" [RFC5575] (see Appendix B for the differences). This document also obsoletes "Clarification of the Flowspec Redirect Extended Community" [RFC7674] since it incorporates the encoding of the BGP Flow Specification Redirect Extended Community in Section 7.4. Modern IP routers have the capability to forward traffic and to @@ -249,21 +249,21 @@ session. 4. Dissemination of IPv4 Flow Specification Information This document defines a Flow Specification NLRI type (Figure 1) that may include several components such as destination prefix, source prefix, protocol, ports, and others (see Section 4.2 below). This NLRI information is encoded using MP_REACH_NLRI and MP_UNREACH_NLRI attributes as defined in [RFC4760]. When advertising - Flow Specifications, the Length of Next Hop Network Address SHOULD be + Flow Specifications, the Length of Next Hop Network Address MUST be set to 0. The Network Address of Next Hop field MUST be ignored. The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as one or more 2-tuples of the form . It consists of a 1- or 2-octet length field followed by a variable-length NLRI value. The length is expressed in octets. +-------------------------------+ | length (0xnn or 0xfnnn) | +-------------------------------+ @@ -332,30 +332,30 @@ +---+---+---+---+---+---+---+---+ | e | a | len | 0 |lt |gt |eq | +---+---+---+---+---+---+---+---+ Figure 2: Numeric Operator (numeric_op) e - end-of-list bit: Set in the last {op, value} pair in the list. a - AND bit: If unset, the result of the previous {op, value} pair is logically ORed with the current one. If set, the operation is - a logical AND. In the first operator octet of a sequence it - SHOULD be encoded as unset and MUST be treated as always unset on + a logical AND. In the first operator octet of a sequence it MUST + be encoded as unset and MUST be treated as always unset on decoding. The AND operator has higher priority than OR for the purposes of evaluating logical expressions. len - length: The length of the value field for this operator given as (1 << len). This encodes 1 (len=00), 2 (len=01), 4 (len=10), 8 (len=11) octets. - 0 - SHOULD be set to 0 on NLRI encoding, and MUST be ignored during + 0 - MUST be set to 0 on NLRI encoding, and MUST be ignored during decoding lt - less than comparison between data and value. gt - greater than comparison between data and value. eq - equality between data and value. The bits lt, gt, and eq can be combined to produce common relational operators such as "less or equal", "greater or equal", and "not equal @@ -390,21 +390,21 @@ e, a, len - Most significant nibble: (end-of-list bit, AND bit, and length field), as defined in the Numeric Operator format in Section 4.2.1.1. not - NOT bit: If set, logical negation of operation. m - Match bit: If set, this is a bitwise match operation defined as "(data AND value) == value"; if unset, (data AND value) evaluates to TRUE if any of the bits in the value mask are set in the data - 0 - all 0 bits: SHOULD be set to 0 on NLRI encoding, and MUST be + 0 - all 0 bits: MUST be set to 0 on NLRI encoding, and MUST be ignored during decoding 4.2.2. Components The encoding of each of the components begins with a type field (1 octet) followed by a variable length parameter. The following sections define component types and parameter encodings for the IPv4 IP layer and transport layer headers. IPv6 NLRI component types are described in [I-D.ietf-idr-flow-spec-v6]. @@ -603,21 +603,21 @@ IsF - Is a fragment - match if [RFC0791] IP Header Fragment Offset is not 0 FF - First fragment - match if [RFC0791] IP Header Fragment Offset is 0 AND Flags Bit-2 (MF) is 1 LF - Last fragment - match if [RFC0791] IP Header Fragment Offset is not 0 AND Flags Bit-2 (MF) is 0 - 0 - SHOULD be set to 0 on NLRI encoding, and MUST be ignored during + 0 - MUST be set to 0 on NLRI encoding, and MUST be ignored during decoding 4.3. Examples of Encodings 4.3.1. Example 1 An example of a Flow Specification NLRI encoding for: "all packets to 192.0.2.0/24 and TCP port 25". +--------+----------------+----------+----------+ @@ -995,22 +995,22 @@ o T: Terminal Action (bit 47): When this bit is set, the traffic filtering engine will evaluate any subsequent Flow Specifications (as defined by the ordering procedure Section 5.1). If not set, the evaluation of the traffic filters stops when this Flow Specification is evaluated. o S: Sample (bit 46): Enables traffic sampling and logging for this Flow Specification (only effective when set). o Traffic Action Field: Other Traffic Action Field (see Section 11) - bits unused in this specification. These bits SHOULD be set to 0 - on encoding, and MUST be ignored during decoding. + bits unused in this specification. These bits MUST be set to 0 on + encoding, and MUST be ignored during decoding. The use of the Terminal Action (bit 47) may result in more than one Flow Specification matching a particular traffic flow. All the Traffic Filtering Actions from these Flow Specifications shall be collected and applied. In case of interfering Traffic Filtering Actions it is an implementation decision which Traffic Filtering Actions are selected. See also Section 7.7. Interferes with: No other BGP Flow Specification Traffic Filtering Action in this document. @@ -1050,21 +1050,21 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | reserved | reserved | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | r.| DSCP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Traffic Marking Extended Community Encoding o DSCP: new DSCP value for the transiting IP packet. - o reserved, r.: SHOULD be set to 0 on encoding, and MUST be ignored + o reserved, r.: MUST be set to 0 on encoding, and MUST be ignored during decoding. Interferes with: No other BGP Flow Specification Traffic Filtering Action in this document. 7.6. Interaction with other Filtering Mechanisms in Routers Implementations should provide mechanisms that map an arbitrary BGP community value (normal or extended) to Traffic Filtering Actions that require different mappings on different systems in the network. @@ -1178,38 +1178,49 @@ | Value | Name | Reference | +-------+------------------------------------------+----------------+ | 133 | Dissemination of Flow Specification | [this | | | rules | document] | | 134 | L3VPN Dissemination of Flow | [this | | | Specification rules | document] | +-------+------------------------------------------+----------------+ Table 3: Registry: SAFI Values - The above textual changes clarify the definition of the SAFIs rather - than change its underlying meaning. Therefore, based on + The above textual changes generalise the definition of the SAFIs + rather than change its underlying meaning. Therefore, based on "The YANG 1.1 Data Modeling Language" [RFC7950], the above text - implies that the following YANG descriptions from + implies that the following YANG enums from "Common YANG Data Types for the Routing Area" [RFC8294] need to have - their descriptions at https://www.iana.org/assignments/iana-routing- - types [2] changed to: + their names and descriptions at https://www.iana.org/assignments/ + iana-routing-types [2] changed to: - enum ipv4-flow-spec-safi { + enum flow-spec-safi { value 133; description "Dissemination of Flow Specification rules SAFI."; } - enum vpnv4-flow-spec-safi { + enum l3vpn-flow-spec-safi { value 134; description - "L3VPN Dissemination of Flow Specification rules SAFI"; + "L3VPN Dissemination of Flow Specification rules SAFI."; + } + + + A new revision statement should be added to the module as follows: + + + revision [revision date] { + description "Non-backwards-compatible change of SAFI names + (SAFI values 133, 134)."; + reference + "[this document]: Dissemination of Flow Specification Rules."; } 11.2. Flow Component Definitions A Flow Specification consists of a sequence of flow components, which are identified by an 8-bit component type. IANA has created and maintains a registry entitled "Flow Spec Component Types". IANA is requested to update the reference for this registry to [this document]. Furthermore the references to the values should be @@ -1546,21 +1557,21 @@ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 15.2. Informative References [I-D.ietf-idr-flow-spec-v6] Loibl, C., Raszuk, R., and S. Hares, "Dissemination of Flow Specification Rules for IPv6", draft-ietf-idr-flow- - spec-v6-10 (work in progress), November 2019. + spec-v6-11 (work in progress), April 2020. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, . [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., and D. McPherson, "Dissemination of Flow Specification Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, .