draft-ietf-idr-rfc5575bis-07.txt   draft-ietf-idr-rfc5575bis-08.txt 
IDR Working Group S. Hares IDR Working Group S. Hares
Internet-Draft Huawei Internet-Draft Huawei
Obsoletes: 5575,7674 (if approved) C. Loibl Obsoletes: 5575,7674 (if approved) C. Loibl
Intended status: Standards Track Next Layer Communications Intended status: Standards Track Next Layer Communications
Expires: October 22, 2018 R. Raszuk Expires: December 23, 2018 R. Raszuk
Bloomberg LP Bloomberg LP
D. McPherson D. McPherson
Verisign Verisign
M. Bacher M. Bacher
T-Mobile Austria T-Mobile Austria
April 20, 2018 June 21, 2018
Dissemination of Flow Specification Rules Dissemination of Flow Specification Rules
draft-ietf-idr-rfc5575bis-07 draft-ietf-idr-rfc5575bis-08
Abstract Abstract
This document updates [RFC5575] which defines a Border Gateway This document defines a Border Gateway Protocol Network Layer
Protocol Network Layer Reachability Information (BGP NLRI) encoding Reachability Information (BGP NLRI) encoding format that can be used
format that can be used to distribute traffic Flow Specifications. to distribute traffic Flow Specifications. This allows the routing
This allows the routing system to propagate information regarding system to propagate information regarding more specific components of
more specific components of the traffic aggregate defined by an IP the traffic aggregate defined by an IP destination prefix.
destination prefix.
It specifies IPv4 traffic Flow Specifications via a BGP NLRI which It specifies IPv4 traffic Flow Specifications via a BGP NLRI which
carries traffic Flow Specification filter, and an Extended community carries traffic Flow Specification filter, and an Extended community
value which encodes actions a routing system can take if the packet value which encodes actions a routing system can take if the packet
matches the traffic flow filters. The flow filters and the actions matches the traffic flow filters. The flow filters and the actions
are processed in a fixed order. Other drafts specify IPv6, MPLS are processed in a fixed order. Other drafts specify IPv6, MPLS
addresses, L2VPN addresses, and NV03 encapsulation of IP addresses. addresses, L2VPN addresses, and NV03 encapsulation of IP addresses.
This document updates [RFC5575] to correct unclear specifications in This document obsoletes RFC5575 and RFC7674 to correct unclear
the flow filters and to provide rules for actions which interfere specifications in the flow filters and to provide rules for actions
(e.g. redirection of traffic and flow filtering). which interfere (e.g. redirection of traffic and flow filtering).
Applications which use the bgp Flow Specification are: 1) application Applications which use the bgp Flow Specification are: 1) application
which automate inter-domain coordination of traffic filtering, such which automate inter-domain coordination of traffic filtering, such
as what is required in order to mitigate (distributed) denial-of- as what is required in order to mitigate (distributed) denial-of-
service attacks; 2) applications which control traffic filtering in service attacks; 2) applications which control traffic filtering in
the context of a BGP/MPLS VPN service, and 3) applications with the context of a BGP/MPLS VPN service, and 3) applications with
centralized control of traffic in a SDN or NFV context. Some centralized control of traffic in a SDN or NFV context. Some
deployments of these three applications can be handled by the strict deployments of these three applications can be handled by the strict
ordering of the BGP NLRI traffic flow filters, and the strict actions ordering of the BGP NLRI traffic flow filters, and the strict actions
encoded in the extended community Flow Specification actions. encoded in the extended community Flow Specification actions.
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 22, 2018. This Internet-Draft will expire on December 23, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 6, line 8 skipping to change at page 6, line 8
Loc-RIB - Local RIB. Loc-RIB - Local RIB.
AS - Autonomous System. AS - Autonomous System.
VRF - Virtual Routing and Forwarding instance. VRF - Virtual Routing and Forwarding instance.
PE - Provider Edge router PE - Provider Edge router
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119] "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Flow Specifications 3. Flow Specifications
A Flow Specification is an n-tuple consisting of several matching A Flow Specification is an n-tuple consisting of several matching
criteria that can be applied to IP traffic. A given IP packet is criteria that can be applied to IP traffic. A given IP packet is
said to match the defined flow if it matches all the specified said to match the defined flow if it matches all the specified
criteria. criteria.
A given flow may be associated with a set of attributes, depending on A given flow may be associated with a set of attributes, depending on
the particular application; such attributes may or may not include the particular application; such attributes may or may not include
skipping to change at page 8, line 12 skipping to change at page 8, line 12
specification when it matches the intersection (AND) of all the specification when it matches the intersection (AND) of all the
components present in the specification. components present in the specification.
The encoding of each of the NLRI components begins with a type field The encoding of each of the NLRI components begins with a type field
(1 octet) followed by a variable length parameter. Section 4.2.1 to (1 octet) followed by a variable length parameter. Section 4.2.1 to
Section 4.2.12 define component types and parameter encodings for the Section 4.2.12 define component types and parameter encodings for the
IPv4 IP layer and transport layer headers. IPv6 NLRI component types IPv4 IP layer and transport layer headers. IPv6 NLRI component types
are described in [I-D.ietf-idr-flow-spec-v6]. are described in [I-D.ietf-idr-flow-spec-v6].
Flow Specification components must follow strict type ordering by Flow Specification components must follow strict type ordering by
increasing numerical order. A given component type may or may not be increasing numerical order. A given component type may (exactly
present in the specification, but if present, it MUST precede any once) or may not be present in the specification. If present, it
component of higher numeric type value. MUST precede any component of higher numeric type value.
All combinations of component types within a single NLRI are allowed, All combinations of component types within a single NLRI are allowed,
even if the combination makes no sense from a semantical perspective. even if the combination makes no sense from a semantical perspective.
If a given component type within a prefix in unknown, the prefix in If a given component type within a prefix in unknown, the prefix in
question cannot be used for traffic filtering purposes by the question cannot be used for traffic filtering purposes by the
receiver. Since a Flow Specification has the semantics of a logical receiver. Since a Flow Specification has the semantics of a logical
AND of all components, if a component is FALSE, by definition it AND of all components, if a component is FALSE, by definition it
cannot be applied. However, for the purposes of BGP route cannot be applied. However, for the purposes of BGP route
propagation, this prefix should still be transmitted since BGP route propagation, this prefix should still be transmitted since BGP route
distribution is independent on NLRI semantics. distribution is independent on NLRI semantics.
skipping to change at page 15, line 26 skipping to change at page 15, line 26
precedence. For strings of different lengths, the common prefix is precedence. For strings of different lengths, the common prefix is
compared. If the common prefix is not equal the string with the compared. If the common prefix is not equal the string with the
lowest prefix has higher precedence. If the common prefix is equal, lowest prefix has higher precedence. If the common prefix is equal,
the longest string is considered to have higher precedence than the the longest string is considered to have higher precedence than the
shorter one. shorter one.
The code below shows a Python3 implementation of the comparison The code below shows a Python3 implementation of the comparison
algorithm. The full code was tested with Python 3.6.3 and can be algorithm. The full code was tested with Python 3.6.3 and can be
obtained at https://github.com/stoffi92/flowspec-cmp [1]. obtained at https://github.com/stoffi92/flowspec-cmp [1].
<CODE BEGINS>
import itertools import itertools
import ipaddress import ipaddress
def flow_rule_cmp(a, b): def flow_rule_cmp(a, b):
for comp_a, comp_b in itertools.zip_longest(a.components, for comp_a, comp_b in itertools.zip_longest(a.components,
b.components): b.components):
# If a component type does not exist in one rule # If a component type does not exist in one rule
# this rule has lower precedence # this rule has lower precedence
if not comp_a: if not comp_a:
return B_HAS_PRECEDENCE return B_HAS_PRECEDENCE
skipping to change at page 15, line 51 skipping to change at page 16, line 4
if comp_a.component_type > comp_b.component_type: if comp_a.component_type > comp_b.component_type:
return B_HAS_PRECEDENCE return B_HAS_PRECEDENCE
# component types are equal -> type specific comparison # component types are equal -> type specific comparison
if comp_a.component_type in (IP_DESTINATION, IP_SOURCE): if comp_a.component_type in (IP_DESTINATION, IP_SOURCE):
# assuming comp_a.value, comp_b.value of type ipaddress # assuming comp_a.value, comp_b.value of type ipaddress
if comp_a.value.overlaps(comp_b.value): if comp_a.value.overlaps(comp_b.value):
# longest prefixlen has precedence # longest prefixlen has precedence
if comp_a.value.prefixlen > comp_b.value.prefixlen: if comp_a.value.prefixlen > comp_b.value.prefixlen:
return A_HAS_PRECEDENCE return A_HAS_PRECEDENCE
if comp_a.value.prefixlen < comp_b.value.prefixlen: if comp_a.value.prefixlen < comp_b.value.prefixlen:
return B_HAS_PRECEDENCE
return B_HAS_PRECEDENCE
# components equal -> continue with next component # components equal -> continue with next component
elif comp_a.value > comp_b.value: elif comp_a.value > comp_b.value:
return B_HAS_PRECEDENCE return B_HAS_PRECEDENCE
elif comp_a.value < comp_b.value: elif comp_a.value < comp_b.value:
return A_HAS_PRECEDENCE return A_HAS_PRECEDENCE
else: else:
# assuming comp_a.value, comp_b.value of type bytearray # assuming comp_a.value, comp_b.value of type bytearray
if len(comp_a.value) == len(comp_b.value): if len(comp_a.value) == len(comp_b.value):
if comp_a.value > comp_b.value: if comp_a.value > comp_b.value:
return B_HAS_PRECEDENCE return B_HAS_PRECEDENCE
skipping to change at page 16, line 30 skipping to change at page 16, line 31
if comp_a.value[:common] > comp_b.value[:common]: if comp_a.value[:common] > comp_b.value[:common]:
return B_HAS_PRECEDENCE return B_HAS_PRECEDENCE
elif comp_a.value[:common] < comp_b.value[:common]: elif comp_a.value[:common] < comp_b.value[:common]:
return A_HAS_PRECEDENCE return A_HAS_PRECEDENCE
# the first common bytes match # the first common bytes match
elif len(comp_a.value) > len(comp_b.value): elif len(comp_a.value) > len(comp_b.value):
return A_HAS_PRECEDENCE return A_HAS_PRECEDENCE
else: else:
return B_HAS_PRECEDENCE return B_HAS_PRECEDENCE
return EQUAL return EQUAL
<CODE ENDS>
6. Validation Procedure 6. Validation Procedure
Flow Specifications received from a BGP peer that are accepted in the Flow Specifications received from a BGP peer that are accepted in the
respective Adj-RIB-In are used as input to the route selection respective Adj-RIB-In are used as input to the route selection
process. Although the forwarding attributes of two routes for the process. Although the forwarding attributes of two routes for the
same Flow Specification prefix may be the same, BGP is still required same Flow Specification prefix may be the same, BGP is still required
to perform its path selection algorithm in order to select the to perform its path selection algorithm in order to select the
correct set of attributes to advertise. correct set of attributes to advertise.
skipping to change at page 25, line 43 skipping to change at page 25, line 43
| 8 | ICMP code | [this document] | | 8 | ICMP code | [this document] |
| 9 | TCP flags | [this document] | | 9 | TCP flags | [this document] |
| 10 | Packet length | [this document] | | 10 | Packet length | [this document] |
| 11 | DSCP | [this document] | | 11 | DSCP | [this document] |
| 12 | Fragment | [this document] | | 12 | Fragment | [this document] |
+-------+--------------------+-----------------+ +-------+--------------------+-----------------+
Table 4: Registry: Flow Spec Component Types Table 4: Registry: Flow Spec Component Types
In order to manage the limited number space and accommodate several In order to manage the limited number space and accommodate several
usages, the following policies defined by [RFC5226] used: usages, the following policies defined by [RFC8126] used:
+--------------+-------------------------------+ +--------------+-------------------------------+
| Range | Policy | | Range | Policy |
+--------------+-------------------------------+ +--------------+-------------------------------+
| 0 | Invalid value | | 0 | Invalid value |
| [1 .. 12] | Defined by this specification | | [1 .. 12] | Defined by this specification |
| [13 .. 127] | Specification required | | [13 .. 127] | Specification required |
| [128 .. 255] | First Come First Served | | [128 .. 255] | First Come First Served |
+--------------+-------------------------------+ +--------------+-------------------------------+
skipping to change at page 27, line 28 skipping to change at page 27, line 28
| 0x82 | Generic Transitive Experimental Use Extended | [this | | 0x82 | Generic Transitive Experimental Use Extended | [this |
| | Community Part 3 (Sub-Types are defined in | document] | | | Community Part 3 (Sub-Types are defined in | document] |
| | the "Generic Transitive Experimental Use | [See | | | the "Generic Transitive Experimental Use | [See |
| | Extended Community Part 3 Sub-Types" | Note-1] | | | Extended Community Part 3 Sub-Types" | Note-1] |
| | Registry) | | | | Registry) | |
+-------+-----------------------------------------------+-----------+ +-------+-----------------------------------------------+-----------+
Table 6: Registry: Generic Transitive Experimental Use Extended Table 6: Registry: Generic Transitive Experimental Use Extended
Community Types Community Types
Note-1: This document replaces [RFC7674]. Note-1: This document obsoletes RFC7674.
For the sub-type part of the extended community actions IANA For the sub-type part of the extended community actions IANA
maintains and updated the following registries: maintains and updated the following registries:
+----------+-----------------------------------------+--------------+ +----------+-----------------------------------------+--------------+
| Sub-Type | Name | Reference | | Sub-Type | Name | Reference |
| Value | | | | Value | | |
+----------+-----------------------------------------+--------------+ +----------+-----------------------------------------+--------------+
| 0x06 | Flow spec traffic-rate-bytes | [this | | 0x06 | Flow spec traffic-rate-bytes | [this |
| | | document] | | | | document] |
skipping to change at page 28, line 5 skipping to change at page 28, line 5
| | "Traffic Action Fields" registry) | [See Note-2] | | | "Traffic Action Fields" registry) | [See Note-2] |
| 0x08 | Flow spec rt-redirect AS-2byte format | [this | | 0x08 | Flow spec rt-redirect AS-2byte format | [this |
| | | document] | | | | document] |
| 0x09 | Flow spec traffic-remarking | [this | | 0x09 | Flow spec traffic-remarking | [this |
| | | document] | | | | document] |
+----------+-----------------------------------------+--------------+ +----------+-----------------------------------------+--------------+
Table 7: Registry: Generic Transitive Experimental Use Extended Table 7: Registry: Generic Transitive Experimental Use Extended
Community Sub-Types Community Sub-Types
Note-2: This document replaces both [RFC7674] and [RFC5575]. Note-2: This document obsoletes both RFC7674 and RFC5575.
+-------------+---------------------------+-------------------------+ +-------------+---------------------------+-------------------------+
| Sub-Type | Name | Reference | | Sub-Type | Name | Reference |
| Value | | | | Value | | |
+-------------+---------------------------+-------------------------+ +-------------+---------------------------+-------------------------+
| 0x08 | Flow spec rt-redirect | [this document] [See | | 0x08 | Flow spec rt-redirect | [this document] [See |
| | IPv4 format | Note-3] | | | IPv4 format | Note-3] |
+-------------+---------------------------+-------------------------+ +-------------+---------------------------+-------------------------+
Table 8: Registry: Generic Transitive Experimental Use Extended Table 8: Registry: Generic Transitive Experimental Use Extended
skipping to change at page 28, line 29 skipping to change at page 28, line 29
| Sub-Type | Name | Reference | | Sub-Type | Name | Reference |
| Value | | | | Value | | |
+-------------+----------------------------+------------------------+ +-------------+----------------------------+------------------------+
| 0x08 | Flow spec rt-redirect AS- | [this document] [See | | 0x08 | Flow spec rt-redirect AS- | [this document] [See |
| | 4byte format | Note-3] | | | 4byte format | Note-3] |
+-------------+----------------------------+------------------------+ +-------------+----------------------------+------------------------+
Table 9: Registry: Generic Transitive Experimental Use Extended Table 9: Registry: Generic Transitive Experimental Use Extended
Community Part 3 Sub-Types Community Part 3 Sub-Types
Note-3: This document replaces [RFC7674], and becomes the only Note-3: This document obsoletes RFC7674, and becomes the only
reference for this table. reference for this table.
The "traffic-action" extended community (Section 7.3) defined in this The "traffic-action" extended community (Section 7.3) defined in this
document has 46 unused bits, which can be used to convey additional document has 46 unused bits, which can be used to convey additional
meaning. IANA created and maintains a new registry entitled: meaning. IANA created and maintains a new registry entitled:
"Traffic Action Fields". These values should be assigned via IETF "Traffic Action Fields". These values should be assigned via IETF
Review rules only. The following traffic-action fields have been Review rules only. The following traffic-action fields have been
allocated: allocated:
+-----+-----------------+-----------------+ +-----+-----------------+-----------------+
skipping to change at page 29, line 29 skipping to change at page 29, line 29
of addresses but not ICMP packets. It is also possible to permit of addresses but not ICMP packets. It is also possible to permit
packets smaller than 900 or greater than 1000 bytes to pass between a packets smaller than 900 or greater than 1000 bytes to pass between a
pair of addresses, but not packets whose length is in the range 900- pair of addresses, but not packets whose length is in the range 900-
1000. Such behavior may be confusing and these capabilities should 1000. Such behavior may be confusing and these capabilities should
be used with care whether manually configured or coordinated through be used with care whether manually configured or coordinated through
the protocol extensions described in this document. the protocol extensions described in this document.
13. Original authors 13. Original authors
Barry Greene, MuPedro Marques, Jared Mauch, Danny McPherson, and Barry Greene, MuPedro Marques, Jared Mauch, Danny McPherson, and
Nischal Sheth were authors on [RFC5575], and therefore are Nischal Sheth were authors on RFC5575, and therefore are contributing
contributing authors on this document. authors on this document.
14. Acknowledgements 14. Acknowledgements
The authors would like to thank Yakov Rekhter, Dennis Ferguson, Chris The authors would like to thank Yakov Rekhter, Dennis Ferguson, Chris
Morrow, Charlie Kaufman, and David Smith for their comments for the Morrow, Charlie Kaufman, and David Smith for their comments for the
comments on the original [RFC5575]. Chaitanya Kodeboyina helped comments on the original RFC5575. Chaitanya Kodeboyina helped design
design the flow validation procedure; and Steven Lin and Jim Washburn the flow validation procedure; and Steven Lin and Jim Washburn ironed
ironed out all the details necessary to produce a working out all the details necessary to produce a working implementation in
implementation in the original [RFC5575]. the original RFC5575.
Additional the authors would like to thank Alexander Mayrhofer, Additional the authors would like to thank Alexander Mayrhofer,
Nicolas Fevrier and Job Snijders for their comments and review. Nicolas Fevrier and Job Snijders for their comments and review.
15. References 15. References
15.1. Normative References 15.1. Normative References
[IEEE.754.1985]
IEEE, "Standard for Binary Floating-Point Arithmetic",
IEEE 754-1985, August 1985.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
skipping to change at page 30, line 44 skipping to change at page 30, line 48
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
<https://www.rfc-editor.org/info/rfc4761>. <https://www.rfc-editor.org/info/rfc4761>.
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP) LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
<https://www.rfc-editor.org/info/rfc4762>. <https://www.rfc-editor.org/info/rfc4762>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
[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,
<https://www.rfc-editor.org/info/rfc5575>.
[RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS
Specific BGP Extended Community", RFC 5668, Specific BGP Extended Community", RFC 5668,
DOI 10.17487/RFC5668, October 2009, DOI 10.17487/RFC5668, October 2009,
<https://www.rfc-editor.org/info/rfc5668>. <https://www.rfc-editor.org/info/rfc5668>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
skipping to change at page 31, line 29 skipping to change at page 31, line 24
[RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP
Extended Communities", RFC 7153, DOI 10.17487/RFC7153, Extended Communities", RFC 7153, DOI 10.17487/RFC7153,
March 2014, <https://www.rfc-editor.org/info/rfc7153>. March 2014, <https://www.rfc-editor.org/info/rfc7153>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages", Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015, RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/info/rfc7606>. <https://www.rfc-editor.org/info/rfc7606>.
[RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Extended Community", RFC 7674, DOI 10.17487/RFC7674, Writing an IANA Considerations Section in RFCs", BCP 26,
October 2015, <https://www.rfc-editor.org/info/rfc7674>. RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
15.2. Informative References 15.2. Informative References
[I-D.ietf-idr-flow-spec-v6] [I-D.ietf-idr-flow-spec-v6]
McPherson, D., Raszuk, R., Pithawala, B., McPherson, D., Raszuk, R., Pithawala, B.,
akarch@cisco.com, a., and S. Hares, "Dissemination of Flow akarch@cisco.com, a., and S. Hares, "Dissemination of Flow
Specification Rules for IPv6", draft-ietf-idr-flow-spec- Specification Rules for IPv6", draft-ietf-idr-flow-spec-
v6-09 (work in progress), November 2017. v6-09 (work in progress), November 2017.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
15.3. URIs 15.3. URIs
[1] https://github.com/stoffi92/flowspec-cmp [1] https://github.com/stoffi92/flowspec-cmp
Appendix A. Comparison with RFC 5575 Appendix A. Comparison with RFC 5575
This document includes numerous editorial changes to [RFC5575]. It This document includes numerous editorial changes to RFC5575. It is
is recommended to read the entire document. The authors, however recommended to read the entire document. The authors, however want
want to point out the following technical changes to [RFC5575]: to point out the following technical changes to RFC5575:
Section 4.2.3 defines a numeric operator and comparison bit Section 4.2.3 defines a numeric operator and comparison bit
combinations. In [RFC5575] the meaning of those bit combination combinations. In RFC5575 the meaning of those bit combination was
was not explicitly defined and left open to the reader. not explicitly defined and left open to the reader.
Section 4.2.3 - Section 4.2.8, Section 4.2.10, Section 4.2.11 make Section 4.2.3 - Section 4.2.8, Section 4.2.10, Section 4.2.11 make
use of the above numeric operator. The allowed length of the use of the above numeric operator. The allowed length of the
comparison value was not consistently defined in [RFC5575]. comparison value was not consistently defined in RFC5575.
Section 7 defines all traffic action extended communities as Section 7 defines all traffic action extended communities as
transitive extended communities. [RFC5575] defined the traffic- transitive extended communities. RFC5575 defined the traffic-rate
rate action to be non-transitive and did not define the action to be non-transitive and did not define the transitivity of
transitivity of the other action communities at all. the other action communities at all.
Section 7.2 introduces a new traffic filtering action (traffic- Section 7.2 introduces a new traffic filtering action (traffic-
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"
redirect" to make it clearer that the redirection is based on to make it clearer that the redirection is based on route-target.
route-target.
Section 7.6 introduces rules how updates of Flow Specifications Section 7.6 introduces rules how updates of Flow Specifications
shall be handled in case they contain interfering actions. shall be handled in case they contain interfering actions.
Section 7.3 also cross-references this section. [RFC5575] did not Section 7.3 also cross-references this section. RFC5575 did not
define this. define this.
Authors' Addresses Authors' Addresses
Susan Hares Susan Hares
Huawei Huawei
7453 Hickory Hill 7453 Hickory Hill
Saline, MI 48176 Saline, MI 48176
USA USA
 End of changes. 28 change blocks. 
56 lines changed or deleted 57 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/