--- 1/draft-ietf-bfd-seamless-use-case-06.txt 2016-05-04 13:15:57.227031368 -0700 +++ 2/draft-ietf-bfd-seamless-use-case-07.txt 2016-05-04 13:15:57.263032278 -0700 @@ -1,23 +1,23 @@ Network Working Group S. Aldrin Internet-Draft Google, Inc Intended status: Informational C. Pignataro -Expires: October 24, 2016 Cisco +Expires: November 5, 2016 Cisco G. Mirsky Ericsson N. Kumar Cisco - April 22, 2016 + May 4, 2016 Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases - draft-ietf-bfd-seamless-use-case-06 + draft-ietf-bfd-seamless-use-case-07 Abstract This document describes various use cases for a Seamless Bidirectional Forwarding Detection (S-BFD), and provides requirements such that protocol mechanisms allow for a simplified detection of forwarding failures. These use cases support S-BFD, as a simplified mechanism to use Bidirectional Forwarding Detection (BFD) with large portions of @@ -34,21 +34,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -400,22 +400,23 @@ through the network, if Equal-Cost Multipath (ECMP) is used. In addition, the longer it takes from BFD session failure to starting 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 BFD had built-in fault isolation capability, fault isolation can get triggered at the earliest sign of fault detection. This embedded fault isolation will be more effective when those BFD fault isolation packets are load balanced in the same way as the BFD packets that were dropped, detecting the fault. - This use case describes S-BFD fault isolation capabilities using - status indicating fields. + This use case describes S-BFD fault isolation capabilities, utilizing + 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 BFD is capable of providing very fast failure detection, as relevant network nodes continuously transmit BFD packets at the negotiated rate. If BFD packet transmission is interrupted, even for a very short period of time, BFD can declare a failure irrespective of path liveliness. It is possible, on a system where BFD is running, for certain events (intentionally or unintentionally) to cause a short interruption of BFD packet transmissions. With distributed @@ -512,25 +513,31 @@ REQ#10: S-BFD MUST incorporate robust security protections against impersonators, malicions actors, and various attacks. The simple and accelerated establishment of an S-BFD session should not negatively affect security. 5. Security Considerations This document details the use cases and identifies various associated requirements. Some of these requirements are security related. The use cases herein described do not expose a system to abuse or to - additional security risks. 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. + additional security risks. Since some negotiation aspects are + eliminated, a misconfiguration can result in S-BFD packets being sent + to an incorrect node. If this receiving node runs S-BFD, the packet + will be discarted because of the discriminator mismatch. If the node + 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 There are no IANA considerations introduced by this document. 7. Acknowledgements The authors would like to thank Tobias Gondrom and Eric Gray, for their insightful and useful comments. The authors appreciate the thorough review and comments provided by Dale R. Worley. @@ -588,22 +595,22 @@ progress), April 2016. [I-D.ietf-bfd-seamless-ip] Akiya, N., Pignataro, C., and D. Ward, "Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6 and MPLS", draft-ietf-bfd-seamless-ip-04 (work in progress), April 2016. [I-D.ietf-spring-oam-usecase] Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "A - scalable and topology aware MPLS data plane monitoring - system", draft-ietf-spring-oam-usecase-02 (work in + Scalable and Topology-Aware MPLS Dataplane Monitoring + System", draft-ietf-spring-oam-usecase-03 (work in progress), April 2016. [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf- spring-segment-routing-07 (work in progress), December 2015. [I-D.ietf-spring-sr-oam-requirement] Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G.,