draft-ietf-bfd-seamless-use-case-06.txt | draft-ietf-bfd-seamless-use-case-07.txt | |||
---|---|---|---|---|
Network Working Group S. Aldrin | Network Working Group S. Aldrin | |||
Internet-Draft Google, Inc | Internet-Draft Google, Inc | |||
Intended status: Informational C. Pignataro | Intended status: Informational C. Pignataro | |||
Expires: October 24, 2016 Cisco | Expires: November 5, 2016 Cisco | |||
G. Mirsky | G. Mirsky | |||
Ericsson | Ericsson | |||
N. Kumar | N. Kumar | |||
Cisco | Cisco | |||
April 22, 2016 | May 4, 2016 | |||
Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases | Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases | |||
draft-ietf-bfd-seamless-use-case-06 | draft-ietf-bfd-seamless-use-case-07 | |||
Abstract | Abstract | |||
This document describes various use cases for a Seamless | This document describes various use cases for a Seamless | |||
Bidirectional Forwarding Detection (S-BFD), and provides requirements | Bidirectional Forwarding Detection (S-BFD), and provides requirements | |||
such that protocol mechanisms allow for a simplified detection of | such that protocol mechanisms allow for a simplified detection of | |||
forwarding failures. | forwarding failures. | |||
These use cases support S-BFD, as a simplified mechanism to use | These use cases support S-BFD, as a simplified mechanism to use | |||
Bidirectional Forwarding Detection (BFD) with large portions of | Bidirectional Forwarding Detection (BFD) with large portions of | |||
skipping to change at page 1, line 45 ¶ | skipping to change at page 1, line 45 ¶ | |||
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 October 24, 2016. | This Internet-Draft will expire on November 5, 2016. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2016 IETF Trust and the persons identified as the | Copyright (c) 2016 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 9, line 37 ¶ | skipping to change at page 9, line 37 ¶ | |||
through the network, if Equal-Cost Multipath (ECMP) is used. In | through the network, if Equal-Cost Multipath (ECMP) is used. In | |||
addition, the longer it takes from BFD session failure to starting | addition, the longer it takes from BFD session failure to starting | |||
fault isolation, the more likely that the fault will not be able to | fault isolation, the more likely that the fault will not be able to | |||
be isolated (e.g., a fault can get corrected or routed around). If | be isolated (e.g., a fault can get corrected or routed around). If | |||
BFD had built-in fault isolation capability, fault isolation can get | BFD had built-in fault isolation capability, fault isolation can get | |||
triggered at the earliest sign of fault detection. This embedded | triggered at the earliest sign of fault detection. This embedded | |||
fault isolation will be more effective when those BFD fault isolation | fault isolation will be more effective when those BFD fault isolation | |||
packets are load balanced in the same way as the BFD packets that | packets are load balanced in the same way as the BFD packets that | |||
were dropped, detecting the fault. | were dropped, detecting the fault. | |||
This use case describes S-BFD fault isolation capabilities using | This use case describes S-BFD fault isolation capabilities, utilizing | |||
status indicating fields. | a TTL field (e.g., as in Section 5.1.1 of [I-D.ietf-bfd-seamless-ip]) | |||
or using status indicating fields. | ||||
3.8. Multiple BFD Sessions to the Same Target Node | 3.8. Multiple BFD Sessions to the Same Target Node | |||
BFD is capable of providing very fast failure detection, as relevant | BFD is capable of providing very fast failure detection, as relevant | |||
network nodes continuously transmit BFD packets at the negotiated | network nodes continuously transmit BFD packets at the negotiated | |||
rate. If BFD packet transmission is interrupted, even for a very | rate. If BFD packet transmission is interrupted, even for a very | |||
short period of time, BFD can declare a failure irrespective of path | short period of time, BFD can declare a failure irrespective of path | |||
liveliness. It is possible, on a system where BFD is running, for | liveliness. It is possible, on a system where BFD is running, for | |||
certain events (intentionally or unintentionally) to cause a short | certain events (intentionally or unintentionally) to cause a short | |||
interruption of BFD packet transmissions. With distributed | interruption of BFD packet transmissions. With distributed | |||
skipping to change at page 12, line 10 ¶ | skipping to change at page 12, line 10 ¶ | |||
REQ#10: S-BFD MUST incorporate robust security protections against | REQ#10: S-BFD MUST incorporate robust security protections against | |||
impersonators, malicions actors, and various attacks. The | impersonators, malicions actors, and various attacks. The | |||
simple and accelerated establishment of an S-BFD session | simple and accelerated establishment of an S-BFD session | |||
should not negatively affect security. | should not negatively affect security. | |||
5. Security Considerations | 5. Security Considerations | |||
This document details the use cases and identifies various associated | This document details the use cases and identifies various associated | |||
requirements. Some of these requirements are security related. The | requirements. Some of these requirements are security related. The | |||
use cases herein described do not expose a system to abuse or to | use cases herein described do not expose a system to abuse or to | |||
additional security risks. The proposed new protocols, extensions, | additional security risks. Since some negotiation aspects are | |||
and enhancements for a Seamless BFD supporting these use cases and | eliminated, a misconfiguration can result in S-BFD packets being sent | |||
realizing these requirements will address the associated security | to an incorrect node. If this receiving node runs S-BFD, the packet | |||
considerations. A Seamless BFD should not have reduced security | will be discarted because of the discriminator mismatch. If the node | |||
capabilities as compared to traditional BFD. | does not run S-BFD, the packet will be naturally discarded. | |||
The proposed new protocols, extensions, and enhancements for a | ||||
Seamless BFD supporting these use cases and realizing these | ||||
requirements will address the associated security considerations. A | ||||
Seamless BFD should not have reduced security capabilities as | ||||
compared to traditional BFD. | ||||
6. IANA Considerations | 6. IANA Considerations | |||
There are no IANA considerations introduced by this document. | There are no IANA considerations introduced by this document. | |||
7. Acknowledgements | 7. Acknowledgements | |||
The authors would like to thank Tobias Gondrom and Eric Gray, for | The authors would like to thank Tobias Gondrom and Eric Gray, for | |||
their insightful and useful comments. The authors appreciate the | their insightful and useful comments. The authors appreciate the | |||
thorough review and comments provided by Dale R. Worley. | thorough review and comments provided by Dale R. Worley. | |||
skipping to change at page 13, line 41 ¶ | skipping to change at page 13, line 45 ¶ | |||
progress), April 2016. | progress), April 2016. | |||
[I-D.ietf-bfd-seamless-ip] | [I-D.ietf-bfd-seamless-ip] | |||
Akiya, N., Pignataro, C., and D. Ward, "Seamless | Akiya, N., Pignataro, C., and D. Ward, "Seamless | |||
Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6 | Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6 | |||
and MPLS", draft-ietf-bfd-seamless-ip-04 (work in | and MPLS", draft-ietf-bfd-seamless-ip-04 (work in | |||
progress), April 2016. | progress), April 2016. | |||
[I-D.ietf-spring-oam-usecase] | [I-D.ietf-spring-oam-usecase] | |||
Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "A | Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "A | |||
scalable and topology aware MPLS data plane monitoring | Scalable and Topology-Aware MPLS Dataplane Monitoring | |||
system", draft-ietf-spring-oam-usecase-02 (work in | System", draft-ietf-spring-oam-usecase-03 (work in | |||
progress), April 2016. | progress), April 2016. | |||
[I-D.ietf-spring-segment-routing] | [I-D.ietf-spring-segment-routing] | |||
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., | Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., | |||
and R. Shakir, "Segment Routing Architecture", draft-ietf- | and R. Shakir, "Segment Routing Architecture", draft-ietf- | |||
spring-segment-routing-07 (work in progress), December | spring-segment-routing-07 (work in progress), December | |||
2015. | 2015. | |||
[I-D.ietf-spring-sr-oam-requirement] | [I-D.ietf-spring-sr-oam-requirement] | |||
Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G., | Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G., | |||
End of changes. 7 change blocks. | ||||
13 lines changed or deleted | 20 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/ |