draft-ietf-idr-rfc5575bis-00.txt   draft-ietf-idr-rfc5575bis-01.txt 
IDR Working Group S. Hares IDR Working Group S. Hares
Internet-Draft Huawei Internet-Draft Huawei
Obsoletes: 5575 (if approved) R. Raszuk Obsoletes: 5575 (if approved) R. Raszuk
Updates: 7674 (if approved) Bloomberg LP Updates: 7674 (if approved) Bloomberg LP
Intended status: Standards Track D. McPherson Intended status: Standards Track D. McPherson
Expires: August 26, 2017 Verisign Expires: September 27, 2017 Verisign
C. Loibl C. Loibl
Next Layer Communications Next Layer Communications
M. Bacher M. Bacher
T-Mobile Austria T-Mobile Austria
February 22, 2017 March 26, 2017
Dissemination of Flow Specification Rules Dissemination of Flow Specification Rules
draft-ietf-idr-rfc5575bis-00 draft-ietf-idr-rfc5575bis-01
Abstract Abstract
This document updates RFC5575 which defines a Border Gateway Protocol This document updates RFC5575 which defines a Border Gateway Protocol
Network Layer Reachability Information (BGP NLRI) encoding format Network Layer Reachability Information (BGP NLRI) encoding format
that can be used to distribute traffic flow specifications. This that can be used to distribute traffic flow specifications. This
allows the routing system to propagate information regarding more allows the routing system to propagate information regarding more
specific components of the traffic aggregate defined by an IP specific components of the traffic aggregate defined by an IP
destination prefix. This draft specifies IPv4 traffic flow destination prefix. This draft specifies IPv4 traffic flow
specifications via a BGP NLRI which carries traffic flow specifications via a BGP NLRI which carries traffic flow
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 August 26, 2017. This Internet-Draft will expire on September 27, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 13 skipping to change at page 3, line 13
4.2.8. Type 8 - ICMP code . . . . . . . . . . . . . . . . . 11 4.2.8. Type 8 - ICMP code . . . . . . . . . . . . . . . . . 11
4.2.9. Type 9 - TCP flags . . . . . . . . . . . . . . . . . 11 4.2.9. Type 9 - TCP flags . . . . . . . . . . . . . . . . . 11
4.2.10. Type 10 - Packet length . . . . . . . . . . . . . . . 12 4.2.10. Type 10 - Packet length . . . . . . . . . . . . . . . 12
4.2.11. Type 11 - DSCP (Diffserv Code Point) . . . . . . . . 12 4.2.11. Type 11 - DSCP (Diffserv Code Point) . . . . . . . . 12
4.2.12. Type 12 - Fragment . . . . . . . . . . . . . . . . . 12 4.2.12. Type 12 - Fragment . . . . . . . . . . . . . . . . . 12
4.3. Examples of Encodings . . . . . . . . . . . . . . . . . . 12 4.3. Examples of Encodings . . . . . . . . . . . . . . . . . . 12
5. Traffic Filtering . . . . . . . . . . . . . . . . . . . . . . 13 5. Traffic Filtering . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Ordering of Traffic Filtering Rules . . . . . . . . . . . 14 5.1. Ordering of Traffic Filtering Rules . . . . . . . . . . . 14
6. Validation Procedure . . . . . . . . . . . . . . . . . . . . 16 6. Validation Procedure . . . . . . . . . . . . . . . . . . . . 16
7. Traffic Filtering Actions . . . . . . . . . . . . . . . . . . 17 7. Traffic Filtering Actions . . . . . . . . . . . . . . . . . . 17
7.1. Traffic Rate in Bytes (sub-type 0x06) . . . . . . . . . . 18 7.1. Traffic Rate in Bytes (traffic-rate-bytes) sub-type 0x06 18
7.2. Traffic Rate in Packets (sub-type TBD) . . . . . . . . . 19 7.2. Traffic Rate in Packets (traffic-rate-packets) sub-type
7.3. Traffic-action (sub-type 0x07) . . . . . . . . . . . . . 19 TBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.4. IP Redirect (sub-type 0x08) . . . . . . . . . . . . . . . 19 7.3. Traffic-action (traffic-action) sub-type 0x07 . . . . . . 19
7.5. Traffic Marking (sub-type 0x09) . . . . . . . . . . . . . 20 7.4. RT Redirect (rt-redirect) sub-type 0x08 . . . . . . . . . 20
7.5. Traffic Marking (traffic-marking) sub-type 0x09 . . . . . 20
7.6. Rules on Traffic Action Interference . . . . . . . . . . 20 7.6. Rules on Traffic Action Interference . . . . . . . . . . 20
7.6.1. Examples . . . . . . . . . . . . . . . . . . . . . . 21 7.6.1. Examples . . . . . . . . . . . . . . . . . . . . . . 21
8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks . 21 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks . 21
8.1. Validation Procedures for BGP/MPLS VPNs . . . . . . . . . 22 8.1. Validation Procedures for BGP/MPLS VPNs . . . . . . . . . 22
8.2. Traffic Actions Rules . . . . . . . . . . . . . . . . . . 22 8.2. Traffic Actions Rules . . . . . . . . . . . . . . . . . . 22
9. Limitations of Previous Traffic Filtering Efforts . . . . . . 22 9. Limitations of Previous Traffic Filtering Efforts . . . . . . 22
9.1. Limitations in Previous DDoS Traffic Filtering Efforts . 22 9.1. Limitations in Previous DDoS Traffic Filtering Efforts . 22
9.2. Limitations in Previous BGP/MPLS Traffic Filtering . . . 23 9.2. Limitations in Previous BGP/MPLS Traffic Filtering . . . 23
10. Traffic Monitoring . . . . . . . . . . . . . . . . . . . . . 23 10. Traffic Monitoring . . . . . . . . . . . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
11.1. AFI/SAFI Definitions . . . . . . . . . . . . . . . . . . 24 11.1. AFI/SAFI Definitions . . . . . . . . . . . . . . . . . . 24
11.2. Flow Component definitions . . . . . . . . . . . . . . . 24 11.2. Flow Component definitions . . . . . . . . . . . . . . . 24
11.3. Extended Community Flow Specification Actions . . . . . 25 11.3. Extended Community Flow Specification Actions . . . . . 26
12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26
13. Original authors . . . . . . . . . . . . . . . . . . . . . . 27 13. Original authors . . . . . . . . . . . . . . . . . . . . . . 27
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
15.1. Normative References . . . . . . . . . . . . . . . . . . 27 15.1. Normative References . . . . . . . . . . . . . . . . . . 27
15.2. Informative References . . . . . . . . . . . . . . . . . 29 15.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
skipping to change at page 8, line 16 skipping to change at page 8, line 16
(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 or may not be
present in the specification, but if present, it MUST precede any present in the specification, but if present, it MUST precede any
component of higher numeric type value. component of higher numeric type value.
All combinations of component types within a single NLRI are allowed,
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.
The <type, value> encoding is chosen in order to allow for future The <type, value> encoding is chosen in order to allow for future
extensibility. extensibility.
skipping to change at page 18, line 5 skipping to change at page 18, line 5
can be accomplished by mapping a user-defined community value to can be accomplished by mapping a user-defined community value to
platform-/network-specific behavior via user configuration. platform-/network-specific behavior via user configuration.
The default action for a traffic filtering flow specification is to The default action for a traffic filtering flow specification is to
accept IP traffic that matches that particular rule. accept IP traffic that matches that particular rule.
This document defines the following extended communities values shown This document defines the following extended communities values shown
in Table 2 in the form 0x8xnn where nn indicates the sub-type. in Table 2 in the form 0x8xnn where nn indicates the sub-type.
Encodings for these extended communities are described below. Encodings for these extended communities are described below.
+--------+----------------------+-----------------------------------+ +-----------+----------------------+--------------------------------+
| type | extended community | encoding | | community | action | encoding |
+--------+----------------------+-----------------------------------+ +-----------+----------------------+--------------------------------+
| 0x8006 | traffic-rate-bytes | 2-byte ASN, 4-byte float | | 0x8006 | traffic-rate-bytes | 2-byte ASN, 4-byte float |
| 0x8007 | traffic-action | bitmask | | TBD | traffic-rate-packets | 2-byte ASN, 4-byte float |
| 0x8008 | redirect AS-2byte | 2-octet AS, 4-octet value | | 0x8007 | traffic-action | bitmask |
| 0x8108 | redirect IPv4 | 4-octet IPv4 addres, 2-octet | | 0x8008 | rt-redirect AS-2byte | 2-octet AS, 4-octet value |
| | | value | | 0x8108 | rt-redirect IPv4 | 4-octet IPv4 addres, 2-octet |
| 0x8208 | redirect AS-4byte | 4-octet AS, 2-octet value | | | | value |
| 0x8009 | traffic-marking | DSCP value | | 0x8208 | rt-redirect AS-4byte | 4-octet AS, 2-octet value |
| TBD | traffic-rate-packets | 2-byte ASN, 4-byte float | | 0x8009 | traffic-marking | DSCP value |
+--------+----------------------+-----------------------------------+ +-----------+----------------------+--------------------------------+
Table 2: Traffic Action Extended Communities Table 2: Traffic Action Extended Communities
Some traffic action communities may interfere with each other. Some traffic action communities may interfere with each other.
Section 7.6 of this specification provides rules for handling Section 7.6 of this specification provides rules for handling
interference between specific types of traffic actions, and error interference between specific types of traffic actions, and error
handling based on [RFC7606]. Any additional definition of a traffic handling based on [RFC7606]. Any additional definition of a traffic
actions specified by additional standards documents or vendor actions specified by additional standards documents or vendor
documents MUST specify if the traffic action interacts with an documents MUST specify if the traffic action interacts with an
existing traffic actions, and provide error handling per [RFC7606]. existing traffic actions, and provide error handling per [RFC7606].
The traffic actions are processed in ascending order of the sub-type Multiple traffic actions may be present for a single NLRI. The
found in the BGP Extended Communities. All traffic actions are traffic actions are processed in ascending order of the sub-type
specified in transitive BGP Extended Communities. found in the BGP Extended Communities. If not all of them can be
processed the filter SHALL NOT be applied at all (for example: if for
a given flow there are the action communities rate-limit-bytes and
traffic-marking attached, and the plattform does not support one of
them also the other shall not be applied for that flow).
7.1. Traffic Rate in Bytes (sub-type 0x06) All traffic actions are specified as transitive BGP Extended
Communities.
7.1. Traffic Rate in Bytes (traffic-rate-bytes) sub-type 0x06
The traffic-rate-bytes extended community uses the following extended The traffic-rate-bytes extended community uses the following extended
community encoding: community encoding:
The first two octets carry the 2-octet id, which can be assigned from The first two octets carry the 2-octet id, which can be assigned from
a 2-byte AS number. When a 4-byte AS number is locally present, the a 2-byte AS number. When a 4-byte AS number is locally present, the
2 least significant bytes of such an AS number can be used. This 2 least significant bytes of such an AS number can be used. This
value is purely informational and should not be interpreted by the value is purely informational and should not be interpreted by the
implementation. implementation.
skipping to change at page 18, line 45 skipping to change at page 19, line 4
community encoding: community encoding:
The first two octets carry the 2-octet id, which can be assigned from The first two octets carry the 2-octet id, which can be assigned from
a 2-byte AS number. When a 4-byte AS number is locally present, the a 2-byte AS number. When a 4-byte AS number is locally present, the
2 least significant bytes of such an AS number can be used. This 2 least significant bytes of such an AS number can be used. This
value is purely informational and should not be interpreted by the value is purely informational and should not be interpreted by the
implementation. implementation.
The remaining 4 octets carry the maximum rate information in IEEE The remaining 4 octets carry the maximum rate information in IEEE
floating point [IEEE.754.1985] format, units being bytes per second. floating point [IEEE.754.1985] format, units being bytes per second.
A traffic-rate of 0 should result on all traffic for the particular A traffic-rate of 0 should result on all traffic for the particular
flow to be discarded. flow to be discarded.
Interferes with: Traffic Rate in packets (traffic-rate-packets). Interferes with: No other BGP Flow Specification traffic action in
Process traffic rate in bytes (sub-type 0x06) action before traffic this document.
rate in packets action (sub-type TBD).
7.2. Traffic Rate in Packets (sub-type TBD) 7.2. Traffic Rate in Packets (traffic-rate-packets) sub-type TBD
The traffic-rate-packets extended community uses the same encoding as The traffic-rate-packets extended community uses the same encoding as
the traffic-rate-bytes extended community. The floating point value the traffic-rate-bytes extended community. The floating point value
carries the maximum packet rate in packets per second. A traffic- carries the maximum packet rate in packets per second. A traffic-
rate-packets of 0 should result in all traffic for the particular rate-packets of 0 should result in all traffic for the particular
flow to be discarded. flow to be discarded.
Interferes with: Traffic Rate in bytes (traffic-rate-bytes). Process Interferes with: No other BGP Flow Specification traffic action in
traffic rate in bytes (sub-type 0x06) action before traffic rate in this document.
packets action (sub-type TBD).
7.3. Traffic-action (sub-type 0x07) 7.3. Traffic-action (traffic-action) sub-type 0x07
The traffic-action extended community consists of 6 bytes of which The traffic-action extended community consists of 6 bytes of which
only the 2 least significant bits of the 6th byte (from left to only the 2 least significant bits of the 6th byte (from left to
right) are currently defined. right) are currently defined.
40 41 42 43 44 45 46 47 40 41 42 43 44 45 46 47
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| reserved | S | T | | reserved | S | T |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
where S and T are defined as: where S and T are defined as:
o T: Terminal Action (bit 47): When this bit is set, the traffic o T: Terminal Action (bit 47): When this bit is set, the traffic
filtering engine will apply any subsequent filtering rules (as filtering engine will apply any subsequent filtering rules (as
defined by the ordering procedure). If not set, the evaluation of defined by the ordering procedure). If not set, the evaluation of
the traffic filter stops when this rule is applied. the traffic filter stops when this rule is applied.
o S:Sample (bit 46): Enables traffic sampling and logging for this o S: Sample (bit 46): Enables traffic sampling and logging for this
flow specification. flow specification.
o reserved: should always be set to 0 by the originator and not be
evaluated by the receiving BGP speaker.
The use of the Terminal Action (bit 47) may result in more than one
filter-rule matching a particular flow. All the flow actions from
these rules shall be collected and applied. If interfering actions
have been collected only the first occurence SHALL be applied.
However, if a single rule contains interfering actions this rule
SHALL still be handled as described in Section 7.6.
Interferes with: No other BGP Flow Specification traffic action in Interferes with: No other BGP Flow Specification traffic action in
this document. this document.
7.4. IP Redirect (sub-type 0x08) 7.4. RT Redirect (rt-redirect) sub-type 0x08
The redirect extended community allows the traffic to be redirected The redirect extended community allows the traffic to be redirected
to a VRF routing instance that lists the specified route-target in to a VRF routing instance that lists the specified route-target in
its import policy. If several local instances match this criteria, its import policy. If several local instances match this criteria,
the choice between them is a local matter (for example, the instance the choice between them is a local matter (for example, the instance
with the lowest Route Distinguisher value can be elected). This with the lowest Route Distinguisher value can be elected). This
extended community uses the same encoding as the Route Target extended community allows 3 different encodings formats for the
extended community [RFC4360]. route-target (type 0x80, 0x81, 0x82). Is uses the same encoding as
the Route Target extended community [RFC4360].
It should be noted that the low-order nibble of the Redirect's Type It should be noted that the low-order nibble of the Redirect's Type
field corresponds to the Route Target Extended Community format field field corresponds to the Route Target Extended Community format field
(Type). (See Sections 3.1, 3.2, and 4 of [RFC4360] plus Section 2 of (Type). (See Sections 3.1, 3.2, and 4 of [RFC4360] plus Section 2 of
[RFC5668].) The low-order octet (Sub-Type) of the Redirect Extended [RFC5668].) The low-order octet (Sub-Type) of the Redirect Extended
Community remains 0x08 for all three encodings of the BGP Extended Community remains 0x08 for all three encodings of the BGP Extended
Communities (AS 2-byte, AS 4-byte, and IPv4 address). Communities (AS 2-byte, AS 4-byte, and IPv4 address).
Interferes with: All other redirect functions. All redirect Interferes with: All other redirect functions. All redirect
functions are mutually exclusive. If this redirect function exists, functions are mutually exclusive. If this redirect function exists,
then no other redirect functions can be processed. then no other redirect functions can be processed.
7.5. Traffic Marking (sub-type 0x09) 7.5. Traffic Marking (traffic-marking) sub-type 0x09
The traffic marking extended community instructs a system to modify The traffic marking extended community instructs a system to modify
the DSCP bits of a transiting IP packet to the corresponding value. the DSCP bits of a transiting IP packet to the corresponding value.
This extended community is encoded as a sequence of 5 zero bytes This extended community is encoded as a sequence of 5 zero bytes
followed by the DSCP value encoded in the 6 least significant bits of followed by the DSCP value encoded in the 6 least significant bits of
6th byte. 6th byte.
Interferes with: No other action in this document. Interferes with: No other BGP Flow Specification traffic action in
this document.
7.6. Rules on Traffic Action Interference 7.6. Rules on Traffic Action Interference
Traffic actions may interfere with each other. If interfering Traffic actions may interfere with each other. If interfering
traffic actions are present for a single flow specification NLRI the traffic actions are present for a single flow specification NLRI the
entire flow specification (irrespective if there are any other non entire flow specification (irrespective if there are any other non
conflicting actions associated with the same flow specification) conflicting actions associated with the same flow specification)
SHALL be treated as BGP WITHDRAW. SHALL be treated as BGP WITHDRAW.
This document defines 7 traffic actions which are interfering in the This document defines 7 traffic actions which are interfering in the
skipping to change at page 21, line 7 skipping to change at page 21, line 23
interfering. interfering.
When a traffic action is defined in a standards document the handling When a traffic action is defined in a standards document the handling
of interaction with other/same traffic actions MUST be defined as of interaction with other/same traffic actions MUST be defined as
well. Invalid interactions between actions SHOULD NOT trigger a BGP well. Invalid interactions between actions SHOULD NOT trigger a BGP
NOTIFICATION. All error handling for error conditions based on NOTIFICATION. All error handling for error conditions based on
[RFC7606]. [RFC7606].
7.6.1. Examples 7.6.1. Examples
(redirect vpn-a, redirect vpn-b, traffic-rate-bytes 1Mbit/s) (rt-redirect vrf-a, rt-redirect vrf-b, traffic-rate-bytes 1Mbit/s)
Redirect vpn-a and redirect vpn-b are interfering: The BGP UPDATE RT-redirect vrf-a and rt-redirect vrf-b are interfering: The BGP
is treated as WITHDRAW. UPDATE is treated as WITHDRAW.
(redirect vpn-a, traffic-rate-bytes 1Mbit/s, traffic-rate-bytes (rt-redirect vrf-a, traffic-rate-bytes 1Mbit/s, traffic-rate-bytes
2Mbit/s) 2Mbit/s)
Duplicate traffic-rate-bytes are interfering: The BGP UPDATE is Duplicate traffic-rate-bytes are interfering: The BGP UPDATE is
treated as WITHDRAW. treated as WITHDRAW.
(redirect vpn-a, traffic-rate-bytes 1Mbit/s, traffic-rate-packets (rt-redirect vrf-a, traffic-rate-bytes 1Mbit/s, traffic-rate-
1000) packets 1000)
No interfering action communities: The BGP UPDATE is subject to No interfering action communities: The BGP UPDATE is subject to
further processing. further processing.
8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks
Provider-based Layer 3 VPN networks, such as the ones using a BGP/ Provider-based Layer 3 VPN networks, such as the ones using a BGP/
MPLS IP VPN [RFC4364] control plane, may have different traffic MPLS IP VPN [RFC4364] control plane, may have different traffic
filtering requirements than Internet service providers. But also filtering requirements than Internet service providers. But also
Internet service providers may use those VPNs for scenarios like Internet service providers may use those VPNs for scenarios like
having the Internet routing table in a VRF, resulting in the same having the Internet routing table in a VRF, resulting in the same
traffic filtering requirements as defined for the global routing traffic filtering requirements as defined for the global routing
table environment within this document. This document proposes an table environment within this document. This document proposes an
additional BGP NLRI type (AFI=1, SAFI=134) value, which can be used additional BGP NLRI type (AFI=1, SAFI=134) value, which can be used
to propagate traffic filtering information in a BGP/MPLS VPN to propagate traffic filtering information in a BGP/MPLS VPN
environment. environment.
The NLRI format for this address family consists of a fixed-length The NLRI format for this address family consists of a fixed-length
Route Distinguisher field (8 bytes) followed by a flow specification, Route Distinguisher field (8 bytes) followed by a flow specification,
following the encoding defined above in section x of this document. following the encoding defined above in Section 4.2 of this document.
The NLRI length field shall include both the 8 bytes of the Route The NLRI length field shall include both the 8 bytes of the Route
Distinguisher as well as the subsequent flow specification. Distinguisher as well as the subsequent flow specification.
+------------------------------+ +------------------------------+
| length (0xnn or 0xfn nn) | | length (0xnn or 0xfn nn) |
+------------------------------+ +------------------------------+
| Route Distinguisher (8 bytes)| | Route Distinguisher (8 bytes)|
+------------------------------+ +------------------------------+
| NLRI value (variable) | | NLRI value (variable) |
+------------------------------+ +------------------------------+
skipping to change at page 29, line 16 skipping to change at page 29, line 25
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,
<http://www.rfc-editor.org/info/rfc7606>. <http://www.rfc-editor.org/info/rfc7606>.
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-07 (work in progress), March 2016. v6-08 (work in progress), March 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,
<http://www.rfc-editor.org/info/rfc4303>. <http://www.rfc-editor.org/info/rfc4303>.
Authors' Addresses Authors' Addresses
Susan Hares Susan Hares
Huawei Huawei
7453 Hickory Hill 7453 Hickory Hill
 End of changes. 28 change blocks. 
49 lines changed or deleted 70 lines changed or added

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