draft-ietf-idr-flowspec-path-redirect-09.txt | draft-ietf-idr-flowspec-path-redirect-10.txt | |||
---|---|---|---|---|
IDR Working Group G. Van de Velde, Ed. | IDR Working Group G. Van de Velde, Ed. | |||
Internet-Draft Nokia | Internet-Draft Nokia | |||
Intended status: Standards Track K. Patel | Intended status: Standards Track K. Patel | |||
Expires: February 20, 2020 Arrcus | Expires: May 1, 2020 Arrcus | |||
Z. Li | Z. Li | |||
Huawei Technologies | Huawei Technologies | |||
August 19, 2019 | October 29, 2019 | |||
Flowspec Indirection-id Redirect | Flowspec Indirection-id Redirect | |||
draft-ietf-idr-flowspec-path-redirect-09 | draft-ietf-idr-flowspec-path-redirect-10 | |||
Abstract | Abstract | |||
This document defines a new extended community known as "FlowSpec | This document defines a new extended community known as "FlowSpec | |||
Redirect to indirection-id Extended Community". This extended | Redirect to indirection-id Extended Community". This extended | |||
community triggers advanced redirection capabilities to flowspec | community triggers advanced redirection capabilities to flowspec | |||
clients. When activated, this flowspec extended community is used by | clients. When activated, this flowspec extended community is used by | |||
a flowspec client to retrieve the corresponding next-hop and encoding | a flowspec client to retrieve the corresponding next-hop and encoding | |||
information within a localised indirection-id mapping table. | information within a localised indirection-id mapping table. | |||
skipping to change at page 1, line 48 ¶ | skipping to change at page 1, line 48 ¶ | |||
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 February 20, 2020. | This Internet-Draft will expire on May 1, 2020. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 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 2, line 33 ¶ | skipping to change at page 2, line 33 ¶ | |||
2. indirection-id and indirection-id table . . . . . . . . . . . 3 | 2. indirection-id and indirection-id table . . . . . . . . . . . 3 | |||
3. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . 3 | 3. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . 3 | |||
3.1. Redirection shortest Path tunnel . . . . . . . . . . . . 3 | 3.1. Redirection shortest Path tunnel . . . . . . . . . . . . 3 | |||
3.2. Redirection to path-engineered tunnels . . . . . . . . . 4 | 3.2. Redirection to path-engineered tunnels . . . . . . . . . 4 | |||
3.3. Redirection to complex dynamically constructed tunnels . 5 | 3.3. Redirection to complex dynamically constructed tunnels . 5 | |||
4. Redirect to indirection-id Community . . . . . . . . . . . . 6 | 4. Redirect to indirection-id Community . . . . . . . . . . . . 6 | |||
5. Redirect using localised indirection-id mapping table . . . . 8 | 5. Redirect using localised indirection-id mapping table . . . . 8 | |||
6. Validation Procedures . . . . . . . . . . . . . . . . . . . . 8 | 6. Validation Procedures . . . . . . . . . . . . . . . . . . . . 8 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | |||
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 | 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 | |||
9. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 9 | 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . 11 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 | |||
11.2. Informative References . . . . . . . . . . . . . . . . . 11 | 11.2. Informative References . . . . . . . . . . . . . . . . . 11 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
1. Introduction | 1. Introduction | |||
Flowspec is an extension to BGP that allows for the dissemination of | Flowspec is an extension to BGP that allows for the dissemination of | |||
traffic flow specification rules. This has many possible | traffic flow specification rules. This has many possible | |||
skipping to change at page 8, line 38 ¶ | skipping to change at page 8, line 38 ¶ | |||
When a BGP flowspec client receives a flowspec policy route with a | When a BGP flowspec client receives a flowspec policy route with a | |||
"Redirect to indirection-id" extended community attached, and the | "Redirect to indirection-id" extended community attached, and the | |||
route represents the best BGP path, it will install a flowspec | route represents the best BGP path, it will install a flowspec | |||
policy-based forwarding rule matching the tupples described by the | policy-based forwarding rule matching the tupples described by the | |||
flowpsec NLRI field and consequently redirects the flow (C=0) or | flowpsec NLRI field and consequently redirects the flow (C=0) or | |||
copies the flow (C=1) using the information identified by the | copies the flow (C=1) using the information identified by the | |||
"Redirect to indirection-id" community. | "Redirect to indirection-id" community. | |||
6. Validation Procedures | 6. Validation Procedures | |||
The validation check described in rfc5575bis [3] and revised in [2] | The validation check described in rfc5575bis [3] SHOULD be applied by | |||
SHOULD be applied by default by a flowspec client, for received | default by a flowspec client, for received flowspec policy routes | |||
flowspec policy routes containing a "Redirect to indirection-id" | containing a "Redirect to indirection-id" extended community. This | |||
extended community. This results that a flowspec route with a | results that a flowspec route with a destination prefix subcomponent | |||
destination prefix subcomponent SHOULD NOT be accepted from an EBGP | SHOULD NOT be accepted from an EBGP peer unless that peer also | |||
peer unless that peer also advertised the best path for the matching | advertised the best path for the matching unicast route. | |||
unicast route. | ||||
While it MUST NOT happen, and is seen as invalid combination, it is | While it MUST NOT happen, and is seen as invalid combination, it is | |||
possible from a semantics perspective to have multiple clashing | possible from a semantics perspective to have multiple clashing | |||
redirect actions defined within a single flowspec rule. For best and | redirect actions defined within a single flowspec rule. For best and | |||
consistant compatibility with legacy implementations, the redirect | consistant compatibility with legacy implementations, the redirect | |||
functionality as documented by rfc5575bis MUST NOT be broken, and | functionality as documented by rfc5575bis MUST NOT be broken, and | |||
hence when a clash occurs, then rfc5575bis based redirect MUST take | hence when a clash occurs, then rfc5575bis based redirect MUST take | |||
priority. Additionally, if the "Redirect to indirection-id" does not | priority. Additionally, if the "Redirect to indirection-id" does not | |||
result in a valid redirection, then the flowspec rule MUST be | result in a valid redirection, then the flowspec rule MUST be | |||
processed as if the "Redirect to indirection-id" community was not | processed as if the "Redirect to indirection-id" community was not | |||
skipping to change at page 9, line 23 ¶ | skipping to change at page 9, line 22 ¶ | |||
A system using "Redirect to indirection-id" extended community can | A system using "Redirect to indirection-id" extended community can | |||
cause during the redirect mitigation of a DDoS attack overflow of | cause during the redirect mitigation of a DDoS attack overflow of | |||
traffic received by the mitigation infrastructure. | traffic received by the mitigation infrastructure. | |||
8. Acknowledgements | 8. Acknowledgements | |||
This document received valuable comments and input from IDR working | This document received valuable comments and input from IDR working | |||
group including Adam Simpson, Mustapha Aissaoui, Jan Mertens, Robert | group including Adam Simpson, Mustapha Aissaoui, Jan Mertens, Robert | |||
Raszuk, Jeff Haas, Susan Hares and Lucy Yong. | Raszuk, Jeff Haas, Susan Hares and Lucy Yong. | |||
9. Contributor Addresses | 9. Contributors | |||
Below is a list of other contributing authors in alphabetical order: | The following people contributed to the content of this document and | |||
should be considered as co-authors: | ||||
Arjun Sreekantiah | Arjun Sreekantiah | |||
Cisco Systems | ||||
170 W. Tasman Drive | ||||
San Jose, CA 95134 | ||||
USA | USA | |||
Email: asreekan@cisco.com | Email: arjunhrs@gmail.com | |||
Nan Wu | Nan Wu | |||
Huawei Technologies | Huawei Technologies | |||
Huawei Bld., No. 156 Beiquing Rd | Huawei Bld., No. 156 Beiquing Rd | |||
Beijing 100095 | Beijing 100095 | |||
China | China | |||
Email: eric.wu@huawei.com | Email: eric.wu@huawei.com | |||
Shunwan Zhuang | Shunwan Zhuang | |||
End of changes. 10 change blocks. | ||||
18 lines changed or deleted | 15 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/ |