draft-ietf-bfd-seamless-use-case-01.txt   draft-ietf-bfd-seamless-use-case-02.txt 
INTERNET-DRAFT Sam Aldrin Network Working Group A. Aldrin
Intended Status: Informational (Huawei) Internet-Draft
Expires: June 13, 2015 Manav Bhatia Intended status: Informational M. Bhatia
(Ionos) Expires: October 30, 2015 Ionos Networks
Greg Mirsky S. Matsushima
(Ericsson) Softbank
Nagendra Kumar G. Mirsky
(Cisco) Ericsson
Satoru Matsushima N. Kumar
(Softbank) Cisco
April 28, 2015
December 10, 2014
Seamless Bidirectional Forwarding Detection (BFD) Use Case Seamless Bidirectional Forwarding Detection (BFD) Use Case
draft-ietf-bfd-seamless-use-case-01 draft-ietf-bfd-seamless-use-case-02
Abstract Abstract
This document provides various use cases for Bidirectional Forwarding This document provides various use cases for Bidirectional Forwarding
Detection (BFD) such that simplified solution and extensions could be Detection (BFD) such that extensions could be developed to allow for
developed for detecting forwarding failures. simplified detection of forwarding failures.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as working documents as Internet-Drafts. The list of current Internet-
Internet-Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on October 30, 2015.
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at Copyright Notice
http://www.ietf.org/shadow.html
Copyright and License Notice Copyright (c) 2015 IETF Trust and the persons identified as the
Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . 5
3.4. BFD in Centralized Segment Routing . . . . . . . . . . . . 6 3.4. BFD in Centralized Segment Routing . . . . . . . . . . . 6
3.5. BFD to Efficiently Operate under Resource Constraints . . . 6 3.5. BFD Efficient Operation Under Resource Constraints . . . 6
3.6. BFD for Anycast Address . . . . . . . . . . . . . . . . . . 7 3.6. BFD for Anycast Address . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . 7
3.9. MPLS BFD Session Per ECMP Path . . . . . . . . . . . . . . 8 3.9. MPLS BFD Session Per ECMP Path . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . . 9 8. Normative References . . . . . . . . . . . . . . . . . . . . 9
7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
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 and lightweight, there are certain use
cases, where a much faster setting up of sessions and continuity cases, where faster setting up of sessions and continuity check of
check of the data forwarding paths is necessary. This document the data forwarding paths is necessary. This document identifies use
identifies those use cases such that necessary enhancements could be cases such that necessary enhancements could be made to BFD protocol
made to BFD protocol to meet those requirements. to meet those requirements.
There are various ways to detecting faults and BFD protocol was BFD was designed to be a lightweight "Hello" protocol to detect data
designed to be a lightweight "Hello" protocol to detect data plane plane failures. With dynamic provisioning of forwarding paths on a
failures. With dynamic provisioning of forwarding paths at 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 operations point of view, but also the also in terms of the speed at which these sessions could be
speed at which these sessions could be established or deleted. The established or deleted. The existing session establishment mechanism
existing session establishment mechanism of the BFD protocol need to of the BFD protocol need to be enhanced in order to minimize the time
be enhanced in order to minimize the time for the session to come up for the session to come up and validate the forwarding path.
and validate the forwarding path.
This document specifically identifies those cases where certain This document specifically identifies those cases where certain
requirements could be derived to be used as reference, so that, requirements could be derived to be used as reference, so that,
protocol enhancements could be developed to address them. Whilst the protocol enhancements could be developed to address them. While the
use cases could be used as reference for certain requirements, it is use cases could be used as reference for certain requirements, it is
outside the scope of this document to identify all of the outside the scope of this document to identify all of the
requirements for all possible enhancements. Specific solutions and requirements for all possible enhancements. Specific solutions and
enhancement proposals are outside the scope of this document as well. enhancement 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 SR The reader is expected to be familiar with the BFD, IP, MPLS and
terminology and protocol constructs. This section identifies only Segment Routing (SR) terminology and protocol constructs. This
the new terminology introduced. section identifies only the new terminology introduced.
2. Introduction to Seamless BFD 2. Introduction to Seamless BFD
BFD as defined in standard [RFC5880] requires two network nodes, as BFD, as defined in standard [RFC5880], requires two network nodes, to
part of handshake, exchange discriminators. This will enable the exchange locally allocated discriminators. The discriminator enables
sender and receiver of BFD packets of a session to be identified and identification of the sender and receiver of BFD packets of the
check the continuity of the forwarding path. [RFC5881] defines single particular session and proactive continuity monitoring of the
hop BFD whereas [RFC5883] and [RFC5884] defines multi-hop BFD. forwarding path between the two. [RFC5881] defines single hop BFD
whereas [RFC5883] and [RFC5884] defines multi-hop BFD.
In order to establish BFD sessions between network entities and Currently, BFD is best suited to verify that two end points are
seamlessly be able to have the session up and running, BFD protocol reachable or that an existing connection continues to be valid. In
should be capable of doing that. These sessions have to be order for BFD to be able to initially verify that a connection is
established a priori to traffic flow and ensure the forwarding path valid and that it connects the expected set of end points, it is
is available and connectivity is present. With handshake mechanism necessary to provide the node information associated with the
within BFD protocol, establishing sessions at a rapid rate and connection at each end point prior to initiating BFD sessions, such
ensuring the validity or existence of working forwarding path, prior that this information can be used to verify that the connection is
to the session being up and running, becomes complex and time valid.
consuming. In order to achieve seamless BFD sessions, it requires a
mechanism where the ability to specify the discriminators and the
ability to respond to the BFD control packets by the network node,
should already be negotiated ahead of the session becoming active.
Seamless BFD by definition will be able to provide those mechanisms
within the BFD protocol in order to meet the requirements and
establish BFD sessions seamlessly, with minimal overhead, in order to
detect forwarding failures.
As an example of how Seamless BFD (S-BFD) works, a set of network If this information is already known to the end-points of a potential
entities are first identified, to which BFD sessions have to be BFD session, the initial handshake including an exchange of this
established. Each of those network nodes, will be assigned a special node-specific information is unnecessary and it is possible for the
BFD discriminator, to establish a BFD session. These network nodes end points to begin BFD messaging seamlessly. In fact, the initial
will also create a BFD session instance that listens for incoming BFD exchange of discriminator information is an unnecessary extra step
control packets. Mappings between selected network entities and that may be avoided for these cases.
corresponding special BFD discriminators are known to other network
nodes belonging in the same network. A network node in such network
is then able to send a BFD control packet to a particular target with
corresponding special BFD discriminator. Target network node, upon
reception of such BFD control packet, will transmit a response BFD
control packet back to the sender.
3. Use Cases As an example of how Seamless BFD (S-BFD) might work, an entity (such
as an operator, or centralized controller) determines a set of
network entities to which BFD sessions might need to be established.
Each of those network entities is assigned a BFD discriminator, to
establish a BFD session. These network entities will create a BFD
session instance that listens for incoming BFD control packets.
Mappings between selected network entities and corresponding BFD
discriminators are known to other network nodes belonging in the same
network by some means. A network entity in this network is then able
to send a BFD control packet to a particular target with the
corresponding BFD discriminator. Target network node, upon reception
of such BFD control packet, will transmit a response BFD control
packet back to the sender.
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 of the use cases where the existing mechanism section outlines some use cases where the existing mechanism may not
may not be able to satisfy the requirements. In addition, some of the be able to satisfy the requirements. In addition, some of the use
use cases will also be identifying the need for expedited BFD session cases also be identify the need for expedited BFD session
establishment with 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 only one side of the BFD, not both, is there are scenarios when verification is only required in one
interested in verifying continuity of the data plane between a pair direction between a pair of nodes. One such case is when a static
of nodes. One such case is, when a static route uses BFD to validate route uses BFD to validate reachability to the next-hop IP router.
reachability to the next-hop IP router. In this case, the static In this case, the static route is established from one network entity
route is established from one network entity to another. The to another. The requirement in this case is only to validate the
requirement in this case is only to validate the forwarding path for forwarding path for that statically established path, and validation
that statically established path, and validation by the target entity by the target entity to the originating entity is not required. Many
to the originating entity is not required. Many LSPs have the same LSPs have the same unidirectional characteristics and unidirectional
unidirectional characteristics and unidirectional validation validation requirements. Such LSPs are common in Segment Routing and
requirements. Such LSPs are common in Segment Routing and LDP based LDP based networks. Another example is when a unidirectional tunnel
networks. Another example is when a unidirectional tunnel uses BFD uses BFD to validate reachability of an egress node.
to validate reachability to the 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. But with unidirectional BFD, the
need to provision on the target network entity is not needed. Once need to provision on the target network entity is not needed. Once
the mechanism within the BFD protocol is in place, where the source the mechanism within the BFD protocol is in place, where the source
network entity knows the target network entity's discriminator, it network entity knows the target network entity's discriminator, it
starts the session right away. When the targeted network entity starts the session right away. When the targeted network entity
receives the packet, it knows that BFD packet, based on the receives the packet, it knows that BFD packet, based on the
discriminator and processes it. That do not require to have a bi- discriminator and processes it. That does not require establishment
directional session establishment, hence the two way handshake to of a bi-directional session, hence the two way handshake to exchange
exchange discriminators is not needed as well. discriminators is not needed as well.
The primary requirement in this use case is to enable session The primary requirement in 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.
This translates to, the target network entity for the BFD session, This translates to a need for the target network entity (for the BFD
upon receiving the BFD packet, should start processing for the session), should start processing for the discriminator received in
discriminator received. This will enable the source network entity to the BFD packet. This will enable the source network entity to
establish a unidirectional BFD session without bidirectional establish a unidirectional BFD session without the bidirectional
handshake of discriminators for session establishment. 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 does not
require to have sequences for session negotiation and discriminator require to have sequences for session negotiation and discriminator
exchanges in order to establish the BFD session. exchanges in order to establish the BFD session.
When these sequences for handshake are eliminated, the network When these sequences for handshake are eliminated, the network
entities need to know what the discriminator values to be used for entities need to know what the discriminator values to be used for
the session. The same is the case for S-BFD, i.e., when the three-way the session. The same is the case for S-BFD, i.e., when the three-
handshake mechanism is eliminated during bootstrap of BFD sessions. way handshake mechanism is eliminated during bootstrap of BFD
Due to this faster reachability validation of BFD provisioned sessions. However, this information is required at each entity to
paths/LSPs could be achieved. In addition, it is expected that some verify that BFD messages are being received from the expected end-
MPLS technologies will require traffic engineered LSPs to get created points, hence the handshake mechanism serves no purpose. Elimination
dynamically, driven by external applications, e.g. in Software of the unnecessary handshake mechanism allows for faster reachability
Defined Networks (SDN). It would be desirable to perform BFD validation of BFD provisioned paths/LSPs.
validation very quickly to allow applications to utilize dynamically
created LSPs in timely manner.
3.3. Centralized Traffic Engineering In addition, it is expected that some MPLS technologies will require
Various technologies in the SDN domain have evolved which involves traffic engineered LSPs to be created dynamically, perhaps driven by
controller based networks, where the intelligence, traditionally external applications, e.g. in Software Defined Networks (SDN). It
placed in the distributed and dynamic control plane, is separated will be desirable to perform BFD validation very quickly to allow
from the data plane and resides in a logically centralized place. applications to utilize dynamically created LSPs in a timely manner.
There are various controllers which perform this exact function in
establishing forwarding paths for the data flow. Traffic engineering 3.3. Centralized Traffic Engineering
is one important function, where the traffic is engineered depending
Various technologies in the SDN domain that involve controller based
networks have evolved where intelligence, traditionally placed in a
distributed and dynamic control plane, is separated from the data
plane and resides in a logically centralized place. There are
various controllers that perform this exact function in establishing
forwarding paths for the data flow. Traffic engineering is one
important function, where the traffic flow is engineered depending
upon various attributes of the traffic as well as the network state. upon various attributes of the traffic as well as the network state.
When the intelligence of the network resides in the centralized When the intelligence of the network resides in a centralized entity,
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 traffic working, is to establish BFD sessions within the network. When
engineering tunnels are created, it is operationally critical to traffic engineered tunnels are created, it is operationally critical
ensure that the forwarding paths are working prior to switching the to ensure that the forwarding paths are working prior to switching
traffic onto the engineered tunnels. In the absence of control plane the traffic onto the engineered tunnels. In the absence of control
protocols, it is not only the desire to verify the forwarding path plane protocols, it may be desirable to verify the forwarding path
but also an arbitrary path in the network. With tunnels being but also of any arbitrary path in the network. With tunnels being
engineered from the centralized entity, when the network state engineered by a centralized entity, when the network state changes,
changes, traffic has to be switched without much latency and black traffic has to be switched with minimum latency and black holing of
holing of the data. the data.
Traditional BFD session establishment and validation of the Traditional BFD session establishment and validation of the
forwarding path must not become bottleneck in the case of centralized forwarding path must not become a bottleneck in the case of
traffic engineering. If the controller or other centralized entity is centralized traffic engineering. If the controller or other
able to instantly verify a forwarding path of the TE tunnel , it centralized entity is able to instantly verify a forwarding path of
could steer the traffic onto the traffic engineered tunnel very the TE tunnel , it could steer the traffic onto the traffic
quickly thus minimizing adverse effect on a service. This is engineered tunnel very quickly thus minimizing adverse effect on a
especially useful and needed when the scale of the network and number service. This is especially useful and needed when the scale of the
of TE tunnels is too high. Session negotiation and establishment of network and number of TE tunnels is very high.
BFD sessions to identify valid paths is way to high in terms of time
and providing network redundancy becomes a critical issue.
3.4. BFD in Centralized Segment Routing The cost associated with BFD session negotiation and establishment of
BFD sessions to identify valid paths is very high and providing
network redundancy becomes a critical issue.
Centralized controller based Segment Routing network monitoring 3.4. BFD in Centralized Segment Routing
technique, is described in [I-D.geib-spring-oam-usecase]. In
A centralized controller based Segment Routing network monitoring
technique is described in [I-D.geib-spring-oam-usecase]. In
validating this use case, one of the requirements is to ensure the validating this use case, one of the requirements is to ensure the
BFD packet's behavior is according to the requirement and monitoring BFD packet's behavior is according to the requirement and monitoring
of the segment, where the packet is U-turned at the expected node. of the segment, where the packet is U-turned at the expected node.
One of the criterion is to ensure the continuity check to the One of the criterion is to ensure the continuity check to the
adjacent segment-id. adjacent segment-id.
3.5. BFD to Efficiently Operate under Resource Constraints 3.5. BFD Efficient Operation Under Resource Constraints
When BFD sessions are being setup, torn down or parameters (i.e. When BFD sessions are being setup, torn down or modified (i.e.
interval, multiplier, etc) are being modified, BFD protocol requires parameters ? such as interval, multiplier, etc are being modified),
additional packets outside of scheduled packet transmissions to BFD requires additional packets other than scheduled packet
complete the negotiation procedures (i.e. P/F bits). There are transmissions to complete the negotiation procedures (i.e. P/F
scenarios where network resources are constrained: a node may require bits). There are scenarios where network resources are constrained:
BFD to monitor very large number of paths, or BFD may need to operate a node may require BFD to monitor very large number of paths, or BFD
in low powered and traffic sensitive networks, i.e. microwave, low may need to operate in low powered and traffic sensitive networks,
powered nano-cells, etc. In these scenarios, it is desirable for BFD i.e. microwave, low powered nano-cells, etc. In these scenarios, it
to slow down, speed up, stop or resume at will without requiring is desirable for BFD to slow down, speed up, stop or resume at will
additional BFD packets to be exchanged. witho minimal additional BFD packets exchanged to establish a new or
modified session.
3.6. BFD for Anycast Address 3.6. BFD for Anycast Address
BFD protocol requires the 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.
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 and BFD MPLS traverse multiple network nodes. BFD has
been designed to declare failure upon lack of consecutive packet been designed to declare failure upon lack of consecutive packet
reception, which can be caused by any fault anywhere along the path. reception, which can be caused by a fault anywhere along the path.
Fast failure detection provides great benefits, as it can trigger Fast failure detection allows for rapid path recovery procedures.
recovery procedures rapidly. However, operators often have to follow However, operators often have to follow up, manually or
up, manually or automatically, to attempt to identify and localize automatically, to attempt to identify and localize the fault that
the fault which caused the BFD sessions to fail. Usage of other tools caused BFD sessions to fail. Usage of other tools to isolate the
to isolate the fault may cause the packets to traverse differently fault may cause the packets to traverse a different path through the
throughout the network (i.e. ECMP). In addition, longer it takes from network (e.g. if ECMP is used). In addition, the longer it takes
BFD session failure to fault isolation attempt, more likely that from BFD session failure to fault isolation attempt, more likely that
fault cannot be isolated, i.e. fault can get corrected or routed the fault cannot be isolated, e.g. a fault can get corrected or
around. If BFD had built-in fault isolation capability, fault routed around. If BFD had built-in fault isolation capability, fault
isolation can get triggered at the earliest sign of fault and such isolation can get triggered at the earliest sign of fault and such
packets will get load balanced in very similar way, if not the same, packets will get load balanced in very similar way, if not the same,
as BFD packets which went missing. as BFD packets that went missing.
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 transmitting BFD packets at negotiated
rate. If BFD packet transmission is interrupted, even for a very rate. If BFD packet transmission is interrupted, even for a very
short period of time, that can result in BFD to declare failure short 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
BFD for MPLS, defined in [RFC5884], describes procedures to run BFD BFD for MPLS, defined in [RFC5884], describes procedures to run BFD
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
skipping to change at page 9, line 5 skipping to change at page 8, line 17
[RFC5884] in terms of how to bootstrap and maintain correct set of [RFC5884] in terms of how to bootstrap and maintain correct set of
BFD sessions on the egress node. However, that may require constant BFD sessions on the egress node. However, that may require constant
use of MPLS Echo Request messages to create and delete BFD sessions use of MPLS Echo Request messages to create and delete BFD sessions
on the egress node, when ECMP paths and/or corresponding load balance on the egress node, when ECMP paths and/or corresponding load balance
hash keys change. If a BFD session over any paths of the LSP can be hash keys 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 4. Security Considerations
There are no new security considerations introduced by this draft. There are no new security considerations associated with this draft.
5. IANA Considerations 5. IANA Considerations
There are no new IANA considerations introduced by this draft There are no IANA considerations introduced by this draft
6. References 6. Contributors
6.1. Normative References Carlos Pignataro
Cisco Systems
Email: cpignata@cisco.com
Glenn Hayden
ATT
Email: gh1691@att.com
Santosh P K
Juniper
Email: santoshpk@juniper.net
Mach Chen
Huawei
Email: mach.chen@huawei.com
Nobo Akiya
Cisco Systems
Email: nobo@cisco.com
7. Acknowledgements
The authors would like to thank Eric Gray for his useful comments.
8. Normative References
[I-D.geib-spring-oam-usecase]
?, "Geib, R., Filsfils, C., Pignataro, C. and Kumar, N.,
"SR MPLS monitoring use case", draft-geib-spring-oam-
usecase-03(work in progress), October 2014.", 1900.
[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,
February 2006. February 2006.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC5880, June 2010. (BFD)", RFC 5880, June 2010.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC5881, June 2010. (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June
2010.
[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for Multihop Paths", RFC5883, June 2010. (BFD) for Multihop Paths", RFC 5883, June 2010.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label "Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC5884, June 2010. Switched Paths (LSPs)", RFC 5884, June 2010.
6.2. Informative References
[I-D.geib-spring-oam-usecase] Geib, R., Filsfils, C., Pignataro, C.
and Kumar, N., "SR MPLS monitoring use case", draft-geib-
spring-oam-usecase-03(work in progress), October 2014.
7. Authors' Addresses Authors' Addresses
Sam Aldrin Sam Aldrin
Huawei Technologies
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95051
EMail: aldrin.ietf@gmail.com Email: aldrin.ietf@gmail.com
Manav Bhatia Manav Bhatia
Ionos Networks Ionos Networks
EMail: manav@ionosnetworks.com Email: manav@ionosnetworks.com
Satoru Matsushima Satoru Matsushima
Softbank Softbank
EMail: satoru.matsushima@g.softbank.co.jp Email: satoru.matsushima@g.softbank.co.jp
Greg Mirsky Greg Mirsky
Ericsson Ericsson
EMail: gregory.mirsky@ericsson.com Email: gregory.mirsky@ericsson.com
Nagendra Kumar Nagendra Kumar
Cisco Cisco
EMail: naikumar@cisco.com Email: naikumar@cisco.com
8. Contributors
Carlos Pignataro
Cisco Systems
Email: cpignata@cisco.com
Glenn Hayden
ATT
Email: gh1691@att.com
Santosh P K
Juniper
Email: santoshpk@juniper.net
Mach Chen
Huawei
Email: mach.chen@huawei.com
Nobo Akiya
Cisco Systems
Email: nobo@cisco.com
 End of changes. 72 change blocks. 
234 lines changed or deleted 267 lines changed or added

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