--- 1/draft-ietf-bfd-seamless-use-case-05.txt 2016-04-22 14:16:28.412657514 -0700 +++ 2/draft-ietf-bfd-seamless-use-case-06.txt 2016-04-22 14:16:28.444658312 -0700 @@ -1,23 +1,23 @@ Network Working Group S. Aldrin Internet-Draft Google, Inc Intended status: Informational C. Pignataro -Expires: October 17, 2016 Cisco +Expires: October 24, 2016 Cisco G. Mirsky Ericsson N. Kumar Cisco - April 15, 2016 + April 22, 2016 Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases - draft-ietf-bfd-seamless-use-case-05 + draft-ietf-bfd-seamless-use-case-06 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 17, 2016. + This Internet-Draft will expire on October 24, 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 @@ -226,38 +226,41 @@ Additionally, there are operational implications to the unidirectional path validation. If the traditional BFD is to be used, the target network entity has to be provisioned as well as an initiator, even though the reverse path validation with the BFD session is not required. However, in the case of unidirectional BFD, there is no need for provisioning on the target network entity, only the source one. In this use case, a BFD session could be established in a single - direction. When the targeted network entity receives the packet, the - Your Discriminator value in the packet instructs the network entity - to process it, and send a response based on the source address of the - packet. This does not necessitate the requirement for establishment - of a bi-directional session, hence the two way handshake to exchange - discriminators is not needed. The target node does not need to know - the My Discriminator of the source node. + direction. When the targeted network entity receives the packet, it + identities the packet as BFD in an application-specific manner (for + example, a destination UDP port number). Subsequently, the BFD + module processes the packet, using the Your Discriminator value as + context. Then, the network entity sends a response to the + originator. This does not necessitate the requirement for + establishment of a bi-directional session, hence the two way + handshake to exchange discriminators is not needed. The target node + does not need to know the My Discriminator of the source node. Thus, a requirement for BFD for this use case is to enable session establishment from source network entity to target network entity without the need to have a session (and state) for the reverse direction. Further, another requirement is that the BFD response from target back to sender can take any (in-band or out-of-band) - path. The target network entity (for the BFD session), upon receipt - of BFD packet, starts processing the BFD packet based on the - discriminator received. The source network entity can therefore - establish a unidirectional BFD session without the bidirectional - handshake of discriminators for session establishment. + path. The BFD module in the target network entity (for the BFD + session), upon receipt of BFD packet, starts processing the BFD + packet based on the discriminator received. The source network + entity can therefore establish a unidirectional BFD session without + the bidirectional handshake and exchange of discriminators for + session establishment. 3.2. Validation of the Forwarding Path Prior to Switching Traffic This use case is when BFD is used to verify reachability before sending traffic via a path/LSP. This comes with a cost, which is that traffic is prevented to use the path/LSP until BFD is able to validate the reachability, which could take seconds due to BFD session bring-up sequences [RFC5880], LSP ping bootstrapping [RFC5884], etc. This use case would be better supported by eliminating the need for the initial BFD session negotiation.