draft-ietf-bfd-seamless-use-case-08.txt   rfc7882.txt 
Network Working Group S. Aldrin Internet Engineering Task Force (IETF) S. Aldrin
Internet-Draft Google, Inc Request for Comments: 7882 Google, Inc.
Intended status: Informational C. Pignataro Category: Informational C. Pignataro
Expires: November 7, 2016 Cisco ISSN: 2070-1721 Cisco
G. Mirsky G. Mirsky
Ericsson Ericsson
N. Kumar N. Kumar
Cisco Cisco
May 6, 2016 July 2016
Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases
draft-ietf-bfd-seamless-use-case-08
Abstract Abstract
This document describes various use cases for a Seamless This document describes various use cases for Seamless Bidirectional
Bidirectional Forwarding Detection (S-BFD), and provides requirements Forwarding Detection (S-BFD) and provides requirements such that
such that protocol mechanisms allow for a simplified detection of protocol mechanisms allow for simplified detection of forwarding
forwarding failures. failures.
These use cases support S-BFD, as a simplified mechanism to use These use cases support S-BFD, which is a simplified mechanism for
Bidirectional Forwarding Detection (BFD) with large portions of using BFD with a large proportion of negotiation aspects eliminated,
negotiation aspects eliminated, accelerating the establishment of a accelerating the establishment of a BFD session. The benefits of
BFD session. S-BFD benefits include quick provisioning as well as S-BFD include quick provisioning, as well as improved control and
improved control and flexibility to network nodes initiating the path flexibility for network nodes initiating path monitoring.
monitoring.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on November 7, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7882.
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
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 ....................................................3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology ................................................3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Introduction to Seamless BFD ....................................4
2. Introduction to Seamless BFD . . . . . . . . . . . . . . . . 4 3. Use Cases .......................................................5
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Unidirectional Forwarding Path Validation ..................5
3.1. Unidirectional Forwarding Path Validation . . . . . . . . 5 3.2. Validation of the Forwarding Path prior to
3.2. Validation of the Forwarding Path Prior to Switching Switching Traffic ..........................................6
Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Centralized Traffic Engineering ............................7
3.3. Centralized Traffic Engineering . . . . . . . . . . . . . 7 3.4. BFD in Centralized Segment Routing .........................8
3.4. BFD in Centralized Segment Routing . . . . . . . . . . . 8 3.5. Efficient BFD Operation under Resource Constraints .........8
3.5. Efficient BFD Operation under Resource Constraints . . . 8 3.6. BFD for Anycast Addresses ..................................8
3.6. BFD for Anycast Addresses . . . . . . . . . . . . . . . . 8 3.7. BFD Fault Isolation ........................................9
3.7. BFD Fault Isolation . . . . . . . . . . . . . . . . . . . 9 3.8. Multiple BFD Sessions to the Same Target Node ..............9
3.8. Multiple BFD Sessions to the Same Target Node . . . . . . 9 3.9. An MPLS BFD Session per ECMP Path .........................10
3.9. An MPLS BFD Session Per ECMP Path . . . . . . . . . . . . 10 4. Detailed Requirements for Seamless BFD .........................11
4. Detailed Requirements for a Seamless BFD . . . . . . . . . . 10 5. Security Considerations ........................................12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. References .....................................................12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References ......................................12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Informative References ....................................13
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 Acknowledgements ..................................................15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 Contributors ......................................................15
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses ................................................15
9.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
Bidirectional Forwarding Detection (BFD) is a lightweight protocol, Bidirectional Forwarding Detection (BFD), as defined in [RFC5880], is
as defined in [RFC5880], used to detect forwarding failures. Various a lightweight protocol used to detect forwarding failures. Various
protocols and applications rely on BFD as its clients for failure protocols, applications, and clients rely on BFD for failure
detection. Even though the protocol is lightweight and simple, there detection. Even though the protocol is lightweight and simple, there
are certain use cases where faster setting up of sessions and faster are certain use cases where faster setup of sessions and faster
continuity check of the data forwarding paths is necessary. This continuity checks of the data-forwarding paths are necessary. This
document identifies these use cases and consequent requirements, such document identifies these use cases and consequent requirements, such
that enhancements and extensions result in a Seamless BFD (S-BFD) that enhancements and extensions result in a Seamless BFD (S-BFD)
protocol. protocol.
BFD is a simple lightweight "Hello" protocol to detect data plane BFD is a simple and 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 not only scale, establishing BFD sessions for each of those paths not only
creates operational complexity, but also causes undesirable delay in creates operational complexity but also causes undesirable delay in
establishing or deleting sessions. The existing session establishing or deleting sessions. The existing session
establishment mechanism of the BFD protocol has to be enhanced in establishment mechanism of the BFD protocol has to be enhanced in
order to minimize the time for the session to come up to validate the order to minimize the time for 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. Specifically, one key goal is removing the supporting protocols. Specifically, one key goal is removing the
time delay (i.e., the "seam") between a network node wants to perform time delay (i.e., the "seam") between when a network node wants to
a continuity test and the node completes that continuity test. perform a continuity test and when the node completes that continuity
Consequently, "Seamless BFD" (S-BFD) has been chosen as the name for test. Consequently, "Seamless BFD" (S-BFD) has been chosen as the
this mechanism. name for this mechanism.
While the identified requirements could meet various use cases, it is While the identified requirements could meet various use cases, it is
outside the scope of this document to identify all of the possible outside the scope of this document to identify all of the possible
and necessary requirements. Solutions to the identified uses cases and necessary requirements. Solutions related to the identified use
and protocol specific enhancements or proposals are outside the scope cases and protocol-specific enhancements or proposals are outside the
of this document as well. Protocol definitions to support these use scope of this document as well. Protocol definitions to support
cases can be found at [I-D.ietf-bfd-seamless-base] and these use cases can be found in [RFC7880] and [RFC7881].
[I-D.ietf-bfd-seamless-ip].
1.1. Terminology 1.1. Terminology
The reader is expected to be familiar with the BFD [RFC5880], IP The reader is expected to be familiar with the BFD [RFC5880], IP
[RFC0791] [RFC2460], MPLS [RFC3031], and Segment Routing (SR) [RFC791] [RFC2460], MPLS [RFC3031], and Segment Routing [SR-ARCH]
[I-D.ietf-spring-segment-routing] terminologies and protocol terms and protocol constructs.
constructs.
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. These discriminators enable the locally allocated discriminators. These discriminators enable the
identification of the sender and the receiver of BFD packets over the identification of the sender and the receiver of BFD packets over the
particular session. Subsequently, BFD performs proactive continuity particular session. Subsequently, BFD performs proactive continuity
monitoring of the forwarding path between the two. Several monitoring of the forwarding path between the two. Several
specifications describe BFD's multiple deployment uses: specifications describe BFD's multiple deployment uses:
[RFC5881] defines BFD over IPv4 and IPv6 for single IP hops o [RFC5881] defines BFD over IPv4 and IPv6 for single IP hops.
[RFC5883] defines BFD over multihop paths o [RFC5883] defines BFD over multi-hop paths.
[RFC5884] defines BFD for MPLS Label Switched Paths (LSPs) o [RFC5884] defines BFD for MPLS Label Switched Paths (LSPs).
[RFC5885] defines BFD for MPLS Pseudowires (PWs) o [RFC5885] defines BFD for MPLS Pseudowires (PWs).
Currently, BFD is best suited to verify that two endpoints are Currently, BFD is best suited for verifying that two endpoints are
mutually reachable or that an existing connection continues to be up 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 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 connection is valid and that it connects the expected set of
endpoints, it is necessary to provide each endpoint with the endpoints, it is necessary to provide each endpoint with the
discriminators associated with the connection at each endpoint prior discriminators associated with the connection at each endpoint prior
to initiating BFD sessions. The discriminators are used to verify to initiating BFD sessions. The discriminators are used to verify
that the connection is up and verifiable. Currently, the exchange of that the connection is up and valid. Currently, the exchange of
discriminators and the demultiplexing of the initial BFD packets is discriminators and the demultiplexing of the initial BFD packets are
application dependent. application dependent.
If this information is already known to the end-points of a potential If this information is already known to the endpoints of a potential
BFD session, the initial handshake including an exchange of BFD session, the initial handshake including an exchange of
discriminators is unnecessary and it is possible for the endpoints to discriminators is unnecessary, and it is possible for the endpoints
begin BFD messaging seamlessly. A key objective of the S-BFD use to begin BFD messaging seamlessly. A key objective of the S-BFD use
cases described in this document is to avoid needing to exchange the cases described in this document is to avoid needing to exchange the
initial packets before the BFD session can be established, with the initial packets before the BFD session can be established, with the
goal of getting to the established state more quickly; in other goal of getting to the established state more quickly; in other
words, the initial exchange of discriminator information is an words, the initial exchange of discriminator information is an
unnecessary extra step that may be avoided for these cases. unnecessary extra step that may be avoided for these cases.
In a given scenario, an entity (such as an operator, or a centralized In a given scenario, an entity (such as an operator or a centralized
controller) determines a set of network entities to which BFD controller) determines a set of network entities to which BFD
sessions might need to be established. In traditional BFD, each of sessions might need to be established. In traditional BFD, each of
those network entities chooses a BFD discriminator for each BFD those network entities chooses a BFD Discriminator for each BFD
session that the entity will participate in (see Section 6.3 of session that the entity will participate in (see Section 6.3 of
[RFC5880]). However, a key goal of a Seamless BFD is to provide [RFC5880]). However, a key goal of S-BFD is to provide operational
operational simplification. In this context, for S-BFD, each of simplification. In this context, for S-BFD, each of those network
those network entities is assigned one or more BFD discriminators, entities is assigned one or more BFD Discriminators, and those
and allowing those network entities to use one discriminator value network entities are allowed to use one Discriminator value for
for multiple sessions. Therefore, there may be only one or a few multiple sessions. Therefore, there may be only one or a few
discriminators assigned to a node. These network entities will discriminators assigned to a node. These network entities will
create an S-BFD listener session instance that listens for incoming create an S-BFD listener session instance that listens for incoming
BFD control packets. When the mappings between specific network BFD Control packets. When the mappings between specific network
entities and their corresponding BFD discriminators are known to entities and their corresponding BFD Discriminators are known to
other network nodes belonging to the same administrative domain, other network nodes belonging to the same administrative domain,
then, without having received any BFD packet from a particular then, without having received any BFD packets from a particular
target, a network entity in this network is able to send a BFD target, a network entity in this network is able to send a BFD
control packet to the target's assigned discriminator in the Your Control packet to the target's assigned discriminator in the
Discriminator field. The target network node, upon reception of such Your Discriminator field. The target network node, upon reception of
BFD control packet, will transmit a response BFD control packet back such a BFD Control packet, will transmit a response BFD Control
to the sender. 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 a 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 the benefits of forwarding failure
detection using existing BFD mechanics. Both these high-level goals detection using existing BFD mechanisms. Both of these high-level
result in the S-BFD use cases. goals result in the S-BFD use cases outlined in this document.
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 paths 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 unidirectional path. forwarding path for that statically established unidirectional path.
Validation of the forwarding path in the direction of the target Validation of the forwarding path in the direction of the target
entity to the originating entity is not required, in this scenario. entity to the originating entity is not required in this scenario.
Many LSPs have the same unidirectional characteristics and Many LSPs have the same unidirectional characteristics and
unidirectional validation requirements. Such LSPs are common in unidirectional validation requirements. Such LSPs are common in
Segment Routing and LDP based MPLS networks. A final example is when Segment Routing and LDP-based MPLS networks. A final example is when
a unidirectional tunnel uses BFD to validate reachability of an a unidirectional tunnel uses BFD to validate the reachability of an
egress node. egress node.
Additionally, there are operational implications to the Additionally, validation of the unidirectional path has operational
unidirectional path validation. If the traditional BFD is to be implications. If traditional BFD is to be used, the target network
used, the target network entity has to be provisioned as well as an entity, as well as an initiator, has to be provisioned, even though
initiator, even though the reverse path validation with the BFD reverse-path validation with the BFD session is not required.
session is not required. However, in the case of unidirectional BFD, However, in the case of unidirectional BFD, there is no need for
there is no need for provisioning on the target network entity, only provisioning on the target network entity -- only on the source
the source one. entity.
In this use case, a BFD session could be established in a single In this use case, a BFD session could be established in a single
direction. When the targeted network entity receives the packet, it direction. When the target network entity receives the packet, it
identities the packet as BFD in an application-specific manner (for identifies the packet as BFD in an application-specific manner (for
example, a destination UDP port number). Subsequently, the BFD example, a destination UDP port number). Subsequently, the BFD
module processes the packet, using the Your Discriminator value as module processes the packet, using the Your Discriminator value as
context. Then, the network entity sends a response to the context. Then, the network entity sends a response to the
originator. This does not necessitate the requirement for originator. This does not necessitate the requirement for
establishment of a bi-directional session, hence the two way establishment of a bidirectional session; hence, the two-way
handshake to exchange discriminators is not needed. The target node handshake to exchange discriminators is not needed. The target node
does not need to know the My Discriminator of the source node. does not need to know the My Discriminator value of the source node.
Thus, a requirement for BFD for this use case is to enable session Thus, in this use case a requirement for BFD is to enable session
establishment from source network entity to target network entity establishment from the source network entity to the target network
without the need to have a session (and state) for the reverse entity without the need to have a session (and state) for the reverse
direction. Further, another requirement is that the BFD response direction. Further, another requirement is that the BFD response
from target back to sender can take any (in-band or out-of-band) from the target back to the sender can take any (in-band or
path. The BFD module in the target network entity (for the BFD out-of-band) path. The BFD module in the target network entity (for
session), upon receipt of BFD packet, starts processing the BFD the BFD session), upon receipt of a BFD packet, starts processing the
packet based on the discriminator received. The source network BFD packet based on the discriminator received. The source network
entity can therefore establish a unidirectional BFD session without entity can therefore establish a unidirectional BFD session without
the bidirectional handshake and exchange of discriminators for the bidirectional handshake and exchange of discriminators for
session establishment. session establishment.
3.2. Validation of the Forwarding Path Prior to Switching Traffic 3.2. Validation of the Forwarding Path prior to Switching Traffic
This use case is when BFD is used to verify reachability before In this use case, BFD is used to verify reachability before sending
sending traffic via a path/LSP. This comes with a cost, which is traffic via a path/LSP. This comes at a cost: traffic is prevented
that traffic is prevented to use the path/LSP until BFD is able to from using the path/LSP until BFD is able to validate reachability;
validate the reachability, which could take seconds due to BFD this could take seconds due to BFD session bring-up sequences
session bring-up sequences [RFC5880], LSP ping bootstrapping [RFC5880], LSP Ping bootstrapping [RFC5884], etc. This use case
[RFC5884], etc. This use case would be better supported by would be better supported by eliminating the need for the initial BFD
eliminating the need for the initial BFD session negotiation. session negotiation.
All it takes to be able to send BFD packets to a target, and the All it takes to be able to send BFD packets to a target and for the
target properly demultiplexing these, is for the source network target to properly demultiplex these packets is for the source
entities to know what the discriminator values to be used for the network entities to know what Discriminator values will be used for
session. The same is the case for S-BFD: the three-way handshake the session. This is also the case for S-BFD: the three-way
mechanism is eliminated during the bootstrap of BFD sessions. handshake mechanism is eliminated during the bootstrapping of BFD
However, this information is required at each entity to verify that sessions. However, this information is required at each entity to
BFD messages are being received from the expected end-points, hence verify that BFD messages are being received from the expected
the handshake mechanism serves no purpose. Elimination of the endpoints; hence, the handshake mechanism serves no purpose.
unnecessary handshake mechanism allows for faster reachability Elimination of the unnecessary handshake mechanism allows for faster
validation of BFD provisioned paths/LSPs. 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, as e.g. in Software Defined Networks (SDN). external applications, as, for example, in Software-Defined
Networking (SDN). It will be desirable to perform BFD validation as
It will be desirable to perform BFD validation as soon as the LSPs soon as the LSPs are created, so as to use them.
are created, so as to use them.
In order to support this use case, an S-BFD session is established In order to support this use case, an S-BFD session is 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 such that the intelligence, traditionally networks have evolved such that the intelligence, traditionally
placed in a distributed and dynamic control plane, is separated from placed in a distributed and dynamic control plane, is separated from
the networking entities themselves; instead, it 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 the function in establishment of forwarding paths for the perform the function of establishing forwarding paths for the data
data flow. Traffic engineering (TE) is one important function, where flow. Traffic engineering is one important function, where the path
the path of the traffic flow is engineered, depending upon various of the traffic flow is engineered, depending upon various attributes
attributes and constraints of the traffic paths as well as the and constraints of the traffic paths as well as the network state.
network state.
When the intelligence of the network resides in a centralized entity, When the intelligence of the network resides in a centralized entity,
the ability to manage and maintain the dynamic network and its the ability to manage and maintain the dynamic network, and its
multiple data paths and node reachability becomes a challenge. One multiple data paths and node reachability, becomes a challenge. One
way to ensure the forwarding paths are valid and working is done by way to ensure that the forwarding paths are valid and working is done
validation using BFD. When traffic engineered tunnels are created, by validation using BFD. When traffic-engineered tunnels are
it is operationally critical to ensure that the forwarding paths are created, it is operationally critical to ensure that the forwarding
working, prior to switching the traffic onto the engineered tunnels. paths are working, prior to switching the traffic onto the engineered
In the absence of distributed control plane protocols, it may be tunnels. In the absence of distributed control-plane protocols, it
desirable to verify any arbitrary forwarding path in the network. may be desirable to verify any arbitrary forwarding path in the
With tunnels being engineered by a centralized entity, when the network. With tunnels being engineered by a centralized entity, when
network state changes, traffic has to be switched with minimum the network state changes, traffic has to be switched with minimum
latency and without black-holing of the data. latency and without black-holing of the data.
It is highly desirable in this centralized traffic engineering use It is highly desirable in this centralized traffic-engineering use
case that the traditional BFD session establishment and validation of case that the traditional BFD session establishment and validation of
the forwarding path does not become a bottleneck. If the controller the forwarding path do not become a bottleneck. If the controller or
or other centralized entity is able to very rapidly verify the other centralized entity is able to very rapidly verify the
forwarding path of a traffic engineered tunnel, it could steer the forwarding path of a traffic-engineered tunnel, it could steer the
traffic onto the traffic engineered tunnel very quickly thus traffic onto the traffic-engineered tunnel very quickly, thus
minimizing adverse effect on a service. This is even more useful and minimizing adverse effects on a service. This is even more useful
necessary when the scale of the network and number of traffic and necessary when the scale of the network and the number of
engineered tunnels grows. traffic-engineered tunnels grow.
The cost associated with the time required for BFD session The cost associated with the time required for BFD session
negotiation and establishment of BFD sessions to identify valid paths negotiation and establishment of BFD sessions to identify valid paths
is very high when providing network redundancy is 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 for a Segment Routing network based on a
centralized controller is described in [I-D.ietf-spring-oam-usecase]. centralized controller is described in [SR-MPLS]. Specific
Specific OAM requirements for Segment Routing are captured in Operations, Administration, and Maintenance (OAM) requirements for
[I-D.ietf-spring-sr-oam-requirement]. In validating this use case, Segment Routing are captured in [SR-OAM-REQS]. In validating this
one of the requirements is to ensure that the BFD packet's behavior use case, one of the requirements is to ensure that the BFD packet's
is according to the monitoring specified for the segment, and that behavior is according to the monitoring specified for the segment and
the packet is U-turned at the expected node. This criteria ensures that the packet is U-turned at the expected node. This criterion
the continuity check to the adjacent segment-id. ensures the continuity check to the adjacent Segment Identifier.
To support this use case, the operational requirement is for BFD, To support this use case, the operational requirement is for BFD,
initiated from a centralized controller, to perform liveness initiated from a centralized controller, to perform liveness
detection for any given segment under its domain. detection for any given segment in 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 When BFD sessions are being set up, torn down, or modified (i.e.,
parameters such as interval and multiplier are being modified), BFD when parameters such as intervals and multipliers are being
requires additional packets other than scheduled packet transmissions modified), BFD requires additional packets, other than scheduled
to complete the negotiation procedures (i.e., P/F bits). There are packet transmissions, to complete the negotiation procedures (i.e.,
scenarios where network resources are constrained: a node may require Poll (P) bits and Final (F) bits; see Section 4.1 of [RFC5880]).
BFD to monitor very large number of paths, or BFD may need to operate There are scenarios where network resources are constrained: a node
in low powered and traffic sensitive networks; these include may require BFD to monitor a very large number of paths, or BFD may
microwave, low powered nano-cells, and others. In these scenarios, need to operate in low-powered and traffic-sensitive networks; these
it is desirable for BFD to slow down, speed up, stop, or resume at- include microwave systems, low-powered nanocells, and others. In
will and with minimal number of additional BFD packets exchanged to these scenarios, it is desirable for BFD to slow down, speed up,
modify the session or establish a new one. stop, or resume at will and with a minimal number of additional BFD
packets exchanged to modify the session or establish a new one.
The established BFD session parameters and attributes like The established BFD session parameters, and such attributes as
transmission interval, receiver interval, etc., need to be modifiable transmission interval and receiver interval, need to be modifiable
without changing the state of the session. without changing the state of the session.
3.6. BFD for Anycast Addresses 3.6. BFD for Anycast Addresses
The 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.
This use case verifies that a source node can send a packet to an This use case verifies that a source node can send a packet to an
anycast address, and that the target node to which the packet is anycast address and that the target node to which the packet is
delivered can send a response packet to the source node. Traditional delivered can send a response packet to the source node. Traditional
BFD cannot fulfill this requirement, since it does not provide for a BFD cannot fulfill this requirement, since it does not provide for a
set of BFD agents to collectively form one endpoint of a BFD session. 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. The concept of a "target listener" in S-BFD fulfills this
requirement.
To support this use case, the BFD sender transmits BFD packets, which 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 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 the BFD packets are being sent. The anycast target that receives the
packet, responds. This use case does not imply the BFD session BFD packet responds. This use case does not imply BFD session
establishment with every node hosting the anycast address. establishment with every node hosting the anycast address.
Consequently, in this any cast use case, target nodes that do not Consequently, in this anycast use case, target nodes that do not
happen to receive any of the BFD packets do not need to maintain any 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 state, and the source node does not need to maintain separate state
for each target node. for each target node.
3.7. BFD Fault Isolation 3.7. BFD Fault Isolation
BFD for multihop paths [RFC5883] and BFD for MPLS LSPs [RFC5884] BFD for multi-hop paths [RFC5883] and BFD for MPLS LSPs [RFC5884]
perform end-to-end validation, traversing multiple network nodes. perform end-to-end validation, traversing multiple network nodes.
BFD has been designed to declare failure upon lack of consecutive BFD has been designed to declare a failure to receive some number of
packet reception, which can be caused by a fault anywhere along these consecutive packets. This failure can be caused by a fault anywhere
path. Fast failure detection allows for rapid fault detection and along these paths. Fast failure detection allows for rapid fault
consequent rapid path recovery procedures. However, operators often detection and consequent rapid path recovery procedures. However,
have to follow up, manually or automatically, to attempt to identify operators often have to follow up, manually or automatically, to
and localize the fault that caused BFD sessions to fail (i.e., fault attempt to identify and localize the fault that caused BFD sessions
isolation). The usage of other tools to isolate the fault (e.g., to fail (i.e., fault isolation). If Equal-Cost Multipath (ECMP) is
used, the usage of other tools to isolate the fault (e.g.,
traceroute) may cause the packets to traverse a different path traceroute) may cause the packets to traverse a different path
through the network, if Equal-Cost Multipath (ECMP) is used. In through the network. In addition, the longer it takes from the time
addition, the longer it takes from BFD session failure to starting of BFD session failure to the time that fault isolation begins, the
fault isolation, the more likely that the fault will not be able to more likely the fault will not be isolated (e.g., a fault may be
be isolated (e.g., a fault can get corrected or routed around). If corrected via rerouting or some other means during that time). If
BFD had built-in fault isolation capability, fault isolation can get BFD had built-in fault-isolation capability, fault isolation would be
triggered at the earliest sign of fault detection. This embedded triggered when the fault was first detected. This embedded fault
fault isolation will be more effective when those BFD fault isolation isolation would be more effective (i.e., faults would be detected
packets are load balanced in the same way as the BFD packets that sooner) if those BFD fault-isolation packets were load-balanced in
were dropped, detecting the fault. the same way as the BFD packets that were dropped.
This use case describes S-BFD fault isolation capabilities, utilizing This use case describes S-BFD fault-isolation capabilities, utilizing
a TTL field (e.g., as in Section 5.1.1 of [I-D.ietf-bfd-seamless-ip]) a TTL field (e.g., as described in Section 5.1.1 of [RFC7881]) or
or using status indicating fields. using fields that indicate status.
3.8. Multiple BFD Sessions to the Same Target Node 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 the negotiated network nodes continuously transmit BFD packets at the 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, BFD can declare a failure irrespective of path short period of time, BFD can declare a failure irrespective of path
liveliness. It is possible, on a system where BFD is running, for liveness. On a system where BFD is running, it is possible for
certain events (intentionally or unintentionally) to cause a short certain events to (intentionally or unintentionally) cause a brief
interruption of BFD packet transmissions. With distributed interruption of BFD packet transmissions. With distributed
architectures of BFD implementations, this case can be protected. In architectures of BFD implementations, this case can be prevented.
this case, the use case of an S-BFD node running multiple BFD This use case is for an S-BFD node running multiple BFD sessions to
sessions to a targets, with those sessions hosted on different system the same target node, with those sessions hosted on different system
modules (e.g., in different CPU instances). This can reduce BFD modules (e.g., in different CPU instances). This can reduce false
false failures, resulting in more stable network. failures, resulting in a more stable network.
To support this use case, a mapping between the multiple To support this use case, a mapping between the multiple
discriminators on a single system, and the specific entity within the discriminators on a single system and the specific entity within that
system is required. system is required.
3.9. An MPLS BFD Session Per ECMP Path 3.9. An MPLS BFD Session per ECMP Path
BFD for MPLS LSPs, defined in [RFC5884], describes procedures to run BFD for MPLS LSPs, defined in [RFC5884], describes procedures for
BFD as LSP in-band continuity check mechanism, through usage of MPLS running BFD as an LSP in-band continuity check mechanism by using
echo request [RFC4379] to bootstrap the BFD session on the target MPLS Echo Request messages [RFC4379] to bootstrap the BFD session on
(i.e., egress) node. Section 4 of [RFC5884] also describes a the target (i.e., egress) node. Section 4 of [RFC5884] also
possibility of running multiple BFD sessions per alternative paths of describes the possibility of running multiple BFD sessions per
LSP. [RFC7726] further clarified the procedures, both for ingress alternative of LSPs. [RFC7726] further clarifies the procedures, for
and egress nodes, of how to bootstrap, maintain, and remove multiple both ingress and egress nodes, regarding how to bootstrap, maintain,
BFD sessions for the same <MPLS LSP, FEC> tuple. However, this and remove multiple BFD sessions for the same <MPLS LSP, FEC> tuple
mechanism still requires the use of MPLS LSP Ping for bootstrapping, ("FEC" means Forwarding Equivalence Class). However, this mechanism
round-trips for initialization, and keeping state at the receiver. 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 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. run in-band monitoring that exercises every path of this ECMP.
Otherwise there will be scenarios where in-band BFD session remains Otherwise, there will be scenarios where an in-band BFD session
up through one path but traffic is black-holing over another path. A remains up through one path but traffic is black-holing over another
BFD session per ECMP path of an LSP requires the definition of path. A BFD session per ECMP path of an LSP requires the definition
procedures that update [RFC5884] in terms of how to bootstrap and of procedures that update [RFC5884] in terms of how to bootstrap and
maintain the correct set of BFD sessions on the egress node. maintain the correct set of BFD sessions on the egress node.
However, for traditional BFD, that requires the constant use of MPLS 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 an MPLS echo request message, it procedures for bootstrapping via an MPLS Echo Request message, it
would greatly simplify both implementations and operations, and would greatly simplify both implementations and operations and
benefits network devices as less processing are required by them. would benefit network devices, as less processing would be required
by them.
To support this requirement, multiple S-BFD sessions need 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 between the same pair of source
node. and target nodes.
4. Detailed Requirements for a Seamless BFD 4. Detailed Requirements for Seamless BFD
REQ#1: A target network entity (for the S-BFD session), upon REQ 1: Upon receipt of an S-BFD packet, a target network entity
receipt of the S-BFD packet, MUST process the packet based (for the S-BFD session) MUST process the packet based on the
on the discriminator received in the BFD packet. If the discriminator received in the BFD packet. If the S-BFD
S-BFD context is found, the target network entity MUST be context is found, the target network entity MUST be able to
able to send a response. send a response.
REQ#2: The source network entity MUST be able to establish a REQ 2: The source network entity MUST be able to establish a
unidirectional S-BFD session without the bidirectional unidirectional S-BFD session without the bidirectional
handshake of discriminators for session establishment. handshake of discriminators for session establishment.
REQ#3: The S-BFD session MUST be able to be established without the REQ 3: The S-BFD session MUST be able to be established without the
need for exchange of discriminators in session negotiation. need for the exchange of discriminators during session
negotiation.
REQ#4: In a Segment Routed network, S-BFD MUST be able to perform REQ 4: In a Segment Routed network, S-BFD MUST be able to perform
liveness detection initiated from a centralized controller liveness detection initiated from a centralized controller
for any given segment under its domain. for any given segment in its domain.
REQ#5: The established S-BFD session parameters and attributes, REQ 5: The established S-BFD session parameters and attributes,
such as transmission interval, reception interval, etc., such as transmission interval and reception interval, MUST
MUST be modifiable without changing the state of the be modifiable without changing the state of the session.
session.
REQ#6: An S-BFD source network entity MUST be able to send S-BFD REQ 6: An S-BFD source network entity MUST be able to send Control
control packets to an anycast address which are received by packets to an anycast address. These packets are received
any node hosting that address, and must be able to receive and processed by any node hosting the anycast address. The
responses from any of these anycast nodes, without S-BFD entity MUST be able to receive responses to S-BFD
establishing a separate BFD session with every node hosing Control packets from any of these anycast nodes, without
the anycast address. establishing a separate S-BFD session with every node
hosting the anycast address.
REQ#7: S-BFD SHOULD support fault isolation capability, which MAY REQ 7: S-BFD SHOULD support fault-isolation capability, which MAY
be triggered when a fault is encountered. be triggered when a fault is encountered.
REQ#8: S-BFD SHOULD be able to establish multiple sessions between REQ 8: S-BFD SHOULD be able to establish multiple sessions between
the same pair of source and target nodes. This requirement the same pair of source and target nodes. This requirement
enables but does not guarantee the ability to monitor enables but does not guarantee the ability to monitor
diverge paths in ECMP environments. It also provides divergent paths in ECMP environments. It also provides
resiliency in distributed router architectures. The mapping resiliency in distributed router architectures. The mapping
between BFD discriminators and particular entities (e.g., between BFD Discriminators and particular entities (e.g.,
ECMP paths, or Line Cards) is out the scope of the S-BFD ECMP paths, line cards) is out of scope for the S-BFD
specification. protocol.
REQ#9: The S-BFD protocol MUST provide mechanisms for loop REQ 9: The S-BFD protocol MUST provide mechanisms for loop
detection and prevention, protecting against malicious detection and prevention, protecting against malicious
attacks attempting to create packet loops. attacks attempting to create packet loops.
REQ#10: S-BFD MUST incorporate robust security protections against REQ 10: S-BFD MUST incorporate robust security protections against
impersonators, malicions actors, and various active and impersonators, malicious actors, and various active and
passive attacks. The simple and accelerated establishment passive attacks. The simple and accelerated establishment
of an S-BFD session should not negatively affect security. of an S-BFD session should not negatively affect security.
5. Security Considerations 5. Security Considerations
This document details the use cases and identifies various associated This document details use cases for S-BFD and identifies various
requirements. Some of these requirements are security related. The associated requirements. Some of these requirements are security
use cases herein described do not expose a system to abuse or to related. The use cases described herein do not expose a system to
additional security risks. Since some negotiation aspects are abuse or additional security risks. Since some negotiation aspects
eliminated, a misconfiguration can result in S-BFD packets being sent are eliminated, a misconfiguration can result in S-BFD packets being
to an incorrect node. If this receiving node runs S-BFD, the packet sent to an incorrect node. If this receiving node runs S-BFD, the
will be discarted because of the discriminator mismatch. If the node packet will be discarded due to discriminator mismatch. If the node
does not run S-BFD, the packet will be naturally discarded. does not run S-BFD, the packet will be naturally discarded.
The proposed new protocols, extensions, and enhancements for a The proposed new protocols, extensions, and enhancements for S-BFD
Seamless BFD supporting these use cases and realizing these supporting these use cases and realizing these requirements will
requirements will address the associated security considerations. A address associated security considerations. S-BFD should not have
Seamless BFD should not have reduced security capabilities as reduced security capabilities as compared to traditional BFD.
compared to traditional BFD.
6. IANA Considerations
There are no IANA considerations introduced by this document.
7. Acknowledgements
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.
8. Contributors
The following are key contributors to this document:
Manav Bhatia, Ionos Networks
Satoru Matsushima, Softbank
Glenn Hayden, ATT
Santosh P K
Mach Chen, Huawei
Nobo Akiya, Big Switch Networks
9. References 6. References
9.1. Normative References 6.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>.
[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 13, line 23 skipping to change at page 13, line 10
[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883,
June 2010, <http://www.rfc-editor.org/info/rfc5883>. June 2010, <http://www.rfc-editor.org/info/rfc5883>.
[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)", 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>.
9.2. Informative References 6.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]
Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "A
Scalable and Topology-Aware MPLS Dataplane Monitoring
System", draft-ietf-spring-oam-usecase-03 (work in
progress), April 2016.
[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.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC791, September 1981,
<http://www.rfc-editor.org/info/rfc791>. <http://www.rfc-editor.org/info/rfc791>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>. December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001, DOI 10.17487/RFC3031, January 2001,
<http://www.rfc-editor.org/info/rfc3031>. <http://www.rfc-editor.org/info/rfc3031>.
skipping to change at page 14, line 41 skipping to change at page 13, line 42
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>.
[RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S. [RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S.
Aldrin, "Clarifying Procedures for Establishing BFD Aldrin, "Clarifying Procedures for Establishing BFD
Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726, Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726,
DOI 10.17487/RFC7726, January 2016, DOI 10.17487/RFC7726, January 2016,
<http://www.rfc-editor.org/info/rfc7726>. <http://www.rfc-editor.org/info/rfc7726>.
[RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S.
Pallagatti, "Seamless Bidirectional Forwarding Detection
(S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016,
<http://www.rfc-editor.org/info/rfc7880>.
[RFC7881] Pignataro, C., Ward, D., and N. Akiya, "Seamless
Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6,
and MPLS", RFC 7881, DOI 10.17487/RFC7881, July 2016,
<http://www.rfc-editor.org/info/rfc7881>.
[SR-ARCH] Filsfils, C., Ed., Previdi, S., Ed., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing
Architecture", Work in Progress,
draft-ietf-spring-segment-routing-09, July 2016.
[SR-MPLS] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N.
Kumar, "A Scalable and Topology-Aware MPLS Dataplane
Monitoring System", Work in Progress,
draft-ietf-spring-oam-usecase-03, April 2016.
[SR-OAM-REQS]
Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G.,
and S. Litkowski, "OAM Requirements for Segment Routing
Network", Work in Progress,
draft-ietf-spring-sr-oam-requirement-02, July 2016.
Acknowledgements
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.
Contributors
The following are key contributors to this document:
Manav Bhatia, Ionos Networks
Satoru Matsushima, Softbank
Glenn Hayden, ATT
Santosh P K
Mach Chen, Huawei
Nobo Akiya, Big Switch Networks
Authors' Addresses Authors' Addresses
Sam Aldrin Sam Aldrin
Google, Inc Google, Inc.
Email: aldrin.ietf@gmail.com Email: aldrin.ietf@gmail.com
Carlos Pignataro Carlos Pignataro
Cisco Systems, Inc. Cisco Systems, Inc.
Email: cpignata@cisco.com 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 Systems, Inc. Cisco Systems, Inc.
Email: naikumar@cisco.com Email: naikumar@cisco.com
 End of changes. 95 change blocks. 
347 lines changed or deleted 334 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/