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