< draft-liang-ospf-flowspec-extensions-04.txt   draft-liang-ospf-flowspec-extensions-05.txt >
Ospf Working Group Q. Liang Ospf Working Group Q. Liang
Internet-Draft J. You Internet-Draft J. You
Intended status: Standards Track N. Wu Intended status: Standards Track N. Wu
Expires: November 19, 2015 Huawei Expires: November 29, 2015 Huawei
P. Fan P. Fan
China Mobile China Mobile
K. Patel K. Patel
M. Dubrovsky A. Lindem
Cisco Systems Cisco Systems
May 18, 2015 May 28, 2015
OSPF Extensions for Flow Specification OSPF Extensions for Flow Specification
draft-liang-ospf-flowspec-extensions-04 draft-liang-ospf-flowspec-extensions-05
Abstract Abstract
Dissemination of the Traffic flow information was first introduced in Dissemination of the Traffic flow information was first introduced in
the BGP protocol [RFC5575]. FlowSpec routes are used to distribute the BGP protocol [RFC5575]. FlowSpec routes are used to distribute
traffic filtering rules that are used to filter the Denial-of-Service traffic filtering rules that are used to filter Denial-of-Service
(DoS) attacks. For the networks that only deploy IGP (Interior (DoS) attacks. For the networks that only deploy an IGP (Interior
Gateway Protocol) (e.g. OSPF), it is expected to extend the IGP to Gateway Protocol) (e.g., OSPF), it is required that the IGP is
distribute Flow Specification or FlowSpec routes. extended to distribute Flow Specification or FlowSpec routes.
This document discusses the use cases for distributing flow This document discusses the use cases for distributing flow
specification (FlowSpec) routes using OSPF. Furthermore, this specification (FlowSpec) routes using OSPF. Furthermore, this
document defines a new OSPF FlowSpec Opaque Link State Advertisement document defines a OSPF FlowSpec Opaque Link State Advertisement
(LSA) encoding format that can be used to distribute FlowSpec routes, (LSA) encoding format that can be used to distribute FlowSpec routes,
its validation procedures for imposing the filtering information on its validation procedures for imposing the filtering information on
the routers and a capability to indicate the support of FlowSpec the routers, and a capability to indicate the support of FlowSpec
functionality. functionality.
Requirements Language Requirements Language
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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Status of This Memo Status of This Memo
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 November 19, 2015. This Internet-Draft will expire on November 29, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 8 skipping to change at page 3, line 8
4.3.3. Traffic-marking . . . . . . . . . . . . . . . . . . . 13 4.3.3. Traffic-marking . . . . . . . . . . . . . . . . . . . 13
4.3.4. Redirect-to-IP . . . . . . . . . . . . . . . . . . . 14 4.3.4. Redirect-to-IP . . . . . . . . . . . . . . . . . . . 14
4.4. Capability Advertisement . . . . . . . . . . . . . . . . 15 4.4. Capability Advertisement . . . . . . . . . . . . . . . . 15
5. Redistribution of FlowSpec Routes . . . . . . . . . . . . . . 15 5. Redistribution of FlowSpec Routes . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Security considerations . . . . . . . . . . . . . . . . . . . 16 7. Security considerations . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
[RFC5575] defines a new Border Gateway Protocol protocol extensions [RFC5575] defines Border Gateway Protocol protocol extensions that
that can be used to distribute traffic flow specifications. One can be used to distribute traffic flow specifications. One
application of that encoding format is to automate inter-domain application of this encoding format is to automate inter-domain
coordination of traffic filtering, such as what is required in order coordination of traffic filtering, such as what is required in order
to mitigate (distributed) denial-of-service attacks. [RFC5575] to mitigate (distributed) denial-of-service attacks. [RFC5575]
allows flow specifications received from an external autonomous allows flow specifications received from an external autonomous
system to be forwarded to a given BGP peer. However, in order to system to be forwarded to a given BGP peer. However, in order to
block the attack traffic more effectively, it is better to distribute block the attack traffic more effectively, it is better to distribute
the BGP FlowSpec routes to the customer network, which is much closer the BGP FlowSpec routes to the customer network, which is much closer
to the attacker. to the attacker.
For the network only deploying IGP (e.g. OSPF), it is expected to For the networks deploying only an IGP (e.g., OSPF), it is expected
extend IGP to distribute FlowSpec routes. This document discusses to extend the IGP (OSPF in this document) to distribute FlowSpec
the use cases for distributing FlowSpec routes using OSPF. routes. This document discusses the use cases for distributing
Furthermore, this document also defines a new OSPF FlowSpec Opaque FlowSpec routes using OSPF. Furthermore, this document also defines
Link State Advertisement (LSA) [RFC5250] encoding format that can be a new OSPF FlowSpec Opaque Link State Advertisement (LSA) [RFC5250]
used to distribute FlowSpec routes to the edge routers in the encoding format that can be used to distribute FlowSpec routes to the
customer network, its validation procedures for imposing the edge routers in the customer network, its validation procedures for
filtering information on the routers and a capibility to indicate the imposing the filtering information on the routers, and a capability
support of Flowspec functionality. to indicate the support of Flowspec functionality.
The semantic content of the FlowSpec extensions defined in this The semantic content of the FlowSpec extensions defined in this
document are identical to the corresponding extensions to BGP document are identical to the corresponding extensions to BGP
([RFC5575] and [I-D.ietf-idr-flow-spec-v6]). In order to avoid ([RFC5575] and [I-D.ietf-idr-flow-spec-v6]). In order to avoid
repetition, this document only concentrates on those parts of repetition, this document only concentrates on those parts of
specification where OSPF is different from BGP. The OSPF flowspec specification where OSPF is different from BGP. The OSPF flowspec
extensions defined in this document can be used to mitigate the extensions defined in this document can be used to mitigate the
impacts of DoS attacks. impacts of DoS attacks.
2. Terminology 2. Terminology
skipping to change at page 4, line 7 skipping to change at page 4, line 7
throughout this document. However, many additional definitions can throughout this document. However, many additional definitions can
be found in [RFC5250] and [RFC5575]. be found in [RFC5250] and [RFC5575].
Flow Specification (FlowSpec): A flow specification is an n-tuple Flow Specification (FlowSpec): A flow specification is an n-tuple
consisting of several matching criteria that can be applied to IP consisting of several matching criteria that can be applied to IP
traffic, including filters and actions. Each FlowSpec consists of traffic, including filters and actions. Each FlowSpec consists of
a set of filters and a set of actions. a set of filters and a set of actions.
3. Use Cases for OSPF based FlowSpec Distribution 3. Use Cases for OSPF based FlowSpec Distribution
For the network only deploying IGP (e.g. OSPF), it is expected to For the networks deploying only an IGP (e.g., OSPF), it is expected
extend IGP (OSPF in this document) to distribute FlowSpec routes, to extend the IGP (OSPF in this document) to distribute FlowSpec
because when the FlowSpec routes are installed in the customer routes, because when the FlowSpec routes are installed in the
network, it would be closer to the attacker than when they are customer network, they are closer to the attacker than when they are
installed in the provider network. Consequently, the attack traffic installed in the provider network. Consequently, the attack traffic
could be blocked or the suspicious traffic could be limited to a low could be blocked or the suspicious traffic could be limited to a low
rate as early as possible. rate as early as possible.
The following sub-sections discuss the use cases for OSPF based The following sub-sections discuss the use cases for OSPF based
FlowSpec routes distribution. FlowSpec route distribution.
3.1. OSPF Campus Network 3.1. OSPF Campus Network
For the network not deploying BGP, for example, the campus network For networks not deploying BGP, for example, the campus network using
using OSPF, it is expected to extend OSPF to distribute FlowSpec OSPF, it is expected to extend OSPF to distribute FlowSpec routes as
routes as shown in Figure 3. In this kind of network, the traffic shown in Figure 3. In this kind of network, the traffic analyzer
analyzer could be deploy with a router, then the FlowSpec routes from could be deployed with a router, then the FlowSpec routes from the
the traffic analyzer need to be distributed to the other routers in traffic analyzer need to be distributed to the other routers in this
this domain based on OSPF. domain using OSPF.
+--------+ +--------+
|Traffic | |Traffic |
+---+Analyzer| +---+Analyzer|
| +--------+ | +--------+
| |
|FlowSpec |FlowSpec
| |
| |
+--+-------+ +----------+ +--------+ +--+-------+ +----------+ +--------+
| Router A +-----------+ Router B +--------+Attacker| | Router A +-----------+ Router B +--------+Attacker|
+----------+ +----------+ +--------+ +----------+ +----------+ +--------+
| | | | | |
| OSPF FlowSpec | Attack Traffic | | OSPF FlowSpec | Attack Traffic |
| | | | | |
Figure 3: OSPF Campus Network Figure 3: OSPF Campus Network
3.2. BGP/MPLS VPN 3.2. BGP/MPLS VPN
[RFC5575] defines a BGP NLRI encoding format to distribute traffic [RFC5575] defines a BGP NLRI encoding format to distribute traffic
flow specifications in BGP deployed network. However in the BGP/MPLS flow specifications in BGP deployed network. However, in the BGP/
VPN scenario, the IGP (e.g. IS-IS, OSPF) is used between PE MPLS VPN scenario, the IGP (e.g., IS-IS, or OSPF) is used between the
(Provider Edge) and CE (Customer Edge) for many deployments. In PE (Provider Edge) and CE (Customer Edge) in many deployments. In
order to distribute the FlowSpec routes to the customer network, the order to distribute the FlowSpec routes to the customer network, the
IGP needs to support the FlowSpec route distribution. The FlowSpec IGP needs to support FlowSpec route distribution. The FlowSpec
routes are usually generated by the traffic analyzer or the traffic routes are usually generated by the traffic analyzer or the traffic
policy center in the network. Depending on the location of the policy center in the network. Depending on the location of the
traffic analyzer deployment, two different distribution scenarios traffic analyzer deployment, two different distribution scenarios are
will be discussed below. discussed below.
3.2.1. Traffic Analyzer Deployed in Provider Network 3.2.1. Traffic Analyzer Deployed in Provider Network
The traffic analyzer (also acting as the traffic policy center) could The traffic analyzer (also acting as the traffic policy center) could
be deployed in the provider network as shown in Figure 1. If the be deployed in the provider network as shown in Figure 1. If the
traffic analyzer detects attack traffic from the customer network traffic analyzer detects attack traffic from the customer network
VPN1, it would generate the FlowSpec routes for preventing DoS VPN1, it would generate the FlowSpec routes for preventing DoS
attacks. The FlowSpec routes with a route distinguisher information attacks. FlowSpec routes with a Route Distinguisher (RD) in the
corresponding to VPN1 are distributed from the traffic analyzer to Network Layer Reachability information (NRLI) corresponding to VPN1
the PE1 which the traffic analyzer is the attached to. If the are distributed from the traffic analyzer to the PE1 to which the
traffic analyzer is also a BGP speaker, it can distribute the traffic analyzer is attached. If the traffic analyzer is also a BGP
FlowSpec routes based on the BGP [RFC5575]. Then the PE1 distributes speaker, it can distribute the FlowSpec routes using BGP [RFC5575].
the FlowSpec routes further to the PE2. Finally, the FlowSpec routes Then the PE1 distributes the FlowSpec routes further to the PE2.
need to be distributed from the PE2 to the CE2 based on OSPF, i.e. to Finally, the FlowSpec routes need to be distributed from PE2 to the
the customer network VPN1. As the attacker is more likely in the CE2 using OSPF, i.e., to the customer network VPN1. As an attacker
customer network, if the FlowSpec routes installed on the CE2, it is more likely in the customer network, FlowSpec routes installed
could mitigate the impacts of DoS attacks better. directly on CE2 could mitigate the impact of DoS attacks better.
+--------+ +--------+
|Traffic | |Traffic |
+---+Analyzer| ----------- +---+Analyzer| -----------
| +--------+ //- -\\ | +--------+ //- -\\
| /// \\\ | /// \\\
|FlowSpec / \ |FlowSpec / \
| // \\ | // \\
| | | | | |
+--+--+ +-----+ | +-----+ +--------+ | +--+--+ +-----+ | +-----+ +--------+ |
skipping to change at page 6, line 10 skipping to change at page 6, line 10
\\-- --// \\-- --//
--------- ---------
Figure 1: Traffic Analyzer deployed in Provider Network Figure 1: Traffic Analyzer deployed in Provider Network
3.2.2. Traffic Analyzer Deployed in Customer Network 3.2.2. Traffic Analyzer Deployed in Customer Network
The traffic analyzer (also acting as the traffic policy center) could The traffic analyzer (also acting as the traffic policy center) could
be deployed in the customer network as shown in Figure 2. If the be deployed in the customer network as shown in Figure 2. If the
traffic analyzer detects attack traffic, it would generate FlowSpec traffic analyzer detects attack traffic, it would generate FlowSpec
routes for preventing DoS attacks. Then the FlowSpec routes would be routes to prevent associated DoS attacks. Then the FlowSpec routes
distributed from the traffic analyzer to the CE1 based on OSPF or would be distributed from the traffic analyzer to the CE1 using OSPF
other policy protocol (e.g. RESTful API over HTTP). Further, the or another policy protocol (e.g., RESTful API over HTTP).
FlowSpec routes need to be distributed through the provider network Furthermore, the FlowSpec routes need to be distributed throughout
via the PE1/PE2 to the CE2, i.e. to the remote customer network VPN1 the provider network via PE1/PE2 to CE2, i.e., to the remote customer
Site1. If the FlowSpec routes installed on the CE2, it could block network VPN1 Site1. If the FlowSpec routes installed on the CE2, it
the attack traffic as close to the source of the attack as possible. could block the attack traffic as close to the source of the attack
as possible.
+--------+ +--------+
|Traffic | |Traffic |
+---+Analyzer| +---+Analyzer|
| +--------+ -------- | +--------+ ------
| //-- --\\ | //-- --\\
|FlowSpec // \\ |FlowSpec // \\
| / \ | / \
| // \\ | // \\
+--+--+ +-----+ +-----+ | +-----+ +--------+ | +--+--+ +-----+ +-----+ | +-----+ +--------+ |
| CE1 +--------+ PE1 +-------+ PE2 +--------+-+ CE2 +-------+Attacker| | | CE1 +--------+ PE1 +-------+ PE2 +----- +--+ CE2 +-----+Attacker| |
+-----+ +-----+ +-----+ | +-----+ +--------+ | +-----+ +-----+ +-----+ | +-----+ +--------+ |
| | | | | | | | |
| | | | | | | | OSPF FlowSpec | BGP FlowSpec| OSPF FlowSpec |Attack Traffic| |
| OSPF FlowSpec | BGP FlowSpec| OSPF FlowSpec | Attack Traffic | | | | | | | | |
| | | | | | | | |
| | \\ //
\\ // \ VPN1 Site1 /
\ VPN1 Site1 / \\ //
\\ // \\-- --//
\\-- --// -----
--------
Figure 2: Traffic Analyzer deployed in Customer Network Figure 2: Traffic Analyzer deployed in Customer Network
3.2.3. Policy Configuration 3.2.3. Policy Configuration
The CE or PE could deploy local filtering policies to filter OSPF The CE or PE could deploy local filtering policies to filter OSPF
FlowSpec rules, for example, deploying a filtering policy to filter FlowSpec rules, for example, deploying a filtering policy to filter
the incoming OSPF FlowSpec rules in order to drop illegal or invalid the incoming OSPF FlowSpec rules in order to prevent illegal or
FlowSpec rules, or to filter the outcoming OSPF FlowSpec rules in invalid FlowSpec rules from being applied.
order to prevent locally valid OSPF FlowSpec rules from dissemination
outside.
The PE should configure FlowSpec importing policies to control The PE should configure FlowSpec importing policies to control
importing action between BGP IP/VPN FlowSpec RIB and OSPF Instance importing action between the BGP IP/VPN FlowSpec RIB and the OSPF
FlowSpec RIB. Otherwise, the PE couldn't transform a BGP IP/VPN Instance FlowSpec RIB. Otherwise, the PE couldn't transform a BGP
FlowSpec rule to an OSPF FlowSpec rule or transform an OSPF FlowSpec IP/VPN FlowSpec rule to an OSPF FlowSpec rule or transform an OSPF
rule to a BGP IP/VPN FlowSpec rule. FlowSpec rule to a BGP IP/VPN FlowSpec rule.
4. OSPF Extensions for FlowSpec Rules 4. OSPF Extensions for FlowSpec Rules
4.1. FlowSpec LSA 4.1. FlowSpec LSA
4.1.1. OSPFv2 FlowSpec Opaque LSA 4.1.1. OSPFv2 FlowSpec Opaque LSA
This document defines a new OSPFv2 flow specification Opaque Link This document defines a new OSPFv2 flow specification Opaque Link
State Advertisement (LSA) encoding format that can be used to State Advertisement (LSA) encoding format that can be used to
distribute traffic flow specifications. This new OSPF FlowSpec distribute traffic flow specifications. This new OSPF FlowSpec
skipping to change at page 7, line 48 skipping to change at page 7, line 47
| ... | | ... |
Figure 4: OSPFv2 FlowSpec Opaque LSA Figure 4: OSPFv2 FlowSpec Opaque LSA
LS age: the same as defined in [RFC2328]. LS age: the same as defined in [RFC2328].
Options: the same as defined in [RFC2328]. Options: the same as defined in [RFC2328].
LS type: A type-11 or type-10 Opaque-LSA SHOULD be originated. LS type: A type-11 or type-10 Opaque-LSA SHOULD be originated.
Since the type-11 LSA has the same flooding scope as a type-5 LSA Since the type-11 LSA has the same flooding scope as a type-5 LSA
as stated in [RFC5250], it MUST NOT be flooded into stub areas or as stated in [RFC5250], it will not be flooded into stub areas or
NSSAs (Not-So-Stubby Areas). When stub or NSSA areas are NSSAs (Not-So-Stubby Areas). When stub or NSSA areas are
encountered in the scenario of flow spec, we may have to make our encountered in the scenario of flow spec, we may have to make our
choice, either making peace with it and filtering the DoS traffic choice, either making peace with it and filtering the DoS traffic
at ABRs or generating a new type-10 Opaque-LSA into stub/NSSA at ABRs or generating a new type-10 Opaque-LSA into stub/NSSA
areas, which may aggravate the burden of devices in that area. areas, which may aggravate the burden of devices in that area.
Opaque type: OSPF FlowSpec Opaque LSA (Type Code: TBD1). Opaque type: OSPF FlowSpec Opaque LSA (Type Code: TBD1).
Opaque ID: the same as defined in [RFC5250]. Opaque ID: the same as defined in [RFC5250].
skipping to change at page 8, line 42 skipping to change at page 8, line 41
| Values... | | Values... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: TLV Format Figure 5: TLV Format
The Length field defines the length of the value portion in octets The Length field defines the length of the value portion in octets
(thus a TLV with no value portion would have a length of 0). The TLV (thus a TLV with no value portion would have a length of 0). The TLV
is padded to 4-octet alignment; padding is not included in the length is padded to 4-octet alignment; padding is not included in the length
field (so a 3-octet value would have a length of 3, but the total field (so a 3-octet value would have a length of 3, but the total
size of the TLV would be 8 octets). Nested TLVs are also 32-bit size of the TLV would be 8 octets). Nested TLVs are also 32-bit
aligned. For example, a 1-byte value would have the length field set aligned. For example, a 1-octet value would have the length field
to 1, and 3 octets of padding would be added to the end of the value set to 1, and 3 octets of padding would be added to the end of the
portion of the TLV. value portion of the TLV.
If FlowSpec Opaque LSA is Type-11 Opaque LSA, it is not flooded into If FlowSpec Opaque LSA is Type-11 Opaque LSA, it is not flooded into
Stub and NSSA areas. As the traffic accessing a network segment Stub and NSSA areas. As the traffic accessing a network segment
outside Stub and NSSA areas would be aggregated to the ABR, FlowSpec outside Stub and NSSA areas would be aggregated to the ABR, FlowSpec
rules could be executed on the ABR instead of disseminating them into rules could be applied on the ABR instead of disseminating them into
Stub and NSSA areas. Stub and NSSA areas.
4.1.2. OSPFv3 FlowSpec LSA 4.1.2. OSPFv3 FlowSpec LSA
This document defines a new OSPFv3 flow specification LSA encoding This document defines a new OSPFv3 flow specification LSA encoding
format that can be used to distribute traffic flow specifications. format that can be used to distribute traffic flow specifications.
This new OSPFv3 FlowSpec LSA is extended based on [RFC5340]. This new OSPFv3 FlowSpec LSA is extended based on [RFC5340].
The OSPFv3 FlowSpec LSA is defined below in Figure 6: The OSPFv3 FlowSpec LSA is defined below in Figure 6:
skipping to change at page 9, line 48 skipping to change at page 9, line 48
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|U |S2|S1| LSA Function Code | |U |S2|S1| LSA Function Code |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 7: LSA Type Figure 7: LSA Type
In this document, the U bit should be set indicating that the In this document, the U bit should be set indicating that the
OSPFv3 FlowSpec LSA should be flooded even if it is not OSPFv3 FlowSpec LSA should be flooded even if it is not
understood. For the area scope, S1 bit should be set and S2 understood. For the area scope, the S1 bit should be set and the
should be 0. For the AS scope, the S1 bit should be 0 and S2 bit S2 should be clear. For the AS scope, the S1 bit should be clear
should be set. Meanwhile, A new LSA Function Code (TBD2) needs to and the S2 bit should be set. A new LSA Function Code (TBD2)
be defined for OSPFv3 FlowSpec LSA. To facilitate inter-area needs to be defined for OSPFv3 FlowSpec LSA. To facilitate inter-
reachability validation, any OSPFv3 router originating AS scoped area reachability validation, any OSPFv3 router originating AS
LSAs is considered an AS Boundary Router (ASBR). scoped LSAs is considered an AS Boundary Router (ASBR).
Link State ID: the same as defined in [RFC5340]. Link State ID: the same as defined in [RFC5340].
Advertising Router: the same as defined in [RFC5340]. Advertising Router: the same as defined in [RFC5340].
LS sequence number: the same as defined in [RFC5340]. LS sequence number: the same as defined in [RFC5340].
LS checksum: the same as defined in [RFC5340]. LS checksum: the same as defined in [RFC5340].
Length: the same as defined in [RFC5340]. Length: the same as defined in [RFC5340].
TLVs: one or more TLVs MAY be included in a OSPFv3 FlowSpec LSA to TLVs: one or more TLVs MAY be included in a OSPFv3 FlowSpec LSA to
carry FlowSpec information. carry FlowSpec information.
4.2. OSPF FlowSpec Filters TLV 4.2. OSPF FlowSpec Filters TLV
The FlowSpec Opaque LSA carries one or more FlowSpec Filters TLVs and The FlowSpec Opaque LSA carries one or more FlowSpec Filters TLVs and
corresponding FlowSpec Action TLVs. OSPF FlowSpec Filters TLV is corresponding FlowSpec Action TLVs. The OSPF FlowSpec Filters TLV is
defined below in Figure 6. defined below in Figure 8.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Filters (variable) ~ | Flags | Filters (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Filters (variable) ~ ~ Filters (variable) ~
+ + + +
| ... | | ... |
Figure 8: OSPF FlowSpec Filters TLV Figure 8: OSPF FlowSpec Filters TLV
Type: the TLV type (Type Code: TBD3) Type: the TLV type (Type Code: TBD3)
Length: the size of the value field (typically in bytes) Length: the size of the value field in octets
Flags: One byte Field identifying Flags. Flags: One octet Field identifying Flags.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Reserved |S| | Reserved |S|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
The least significant bit S is defined as a strict Filter check bit. The least significant bit S is defined as a strict Filter check bit.
If set, Strict Validation rules outlined in the validation section If set, Strict Validation rules outlined in the validation section
needs to be enforced. Section 4.2.2 need to be enforced.
Filters: the same as "flow-spec NLRI value" defined in [RFC5575] and Filters: the same as "flow-spec NLRI value" defined in [RFC5575] and
[I-D.ietf-idr-flow-spec-v6]. [I-D.ietf-idr-flow-spec-v6].
Table 1: OSPF Supported FlowSpec Filters Table 1: OSPF Supported FlowSpec Filters
+------+------------------------+------------------------------+ +------+------------------------+------------------------------+
| Type | Description | RFC/ WG draft | | Type | Description | RFC/ WG draft |
+------+------------------------+------------------------------+ +------+------------------------+------------------------------+
| 1 | Destination IPv4 Prefix| RFC5575 | | 1 | Destination IPv4 Prefix| RFC5575 |
| | Destination IPv6 Prefix| I-D.ietf-idr-flow-spec-v6 | | | Destination IPv6 Prefix| I-D.ietf-idr-flow-spec-v6 |
skipping to change at page 11, line 49 skipping to change at page 11, line 49
| 11 | DSCP | RFC5575 | | 11 | DSCP | RFC5575 |
+------+------------------------+------------------------------+ +------+------------------------+------------------------------+
| 12 | Fragment | RFC5575 | | 12 | Fragment | RFC5575 |
+------+------------------------+------------------------------+ +------+------------------------+------------------------------+
| 13 | Flow Label | I-D.ietf-idr-flow-spec-v6 | | 13 | Flow Label | I-D.ietf-idr-flow-spec-v6 |
+------+----------------------- ------------------------------+ +------+----------------------- ------------------------------+
4.2.1. Order of Traffic Filtering Rules 4.2.1. Order of Traffic Filtering Rules
With traffic filtering rules, more than one rule may match a With traffic filtering rules, more than one rule may match a
particular traffic flow. The order of traffic filteringapplying the particular traffic flow. The order of applying the traffic filter
rules is the same as described in Section 5.1 of [RFC5575] and in rules is the same as described in Section 5.1 of [RFC5575] and in
Section 3.1 of [I-D.ietf-idr-flow-spec-v6]. Section 3.1 of [I-D.ietf-idr-flow-spec-v6].
4.2.2. Validation Procedure 4.2.2. Validation Procedure
[RFC5575] defines a validation procedure for BGP FlowSpec rules, and [RFC5575] defines a validation procedure for BGP FlowSpec rules, and
[I-D.ietf-idr-bgp-flowspec-oid] describes a modification to the [I-D.ietf-idr-bgp-flowspec-oid] describes a modification to the
validation procedure defined in [RFC5575] for the dissemination of validation procedure defined in [RFC5575] for the dissemination of
BGP flow specifications. The OSPF FlowSpec should support similar BGP flow specifications. The OSPF FlowSpec should support similar
features to mitigate the unnecessary flooding of OSPF FlowSpec LSA. features to mitigate the unnecessary application of traffic filter
OSPF FlowSpec validation procedure is described as follows. rules. The OSPF FlowSpec validation procedure is described as
follows.
When a router receives the FlowSpec rule including a destination When a router receives a FlowSpec rule including a destination prefix
prefix filter from its neighbor router it should consider the prefix filter from its neighbor router, it should consider the prefix filter
filter as a valid filter unless the S bit in the flags field of as a valid filter unless the S bit in the flags field of Filter TLV
Filter TLV is set. If the S bit is set, then the FlowSpec rule is is set. If the S bit is set, then the FlowSpec rule is considered
considered valid if and only if: valid if and only if:
The originator of the FlowSpec rule matches the originator of the The originator of the FlowSpec rule matches the originator of the
best-match unicast route for the destination prefix embedded in best-match unicast route for the destination prefix embedded in
the FlowSpec. the FlowSpec.
The former rule allows any centralized controller to originate the The former rule allows any centralized controller to originate the
prefix filter and advertise it within a given OSPF network. The prefix filter and advertise it within a given OSPF network. The
later rule also knowns as a Strict Validation rule allows strict latter rule, also known as a Strict Validation rule, allows strict
checking and enforces that the originator of the FlowSpec filter is checking and enforces that the originator of the FlowSpec filter is
also the originator of the destination prefix. also the originator of the destination prefix.
When multiple equal-cost paths exist in the routing table entry, each When multiple equal-cost paths exist in the routing table entry, each
path could end up having a separate set of FlowSpec rules. path could end up having a separate set of FlowSpec rules.
When a router receives the FlowSpec rule not including a destination When a router receives a FlowSpec rule not including a destination
prefix filter from its neighbor router, the validation procedure prefix filter from its neighbor router, the validation procedure
described above is not needed. described above is not applicable.
The FlowSpec filter validation state is used by a speaker when the
filter is considered for an installation in its FIB. An OSPF speaker
MUST flood OSPF FlowSpec LSA as per the rules defined in [RFC2328]
regardless of the validation state of the prefix filters.
4.3. OSPF FlowSpec Action TLV 4.3. OSPF FlowSpec Action TLV
There are one or more FlowSpec Action TLVs associated with a FlowSpec There are one or more FlowSpec Action TLVs associated with a FlowSpec
Filters TLV. Meanwhile, different FlowSpec Filters TLV could have Filters TLV. Different FlowSpec Filters TLV could have the same
the same FlowSpec Action TLV/s. The following OSPF FlowSpec action FlowSpec Action TLVs. The following OSPF FlowSpec action TLVs,
TLVs except Redirect are the same as defined in [RFC5575]. except Redirect, are same as defined in [RFC5575].
Redirect: 2-byte IPv4 or 16-byte IPv6 address. This IP address may Redirect: IPv4 or IPv6 address. This IP address may correspond to a
correspond to a tunnel, i.e. the redirect allows the traffic to be tunnel, i.e., the redirect allows the traffic to be redirected to a
redirected to a real next hop or egress interface by looking up the directly attached next-hop or a next-hop requiring a route lookup.
RIB based on the IP address.
Table 2: Traffic Filtering Actions in [RFC5575], etc. Table 2: Traffic Filtering Actions in [RFC5575], etc.
+-------+-----------------+---------------------------------------+ +-------+-----------------+---------------------------------------+
| type | FlowSpec Action | RFC/WG draft | | type | FlowSpec Action | RFC/WG draft |
+-------+-----------------+---------------------------------------+ +-------+-----------------+---------------------------------------+
| 0x8006| traffic-rate | RFC5575 | | 0x8006| traffic-rate | RFC5575 |
| | | | | | | |
| 0x8007| traffic-action | RFC5575 | | 0x8007| traffic-action | RFC5575 |
| | | | | | | |
| 0x8108| redirect-to-IPv4| I-D.ietf-idr-flowspec-redirect-rt-bis | | 0x8108| redirect-to-IPv4| I-D.ietf-idr-flowspec-redirect-rt-bis |
| | | | | |
| 0x800b| redirect-to-IPv6| I-D.ietf-idr-flow-spec-v6 | | 0x800b| redirect-to-IPv6| I-D.ietf-idr-flow-spec-v6 |
| | | | | | | |
| 0x8009| traffic-marking | RFC5575 | | 0x8009| traffic-marking | RFC5575 |
+-------+-----------------+---------------------------------------+ +-------+-----------------+---------------------------------------+
4.3.1. Traffic-rate 4.3.1. Traffic-rate
Traffic-rate TLV is encoded as: Traffic-rate TLV is encoded as:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD5,0x8006 suggested | 4 | | TBD5,0x8006 suggested | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic-rate | | Traffic-rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Traffic-rate: the same as defined in [RFC5575]. Traffic-rate: the same as defined in [RFC5575].
4.3.2. Traffic-action 4.3.2. Traffic-action
Traffic-action TLV is encoded as: Traffic-action TLV is encoded as:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD6, 0x8007 suggested | 2 | | TBD6, 0x8007 suggested | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |S|T| | | Reserved |S|T| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S flag and T flag: the same as defined in [RFC5575]. S flag and T flag: the same as defined in [RFC5575].
4.3.3. Traffic-marking 4.3.3. Traffic-marking
Traffic-marking TLV is encoded as: Traffic-marking TLV is encoded as:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD7, 0x8009 suggested | 2 | | TBD7, 0x8009 suggested | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | DSCP Value| | | Reserved | DSCP Value| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DSCP value: the same as defined in [RFC5575]. DSCP value: the same as defined in [RFC5575].
4.3.4. Redirect-to-IP 4.3.4. Redirect-to-IP
Redirect-to-IPv4 is encoded as: Redirect-to-IPv4 is encoded as:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD8, 0x8108 suggested | 6 | | TBD8, 0x8108 suggested | 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address | | IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |C| | | Reserved |C| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Redirect to IPv6 TLV is encoded as (Only for OSPFv3): Redirect to IPv6 TLV is encoded as (Only for OSPFv3):
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD9, 0x800b suggested | 18 | | TBD9, 0x800b suggested | 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IPv6 Address | | IPv6 Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |C| | | Reserved |C| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4/6 Address: the redirection target address. IPv4/6 Address: the redirection target address.
'C' (or copy) bit: when the 'C' bit is set, the redirection applies 'C' (or copy) bit: when the 'C' bit is set, the redirection applies
to copies of the matching packets and not to the original traffic to copies of the matching packets and not to the original traffic
stream [I-D.ietf-idr-flowspec-redirect-ip]. stream [I-D.ietf-idr-flowspec-redirect-ip].
4.4. Capability Advertisement 4.4. Capability Advertisement
This document defines a new Router-LSA bit known [I-D.ietf-ospf- This document defines a capability bit for OSPF Router-Information
rfc4970bis] as FlowSpec Capability Advertisement bit. When set, the LSA [I-D.ietf-ospf-rfc4970bis] as FlowSpec Capability Advertisement
OSPF router indicates its ability to support the FlowSpec bit. When set, the OSPF router indicates its ability to support the
functionality. The FlowSpec Capability Advertisement bit has a value FlowSpec functionality. The FlowSpec Capability Advertisement bit
to be assigned by IANA from OSPF Router Functional Capability Bits has a value to be assigned by IANA from OSPF Router Functional
Registry [I-D.ietf-ospf-rfc4970bis]. Capability Bits Registry [I-D.ietf-ospf-rfc4970bis].
5. Redistribution of FlowSpec Routes 5. Redistribution of FlowSpec Routes
In certain scenarios, FlowSpec routes MAY get redistributed from one In certain scenarios, FlowSpec routes MAY get redistributed from one
protocol domain to another; specifically from BGP to OSPF and vice- protocol domain to another; specifically from BGP to OSPF and vice-
versa. When redistributed from BGP, OSPF speaker SHOULD generate an versa. When redistributed from BGP, the OSPF speaker SHOULD generate
Opaque LSA for the redistributed routes and announce it within an an Opaque LSA for the redistributed routes and announce it within an
OSPF domain. An implementation MAY provide an option for an OSPF OSPF domain. An implementation MAY provide an option for an OSPF
speaker to announce a redistributed FlowSpec route within a OSPF speaker to announce a redistributed FlowSpec route within a OSPF
domain regardless of being installed in its local FIB. An domain regardless of being installed in its local FIB. An
implementation MAY impose an upper bound on number of FlowSpec routes implementation MAY impose an upper bound on number of FlowSpec routes
that an OSPF router MAY distribute. that an OSPF router MAY advertise.
6. IANA Considerations 6. IANA Considerations
This document defines a new OSPFv2 Opaque LSA, i.e. OSPFv2 FlowSpec This document defines a new OSPFv2 Opaque LSA, i.e., OSPFv2 FlowSpec
Opaque LSA (Type Code: TBD1), which is used to distribute traffic Opaque LSA (Type Code: TBD1), which is used to distribute traffic
flow specifications. flow specifications.
This document defines a new OSPFv3 LSA, i.e. OSPFv3 FlowSpec LSA (LSA This document defines a new OSPFv3 LSA, i.e., OSPFv3 FlowSpec LSA
Function Code: TBD2), which is used to distribute traffic flow (LSA Function Code: TBD2), which is used to distribute traffic flow
specifications. specifications.
This document defines OSPF FlowSpec Filters TLV (Type Code: TBD3), This document defines OSPF FlowSpec Filters TLV (Type Code: TBD3),
which is used to describe the filters. which is used to describe the filters.
This document defines a new FlowSpec capability which need to be This document defines a new FlowSpec capability which need to be
advertised in an RI Opaque LSA. A new informational capability bit advertised in an RI Opaque LSA. A new informational capability bit
needs to be assigned for OSPF FlowSpec feature (FlowSpec Bit: TBD4). needs to be assigned for OSPF FlowSpec feature (FlowSpec Bit: TBD4).
This document defines a new Router LSA bit known as a FlowSpec This document defines a new Router LSA bit known as a FlowSpec
skipping to change at page 16, line 37 skipping to change at page 16, line 37
7. Security considerations 7. Security considerations
This extension to OSPF does not change the underlying security issues This extension to OSPF does not change the underlying security issues
inherent in the existing OSPF. Implementations must assure that inherent in the existing OSPF. Implementations must assure that
malformed TLV and Sub-TLV permutations do not result in errors which malformed TLV and Sub-TLV permutations do not result in errors which
cause hard OSPF failures. cause hard OSPF failures.
8. Acknowledgement 8. Acknowledgement
The authors would like to thank Acee Lindem for his comments. The The authors would also like to thank Burjiz Pithawala, Rashmi
authors would also like to thank Burjiz Pithawala and Rashmi Shrivastava and Mike Dubrovsky for their contribution to the original
Shrivastava for their contribution to the original version of the version of the document.
document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, January
2007.
[RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S.
Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 4970, July 2007.
[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
OSPF Opaque LSA Option", RFC 5250, July 2008. OSPF Opaque LSA Option", RFC 5250, July 2008.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008. for IPv6", RFC 5340, July 2008.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, August 2009. Rules", RFC 5575, August 2009.
skipping to change at page 17, line 43 skipping to change at page 17, line 32
"Dissemination of Flow Specification Rules for IPv6", "Dissemination of Flow Specification Rules for IPv6",
draft-ietf-idr-flow-spec-v6-06 (work in progress), draft-ietf-idr-flow-spec-v6-06 (work in progress),
November 2014. November 2014.
[I-D.ietf-idr-flowspec-redirect-ip] [I-D.ietf-idr-flowspec-redirect-ip]
Uttaro, J., Haas, J., Texier, M., Andy, A., Ray, S., Uttaro, J., Haas, J., Texier, M., Andy, A., Ray, S.,
Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to
IP Action", draft-ietf-idr-flowspec-redirect-ip-02 (work IP Action", draft-ietf-idr-flowspec-redirect-ip-02 (work
in progress), February 2015. in progress), February 2015.
[I-D.ietf-idr-flowspec-redirect-rt-bis]
Haas, J., "Clarification of the Flowspec Redirect Extended
Community", draft-ietf-idr-flowspec-redirect-rt-bis-04
(work in progress), April 2015.
[I-D.shrivastava-ospf-flow-spec]
Shrivastava, R., Dubrovsky, M., Patel, K., and B.
Pithawala, "Flow Specification Extensions to OSPF
Protocol", draft-shrivastava-ospf-flow-spec-01 (work in
progress), April 2013.
Authors' Addresses Authors' Addresses
Qiandeng Liang Qiandeng Liang
Huawei Huawei
101 Software Avenue, Yuhuatai District 101 Software Avenue, Yuhuatai District
Nanjing, 210012 Nanjing, 210012
China China
Email: liuweihang@huawei.com Email: liuweihang@huawei.com
skipping to change at page 18, line 22 skipping to change at page 18, line 4
Email: liuweihang@huawei.com Email: liuweihang@huawei.com
Jianjie You Jianjie You
Huawei Huawei
101 Software Avenue, Yuhuatai District 101 Software Avenue, Yuhuatai District
Nanjing, 210012 Nanjing, 210012
China China
Email: youjianjie@huawei.com Email: youjianjie@huawei.com
Nan Wu Nan Wu
Huawei Huawei
Email: eric.wu@huawei.com Email: eric.wu@huawei.com
Peng Fan Peng Fan
China Mobile China Mobile
Email: fanpeng@chinamobile.com Email: fanpeng@chinamobile.com
Keyur Patel Keyur Patel
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95124 95134 San Jose, CA 95124 95134
USA USA
Email: keyupate@cisco.com Email: keyupate@cisco.com
Mike Acee Lindem
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95124 95134 San Jose, CA 95124 95134
USA USA
Email: mdubrovs@cisco.com Email: acee@cisco.com
 End of changes. 58 change blocks. 
182 lines changed or deleted 161 lines changed or added

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