draft-ietf-bfd-seamless-use-case-04.txt   draft-ietf-bfd-seamless-use-case-05.txt 
Network Working Group S. Aldrin Network Working Group S. Aldrin
Internet-Draft Google, Inc Internet-Draft Google, Inc
Intended status: Informational M. Bhatia Intended status: Informational C. Pignataro
Expires: September 22, 2016 Ionos Networks Expires: October 17, 2016 Cisco
S. Matsushima
Softbank
G. Mirsky G. Mirsky
Ericsson Ericsson
N. Kumar N. Kumar
Cisco Cisco
March 21, 2016 April 15, 2016
Seamless Bidirectional Forwarding Detection (BFD) Use Case Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases
draft-ietf-bfd-seamless-use-case-04 draft-ietf-bfd-seamless-use-case-05
Abstract Abstract
This document provides various use cases for Bidirectional Forwarding This document describes various use cases for a Seamless
Detection (BFD) and various requirements such that extensions could Bidirectional Forwarding Detection (S-BFD), and provides requirements
be developed to allow for simplified detection of forwarding such that protocol mechanisms allow for a simplified detection of
failures. forwarding failures.
These use cases support S-BFD, as a simplified mechanism to use
Bidirectional Forwarding Detection (BFD) with large portions of
negotiation aspects eliminated, accelerating the establishment of a
BFD session. S-BFD benefits include quick provisioning as well as
improved control and flexibility to network nodes initiating the path
monitoring.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 September 22, 2016. This Internet-Draft will expire on October 17, 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 2, line 16 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Introduction to Seamless BFD . . . . . . . . . . . . . . . . 3 2. Introduction to Seamless BFD . . . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Unidirectional Forwarding Path Validation . . . . . . . . 4 3.1. Unidirectional Forwarding Path Validation . . . . . . . . 5
3.2. Validation of forwarding path prior to traffic switching 5 3.2. Validation of the Forwarding Path Prior to Switching
3.3. Centralized Traffic Engineering . . . . . . . . . . . . . 6 Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. BFD in Centralized Segment Routing . . . . . . . . . . . 6 3.3. Centralized Traffic Engineering . . . . . . . . . . . . . 7
3.5. Efficient BFD Operation Under Resource Constraints . . . 7 3.4. BFD in Centralized Segment Routing . . . . . . . . . . . 8
3.6. BFD for Anycast Address . . . . . . . . . . . . . . . . . 7 3.5. Efficient BFD Operation under Resource Constraints . . . 8
3.7. BFD Fault Isolation . . . . . . . . . . . . . . . . . . . 7 3.6. BFD for Anycast Addresses . . . . . . . . . . . . . . . . 8
3.8. Multiple BFD Sessions to Same Target . . . . . . . . . . 8 3.7. BFD Fault Isolation . . . . . . . . . . . . . . . . . . . 9
3.9. MPLS BFD Session Per ECMP Path . . . . . . . . . . . . . 8 3.8. Multiple BFD Sessions to the Same Target Node . . . . . . 9
4. Detailed Requirements . . . . . . . . . . . . . . . . . . . . 9 3.9. An MPLS BFD Session Per ECMP Path . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4. Detailed Requirements for a Seamless BFD . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
Bidirectional Forwarding Detection (BFD) is a lightweight protocol, Bidirectional Forwarding Detection (BFD) is a lightweight protocol,
as defined in [RFC5880], used to detect forwarding failures. Various as defined in [RFC5880], used to detect forwarding failures. Various
protocols and applications rely on BFD for failure detection. Even protocols and applications rely on BFD as its clients for failure
though the protocol is simple, there are certain use cases, where detection. Even though the protocol is lightweight and simple, there
faster setting up of sessions and continuity check of the data are certain use cases where faster setting up of sessions and faster
forwarding paths is necessary. This document identifies various use continuity check of the data forwarding paths is necessary. This
cases and requirements related to those, such that necessary document identifies these use cases and consequent requirements, such
enhancements could be made to BFD protocol. that enhancements and extensions result in a Seamless BFD (S-BFD)
protocol.
BFD is a simple lightweight "Hello" protocol to detect data plane BFD is a simple lightweight "Hello" protocol to detect data plane
failures. With dynamic provisioning of forwarding paths on a large failures. With dynamic provisioning of forwarding paths on a large
scale, establishing BFD sessions for each of those paths creates scale, establishing BFD sessions for each of those paths not only
complexity, not only from an operations point of view, but also in creates operational complexity, but also causes undesirable delay in
terms of the speed at which these sessions could be established or establishing or deleting sessions. The existing session
deleted. The existing session establishment mechanism of the BFD establishment mechanism of the BFD protocol has to be enhanced in
protocol has to be enhanced in order to minimize the time for the order to minimize the time for the session to come up to validate the
session to come up to validate the forwarding path. forwarding path.
This document specifically identifies various use cases and This document specifically identifies various use cases and
corresponding requirements in order to enhance BFD and other corresponding requirements in order to enhance BFD and other
supporting protocols. While the identified requirements could meet supporting protocols. Specifically, one key goal is removing the
various use cases , it is outside the scope of this document to time delay (i.e., the "seam") between a network node wants to perform
identify all of the possible and necessary requirements. Solutions a continuity test and the node completes that continuity test.
to the identified uses cases and protocol specific enhancements or Consequently, "Seamless BFD" (S-BFD) has been chosen as the name for
proposals are outside the scope of this document as well. this mechanism.
While the identified requirements could meet various use cases, it is
outside the scope of this document to identify all of the possible
and necessary requirements. Solutions to the identified uses cases
and protocol specific enhancements or proposals are outside the scope
of this document as well. Protocol definitions to support these use
cases can be found at [I-D.ietf-bfd-seamless-base] and
[I-D.ietf-bfd-seamless-ip].
1.1. Terminology 1.1. Terminology
The reader is expected to be familiar with the BFD, IP, MPLS and The reader is expected to be familiar with the BFD [RFC5880], IP
Segment Routing (SR) [I-D.ietf-spring-segment-routing] terminology [RFC0791] [RFC2460], MPLS [RFC3031], and Segment Routing (SR)
and protocol constructs. This section identifies only the new [I-D.ietf-spring-segment-routing] terminologies and protocol
terminology introduced. constructs.
1.2. Requirements Language 1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
2. Introduction to Seamless BFD 2. Introduction to Seamless BFD
BFD, as defined in [RFC5880], requires two network nodes, to exchange BFD, as defined in [RFC5880], requires two network nodes to exchange
locally allocated discriminators. The discriminator enables locally allocated discriminators. These discriminators enable the
identification of the sender and receiver of BFD packets of the identification of the sender and the receiver of BFD packets over the
particular session and perform proactive continuity monitoring of the particular session. Subsequently, BFD performs proactive continuity
forwarding path between the two. [RFC5881] defines single hop BFD monitoring of the forwarding path between the two. Several
whereas [RFC5883] defines multi-hop BFD, [RFC5884] BFD for MPLS specifications describe BFD's multiple deployment uses:
LSPs, and [RFC5885] - BFD for PWs.
Currently, BFD is best suited to verify that two end points are [RFC5881] defines BFD over IPv4 and IPv6 for single IP hops
reachable or that an existing connection continues to be up and
alive. In order for BFD to be able to initially verify that a [RFC5883] defines BFD over multihop paths
connection is valid and that it connects the expected set of end
points, it is necessary to provide the node information associated [RFC5884] defines BFD for MPLS Label Switched Paths (LSPs)
with the connection at each end point prior to initiating BFD
sessions, such that this information can be used to verify that the [RFC5885] defines BFD for MPLS Pseudowires (PWs)
connection is up and verifiable.
Currently, BFD is best suited to verify that two endpoints are
mutually reachable or that an existing connection continues to be up
and alive. In order for BFD to be able to initially verify that a
connection is valid and that it connects the expected set of
endpoints, it is necessary to provide each endpoint with the
discriminators associated with the connection at each endpoint prior
to initiating BFD sessions. The discriminators are used to verify
that the connection is up and verifiable. Currently, the exchange of
discriminators and the demultiplexing of the initial BFD packets is
application dependent.
If this information is already known to the end-points of a potential If this information is already known to the end-points of a potential
BFD session, the initial handshake including an exchange of this BFD session, the initial handshake including an exchange of
node-specific information is unnecessary and it is possible for the discriminators is unnecessary and it is possible for the endpoints to
end points to begin BFD messaging seamlessly. In fact, the initial begin BFD messaging seamlessly. A key objective of the S-BFD use
exchange of discriminator information is an unnecessary extra step cases described in this document is to avoid needing to exchange the
that may be avoided for these cases. initial packets before the BFD session can be established, with the
goal of getting to the established state more quickly; in other
words, the initial exchange of discriminator information is an
unnecessary extra step that may be avoided for these cases.
In a given scenario, where an entity (such as an operator, or In a given scenario, an entity (such as an operator, or a centralized
centralized controller) determines a set of network entities to which controller) determines a set of network entities to which BFD
BFD sessions might need to be established. Each of those network sessions might need to be established. In traditional BFD, each of
entities is assigned a BFD discriminator, to establish a BFD session. those network entities chooses a BFD discriminator for each BFD
These network entities will create a BFD session instance that session that the entity will participate in (see Section 6.3 of
listens for incoming BFD control packets. Mappings between selected [RFC5880]). However, a key goal of a Seamless BFD is to provide
network entities and corresponding BFD discriminators are known to operational simplification. In this context, for S-BFD, each of
other network nodes belonging in the same network by some means. A those network entities is assigned one or more BFD discriminators,
network entity in this network is then able to send a BFD control and allowing those network entities to use one discriminator value
packet to a particular target with the corresponding BFD for multiple sessions. Therefore, there may be only one or a few
discriminator. Target network node, upon reception of such BFD discriminators assigned to a node. These network entities will
control packet, will transmit a response BFD control packet back to create an S-BFD listener session instance that listens for incoming
the sender. BFD control packets. When the mappings between specific network
entities and their corresponding BFD discriminators are known to
other network nodes belonging to the same administrative domain,
then, without having received any BFD packet from a particular
target, a network entity in this network is able to send a BFD
control packet to the target's assigned discriminator in the Your
Discriminator field. The target network node, upon reception of such
BFD control packet, will transmit a response BFD control packet back
to the sender.
3. Use Cases 3. Use Cases
As per the BFD protocol [RFC5880], BFD sessions are established using As per the BFD protocol [RFC5880], BFD sessions are established using
handshake mechanism prior to validating the forwarding path. This handshake mechanism prior to validating the forwarding path. This
section outlines some use cases where the existing mechanism may not section outlines some use cases where the existing mechanism may not
be able to satisfy the requirements identified. In addition, some of be able to satisfy the requirements identified. In addition, some of
the use cases also stress the need for expedited BFD session the use cases also stress the need for expedited BFD session
establishment while preserving benefits of forwarding failure establishment while preserving benefits of forwarding failure
detection using existing BFD specifications. detection using existing BFD mechanics. Both these high-level goals
result in the S-BFD use cases.
3.1. Unidirectional Forwarding Path Validation 3.1. Unidirectional Forwarding Path Validation
Even though bidirectional verification of forwarding path is useful, Even though bidirectional verification of forwarding path is useful,
there are scenarios where verification is only required in one there are scenarios where verification is only required in one
direction between a pair of nodes. One such case is, when a static direction between a pair of nodes. One such case is, when a static
route uses BFD to validate reachability to the next-hop IP router. route uses BFD to validate reachability to the next-hop IP router.
In this case, the static route is established from one network entity In this case, the static route is established from one network entity
to another. The requirement in this case is only to validate the to another. The requirement in this case is only to validate the
forwarding path for that statically established path. Validation of forwarding path for that statically established unidirectional path.
the forwarding path in the direction of the target entity to the Validation of the forwarding path in the direction of the target
originating entity is not required, in this scenario. Many LSPs have entity to the originating entity is not required, in this scenario.
the same unidirectional characteristics and unidirectional validation Many LSPs have the same unidirectional characteristics and
requirements. Such LSPs are common in Segment Routing and LDP based unidirectional validation requirements. Such LSPs are common in
networks. Another example is when a unidirectional tunnel uses BFD Segment Routing and LDP based MPLS networks. A final example is when
to validate reachability of an egress node. a unidirectional tunnel uses BFD to validate reachability of an
egress node.
If the traditional BFD is to be used, the target network entity has Additionally, there are operational implications to the
to be provisioned as well, even though the reverse path validation unidirectional path validation. If the traditional BFD is to be
with BFD session is not required. However, in the case of used, the target network entity has to be provisioned as well as an
unidirectional BFD, there is no need for provisioning on the target initiator, even though the reverse path validation with the BFD
network entity . Once the mechanism within the BFD protocol is in session is not required. However, in the case of unidirectional BFD,
place, session could be established in a single direction. When the there is no need for provisioning on the target network entity, only
targeted network entity receives the packet, it knows that BFD the source one.
packet, based on the discriminator and processes it. This does not
necessitates the requirement for establishment of a bi-directional
session, hence the two way handshake to exchange discriminators is
not needed.
Thus the requirement for BFD for this use case is to enable session 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.
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 in the reverse direction. This without the need to have a session (and state) for the reverse
requires to ensure that the target network entity (for the BFD direction. Further, another requirement is that the BFD response
session), upon receipt of BFD packet, MUST start processing for the from target back to sender can take any (in-band or out-of-band)
discriminator received in the BFD packet. The source network entity path. The target network entity (for the BFD session), upon receipt
MUST be able to establish a unidirectional BFD session without the of BFD packet, starts processing the BFD packet based on the
bidirectional handshake of discriminators for session establishment. discriminator received. The source network entity can therefore
establish a unidirectional BFD session without the bidirectional
handshake of discriminators for session establishment.
3.2. Validation of forwarding path prior to traffic switching 3.2. Validation of the Forwarding Path Prior to Switching Traffic
BFD provides data delivery confidence when reachability validation is This use case is when BFD is used to verify reachability before
performed prior to traffic utilizing specific paths/LSPs. However sending traffic via a path/LSP. This comes with a cost, which is
this comes with a cost, where, traffic is prevented to use such that traffic is prevented to use the path/LSP until BFD is able to
paths/LSPs until BFD is able to validate the reachability, which validate the reachability, which could take seconds due to BFD
could take seconds due to BFD session bring-up sequences [RFC5880], session bring-up sequences [RFC5880], LSP ping bootstrapping
LSP ping bootstrapping [RFC5884], etc. This use case could be well [RFC5884], etc. This use case would be better supported by
supported by eliminating the need for session negotiation and eliminating the need for the initial BFD session negotiation.
discriminator exchanges in order to establish the BFD session.
All it takes is for the network entities to know what the All it takes to be able to send BFD packets to a target, and the
discriminator values to be used for the session. The same is the target properly demultiplexing these, is for the source network
case for S-BFD, i.e., the three-way handshake mechanism is eliminated entities to know what the discriminator values to be used for the
during bootstrap of BFD sessions. However, this information is session. The same is the case for S-BFD: the three-way handshake
required at each entity to verify that BFD messages are being mechanism is eliminated during the bootstrap of BFD sessions.
received from the expected end-points, hence the handshake mechanism However, this information is required at each entity to verify that
serves no purpose. Elimination of the unnecessary handshake BFD messages are being received from the expected end-points, hence
mechanism allows for faster reachability validation of BFD the handshake mechanism serves no purpose. Elimination of the
provisioned paths/LSPs. unnecessary handshake mechanism allows for faster reachability
validation of BFD provisioned paths/LSPs.
In addition, it is expected that some MPLS technologies will require In addition, it is expected that some MPLS technologies will require
traffic engineered LSPs to be created dynamically, perhaps driven by traffic engineered LSPs to be created dynamically, perhaps driven by
external applications, e.g. in Software Defined Networks (SDN). It external applications, as e.g. in Software Defined Networks (SDN).
will be desirable to perform BFD validation as soon as the LSP?s are It will be desirable to perform BFD validation as soon as the LSPs
created, in order to use them. are created, so as to use them.
In order to support this use case, the BFD session MUST be able to be In order to support this use case, an S-BFD session is established
established without the need for session negotiation and exchange of without the need for session negotiation and exchange of
discriminators. discriminators.
3.3. Centralized Traffic Engineering 3.3. Centralized Traffic Engineering
Various technologies in the SDN domain that involve controller based Various technologies in the SDN domain that involve controller-based
networks have evolved where intelligence, traditionally placed in a networks have evolved such that the intelligence, traditionally
distributed and dynamic control plane, is separated from the placed in a distributed and dynamic control plane, is separated from
networking entities along the data path, instead resides in a the networking entities themselves; instead, it resides in a
logically centralized place. There are various controllers that (logically) centralized place. There are various controllers that
perform this exact function in establishment of forwarding paths for perform the function in establishment of forwarding paths for the
the data flow. Traffic engineering is one important function, where data flow. Traffic engineering (TE) is one important function, where
the traffic flow is engineered, depending upon various attributes and the path of the traffic flow is engineered, depending upon various
constraints of the traffic paths as well as the network state. attributes and constraints of the traffic paths as well as the
network state.
When the intelligence of the network resides in a centralized entity, When the intelligence of the network resides in a centralized entity,
ability to manage and maintain the dynamic network becomes a the ability to manage and maintain the dynamic network and its
challenge. One way to ensure the forwarding paths are valid, and multiple data paths and node reachability becomes a challenge. One
working, is done by validation of the network using BFD. When way to ensure the forwarding paths are valid and working is done by
traffic engineered tunnels are created, it is operationally critical validation using BFD. When traffic engineered tunnels are created,
to ensure that the forwarding paths are working, prior to switching it is operationally critical to ensure that the forwarding paths are
the traffic onto the engineered tunnels. In the absence of control working, prior to switching the traffic onto the engineered tunnels.
plane protocols, it may be desirable to verify, not only the In the absence of distributed control plane protocols, it may be
forwarding path but also of any arbitrary path in the network. With desirable to verify any arbitrary forwarding path in the network.
tunnels being engineered by a centralized entity, when the network With tunnels being engineered by a centralized entity, when the
state changes, traffic has to be switched with minimum latency and network state changes, traffic has to be switched with minimum
without black holing of the data. latency and without black-holing of the data.
Traditional BFD session establishment and validation of the It is highly desirable in this centralized traffic engineering use
forwarding path must not become a bottleneck in the case of case that the traditional BFD session establishment and validation of
centralized traffic engineering. If the controller or other the forwarding path does not become a bottleneck. If the controller
centralized entity is able to instantly verify a forwarding path of or other centralized entity is able to very rapidly verify the
the TE tunnel , it could steer the traffic onto the traffic forwarding path of a traffic engineered tunnel, it could steer the
engineered tunnel very quickly thus minimizing adverse effect on a traffic onto the traffic engineered tunnel very quickly thus
service. This is especially useful and needed when the scale of the minimizing adverse effect on a service. This is even more useful and
network and number of TE tunnels is very high. necessary when the scale of the network and number of traffic
engineered tunnels grows.
The cost associated with BFD session negotiation and establishment of The cost associated with the time required for BFD session
BFD sessions to identify valid paths is very high and providing negotiation and establishment of BFD sessions to identify valid paths
network redundancy becomes a critical issue. is very high when providing network redundancy is a critical issue.
3.4. BFD in Centralized Segment Routing 3.4. BFD in Centralized Segment Routing
A monitoring technique of a Segment Routing network based on a A monitoring technique of a Segment Routing network based on a
centralized controller is described in [I-D.ietf-spring-oam-usecase]. centralized controller is described in [I-D.ietf-spring-oam-usecase].
Various OAM requirements for Segment Routing were captured in Specific OAM requirements for Segment Routing are captured in
[I-D.ietf-spring-sr-oam-requirement]. In validating this use case, [I-D.ietf-spring-sr-oam-requirement]. In validating this use case,
one of the requirements is to ensure the BFD packet's behavior is one of the requirements is to ensure that the BFD packet's behavior
according to the requirement and monitoring of the segment, where the is according to the monitoring specified for the segment, and that
packet is U-turned at the expected node. One of the criterion is to the packet is U-turned at the expected node. This criteria ensures
ensure the continuity check to the adjacent segment-id. the continuity check to the adjacent segment-id.
To support this use case, BFD MUST be able to perform liveness To support this use case, the operational requirement is for BFD,
detection initated from centralized controller for any given segment initiated from a centralized controller, to perform liveness
under its domain. detection for any given segment under its domain.
3.5. Efficient BFD Operation Under Resource Constraints 3.5. Efficient BFD Operation under Resource Constraints
When BFD sessions are being setup, torn down or modified (i.e. When BFD sessions are being setup, torn down or modified (i.e., when
parameters ? such as interval, multiplier, etc are being modified), parameters such as interval and multiplier are being modified), BFD
BFD requires additional packets other than scheduled packet requires additional packets other than scheduled packet transmissions
transmissions to complete the negotiation procedures (i.e. P/F to complete the negotiation procedures (i.e., P/F bits). There are
bits). There are scenarios where network resources are constrained: scenarios where network resources are constrained: a node may require
a node may require BFD to monitor very large number of paths, or BFD BFD to monitor very large number of paths, or BFD may need to operate
may need to operate in low powered and traffic sensitive networks, in low powered and traffic sensitive networks; these include
i.e. microwave, low powered nano-cells, etc. In these scenarios, it microwave, low powered nano-cells, and others. In these scenarios,
is desirable for BFD to slow down, speed up, stop or resume at will it is desirable for BFD to slow down, speed up, stop, or resume at-
witho minimal additional BFD packets exchanged to establish a new or will and with minimal number of additional BFD packets exchanged to
modified session. modify the session or establish a new one.
The established BFD session parameters and attributes like The established BFD session parameters and attributes like
transmission interval, receiver interval, etc., MUST be modifiable transmission interval, receiver interval, etc., need to be modifiable
without changing the state of the session. without changing the state of the session.
3.6. BFD for Anycast Address 3.6. BFD for Anycast Addresses
BFD protocol requires two endpoints to host BFD sessions, both The BFD protocol requires two endpoints to host BFD sessions, both
sending packets to each other. This BFD model does not fit well with sending packets to each other. This BFD model does not fit well with
anycast address monitoring, as BFD packets transmitted from a network anycast address monitoring, as BFD packets transmitted from a network
node to an anycast address will reach only one of potentially many node to an anycast address will reach only one of potentially many
network nodes hosting the anycast address. network nodes hosting the anycast address.
To support this use case, the BFD MUST be able to send packets in This use case verifies that a source node can send a packet to an
order to be received by any of nodes hosting anycast address to which anycast address, and that the target node to which the packet is
the BFD packets being sent and to respond. This requirement does not delivered can send a response packet to the source node. Traditional
require BFD session establishment with every node hosting the anycast BFD cannot fulfill this requirement, since it does not provide for a
address. set of BFD agents to collectively form one endpoint of a BFD session.
The concept of a Target Listener in S-BFD solves this requirement.
To support this use case, the BFD sender transmits BFD packets, which
are received by any of the nodes hosting the anycast address to which
the BFD packets being sent. The anycast target that receives the BFD
packet, responds. This use case does not imply the BFD session
establishment with every node hosting the anycast address.
Consequently, in this any cast use case, target nodes that do not
happen to receive any of the BFD packets do not need to maintain any
state, and the source node does not need to maintain separate state
for each target node.
3.7. BFD Fault Isolation 3.7. BFD Fault Isolation
BFD multi-hop [RFC5883]and BFD MPLS [RFC5884] traverse multiple BFD for multihop paths [RFC5883] and BFD for MPLS LSPs [RFC5884]
network nodes. BFD has been designed to declare failure upon lack of perform end-to-end validation, traversing multiple network nodes.
consecutive packet reception, which can be caused by a fault anywhere BFD has been designed to declare failure upon lack of consecutive
along the path. Fast failure detection allows for rapid path packet reception, which can be caused by a fault anywhere along these
recovery procedures. However, operators often have to follow up, path. Fast failure detection allows for rapid fault detection and
manually or automatically, to attempt to identify and localize the consequent rapid path recovery procedures. However, operators often
fault that caused BFD sessions to fail. Usage of other tools to have to follow up, manually or automatically, to attempt to identify
isolate the fault may cause the packets to traverse a different path and localize the fault that caused BFD sessions to fail (i.e., fault
through the network (e.g. if ECMP is used). In addition, the longer isolation). The usage of other tools to isolate the fault (e.g.,
it takes from BFD session failure to fault isolation attempt, more traceroute) may cause the packets to traverse a different path
likely that the fault cannot be isolated, e.g. a fault can get through the network, if Equal-Cost Multipath (ECMP) is used. In
corrected or routed around. If BFD had built-in fault isolation addition, the longer it takes from BFD session failure to starting
capability, fault isolation can get triggered at the earliest sign of fault isolation, the more likely that the fault will not be able to
fault and such packets will get load balanced in very similar way, if be isolated (e.g., a fault can get corrected or routed around). If
not the same, as BFD packets that went missing. 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.
To support this requirement, BFD SHOULD support fault isolation This use case describes S-BFD fault isolation capabilities using
capability using status indicating fields, when encountered. status indicating fields.
3.8. Multiple BFD Sessions to Same Target 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 negotiated rate. network nodes continuously transmit BFD packets at the negotiated
If BFD packet transmission is interrupted, even for a very short rate. If BFD packet transmission is interrupted, even for a very
period of time, that can result in BFD to declare failure short period of time, BFD can declare a failure irrespective of path
irrespective of path liveliness. It is possible, on a system where liveliness. It is possible, on a system where BFD is running, for
BFD is running, for certain events, intentionally or unintentionally, certain events (intentionally or unintentionally) to cause a short
to cause a short interruption of BFD packet transmissions. With interruption of BFD packet transmissions. With distributed
distributed architectures of BFD implementations, this can be architectures of BFD implementations, this case can be protected. In
protected, if a node was to run multiple BFD sessions to targets, this case, the use case of an S-BFD node running multiple BFD
hosted on different parts of the system (ex: different CPU sessions to a targets, with those sessions hosted on different system
instances). This can reduce BFD false failures, resulting in more modules (e.g., in different CPU instances). This can reduce BFD
stable network. false failures, resulting in more stable network.
3.9. MPLS BFD Session Per ECMP Path To support this use case, a mapping between the multiple
discriminators on a single system, and the specific entity within the
system is required.
BFD for MPLS, defined in [RFC5884], describes procedures to run BFD 3.9. An MPLS BFD Session Per ECMP Path
as LSP in-band continuity check mechanism, through usage of MPLS echo
request [RFC4379] to bootstrap the BFD session on the egress node.
Section 4 of [RFC5884] also describes a possibility of running
multiple BFD sessions per alternative paths of LSP. However, details
on how to bootstrap and maintain correct set of BFD sessions on the
egress node is absent.
When an LSP has ECMP segment, it may be desirable to run in-band BFD for MPLS LSPs, defined in [RFC5884], describes procedures to run
monitoring that exercises every path of ECMP. Otherwise there will BFD as LSP in-band continuity check mechanism, through usage of MPLS
be scenarios where in-band BFD session remains up through one path echo request [RFC4379] to bootstrap the BFD session on the target
but traffic is black-holing over another path. BFD session per ECMP (i.e., egress) node. Section 4 of [RFC5884] also describes a
path of LSP requires definition of procedures that update [RFC5884] possibility of running multiple BFD sessions per alternative paths of
in terms of how to bootstrap and maintain correct set of BFD sessions LSP. [RFC7726] further clarified the procedures, both for ingress
on the egress node. However, that may require constant use of MPLS and egress nodes, of how to bootstrap, maintain, and remove multiple
BFD sessions for the same <MPLS LSP, FEC> tuple. However, this
mechanism still requires the use of MPLS LSP Ping for bootstrapping,
round-trips for initialization, and keeping state at the receiver.
In the presence of ECMP within an MPLS LSP, it may be desirable to
run in-band monitoring that exercises every path of this ECMP.
Otherwise there will be scenarios where in-band BFD session remains
up through one path but traffic is black-holing over another path. A
BFD session per ECMP path of an LSP requires the definition of
procedures that update [RFC5884] in terms of how to bootstrap and
maintain the correct set of BFD sessions on the egress node.
However, for traditional BFD, that requires the constant use of MPLS
Echo Request messages to create and delete BFD sessions on the egress Echo Request messages to create and delete BFD sessions on the egress
node, when ECMP paths and/or corresponding load balance hash keys node, when ECMP paths and/or corresponding load balance hash keys
change. If a BFD session over any paths of the LSP can be change. If a BFD session over any paths of the LSP can be
instantiated, stopped and resumed without requiring additional instantiated, stopped and resumed without requiring additional
procedures of bootstrapping via MPLS echo request, it would simplify procedures of bootstrapping via an MPLS echo request message, it
implementations and operations, and benefits network devices as less would greatly simplify both implementations and operations, and
processing are required by them. benefits network devices as less processing are required by them.
To support this requirement, multiple BFD sessions MUST be able to be To support this requirement, multiple S-BFD sessions need to be
established over different ECMP paths from the same source to target established over different ECMP paths from the same source to target
node. node.
4. Detailed Requirements 4. Detailed Requirements for a Seamless BFD
REQ#1- A target network entity (for the BFD session), upon receipt of
BFD packet, MUST start processing for the discriminator received in
the BFD packet.
REQ#2- The source network entity MUST be able to establish a
unidirectional BFD session without the bidirectional handshake of
discriminators for session establishment.
REQ#3 - The BFD session MUST be able to be established without the
need for session negotiation and exchange of discriminators.
REQ#4 - BFD MUST be able to perform liveness detection initated from
centralized controller for any given segment under its domain.
REQ#5 - The established BFD session parameters and attributes like
transmission interval, receiver interval, etc., MUST be modifiable
without changing the state of the session.
REQ#6 - The BFD MUST be able to send and receive response to control
packets addressed to an anycast address to be received by any of
nodes hosting that address. This requirement does not require BFD
session establishment with every node hosting the anycast address.
REQ#7 - BFD SHOULD support fault isolation capability and to indicate
the same, when fault is encountered.
REQ#8 - BFD MUST be able to establish multiple sessions between the
same pair of source and target nodes. This requirement enables but
does not guarantee ability to monitor diverge paths in ECMP
environment. The mapping between BFD session and particular ECMP
path is out the scope of BFD specification.
5. Security Considerations
This document details the use cases and identifies various
requirements for the same. As this document do not propose any new
protocol or changes to the existing ones, no new security
considerations have been identified with this draft.
6. IANA Considerations
There are no IANA considerations introduced by this draft REQ#1: A target network entity (for the S-BFD session), upon
receipt of the S-BFD packet, MUST process the packet based
on the discriminator received in the BFD packet. If the
S-BFD context is found, the target network entity MUST be
able to send a response.
7. Contributors REQ#2: The source network entity MUST be able to establish a
unidirectional S-BFD session without the bidirectional
handshake of discriminators for session establishment.
Carlos Pignataro REQ#3: The S-BFD session MUST be able to be established without the
need for exchange of discriminators in session negotiation.
Cisco Systems REQ#4: In a Segment Routed network, S-BFD MUST be able to perform
liveness detection initiated from a centralized controller
for any given segment under its domain.
Email: cpignata@cisco.com REQ#5: The established S-BFD session parameters and attributes,
such as transmission interval, reception interval, etc.,
MUST be modifiable without changing the state of the
session.
Glenn Hayden REQ#6: An S-BFD source network entity MUST be able to send S-BFD
control packets to an anycast address which are received by
any node hosting that address, and must be able to receive
responses from any of these anycast nodes, without
establishing a separate BFD session with every node hosing
the anycast address.
ATT REQ#7: S-BFD SHOULD support fault isolation capability, which MAY
be triggered when a fault is encountered.
Email: gh1691@att.com REQ#8: S-BFD SHOULD be able to establish multiple sessions between
the same pair of source and target nodes. This requirement
enables but does not guarantee the ability to monitor
diverge paths in ECMP environments. It also provides
resiliency in distributed router architectures. The mapping
between BFD discriminators and particular entities (e.g.,
ECMP paths, or Line Cards) is out the scope of the S-BFD
specification.
Santosh P K REQ#9: The S-BFD protocol MUST provide mechanisms for loop
detection and prevention, protecting against malicious
attacks attempting to create packet loops.
Juniper 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.
Email: santoshpk@juniper.net 5. Security Considerations
Mach Chen 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.
Huawei 6. IANA Considerations
Email: mach.chen@huawei.com There are no IANA considerations introduced by this document.
Nobo Akiya 7. Acknowledgements
Cisco Systems 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.
Email: nobo@cisco.com 8. Contributors
8. Acknowledgements The following are key contributors to this document:
The authors would like to thank Eric Gray for his useful comments. Manav Bhatia, Ionos Networks
Satoru Matsushima, Softbank
Glenn Hayden, ATT
Santosh P K
Mach Chen, Huawei
Nobo Akiya, Big Switch Networks
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
DOI 10.17487/RFC4379, February 2006,
<http://www.rfc-editor.org/info/rfc4379>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<http://www.rfc-editor.org/info/rfc5880>. <http://www.rfc-editor.org/info/rfc5880>.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
DOI 10.17487/RFC5881, June 2010, DOI 10.17487/RFC5881, June 2010,
<http://www.rfc-editor.org/info/rfc5881>. <http://www.rfc-editor.org/info/rfc5881>.
[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
skipping to change at page 11, line 36 skipping to change at page 13, line 27
June 2010, <http://www.rfc-editor.org/info/rfc5884>. June 2010, <http://www.rfc-editor.org/info/rfc5884>.
[RFC5885] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional [RFC5885] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional
Forwarding Detection (BFD) for the Pseudowire Virtual Forwarding Detection (BFD) for the Pseudowire Virtual
Circuit Connectivity Verification (VCCV)", RFC 5885, Circuit Connectivity Verification (VCCV)", RFC 5885,
DOI 10.17487/RFC5885, June 2010, DOI 10.17487/RFC5885, June 2010,
<http://www.rfc-editor.org/info/rfc5885>. <http://www.rfc-editor.org/info/rfc5885>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-bfd-seamless-base]
Akiya, N., Pignataro, C., Ward, D., Bhatia, M., and J.
Networks, "Seamless Bidirectional Forwarding Detection
(S-BFD)", draft-ietf-bfd-seamless-base-09 (work in
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] [I-D.ietf-spring-oam-usecase]
Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "A
Case for a Scalable and Topology-Aware Segment Routing scalable and topology aware MPLS data plane monitoring
MPLS Data Plane Monitoring System", draft-ietf-spring-oam- system", draft-ietf-spring-oam-usecase-02 (work in
usecase-01 (work in progress), October 2015. 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.,
and S. Litkowski, "OAM Requirements for Segment Routing and S. Litkowski, "OAM Requirements for Segment Routing
Network", draft-ietf-spring-sr-oam-requirement-01 (work in Network", draft-ietf-spring-sr-oam-requirement-01 (work in
progress), December 2015. progress), December 2015.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<http://www.rfc-editor.org/info/rfc3031>.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
DOI 10.17487/RFC4379, February 2006,
<http://www.rfc-editor.org/info/rfc4379>.
[RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S.
Aldrin, "Clarifying Procedures for Establishing BFD
Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726,
DOI 10.17487/RFC7726, January 2016,
<http://www.rfc-editor.org/info/rfc7726>.
Authors' Addresses Authors' Addresses
Sam Aldrin Sam Aldrin
Google, Inc Google, Inc
1600 Amphitheatre Parkway
Mountain View, CA
Email: aldrin.ietf@gmail.com Email: aldrin.ietf@gmail.com
Manav Bhatia Carlos Pignataro
Ionos Networks Cisco Systems, Inc.
Email: manav@ionosnetworks.com
Satoru Matsushima
Softbank
Email: satoru.matsushima@g.softbank.co.jp Email: cpignata@cisco.com
Greg Mirsky Greg Mirsky
Ericsson Ericsson
Email: gregory.mirsky@ericsson.com Email: gregory.mirsky@ericsson.com
Nagendra Kumar Nagendra Kumar
Cisco Cisco Systems, Inc.
Email: naikumar@cisco.com Email: naikumar@cisco.com
 End of changes. 75 change blocks. 
324 lines changed or deleted 419 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/