draft-ietf-bfd-seamless-use-case-03.txt   draft-ietf-bfd-seamless-use-case-04.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 M. Bhatia
Expires: February 1, 2016 Ionos Networks Expires: September 22, 2016 Ionos Networks
S. Matsushima S. Matsushima
Softbank Softbank
G. Mirsky G. Mirsky
Ericsson Ericsson
N. Kumar N. Kumar
Cisco Cisco
July 31, 2015 March 21, 2016
Seamless Bidirectional Forwarding Detection (BFD) Use Case Seamless Bidirectional Forwarding Detection (BFD) Use Case
draft-ietf-bfd-seamless-use-case-03 draft-ietf-bfd-seamless-use-case-04
Abstract Abstract
This document provides various use cases for Bidirectional Forwarding This document provides various use cases for Bidirectional Forwarding
Detection (BFD) such that extensions could be developed to allow for Detection (BFD) and various requirements such that extensions could
simplified detection of forwarding failures. be developed to allow for simplified detection of forwarding
failures.
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 February 1, 2016. This Internet-Draft will expire on September 22, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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
2. Introduction to Seamless BFD . . . . . . . . . . . . . . . . 3 2. Introduction to Seamless BFD . . . . . . . . . . . . . . . . 3
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Unidirectional Forwarding Path Validation . . . . . . . . 4 3.1. Unidirectional Forwarding Path Validation . . . . . . . . 4
3.2. Validation of forwarding path prior to traffic switching 5 3.2. Validation of forwarding path prior to traffic switching 5
3.3. Centralized Traffic Engineering . . . . . . . . . . . . . 5 3.3. Centralized Traffic Engineering . . . . . . . . . . . . . 6
3.4. BFD in Centralized Segment Routing . . . . . . . . . . . 6 3.4. BFD in Centralized Segment Routing . . . . . . . . . . . 6
3.5. BFD Efficient Operation Under Resource Constraints . . . 6 3.5. Efficient BFD Operation Under Resource Constraints . . . 7
3.6. BFD for Anycast Address . . . . . . . . . . . . . . . . . 7 3.6. BFD for Anycast Address . . . . . . . . . . . . . . . . . 7
3.7. BFD Fault Isolation . . . . . . . . . . . . . . . . . . . 7 3.7. BFD Fault Isolation . . . . . . . . . . . . . . . . . . . 7
3.8. Multiple BFD Sessions to Same Target . . . . . . . . . . 7 3.8. Multiple BFD Sessions to Same Target . . . . . . . . . . 8
3.9. MPLS BFD Session Per ECMP Path . . . . . . . . . . . . . 7 3.9. MPLS BFD Session Per ECMP Path . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Detailed Requirements . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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 for failure detection. Even
though the protocol is simple and lightweight, there are certain use though the protocol is simple, there are certain use cases, where
cases, where faster setting up of sessions and continuity check of faster setting up of sessions and continuity check of the data
the data forwarding paths is necessary. This document identifies use forwarding paths is necessary. This document identifies various use
cases such that necessary enhancements could be made to BFD protocol cases and requirements related to those, such that necessary
to meet those requirements. enhancements could be made to BFD protocol.
BFD was designed to be a lightweight "Hello" protocol to detect data BFD is a simple lightweight "Hello" protocol to detect data plane
plane failures. With dynamic provisioning of forwarding paths on a failures. With dynamic provisioning of forwarding paths on a large
large scale, establishing BFD sessions for each of those paths scale, establishing BFD sessions for each of those paths creates
creates complexity, not only from an operations point of view, but complexity, not only from an operations point of view, but also in
also in terms of the speed at which these sessions could be terms of the speed at which these sessions could be established or
established or deleted. The existing session establishment mechanism deleted. The existing session establishment mechanism of the BFD
of the BFD protocol need to be enhanced in order to minimize the time protocol has to be enhanced in order to minimize the time for the
for the session to come up and validate the forwarding path. session to come up to validate the forwarding path.
This document specifically identifies those cases where certain This document specifically identifies various use cases and
requirements could be derived to be used as reference, so that, corresponding requirements in order to enhance BFD and other
protocol enhancements could be developed to address them. While the supporting protocols. While the identified requirements could meet
use cases could be used as reference for certain requirements, it is various use cases , it is outside the scope of this document to
outside the scope of this document to identify all of the identify all of the possible and necessary requirements. Solutions
requirements for all possible enhancements. Specific solutions and to the identified uses cases and protocol specific enhancements or
enhancement proposals are outside the scope of this document as well. proposals are outside the scope of this document as well.
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, IP, MPLS and
Segment Routing (SR) terminology and protocol constructs. This Segment Routing (SR) [I-D.ietf-spring-segment-routing] terminology
section identifies only the new terminology introduced. and protocol constructs. This section identifies only the new
terminology introduced.
1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[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. The discriminator enables
identification of the sender and receiver of BFD packets of the identification of the sender and receiver of BFD packets of the
particular session and proactive continuity monitoring of the particular session and perform proactive continuity monitoring of the
forwarding path between the two. [RFC5881] defines single hop BFD forwarding path between the two. [RFC5881] defines single hop BFD
whereas [RFC5883] defines multi-hop BFD, [RFC5884] BFD for MPLS whereas [RFC5883] defines multi-hop BFD, [RFC5884] BFD for MPLS
LSPs, and [RFC5885] - BFD for PWs. LSPs, and [RFC5885] - BFD for PWs.
Currently, BFD is best suited to verify that two end points are Currently, BFD is best suited to verify that two end points are
reachable or that an existing connection continues to be valid. In reachable or that an existing connection continues to be up and
order for BFD to be able to initially verify that a connection is alive. In order for BFD to be able to initially verify that a
valid and that it connects the expected set of end points, it is connection is valid and that it connects the expected set of end
necessary to provide the node information associated with the points, it is necessary to provide the node information associated
connection at each end point prior to initiating BFD sessions, such with the connection at each end point prior to initiating BFD
that this information can be used to verify that the connection is sessions, such that this information can be used to verify that the
valid. connection is up and verifiable.
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 this
node-specific information is unnecessary and it is possible for the node-specific information is unnecessary and it is possible for the
end points to begin BFD messaging seamlessly. In fact, the initial end points to begin BFD messaging seamlessly. In fact, the initial
exchange of discriminator information is an unnecessary extra step exchange of discriminator information is an unnecessary extra step
that may be avoided for these cases. that may be avoided for these cases.
As an example of how Seamless BFD (S-BFD) might work, an entity (such In a given scenario, where an entity (such as an operator, or
as an operator, or centralized controller) determines a set of centralized controller) determines a set of network entities to which
network entities to which BFD sessions might need to be established. BFD sessions might need to be established. Each of those network
Each of those network entities is assigned a BFD discriminator, to entities is assigned a BFD discriminator, to establish a BFD session.
establish a BFD session. These network entities will create a BFD These network entities will create a BFD session instance that
session instance that listens for incoming BFD control packets. listens for incoming BFD control packets. Mappings between selected
Mappings between selected network entities and corresponding BFD network entities and corresponding BFD discriminators are known to
discriminators are known to other network nodes belonging in the same other network nodes belonging in the same network by some means. A
network by some means. A network entity in this network is then able network entity in this network is then able to send a BFD control
to send a BFD control packet to a particular target with the packet to a particular target with the corresponding BFD
corresponding BFD discriminator. Target network node, upon reception discriminator. Target network node, upon reception of such BFD
of such BFD control packet, will transmit a response BFD control control packet, will transmit a response BFD control packet back to
packet back to the sender. 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. In addition, some of the use be able to satisfy the requirements identified. In addition, some of
cases also be identify 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 specifications.
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 when 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, and validation forwarding path for that statically established path. Validation of
by the target entity to the originating entity is not required. Many the forwarding path in the direction of the target entity to the
LSPs have the same unidirectional characteristics and unidirectional originating entity is not required, in this scenario. Many LSPs have
validation requirements. Such LSPs are common in Segment Routing and the same unidirectional characteristics and unidirectional validation
LDP based networks. Another example is when a unidirectional tunnel requirements. Such LSPs are common in Segment Routing and LDP based
uses BFD to validate reachability of an egress node. networks. Another example is when 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 If the traditional BFD is to be used, the target network entity has
to be provisioned as well, even though the reverse path validation to be provisioned as well, even though the reverse path validation
with BFD session is not required. But with unidirectional BFD, the with BFD session is not required. However, in the case of
need to provision on the target network entity is not needed. Once unidirectional BFD, there is no need for provisioning on the target
the mechanism within the BFD protocol is in place, where the source network entity . Once the mechanism within the BFD protocol is in
network entity knows the target network entity's discriminator, it place, session could be established in a single direction. When the
starts the session right away. When the targeted network entity targeted network entity receives the packet, it knows that BFD
receives the packet, it knows that BFD packet, based on the packet, based on the discriminator and processes it. This does not
discriminator and processes it. That does not require establishment necessitates the requirement for establishment of a bi-directional
of a bi-directional session, hence the two way handshake to exchange session, hence the two way handshake to exchange discriminators is
discriminators is not needed as well. not needed.
The primary requirement in this use case is to enable session
establishment from source network entity to target network entity.
This translates to a need for the target network entity (for the BFD Thus the requirement for BFD for this use case is to enable session
session), should start processing for the discriminator received in establishment from source network entity to target network entity
the BFD packet. This will enable the source network entity to without the need to have a session in the reverse direction. This
establish a unidirectional BFD session without the bidirectional requires to ensure that the target network entity (for the BFD
handshake of discriminators for session establishment. session), upon receipt of BFD packet, MUST start processing for the
discriminator received in the BFD packet. The source network entity
MUST be able to 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 forwarding path prior to traffic switching
BFD provides data delivery confidence when reachability validation is BFD provides data delivery confidence when reachability validation is
performed prior to traffic utilizing specific paths/LSPs. However performed prior to traffic utilizing specific paths/LSPs. However
this comes with a cost, where, traffic is prevented to use such this comes with a cost, where, traffic is prevented to use such
paths/LSPs until BFD is able to validate the reachability, which paths/LSPs until BFD is able to validate the reachability, which
could take seconds due to BFD session bring-up sequences [RFC5880], could take seconds due to BFD session bring-up sequences [RFC5880],
LSP ping bootstrapping [RFC5884], etc. This use case does not LSP ping bootstrapping [RFC5884], etc. This use case could be well
require to have sequences for session negotiation and discriminator supported by eliminating the need for session negotiation and
exchanges in order to establish the BFD session. discriminator exchanges in order to establish the BFD session.
When these sequences for handshake are eliminated, the network All it takes is for the network entities to know what the
entities need to know what the discriminator values to be used for discriminator values to be used for the session. The same is the
the session. The same is the case for S-BFD, i.e., when the three- case for S-BFD, i.e., the three-way handshake mechanism is eliminated
way handshake mechanism is eliminated during bootstrap of BFD during bootstrap of BFD sessions. However, this information is
sessions. However, this information is required at each entity to required at each entity to verify that BFD messages are being
verify that BFD messages are being received from the expected end- received from the expected end-points, hence the handshake mechanism
points, hence the handshake mechanism serves no purpose. Elimination serves no purpose. Elimination of the unnecessary handshake
of the unnecessary handshake mechanism allows for faster reachability mechanism allows for faster reachability validation of BFD
validation of BFD provisioned paths/LSPs. 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, e.g. in Software Defined Networks (SDN). It
will be desirable to perform BFD validation very quickly to allow will be desirable to perform BFD validation as soon as the LSP?s are
applications to utilize dynamically created LSPs in a timely manner. created, in order to use them.
In order to support this use case, the BFD session MUST be able to be
established without the need for session negotiation and exchange of
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 where intelligence, traditionally placed in a
distributed and dynamic control plane, is separated from the data distributed and dynamic control plane, is separated from the
plane and resides in a logically centralized place. There are networking entities along the data path, instead resides in a
various controllers that perform this exact function in establishing logically centralized place. There are various controllers that
forwarding paths for the data flow. Traffic engineering is one perform this exact function in establishment of forwarding paths for
important function, where the traffic flow is engineered depending the data flow. Traffic engineering is one important function, where
upon various attributes of the traffic as well as the network state. the traffic flow is engineered, depending upon various 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 ability to manage and maintain the dynamic network becomes a
challenge. One way to ensure the forwarding paths are valid, and challenge. One way to ensure the forwarding paths are valid, and
working, is to establish BFD sessions within the network. When working, is done by validation of the network using BFD. When
traffic engineered tunnels are created, it is operationally critical traffic engineered tunnels are created, it is operationally critical
to ensure that the forwarding paths are working prior to switching to ensure that the forwarding paths are working, prior to switching
the traffic onto the engineered tunnels. In the absence of control the traffic onto the engineered tunnels. In the absence of control
plane protocols, it may be desirable to verify the forwarding path plane protocols, it may be desirable to verify, not only the
but also of any arbitrary path in the network. With tunnels being forwarding path but also of any arbitrary path in the network. With
engineered by a centralized entity, when the network state changes, tunnels being engineered by a centralized entity, when the network
traffic has to be switched with minimum latency and black holing of state changes, traffic has to be switched with minimum latency and
the data. without black holing of the data.
Traditional BFD session establishment and validation of the Traditional BFD session establishment and validation of the
forwarding path must not become a bottleneck in the case of forwarding path must not become a bottleneck in the case of
centralized traffic engineering. If the controller or other centralized traffic engineering. If the controller or other
centralized entity is able to instantly verify a forwarding path of centralized entity is able to instantly verify a forwarding path of
the TE tunnel , it could steer the traffic onto the traffic the TE tunnel , it could steer the traffic onto the traffic
engineered tunnel very quickly thus minimizing adverse effect on a engineered tunnel very quickly thus minimizing adverse effect on a
service. This is especially useful and needed when the scale of the service. This is especially useful and needed when the scale of the
network and number of TE tunnels is very high. network and number of TE tunnels is very high.
The cost associated with BFD session negotiation and establishment of The cost associated with BFD session negotiation and establishment of
BFD sessions to identify valid paths is very high and providing BFD sessions to identify valid paths is very high and providing
network redundancy becomes a critical issue. network redundancy becomes a critical issue.
3.4. BFD in Centralized Segment Routing 3.4. BFD in Centralized Segment Routing
A centralized controller based Segment Routing network monitoring A monitoring technique of a Segment Routing network based on a
technique is described in [I-D.geib-spring-oam-usecase]. In centralized controller is described in [I-D.ietf-spring-oam-usecase].
validating this use case, one of the requirements is to ensure the Various OAM requirements for Segment Routing were captured in
BFD packet's behavior is according to the requirement and monitoring [I-D.ietf-spring-sr-oam-requirement]. In validating this use case,
of the segment, where the packet is U-turned at the expected node. one of the requirements is to ensure the BFD packet's behavior is
One of the criterion is to ensure the continuity check to the according to the requirement and monitoring of the segment, where the
adjacent segment-id. packet is U-turned at the expected node. One of the criterion is to
ensure the continuity check to the adjacent segment-id.
3.5. BFD Efficient Operation Under Resource Constraints To support this use case, BFD MUST be able to perform liveness
detection initated from centralized controller for any given segment
under its domain.
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.
parameters ? such as interval, multiplier, etc are being modified), parameters ? such as interval, multiplier, etc are being modified),
BFD requires additional packets other than scheduled packet BFD requires additional packets other than scheduled packet
transmissions to complete the negotiation procedures (i.e. P/F transmissions to complete the negotiation procedures (i.e. P/F
bits). There are scenarios where network resources are constrained: bits). There are scenarios where network resources are constrained:
a node may require BFD to monitor very large number of paths, or BFD a node may require BFD to monitor very large number of paths, or BFD
may need to operate in low powered and traffic sensitive networks, may need to operate in low powered and traffic sensitive networks,
i.e. microwave, low powered nano-cells, etc. In these scenarios, it i.e. microwave, low powered nano-cells, etc. In these scenarios, it
is desirable for BFD to slow down, speed up, stop or resume at will is desirable for BFD to slow down, speed up, stop or resume at will
witho minimal additional BFD packets exchanged to establish a new or witho minimal additional BFD packets exchanged to establish a new or
modified session. modified session.
The established BFD session parameters and attributes like
transmission interval, receiver interval, etc., MUST be modifiable
without changing the state of the session.
3.6. BFD for Anycast Address 3.6. BFD for Anycast Address
BFD protocol requires two endpoints to host BFD sessions, both 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
order to be received by any of nodes hosting anycast address to which
the BFD packets being sent and to respond. This requirement does not
require BFD session establishment with every node hosting the anycast
address.
3.7. BFD Fault Isolation 3.7. BFD Fault Isolation
BFD multi-hop and BFD MPLS traverse multiple network nodes. BFD has BFD multi-hop [RFC5883]and BFD MPLS [RFC5884] traverse multiple
been designed to declare failure upon lack of consecutive packet network nodes. BFD has been designed to declare failure upon lack of
reception, which can be caused by a fault anywhere along the path. consecutive packet reception, which can be caused by a fault anywhere
Fast failure detection allows for rapid path recovery procedures. along the path. Fast failure detection allows for rapid path
However, operators often have to follow up, manually or recovery procedures. However, operators often have to follow up,
automatically, to attempt to identify and localize the fault that manually or automatically, to attempt to identify and localize the
caused BFD sessions to fail. Usage of other tools to isolate the fault that caused BFD sessions to fail. Usage of other tools to
fault may cause the packets to traverse a different path through the isolate the fault may cause the packets to traverse a different path
network (e.g. if ECMP is used). In addition, the longer it takes through the network (e.g. if ECMP is used). In addition, the longer
from BFD session failure to fault isolation attempt, more likely that it takes from BFD session failure to fault isolation attempt, more
the fault cannot be isolated, e.g. a fault can get corrected or likely that the fault cannot be isolated, e.g. a fault can get
routed around. If BFD had built-in fault isolation capability, fault corrected or routed around. If BFD had built-in fault isolation
isolation can get triggered at the earliest sign of fault and such capability, fault isolation can get triggered at the earliest sign of
packets will get load balanced in very similar way, if not the same, fault and such packets will get load balanced in very similar way, if
as BFD packets that went missing. not the same, as BFD packets that went missing.
To support this requirement, BFD SHOULD support fault isolation
capability using status indicating fields, when encountered.
3.8. Multiple BFD Sessions to Same Target 3.8. Multiple BFD Sessions to Same Target
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 transmitting BFD packets at negotiated network nodes continuously transmit BFD packets at negotiated rate.
rate. If BFD packet transmission is interrupted, even for a very If BFD packet transmission is interrupted, even for a very short
short period of time, that can result in BFD to declare failure period of time, that can result in BFD to declare failure
irrespective of path liveliness. It is possible, on a system where irrespective of path liveliness. It is possible, on a system where
BFD is running, for certain events, intentionally or unintentionally, BFD is running, for certain events, intentionally or unintentionally,
to cause a short interruption of BFD packet transmissions. With to cause a short interruption of BFD packet transmissions. With
distributed architectures of BFD implementations, this can be distributed architectures of BFD implementations, this can be
protected, if a node was to run multiple BFD sessions to targets, protected, if a node was to run multiple BFD sessions to targets,
hosted on different parts of the system (ex: different CPU hosted on different parts of the system (ex: different CPU
instances). This can reduce BFD false failures, resulting in more instances). This can reduce BFD false failures, resulting in more
stable network. stable network.
3.9. MPLS BFD Session Per ECMP Path 3.9. MPLS BFD Session Per ECMP Path
skipping to change at page 8, line 10 skipping to change at page 8, line 41
as LSP in-band continuity check mechanism, through usage of MPLS echo as LSP in-band continuity check mechanism, through usage of MPLS echo
request [RFC4379] to bootstrap the BFD session on the egress node. request [RFC4379] to bootstrap the BFD session on the egress node.
Section 4 of [RFC5884] also describes a possibility of running Section 4 of [RFC5884] also describes a possibility of running
multiple BFD sessions per alternative paths of LSP. However, details multiple BFD sessions per alternative paths of LSP. However, details
on how to bootstrap and maintain correct set of BFD sessions on the on how to bootstrap and maintain correct set of BFD sessions on the
egress node is absent. egress node is absent.
When an LSP has ECMP segment, it may be desirable to run in-band When an LSP has ECMP segment, it may be desirable to run in-band
monitoring that exercises every path of ECMP. Otherwise there will monitoring that exercises every path of ECMP. Otherwise there will
be scenarios where in-band BFD session remains up through one path be scenarios where in-band BFD session remains up through one path
but traffic is black-holing over another path. One way to achieve but traffic is black-holing over another path. BFD session per ECMP
BFD session per ECMP path of LSP is to define procedures that update path of LSP requires definition of procedures that update [RFC5884]
[RFC5884] in terms of how to bootstrap and maintain correct set of in terms of how to bootstrap and maintain correct set of BFD sessions
BFD sessions on the egress node. However, that may require constant on the egress node. However, that may require constant use of MPLS
use of MPLS Echo Request messages to create and delete BFD sessions Echo Request messages to create and delete BFD sessions on the egress
on the egress node, when ECMP paths and/or corresponding load balance node, when ECMP paths and/or corresponding load balance hash keys
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 MPLS echo request, it would simplify
implementations and operations, and benefits network devices as less implementations and operations, and benefits network devices as less
processing are required by them. processing are required by them.
4. Security Considerations To support this requirement, multiple BFD sessions MUST be able to be
established over different ECMP paths from the same source to target
node.
There are no new security considerations associated with this draft. 4. Detailed Requirements
5. IANA Considerations 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 There are no IANA considerations introduced by this draft
6. Contributors 7. Contributors
Carlos Pignataro Carlos Pignataro
Cisco Systems Cisco Systems
Email: cpignata@cisco.com Email: cpignata@cisco.com
Glenn Hayden Glenn Hayden
ATT ATT
skipping to change at page 9, line 14 skipping to change at page 10, line 41
Huawei Huawei
Email: mach.chen@huawei.com Email: mach.chen@huawei.com
Nobo Akiya Nobo Akiya
Cisco Systems Cisco Systems
Email: nobo@cisco.com Email: nobo@cisco.com
7. Acknowledgements 8. Acknowledgements
The authors would like to thank Eric Gray for his useful comments. The authors would like to thank Eric Gray for his useful comments.
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379, Label Switched (MPLS) Data Plane Failures", RFC 4379,
DOI 10.17487/RFC4379, February 2006, DOI 10.17487/RFC4379, February 2006,
<http://www.rfc-editor.org/info/rfc4379>. <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>.
skipping to change at page 10, line 5 skipping to change at page 11, line 34
"Bidirectional Forwarding Detection (BFD) for MPLS Label "Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884,
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>.
8.2. Informative References 9.2. Informative References
[I-D.geib-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, "Use
case for a scalable and topology aware MPLS data plane Case for a Scalable and Topology-Aware Segment Routing
monitoring system", draft-geib-spring-oam-usecase-06 (work MPLS Data Plane Monitoring System", draft-ietf-spring-oam-
in progress), July 2015. usecase-01 (work in progress), October 2015.
[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.,
and S. Litkowski, "OAM Requirements for Segment Routing
Network", draft-ietf-spring-sr-oam-requirement-01 (work in
progress), December 2015.
Authors' Addresses Authors' Addresses
Sam Aldrin Sam Aldrin
Google, Inc Google, Inc
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA Mountain View, CA
Email: aldrin.ietf@gmail.com Email: aldrin.ietf@gmail.com
 End of changes. 46 change blocks. 
161 lines changed or deleted 254 lines changed or added

This html diff was produced by rfcdiff 1.44. The latest version is available from http://tools.ietf.org/tools/rfcdiff/