draft-ietf-idr-rfc5575bis-23.txt   draft-ietf-idr-rfc5575bis-24.txt 
IDR Working Group C. Loibl IDR Working Group C. Loibl
Internet-Draft next layer Telekom GmbH Internet-Draft next layer Telekom GmbH
Obsoletes: 5575,7674 (if approved) S. Hares Obsoletes: 5575,7674 (if approved) S. Hares
Intended status: Standards Track Huawei Intended status: Standards Track Huawei
Expires: October 25, 2020 R. Raszuk Expires: October 30, 2020 R. Raszuk
Bloomberg LP Bloomberg LP
D. McPherson D. McPherson
Verisign Verisign
M. Bacher M. Bacher
T-Mobile Austria T-Mobile Austria
April 23, 2020 April 28, 2020
Dissemination of Flow Specification Rules Dissemination of Flow Specification Rules
draft-ietf-idr-rfc5575bis-23 draft-ietf-idr-rfc5575bis-24
Abstract Abstract
This document defines a Border Gateway Protocol Network Layer This document defines a Border Gateway Protocol Network Layer
Reachability Information (BGP NLRI) encoding format that can be used Reachability Information (BGP NLRI) encoding format that can be used
to distribute traffic Flow Specifications. This allows the routing to distribute traffic Flow Specifications. This allows the routing
system to propagate information regarding more specific components of system to propagate information regarding more specific components of
the traffic aggregate defined by an IP destination prefix. the traffic aggregate defined by an IP destination prefix.
It also specifies BGP Extended Community encoding formats, that can It also specifies BGP Extended Community encoding formats, that can
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 25, 2020. This Internet-Draft will expire on October 30, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 18 skipping to change at page 3, line 18
7.5. Traffic Marking (traffic-marking) sub-type 0x09 . . . . . 23 7.5. Traffic Marking (traffic-marking) sub-type 0x09 . . . . . 23
7.6. Interaction with other Filtering Mechanisms in Routers . 23 7.6. Interaction with other Filtering Mechanisms in Routers . 23
7.7. Considerations on Traffic Filtering Action Interference . 24 7.7. Considerations on Traffic Filtering Action Interference . 24
8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks . 24 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks . 24
9. Traffic Monitoring . . . . . . . . . . . . . . . . . . . . . 25 9. Traffic Monitoring . . . . . . . . . . . . . . . . . . . . . 25
10. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 25 10. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 25
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11.1. AFI/SAFI Definitions . . . . . . . . . . . . . . . . . . 25 11.1. AFI/SAFI Definitions . . . . . . . . . . . . . . . . . . 25
11.2. Flow Component Definitions . . . . . . . . . . . . . . . 26 11.2. Flow Component Definitions . . . . . . . . . . . . . . . 26
11.3. Extended Community Flow Specification Actions . . . . . 27 11.3. Extended Community Flow Specification Actions . . . . . 27
12. Security Considerations . . . . . . . . . . . . . . . . . . . 29 12. Security Considerations . . . . . . . . . . . . . . . . . . . 30
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
15.1. Normative References . . . . . . . . . . . . . . . . . . 31 15.1. Normative References . . . . . . . . . . . . . . . . . . 32
15.2. Informative References . . . . . . . . . . . . . . . . . 33 15.2. Informative References . . . . . . . . . . . . . . . . . 34
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 34 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Appendix A. Python code: flow_rule_cmp . . . . . . . . . . . . . 34 Appendix A. Example Python code: flow_rule_cmp . . . . . . . . . 35
Appendix B. Comparison with RFC 5575 . . . . . . . . . . . . . . 35 Appendix B. Comparison with RFC 5575 . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
This document obsoletes "Dissemination of Flow Specification Rules" This document obsoletes "Dissemination of Flow Specification Rules"
[RFC5575] (see Appendix B for the differences). This document also [RFC5575] (see Appendix B for the differences). This document also
obsoletes "Clarification of the Flowspec Redirect Extended Community" obsoletes "Clarification of the Flowspec Redirect Extended Community"
[RFC7674] since it incorporates the encoding of the BGP Flow [RFC7674] since it incorporates the encoding of the BGP Flow
Specification Redirect Extended Community in Section 7.4. Specification Redirect Extended Community in Section 7.4.
Modern IP routers have the capability to forward traffic and to Modern IP routers have the capability to forward traffic and to
skipping to change at page 7, line 11 skipping to change at page 7, line 11
(AFI, SAFI) pair carried in the Multiprotocol Extension Capability (AFI, SAFI) pair carried in the Multiprotocol Extension Capability
MUST be (AFI=1, SAFI=133) for IPv4 Flow Specification, and (AFI=1, MUST be (AFI=1, SAFI=133) for IPv4 Flow Specification, and (AFI=1,
SAFI=134) for VPNv4 Flow Specification. SAFI=134) for VPNv4 Flow Specification.
4.1. Length Encoding 4.1. Length Encoding
o If the NLRI length is smaller than 240 (0xf0 hex) octets, the o If the NLRI length is smaller than 240 (0xf0 hex) octets, the
length field can be encoded as a single octet. length field can be encoded as a single octet.
o Otherwise, it is encoded as an extended-length 2-octet value in o Otherwise, it is encoded as an extended-length 2-octet value in
which the most significant nibble of the first octet is all ones. which the most significant nibble has the hex value 0xf.
In Figure 1 above, values less-than 240 are encoded using two hex In Figure 1 above, values less-than 240 are encoded using two hex
digits (0xnn). Values above 239 are encoded using 3 hex digits digits (0xnn). Values above 239 are encoded using 3 hex digits
(0xfnnn). The highest value that can be represented with this (0xfnnn). The highest value that can be represented with this
encoding is 4095. For example the length value of 239 is encoded as encoding is 4095. For example the length value of 239 is encoded as
0xef (single octet) while 240 is encoded as 0xf0f0 (2-octet). 0xef (single octet) while 240 is encoded as 0xf0f0 (2-octet).
4.2. NLRI Value Encoding 4.2. NLRI Value Encoding
The Flow Specification NLRI value consists of a list of optional The Flow Specification NLRI value consists of a list of optional
components and is encoded as follows: components and is encoded as follows:
Encoding: <[component]+> Encoding: <[component]+>
A specific packet is considered to match the Flow Specification when A specific packet is considered to match the Flow Specification when
it matches the intersection (AND) of all the components present in it matches the intersection (AND) of all the components present in
the Flow Specification. the Flow Specification.
Components MUST follow strict type ordering by increasing numerical Components MUST follow strict type ordering by increasing numerical
order. A given component type may (exactly once) or may not be order. A given component type MAY (exactly once) be present in the
present in the Flow Specification. If present, it MUST precede any Flow Specification. If present, it MUST precede any component of
component of higher numeric type value. higher numeric type value.
All combinations of components within a single Flow Specification are All combinations of components within a single Flow Specification are
allowed. However, some combinations cannot match any packets (e.g. allowed. However, some combinations cannot match any packets (e.g.
"ICMP Type AND Port" will never match any packets), and thus SHOULD "ICMP Type AND Port" will never match any packets), and thus SHOULD
NOT be propagated by BGP. NOT be propagated by BGP.
A NLRI value not encoded as specified in Section 4.2 is considered A NLRI value not encoded as specified specified here is considered
malformed and error handling according to Section 10 is performed. malformed and error handling according to Section 10 is performed.
4.2.1. Operators 4.2.1. Operators
Most of the components described below make use of comparison Most of the components described below make use of comparison
operators. Which of the two operators is used is defined by the operators. Which of the two operators is used is defined by the
components in Section 4.2.2. The operators are encoded as a single components in Section 4.2.2. The operators are encoded as a single
octet. octet.
4.2.1.1. Numeric Operator (numeric_op) 4.2.1.1. Numeric Operator (numeric_op)
skipping to change at page 10, line 44 skipping to change at page 10, line 44
Defines a list of {numeric_op, value} pairs that matches source OR Defines a list of {numeric_op, value} pairs that matches source OR
destination TCP/UDP ports (see [RFC0793] Section 3.1 and [RFC0768] destination TCP/UDP ports (see [RFC0793] Section 3.1 and [RFC0768]
Section "Format"). This component matches if either the destination Section "Format"). This component matches if either the destination
port OR the source port of a IP packet matches the value. port OR the source port of a IP packet matches the value.
This component uses the Numeric Operator (numeric_op) described in This component uses the Numeric Operator (numeric_op) described in
Section 4.2.1.1. Type 4 component values SHOULD be encoded as 1- or Section 4.2.1.1. Type 4 component values SHOULD be encoded as 1- or
2-octet quantities (numeric_op len=00 or len=01). 2-octet quantities (numeric_op len=00 or len=01).
In case of the presence of the port (destination-port, source-port) In case of the presence of the port (destination-port
component only TCP or UDP packets can match the entire Flow Section 4.2.2.5, source-port Section 4.2.2.6) component only TCP or
Specification. The port component, if present, never matches when UDP packets can match the entire Flow Specification. The port
the packet's IP protocol value is not 6 (TCP) or 17 (UDP), if the component, if present, never matches when the packet's IP protocol
packet is fragmented and this is not the first fragment, or if the value is not 6 (TCP) or 17 (UDP), if the packet is fragmented and
system is unable to locate the transport header. Different this is not the first fragment, or if the system is unable to locate
implementations may or may not be able to decode the transport header the transport header. Different implementations may or may not be
in the presence of IP options or Encapsulating Security Payload (ESP) able to decode the transport header in the presence of IP options or
NULL [RFC4303] encryption. Encapsulating Security Payload (ESP) NULL [RFC4303] encryption.
4.2.2.5. Type 5 - Destination Port 4.2.2.5. Type 5 - Destination Port
Encoding: <type (1 octet), [numeric_op, value]+> Encoding: <type (1 octet), [numeric_op, value]+>
Defines a list of {numeric_op, value} pairs used to match the Defines a list of {numeric_op, value} pairs used to match the
destination port of a TCP or UDP packet (see also [RFC0793] destination port of a TCP or UDP packet (see also [RFC0793]
Section 3.1 and [RFC0768] Section "Format"). Section 3.1 and [RFC0768] Section "Format").
This component uses the Numeric Operator (numeric_op) described in This component uses the Numeric Operator (numeric_op) described in
skipping to change at page 11, line 45 skipping to change at page 11, line 45
Encoding: <type (1 octet), [numeric_op, value]+> Encoding: <type (1 octet), [numeric_op, value]+>
Defines a list of {numeric_op, value} pairs used to match the type Defines a list of {numeric_op, value} pairs used to match the type
field of an ICMP packet (see also [RFC0792] Section "Message field of an ICMP packet (see also [RFC0792] Section "Message
Formats"). Formats").
This component uses the Numeric Operator (numeric_op) described in This component uses the Numeric Operator (numeric_op) described in
Section 4.2.1.1. Type 7 component values SHOULD be encoded as single Section 4.2.1.1. Type 7 component values SHOULD be encoded as single
octet (numeric_op len=00). octet (numeric_op len=00).
In case of the presence of the ICMP type (code) component only ICMP In case of the presence of the ICMP type component only ICMP packets
packets can match the entire Flow Specification. The ICMP type can match the entire Flow Specification. The ICMP type component, if
(code) component, if present, never matches when the packet's IP present, never matches when the packet's IP protocol value is not 1
protocol value is not 1 (ICMP), if the packet is fragmented and this (ICMP), if the packet is fragmented and this is not the first
is not the first fragment, or if the system is unable to locate the fragment, or if the system is unable to locate the transport header.
transport header. Different implementations may or may not be able Different implementations may or may not be able to decode the
to decode the transport header in the presence of IP options or transport header in the presence of IP options or Encapsulating
Encapsulating Security Payload (ESP) NULL [RFC4303] encryption. Security Payload (ESP) NULL [RFC4303] encryption.
4.2.2.8. Type 8 - ICMP code 4.2.2.8. Type 8 - ICMP code
Encoding: <type (1 octet), [numeric_op, value]+> Encoding: <type (1 octet), [numeric_op, value]+>
Defines a list of {numeric_op, value} pairs used to match the code Defines a list of {numeric_op, value} pairs used to match the code
field of an ICMP packet (see also [RFC0792] Section "Message field of an ICMP packet (see also [RFC0792] Section "Message
Formats"). Formats").
This component uses the Numeric Operator (numeric_op) described in This component uses the Numeric Operator (numeric_op) described in
Section 4.2.1.1. Type 8 component values SHOULD be encoded as single Section 4.2.1.1. Type 8 component values SHOULD be encoded as single
octet (numeric_op len=00). octet (numeric_op len=00).
The last paragraph of Section 4.2.2.7 also applies to this component. In case of the presence of the ICMP code component only ICMP packets
can match the entire Flow Specification. The ICMP code component, if
present, never matches when the packet's IP protocol value is not 1
(ICMP), if the packet is fragmented and this is not the first
fragment, or if the system is unable to locate the transport header.
Different implementations may or may not be able to decode the
transport header in the presence of IP options or Encapsulating
Security Payload (ESP) NULL [RFC4303] encryption.
4.2.2.9. Type 9 - TCP flags 4.2.2.9. Type 9 - TCP flags
Encoding: <type (1 octet), [bitmask_op, bitmask]+> Encoding: <type (1 octet), [bitmask_op, bitmask]+>
Defines a list of {bitmask_op, bitmask} pairs used to match TCP Defines a list of {bitmask_op, bitmask} pairs used to match TCP
Control Bits (see also [RFC0793] Section 3.1). Control Bits (see also [RFC0793] Section 3.1).
This component uses the Bitmask Operator (bitmask_op) described in This component uses the Bitmask Operator (bitmask_op) described in
Section 4.2.1.2. Type 9 component bitmasks MUST be encoded as 1- or Section 4.2.1.2. Type 9 component bitmasks MUST be encoded as 1- or
skipping to change at page 26, line 18 skipping to change at page 26, line 18
| Value | Name | Reference | | Value | Name | Reference |
+-------+------------------------------------------+----------------+ +-------+------------------------------------------+----------------+
| 133 | Dissemination of Flow Specification | [this | | 133 | Dissemination of Flow Specification | [this |
| | rules | document] | | | rules | document] |
| 134 | L3VPN Dissemination of Flow | [this | | 134 | L3VPN Dissemination of Flow | [this |
| | Specification rules | document] | | | Specification rules | document] |
+-------+------------------------------------------+----------------+ +-------+------------------------------------------+----------------+
Table 3: Registry: SAFI Values 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 YANG 1.1 Data Modeling Language" [RFC7950], the above text
implies that the following YANG descriptions 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:
<CODE BEGINS>
enum ipv4-flow-spec-safi {
value 133;
description
"Dissemination of Flow Specification rules SAFI.";
}
enum vpnv4-flow-spec-safi {
value 134;
description
"L3VPN Dissemination of Flow Specification rules SAFI";
}
<CODE ENDS>
11.2. Flow Component Definitions 11.2. Flow Component Definitions
A Flow Specification consists of a sequence of flow components, which A Flow Specification consists of a sequence of flow components, which
are identified by an 8-bit component type. IANA has created and are identified by an 8-bit component type. IANA has created and
maintains a registry entitled "Flow Spec Component Types". IANA is maintains a registry entitled "Flow Spec Component Types". IANA is
requested to update the reference for this registry to [this requested to update the reference for this registry to [this
document]. Furthermore the references to the values should be document]. Furthermore the references to the values should be
updated according to the table below (Note: This document obsoletes updated according to the table below (Note: This document obsoletes
both RFC7674 and RFC5575 and all references to those documents should both RFC7674 and RFC5575 and all references to those documents should
be deleted from the registry below). be deleted from the registry below).
skipping to change at page 34, line 5 skipping to change at page 34, line 30
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811, Austein, "BGP Prefix Origin Validation", RFC 6811,
DOI 10.17487/RFC6811, January 2013, DOI 10.17487/RFC6811, January 2013,
<https://www.rfc-editor.org/info/rfc6811>. <https://www.rfc-editor.org/info/rfc6811>.
[RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect [RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect
Extended Community", RFC 7674, DOI 10.17487/RFC7674, Extended Community", RFC 7674, DOI 10.17487/RFC7674,
October 2015, <https://www.rfc-editor.org/info/rfc7674>. October 2015, <https://www.rfc-editor.org/info/rfc7674>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
Specification", RFC 8205, DOI 10.17487/RFC8205, September Specification", RFC 8205, DOI 10.17487/RFC8205, September
2017, <https://www.rfc-editor.org/info/rfc8205>. 2017, <https://www.rfc-editor.org/info/rfc8205>.
[RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger,
"Common YANG Data Types for the Routing Area", RFC 8294,
DOI 10.17487/RFC8294, December 2017,
<https://www.rfc-editor.org/info/rfc8294>.
15.3. URIs 15.3. URIs
[1] https://github.com/stoffi92/rfc5575bis/tree/master/flowspec-cmp [1] https://github.com/stoffi92/rfc5575bis/tree/master/flowspec-cmp
Appendix A. Python code: flow_rule_cmp [2] https://www.iana.org/assignments/iana-routing-types
<CODE BEGINS> Appendix A. Example 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 <CODE BEGINS>
modification, is permitted pursuant to, and subject to the license """
terms contained in, the Simplified BSD License set forth in Section Copyright (c) 2020 IETF Trust and the persons identified as authors
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents of draft-ietf-idr-rfc5575bis. All rights reserved.
(http://trustee.ietf.org/license-info).
"""
import itertools Redistribution and use in source and binary forms, with or without
import ipaddress modification, is permitted pursuant to, and subject to the license
terms contained in, the Simplified BSD License set forth in Section
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
"""
def flow_rule_cmp(a, b): import itertools
for comp_a, comp_b in itertools.zip_longest(a.components, import collections
b.components): import ipaddress
# If a component type does not exist in one rule
# this rule has lower precedence
if not comp_a:
return B_HAS_PRECEDENCE
if not comp_b:
return A_HAS_PRECEDENCE
# higher precedence for lower component type
if comp_a.component_type < comp_b.component_type:
return A_HAS_PRECEDENCE
if comp_a.component_type > comp_b.component_type:
return B_HAS_PRECEDENCE
# component types are equal -> type specific comparison
if comp_a.component_type in (IP_DESTINATION, IP_SOURCE):
# assuming comp_a.value, comp_b.value of type
# ipaddress.IPv4Network
if comp_a.value.overlaps(comp_b.value):
# longest prefixlen has precedence
if comp_a.value.prefixlen > comp_b.value.prefixlen:
return A_HAS_PRECEDENCE
if comp_a.value.prefixlen < comp_b.value.prefixlen:
return B_HAS_PRECEDENCE EQUAL = 0
# components equal -> continue with next component A_HAS_PRECEDENCE = 1
elif comp_a.value > comp_b.value: B_HAS_PRECEDENCE = 2
return B_HAS_PRECEDENCE IP_DESTINATION = 1
elif comp_a.value < comp_b.value: IP_SOURCE = 2
return A_HAS_PRECEDENCE
else: FS_component = collections.namedtuple('FS_component',
# assuming comp_a.value, comp_b.value of type bytearray 'component_type op_value')
if len(comp_a.value) == len(comp_b.value):
if comp_a.value > comp_b.value: class FS_nlri(object):
return B_HAS_PRECEDENCE """
if comp_a.value < comp_b.value: FS_nlri class implementation that allows sorting.
return A_HAS_PRECEDENCE
# components equal -> continue with next component By calling .sort() on a array of FS_nlri objects these will be
else: sorted according to the flow_rule_cmp algorithm.
common = min(len(comp_a.value), len(comp_b.value))
if comp_a.value[:common] > comp_b.value[:common]: Example:
return B_HAS_PRECEDENCE nlri = [ FS_nlri(components=[
elif comp_a.value[:common] < comp_b.value[:common]: FS_component(component_type=IP_DESTINATION,
return A_HAS_PRECEDENCE op_value=ipaddress.ip_network('10.1.0.0/16') ),
# the first common bytes match FS_component(component_type=4,
elif len(comp_a.value) > len(comp_b.value): op_value=bytearray([0,1,2,3,4,5,6])),
return A_HAS_PRECEDENCE ]),
else: FS_nlri(components=[
return B_HAS_PRECEDENCE FS_component(component_type=5,
return EQUAL op_value=bytearray([0,1,2,3,4,5,6])),
<CODE ENDS> FS_component(component_type=6,
op_value=bytearray([0,1,2,3,4,5,6])),
]),
]
nlri.sort() # sorts the array accorinding to the algorithm
"""
def __init__(self, components = None):
"""
components: list of type FS_component
"""
self.components = components
def __lt__(self, other):
# use the below algorithm for sorting
result = flow_rule_cmp(self, other)
if result == B_HAS_PRECEDENCE:
return True
else:
return False
def flow_rule_cmp(a, b):
"""
Example of the flowspec comparison algorithm.
"""
for comp_a, comp_b in itertools.zip_longest(a.components,
b.components):
# If a component type does not exist in one rule
# this rule has lower precedence
if not comp_a:
return B_HAS_PRECEDENCE
if not comp_b:
return A_HAS_PRECEDENCE
# Higher precedence for lower component type
if comp_a.component_type < comp_b.component_type:
return A_HAS_PRECEDENCE
if comp_a.component_type > comp_b.component_type:
return B_HAS_PRECEDENCE
# component types are equal -> type specific comparison
if comp_a.component_type in (IP_DESTINATION, IP_SOURCE):
# assuming comp_a.op_value, comp_b.op_value of
# type ipaddress.IPv4Network
if comp_a.op_value.overlaps(comp_b.op_value):
# longest prefixlen has precedence
if comp_a.op_value.prefixlen > \
comp_b.op_value.prefixlen:
return A_HAS_PRECEDENCE
if comp_a.op_value.prefixlen < \
comp_b.op_value.prefixlen:
return B_HAS_PRECEDENCE
# components equal -> continue with next component
elif comp_a.op_value > comp_b.op_value:
return B_HAS_PRECEDENCE
elif comp_a.op_value < comp_b.op_value:
return A_HAS_PRECEDENCE
else:
# assuming comp_a.op_value, comp_b.op_value of type
# bytearray
if len(comp_a.op_value) == len(comp_b.op_value):
if comp_a.op_value > comp_b.op_value:
return B_HAS_PRECEDENCE
if comp_a.op_value < comp_b.op_value:
return A_HAS_PRECEDENCE
# components equal -> continue with next component
else:
common = min(len(comp_a.op_value), len(comp_b.op_value))
if comp_a.op_value[:common] > comp_b.op_value[:common]:
return B_HAS_PRECEDENCE
elif comp_a.op_value[:common] < \
comp_b.op_value[:common]:
return A_HAS_PRECEDENCE
# the first common bytes match
elif len(comp_a.op_value) > len(comp_b.op_value):
return A_HAS_PRECEDENCE
else:
return B_HAS_PRECEDENCE
return EQUAL
<CODE ENDS>
Appendix B. Comparison with RFC 5575 Appendix B. Comparison with RFC 5575
This document includes numerous editorial changes to [RFC5575]. It This document includes numerous editorial changes to [RFC5575]. It
also completely incorporates the redirect action clarification also completely incorporates the redirect action clarification
document [RFC7674]. It is recommended to read the entire document. document [RFC7674]. It is recommended to read the entire document.
The authors, however want to point out the following technical The authors, however want to point out the following technical
changes to [RFC5575]: changes to [RFC5575]:
Section 1 introduces the Flow Specification NLRI. In [RFC5575] Section 1 introduces the Flow Specification NLRI. In [RFC5575]
skipping to change at page 36, line 24 skipping to change at page 38, line 27
rate-packets). This action did not exist in [RFC5575]. rate-packets). This action did not exist in [RFC5575].
Section 7.4 contains the same redirect actions already defined in Section 7.4 contains the same redirect actions already defined in
[RFC5575] however, these actions have been renamed to "rt- [RFC5575] however, these actions have been renamed to "rt-
redirect" to make it clearer that the redirection is based on redirect" to make it clearer that the redirection is based on
route-target. This section also completely incorporates the route-target. This section also completely incorporates the
[RFC7674] clarifications of the Flowspec Redirect Extended [RFC7674] clarifications of the Flowspec Redirect Extended
Community. Community.
Section 7.7 contains general considerations on interfering traffic Section 7.7 contains general considerations on interfering traffic
actions. Section 7.3 also cross-references this section. actions. Section 7.3 also cross-references Section 7.7.
[RFC5575] did not mention this. [RFC5575] did not mention this.
Section 10 contains new error handling. Section 10 contains new error handling.
Authors' Addresses Authors' Addresses
Christoph Loibl Christoph Loibl
next layer Telekom GmbH next layer Telekom GmbH
Mariahilfer Guertel 37/7 Mariahilfer Guertel 37/7
Vienna 1150 Vienna 1150
 End of changes. 23 change blocks. 
98 lines changed or deleted 192 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/