< draft-ietf-bfd-multipoint-18.txt   draft-ietf-bfd-multipoint-19.txt >
Internet Engineering Task Force D. Katz Internet Engineering Task Force D. Katz
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Updates: 5880 (if approved) D. Ward Updates: 5880 (if approved) D. Ward
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: December 20, 2018 S. Pallagatti, Ed. Expires: June 16, 2019 S. Pallagatti, Ed.
Individual contributor Rtbrick
G. Mirsky, Ed. G. Mirsky, Ed.
ZTE Corp. ZTE Corp.
June 18, 2018 December 13, 2018
BFD for Multipoint Networks BFD for Multipoint Networks
draft-ietf-bfd-multipoint-18 draft-ietf-bfd-multipoint-19
Abstract Abstract
This document describes extensions to the Bidirectional Forwarding This document describes extensions to the Bidirectional Forwarding
Detection (BFD) protocol for its use in multipoint and multicast Detection (BFD) protocol for its use in multipoint and multicast
networks. networks.
This document updates RFC 5880.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 20, 2018. This Internet-Draft will expire on June 16, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 29
5.3. Session Failure Semantics . . . . . . . . . . . . . . . . 5 5.3. Session Failure Semantics . . . . . . . . . . . . . . . . 5
5.4. State Variables . . . . . . . . . . . . . . . . . . . . . 5 5.4. State Variables . . . . . . . . . . . . . . . . . . . . . 5
5.4.1. New State Variable Values . . . . . . . . . . . . . . 6 5.4.1. New State Variable Values . . . . . . . . . . . . . . 6
5.4.2. State Variable Initialization and Maintenance . . . . 6 5.4.2. State Variable Initialization and Maintenance . . . . 6
5.5. State Machine . . . . . . . . . . . . . . . . . . . . . . 6 5.5. State Machine . . . . . . . . . . . . . . . . . . . . . . 6
5.6. Session Establishment . . . . . . . . . . . . . . . . . . 7 5.6. Session Establishment . . . . . . . . . . . . . . . . . . 7
5.7. Discriminators and Packet Demultiplexing . . . . . . . . 7 5.7. Discriminators and Packet Demultiplexing . . . . . . . . 7
5.8. Packet consumption on tails . . . . . . . . . . . . . . . 8 5.8. Packet consumption on tails . . . . . . . . . . . . . . . 8
5.9. Bringing Up and Shutting Down Multipoint BFD Service . . 8 5.9. Bringing Up and Shutting Down Multipoint BFD Service . . 8
5.10. Timer Manipulation . . . . . . . . . . . . . . . . . . . 9 5.10. Timer Manipulation . . . . . . . . . . . . . . . . . . . 9
5.11. Detection Times . . . . . . . . . . . . . . . . . . . . . 9 5.11. Detection Times . . . . . . . . . . . . . . . . . . . . . 10
5.12. State Maintenance for Down/AdminDown Sessions . . . . . . 10 5.12. State Maintenance for Down/AdminDown Sessions . . . . . . 10
5.12.1. MultipointHead Sessions . . . . . . . . . . . . . . 10 5.12.1. MultipointHead Sessions . . . . . . . . . . . . . . 10
5.12.2. MultipointTail Sessions . . . . . . . . . . . . . . 10 5.12.2. MultipointTail Sessions . . . . . . . . . . . . . . 10
5.13. Base Specification Text Replacement . . . . . . . . . . . 10 5.13. Base Specification Text Replacement . . . . . . . . . . . 10
5.13.1. Reception of BFD Control Packets . . . . . . . . . . 11 5.13.1. Reception of BFD Control Packets . . . . . . . . . . 11
5.13.2. Demultiplexing BFD Control Packets . . . . . . . . . 13 5.13.2. Demultiplexing BFD Control Packets . . . . . . . . . 13
5.13.3. Transmitting BFD Control Packets . . . . . . . . . . 14 5.13.3. Transmitting BFD Control Packets . . . . . . . . . . 15
6. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Congestion Considerations . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . 20
11.2. Informational References . . . . . . . . . . . . . . . . 19 11.2. Informational References . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The Bidirectional Forwarding Detection protocol [RFC5880] specifies a The Bidirectional Forwarding Detection protocol [RFC5880] specifies a
method for verifying unicast connectivity between a pair of systems. method for verifying unicast connectivity between a pair of systems.
This document defines a method for using BFD to provide verification This document updates [RFC5880] by defining a new method for using
of multipoint or multicast connectivity between a multipoint sender BFD. This new method provides verification of multipoint or
(the "head") and a set of one or more multipoint receivers (the multicast connectivity between a multipoint sender (the "head") and a
"tails"). set of one or more multipoint receivers (the "tails").
As multipoint transmissions are inherently unidirectional, this As multipoint transmissions are inherently unidirectional, this
mechanism purports only to verify this unidirectional connectivity. mechanism purports only to verify this unidirectional connectivity.
Although this seems in conflict with the "Bidirectional" in BFD, the Although this seems in conflict with the "Bidirectional" in BFD, the
protocol is capable of supporting this use case. Use of BFD in protocol is capable of supporting this use case. Use of BFD in
Demand mode enables a tail monitor availability of a multipoint path Demand mode allows a tail to monitor the availability of a multipoint
even without the existence of some kind of a return path to the head. path even without the existence of some kind of a return path to the
As an option, if a return path from a tail to the head exists, the head. As an option, if a return path from a tail to the head exists,
tail may notify the head of the lack of multipoint connectivity. the tail may notify the head of the lack of multipoint connectivity.
Details of tail notification to the head are outside the scope of Details of tail notification to the head are outside the scope of
this document and are discussed in this document and are discussed in
[I-D.ietf-bfd-multipoint-active-tail]. [I-D.ietf-bfd-multipoint-active-tail].
This application of BFD allows for the tails to detect a lack of This application of BFD allows for the tails to detect a lack of
connectivity from the head. For some applications such detection of connectivity from the head. For some applications such detection of
the failure at the tail is useful. For example, use of multipoint the failure at the tail is useful. For example, use of multipoint
BFD to enable fast failure detection and faster failover in multicast BFD to enable fast failure detection and faster failover in multicast
VPN described in [I-D.ietf-bess-mvpn-fast-failover]. Due to VPN described in [I-D.ietf-bess-mvpn-fast-failover]. Due to
unidirectional nature, virtually all options and timing parameters unidirectional nature, virtually all options and timing parameters
are controlled by the head. are controlled by the head.
Throughout this document, the term "multipoint" is defined as a Throughout this document, the term "multipoint" is defined as a
mechanism by which one or more systems receive packets sent by a mechanism by which one or more systems receive packets sent by a
single sender. This specifically includes such things as IP single sender. This specifically includes such things as IP
multicast and point-to-multipoint MPLS. multicast and point-to-multipoint MPLS.
Term "connectivity" in this document is not being used in the context The term "connectivity" in this document is not being used in the
of connectivity verification in transport network but as an context of connectivity verification in transport network but as an
alternative to "continuity", i.e., the existence of a forwarding path alternative to "continuity", i.e., the existence of a forwarding path
between the sender and the receiver. between the sender and the receiver.
This document effectively updates and extends the base BFD This document effectively updates and extends the base BFD
specification [RFC5880]. specification [RFC5880].
2. Keywords 2. Keywords
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
skipping to change at page 4, line 31 skipping to change at page 4, line 31
done independently (and with no penalty in protocol overhead) by done independently (and with no penalty in protocol overhead) by
using point-to-point BFD. using point-to-point BFD.
4. Overview 4. Overview
The heart of this protocol is the periodic transmission of BFD The heart of this protocol is the periodic transmission of BFD
Control packets along a multipoint path, from the head to all tails Control packets along a multipoint path, from the head to all tails
on the path. The contents of the BFD packets provide the means for on the path. The contents of the BFD packets provide the means for
the tails to calculate the detection time for path failure. If no the tails to calculate the detection time for path failure. If no
BFD Control packets are received by a tail for a detection time, the BFD Control packets are received by a tail for a detection time, the
tail declares the path to having failed. For some applications this tail declares that the path has failed. For some applications this
is the only mechanism necessary; the head can remain ignorant of the is the only mechanism necessary; the head can remain ignorant of the
tails. status of connectivity to the tails.
The head of a multipoint BFD session may wish to be alerted to the The head of a multipoint BFD session may wish to be alerted to the
tails' connectivity (or lack thereof). Details of how the head keeps tails' connectivity (or lack thereof). Details of how the head keeps
track of tails and how tails alert their connectivity to the head are track of tails and how tails alert their connectivity to the head are
outside scope of this document and are discussed in outside the scope of this document and are discussed in
[I-D.ietf-bfd-multipoint-active-tail]. [I-D.ietf-bfd-multipoint-active-tail].
Although this document describes a single head and a set of tails Although this document describes a single head and a set of tails
spanned by a single multipoint path, the protocol is capable of spanned by a single multipoint path, the protocol is capable of
supporting (and discriminating between) more than one multipoint path supporting (and discriminating between) more than one multipoint path
at both heads and tails, as described in Section 5.7 and at both heads and tails, as described in Section 5.7 and
Section 5.13.2. Furthermore, the same head and tail may share Section 5.13.2. Furthermore, the same head and tail may share
multiple multipoint paths, and a multipoint path may have multiple multiple multipoint paths, and a multipoint path may have multiple
heads. heads.
skipping to change at page 5, line 42 skipping to change at page 5, line 42
5.3. Session Failure Semantics 5.3. Session Failure Semantics
The semantics of session failure is subtle enough to warrant further The semantics of session failure is subtle enough to warrant further
explanation. explanation.
MultipointHead sessions cannot fail (since they are controlled MultipointHead sessions cannot fail (since they are controlled
administratively). administratively).
If a MultipointTail session fails, it means that the tail definitely If a MultipointTail session fails, it means that the tail definitely
has lost contact with the head (or the head has been administratively has lost contact with the head (or the head has been administratively
disabled) and the tail should take appropriate action. disabled) and the tail may use mechanisms other than BFD, e.g.,
logging or NETCONF [RFC6241], to send a notification to the user.
5.4. State Variables 5.4. State Variables
Multipoint BFD introduces some new state variables and modifies the Multipoint BFD introduces some new state variables and modifies the
usage of a few existing ones. usage of a few existing ones.
5.4.1. New State Variable Values 5.4.1. New State Variable Values
A number of new values of the state variable bfd.SessionType are A number of new values of the state variable bfd.SessionType are
added to the base BFD [RFC5880] and base S-BFD [RFC7880] added to the base BFD [RFC5880] and base S-BFD [RFC7880]
skipping to change at page 7, line 28 skipping to change at page 7, line 28
Detection Timer, and as such all state transitions are Detection Timer, and as such all state transitions are
administratively driven. administratively driven.
5.6. Session Establishment 5.6. Session Establishment
Unlike point-to-point BFD, Multipoint BFD provides a form of the Unlike point-to-point BFD, Multipoint BFD provides a form of the
discovery mechanism for tails to discover the head. The minimum discovery mechanism for tails to discover the head. The minimum
amount of a priori information required both on the head and tails is amount of a priori information required both on the head and tails is
the binding to the multipoint path over which BFD is running. The the binding to the multipoint path over which BFD is running. The
head transmits Multipoint BFD packets on that path, and the tails head transmits Multipoint BFD packets on that path, and the tails
listen for BFD packets on that path. All other information MAY be listen for BFD packets on that path. All other information can be
determined dynamically. determined dynamically.
A session of type MultipointHead is created for each multipoint path A session of type MultipointHead is created for each multipoint path
over which the head wishes to run BFD. This session runs in the over which the head wishes to run BFD. This session runs in the
Active role , per section 6.1 [RFC5880]. Except when Active role, per section 6.1 [RFC5880]. Except when administratively
administratively terminating BFD service, this session is always in terminating BFD service, this session is always in state Up and
state Up and always operates in Demand mode. No received packets are always operates in Demand mode. No received packets are ever
ever demultiplexed to the MultipointHead session. In this sense, it demultiplexed to the MultipointHead session. In this sense, it is a
is a degenerate form of a session. degenerate form of a session.
Sessions on the tail MAY be established dynamically, based on the Sessions on the tail MAY be established dynamically, based on the
receipt of a Multipoint BFD Control packet from the head, and are of receipt of a Multipoint BFD Control packet from the head, and are of
type MultipointTail. Tail sessions always take the Passive role, per type MultipointTail. Tail sessions always take the Passive role, per
section 6.1 [RFC5880]. section 6.1 [RFC5880].
5.7. Discriminators and Packet Demultiplexing 5.7. Discriminators and Packet Demultiplexing
The use of Discriminators is somewhat different in Multipoint BFD The use of Discriminators is somewhat different in Multipoint BFD
than in Point-to-point BFD. than in Point-to-point BFD.
The head sends Multipoint BFD Control packets over the multipoint The head sends Multipoint BFD Control packets over the multipoint
path via the MultipointHead session with My Discr set to a value path via the MultipointHead session with My Discriminator set to a
bound to the multipoint path, and with Your Discr set to zero. value bound to the multipoint path, and with Your Discriminator set
to zero.
IP and MPLS multipoint tails MUST demultiplex BFD packets based on a IP and MPLS multipoint tails MUST demultiplex BFD packets based on a
combination of the source address, My Discriminator and the identity combination of the source address, My Discriminator and the identity
of the multipoint path which the Multipoint BFD Control packet was of the multipoint path which the Multipoint BFD Control packet was
received from. Together they uniquely identify the head of the received from. Together they uniquely identify the head of the
multipoint path. Bootstrapping BFD session to multipoint MPLS LSP in multipoint path. Bootstrapping a BFD session to multipoint MPLS LSP
case of penultimate hop popping may use control plane, e.g., as may use the control plane, e.g., as described in
described in [I-D.ietf-bess-mvpn-fast-failover], and is outside the [I-D.ietf-bess-mvpn-fast-failover], and is outside the scope of this
scope of this document. document.
Note that, unlike point-to-point sessions, the My Discriminator value Note that, unlike point-to-point sessions, the My Discriminator value
on MultipointHead session MUST NOT be changed during the life of a on MultipointHead session MUST NOT be changed during the life of a
session. This is a side effect of the more complex demultiplexing session. This is a side effect of the more complex demultiplexing
scheme. scheme.
5.8. Packet consumption on tails 5.8. Packet consumption on tails
BFD packets received on tails for an IP multicast group MUST be BFD packets received on tails for an IP multicast group MUST be
consumed by tails and MUST NOT be forwarded to receivers. Nodes with consumed by tails and MUST NOT be forwarded to receivers. Nodes with
skipping to change at page 13, line 35 skipping to change at page 13, line 38
If bfd.RemoteDemandMode is 1, bfd.SessionState is Up and If bfd.RemoteDemandMode is 1, bfd.SessionState is Up and
bfd.RemoteSessionState is Up, Demand mode is active on the remote bfd.RemoteSessionState is Up, Demand mode is active on the remote
system and the local system MUST cease the periodic transmission system and the local system MUST cease the periodic transmission
of BFD Control packets (see Section 5.13.3). of BFD Control packets (see Section 5.13.3).
If bfd.RemoteDemandMode is 0, or bfd.SessionState is not Up, or If bfd.RemoteDemandMode is 0, or bfd.SessionState is not Up, or
bfd.RemoteSessionState is not Up, Demand mode is not active on the bfd.RemoteSessionState is not Up, Demand mode is not active on the
remote system and the local system MUST send periodic BFD Control remote system and the local system MUST send periodic BFD Control
packets (see Section 5.13.3). packets (see Section 5.13.3).
If the Poll (P) bit is set, and bfd.SessionType is PointToPoint,
send a BFD Control packet to the remote system with the Poll (P)
bit clear, and the Final (F) bit set (see Section 5.13.3).
If the packet was not discarded, it has been received for purposes If the packet was not discarded, it has been received for purposes
of the Detection Time expiration rules in [RFC5880] section 6.8.4. of the Detection Time expiration rules in [RFC5880] section 6.8.4.
5.13.2. Demultiplexing BFD Control Packets 5.13.2. Demultiplexing BFD Control Packets
This section is part of the replacement for [RFC5880] section 6.8.6, This section is part of the replacement for [RFC5880] section 6.8.6,
separated for clarity. separated for clarity.
If the Multipoint (M) bit is set If the Multipoint (M) bit is set
If the Your Discriminator field is nonzero, the packet MUST be If the Your Discriminator field is nonzero, the packet MUST be
discarded. discarded.
Select a session as based on source address, My Discriminator Select a session as based on source address, My Discriminator
and the identity of the multipoint path which the Multipoint and the identity of the multipoint path which the Multipoint
BFD Control packet was received. BFD Control packet was received.
If a session is found, and bfd.SessionType is not If a session is found, and bfd.SessionType is not
MultipointTail, the packet MUST be discarded. MultipointTail, the packet MUST be discarded.
skipping to change at page 14, line 12 skipping to change at page 14, line 18
and the identity of the multipoint path which the Multipoint and the identity of the multipoint path which the Multipoint
BFD Control packet was received. BFD Control packet was received.
If a session is found, and bfd.SessionType is not If a session is found, and bfd.SessionType is not
MultipointTail, the packet MUST be discarded. MultipointTail, the packet MUST be discarded.
Else Else
If a session is not found, a new session of type If a session is not found, a new session of type
MultipointTail MAY be created, or the packet MAY be MultipointTail MAY be created, or the packet MAY be
discarded. This choice MAY be controlled by the local discarded. This choice can be controlled by the local
policy, e.g. a maximum number of MultipointTail sessions and policy, e.g., by settinga maximum number of MultipointTail
number of active MultipointTail sessions, and is outside the sessions. Use of the local policy and the exact mechanism
scope of this specification. of it are outside the scope of this specification.
Else (Multipoint bit is clear) Else (Multipoint bit is clear)
If the Your Discriminator field is nonzero If the Your Discriminator field is nonzero
Select a session based on the value of Your Discriminator. Select a session based on the value of Your Discriminator.
If no session is found, the packet MUST be discarded. If no session is found, the packet MUST be discarded.
Else (Your Discriminator is zero) Else (Your Discriminator is zero)
skipping to change at page 15, line 5 skipping to change at page 15, line 10
outside the scope of this specification. outside the scope of this specification.
If the State field is Init and bfd.SessionType is not If the State field is Init and bfd.SessionType is not
PointToPoint, the packet MUST be discarded. PointToPoint, the packet MUST be discarded.
5.13.3. Transmitting BFD Control Packets 5.13.3. Transmitting BFD Control Packets
The following procedure replaces the entire section 6.8.7 of The following procedure replaces the entire section 6.8.7 of
[RFC5880]. [RFC5880].
BFD Control packets MUST be transmitted periodically at the rate With the exceptions listed in the remainder of this section, a system
determined according to [RFC5880] section 6.8.2, except as specified MUST NOT transmit BFD Control packets at an interval less than the
in this section. larger of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval, less
applied jitter (see below). In other words, the system reporting the
slower rate determines the transmission rate.
The periodic transmission of BFD Control packets MUST be jittered on
a per-packet basis by up to 25%, that is, the interval MUST be
reduced by a random value of 0 to 25%, in order to avoid self-
synchronization with other systems on the same subnetwork. Thus, the
average interval between packets will be roughly 12.5% less than that
negotiated.
If bfd.DetectMult is equal to 1, the interval between transmitted BFD
Control packets MUST be no more than 90% of the negotiated
transmission interval, and MUST be no less than 75% of the negotiated
transmission interval. This is to ensure that, on the remote system,
the calculated Detection Time does not pass prior to the receipt of
the next BFD Control packet.
A system MUST NOT transmit any BFD Control packets if bfd.RemoteDiscr A system MUST NOT transmit any BFD Control packets if bfd.RemoteDiscr
is zero and the system is taking the Passive role. is zero and the system is taking the Passive role.
A system MUST NOT transmit any BFD Control packets if bfd.SessionType A system MUST NOT transmit any BFD Control packets if bfd.SessionType
is MultipointTail. is MultipointTail.
A system MUST NOT periodically transmit BFD Control packets if Demand A system MUST NOT periodically transmit BFD Control packets if Demand
mode is active on the remote system (bfd.RemoteDemandMode is 1, mode is active on the remote system (bfd.RemoteDemandMode is 1,
bfd.SessionState is Up, and bfd.RemoteSessionState is Up) and a Poll bfd.SessionState is Up, and bfd.RemoteSessionState is Up) and a Poll
skipping to change at page 17, line 26 skipping to change at page 17, line 46
Set to bfd.DesiredMinTxInterval. Set to bfd.DesiredMinTxInterval.
Required Min RX Interval Required Min RX Interval
Set to bfd.RequiredMinRxInterval. Set to bfd.RequiredMinRxInterval.
Required Min Echo RX Interval Required Min Echo RX Interval
Set to 0 if bfd.SessionType is MultipointHead or Set to 0 if bfd.SessionType is MultipointHead or
MultipointTail. MultipointTail. Otherwise, set to the minimum required Echo
packet receive interval for this session. If this field is set
to zero, the local system is unwilling or unable to loop back
BFD Echo packets to the remote system, and the remote system
will not send Echo packets.
Authentication Section Authentication Section
Included and set according to the rules in [RFC5880] section Included and set according to the rules in [RFC5880] section
6.7 if authentication is in use (bfd.AuthType is nonzero). 6.7 if authentication is in use (bfd.AuthType is nonzero).
Otherwise, this section is not present. Otherwise, this section is not present.
6. Assumptions 6. Congestion Considerations
If authentication is in use, the head and all tails may be configured As a foreword, although congestion can occur because of a number of
to have a common authentication key in order for the tails to factors, it should be noted that high transmission rates are by
validate multipoint BFD Control packets. themselves subject to creating congestion either along the path or at
the tail end(s). As such, as stated in [RFC5883]:
Shared keys in multipoint scenarios allow any tail to spoof the head "it is required that the operator correctly provision the rates at
from the viewpoint of any other tail. For this reason, using shared which BFD is transmitted to avoid congestion (e.g link, I/O, CPU)
keys to authenticate BFD Control packets in multipoint scenarios is a and false failure detection."
significant security exposure unless all tails can be trusted not to
spoof the head. Otherwise, asymmetric message authentication would Use of BFD in multipoint networks, as specified in this document,
be needed, e.g., protocols that use Timed Efficient Stream Loss- over multiple hops requires consideration of the mechanisms to react
Tolerant Authentication (TESLA) as described in [RFC4082]. to network congestion. Requirements stated in Section 7 of the BFD
base specification [RFC5880] equally apply to BFD in multipoint
networks and are repeated here:
"When BFD is used across multiple hops, a congestion control
mechanism MUST be implemented, and when congestion is detected,
the BFD implementation MUST reduce the amount of traffic it
generates."
The mechanism to control the load of BFD traffic MAY use BFD's
configuration interface to control BFD state variable
bfd.DesiredMinTxInterval. However, such a control loop do not form
part of the BFD protocol itself and its specification is thus outside
the scope of this document.
Additional considerations apply to BFD in multipoint networks, as
specified in this document. Indeed, because a tail does not transmit
any BFD Control packets to the head of the BFD session, such head
node has no BFD based mechanism to be aware of the state of the
session at the tail. In the absence of any other mechanism, the head
of the session could thus continue to send packets towards the
tail(s) even though a link failure has happened. In such a scenario
when it is required for the head of the session to be aware of the
state of the tail of the session, it is RECOMMENDED to implement
[I-D.ietf-bfd-multipoint-active-tail].
7. IANA Considerations 7. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
8. Security Considerations 8. Security Considerations
The same security considerations as those described in [RFC5880] The same security considerations as those described in [RFC5880]
apply to this document. Additionally, implementations that create apply to this document. Additionally, implementations that create
MultpointTail sessions dynamically upon receipt of Multipoint BFD MultpointTail sessions dynamically upon receipt of Multipoint BFD
skipping to change at page 18, line 30 skipping to change at page 19, line 30
etc), then a MultipointTail session should not be created. etc), then a MultipointTail session should not be created.
If redundant streams are expected for a given multicast stream, If redundant streams are expected for a given multicast stream,
then the implementations should not create more MultipointTail then the implementations should not create more MultipointTail
sessions than the number of streams. Additionally, when the sessions than the number of streams. Additionally, when the
number of MultipointTail sessions exceeds the number of expected number of MultipointTail sessions exceeds the number of expected
streams, then the implementation should generate an alarm to users streams, then the implementation should generate an alarm to users
to indicate the anomaly. to indicate the anomaly.
The implementation should have a reasonable upper bound on the The implementation should have a reasonable upper bound on the
number of MultipointHead sessions that can be created, with the
upper bound potentially being computed based on the load these
would generate.
The implementation should have a reasonable upper bound on the
number of MultipointTail sessions that can be created, with the number of MultipointTail sessions that can be created, with the
upper bound potentially being computed based on the number of upper bound potentially being computed based on the number of
multicast streams that the system is expecting. multicast streams that the system is expecting.
If authentication is in use, the head and all tails may be configured
to have a common authentication key in order for the tails to
validate multipoint BFD Control packets.
Shared keys in multipoint scenarios allow any tail to spoof the head
from the viewpoint of any other tail. For this reason, using shared
keys to authenticate BFD Control packets in multipoint scenarios is a
significant security exposure unless all tails can be trusted not to
spoof the head. Otherwise, asymmetric message authentication would
be needed, e.g., protocols that use Timed Efficient Stream Loss-
Tolerant Authentication (TESLA) as described in [RFC4082].
Applicability of the assymetric message authentication to BFD for
multipoint networks is ouside the scope of this specification and is
for further study.
9. Contributors 9. Contributors
Rahul Aggarwal of Juniper Networks and George Swallow of Cisco Rahul Aggarwal of Juniper Networks and George Swallow of Cisco
Systems provided the initial idea for this specification and Systems provided the initial idea for this specification and
contributed to its development. contributed to its development.
10. Acknowledgments 10. Acknowledgments
Authors would also like to thank Nobo Akiya, Vengada Prasad Govindan, Authors would also like to thank Nobo Akiya, Vengada Prasad Govindan,
Jeff Haas, Wim Henderickx, Gregory Mirsky and Mingui Zhang who have Jeff Haas, Wim Henderickx, Gregory Mirsky and Mingui Zhang who have
skipping to change at page 19, line 33 skipping to change at page 20, line 49
<https://www.rfc-editor.org/info/rfc8029>. <https://www.rfc-editor.org/info/rfc8029>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informational References 11.2. Informational References
[I-D.ietf-bess-mvpn-fast-failover] [I-D.ietf-bess-mvpn-fast-failover]
Morin, T., Kebler, R., and G. Mirsky, "Multicast VPN fast Morin, T., Kebler, R., and G. Mirsky, "Multicast VPN fast
upstream failover", draft-ietf-bess-mvpn-fast-failover-03 upstream failover", draft-ietf-bess-mvpn-fast-failover-04
(work in progress), May 2018. (work in progress), November 2018.
[I-D.ietf-bfd-multipoint-active-tail] [I-D.ietf-bfd-multipoint-active-tail]
Katz, D., Ward, D., Networks, J., and G. Mirsky, "BFD Katz, D., Ward, D., Networks, J., and G. Mirsky, "BFD
Multipoint Active Tails.", draft-ietf-bfd-multipoint- Multipoint Active Tails.", draft-ietf-bfd-multipoint-
active-tail-08 (work in progress), June 2018. active-tail-10 (work in progress), November 2018.
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
Briscoe, "Timed Efficient Stream Loss-Tolerant Briscoe, "Timed Efficient Stream Loss-Tolerant
Authentication (TESLA): Multicast Source Authentication Authentication (TESLA): Multicast Source Authentication
Transform Introduction", RFC 4082, DOI 10.17487/RFC4082, Transform Introduction", RFC 4082, DOI 10.17487/RFC4082,
June 2005, <https://www.rfc-editor.org/info/rfc4082>. June 2005, <https://www.rfc-editor.org/info/rfc4082>.
[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883,
June 2010, <https://www.rfc-editor.org/info/rfc5883>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
Authors' Addresses Authors' Addresses
Dave Katz Dave Katz
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, California 94089-1206 Sunnyvale, California 94089-1206
USA USA
Email: dkatz@juniper.net Email: dkatz@juniper.net
Dave Ward Dave Ward
Cisco Systems Cisco Systems
skipping to change at page 20, line 21 skipping to change at page 21, line 44
Dave Ward Dave Ward
Cisco Systems Cisco Systems
170 West Tasman Dr. 170 West Tasman Dr.
San Jose, California 95134 San Jose, California 95134
USA USA
Email: wardd@cisco.com Email: wardd@cisco.com
Santosh Pallagatti (editor) Santosh Pallagatti (editor)
Individual contributor Rtbrick
Email: santosh.pallagatti@gmail.com Email: santosh.pallagatti@gmail.com
Greg Mirsky (editor) Greg Mirsky (editor)
ZTE Corp. ZTE Corp.
Email: gregimirsky@gmail.com Email: gregimirsky@gmail.com
 End of changes. 34 change blocks. 
67 lines changed or deleted 148 lines changed or added

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