doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

diff --git a/doc/rfc/rfc8562.txt b/doc/rfc/rfc8562.txt
new file mode 100644
index 0000000..a47f730
--- /dev/null
+++ b/doc/rfc/rfc8562.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           D. Katz
+Request for Comments: 8562                              Juniper Networks
+Updates: 5880                                                    D. Ward
+Category: Standards Track                                  Cisco Systems
+ISSN: 2070-1721                                       S. Pallagatti, Ed.
+                                                                  VMware
+                                                          G. Mirsky, Ed.
+                                                               ZTE Corp.
+                                                              April 2019
+
+
+    Bidirectional Forwarding Detection (BFD) for Multipoint Networks
+
+Abstract
+
+   This document describes extensions to the Bidirectional Forwarding
+   Detection (BFD) protocol for its use in multipoint and multicast
+   networks.
+
+   This document updates RFC 5880.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8562.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Katz, et al.                 Standards Track                    [Page 1]
+
+RFC 8562               BFD for Multipoint Networks            April 2019
+
+
+Copyright Notice
+
+   Copyright (c) 2019 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Katz, et al.                 Standards Track                    [Page 2]
+
+RFC 8562               BFD for Multipoint Networks            April 2019
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
+   2.  Keywords  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
+   3.  Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
+   4.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
+   5.  Protocol Details  . . . . . . . . . . . . . . . . . . . . . .   5
+     5.1.  Multipoint BFD Control Packets  . . . . . . . . . . . . .   6
+     5.2.  Session Model . . . . . . . . . . . . . . . . . . . . . .   6
+     5.3.  Session-Failure Semantics . . . . . . . . . . . . . . . .   6
+     5.4.  State Variables . . . . . . . . . . . . . . . . . . . . .   6
+       5.4.1.  New State Variable Values . . . . . . . . . . . . . .   6
+       5.4.2.  State Variable Initialization and Maintenance . . . .   7
+     5.5.  State Machine . . . . . . . . . . . . . . . . . . . . . .   7
+     5.6.  Session Establishment . . . . . . . . . . . . . . . . . .   8
+     5.7.  Discriminators and Packet Demultiplexing  . . . . . . . .   8
+     5.8.  Packet Consumption on Tails . . . . . . . . . . . . . . .   9
+     5.9.  Bringing Up and Shutting Down Multipoint BFD Service  . .   9
+     5.10. Timer Manipulation  . . . . . . . . . . . . . . . . . . .  10
+     5.11. Detection Times . . . . . . . . . . . . . . . . . . . . .  10
+     5.12. State Maintenance for Down/AdminDown Sessions . . . . . .  11
+       5.12.1.  MultipointHead Sessions  . . . . . . . . . . . . . .  11
+       5.12.2.  MultipointTail Sessions  . . . . . . . . . . . . . .  11
+     5.13. Base Specification Text Replacement . . . . . . . . . . .  11
+       5.13.1.  Reception of BFD Control Packets . . . . . . . . . .  12
+       5.13.2.  Demultiplexing BFD Control Packets . . . . . . . . .  15
+       5.13.3.  Transmitting BFD Control Packets . . . . . . . . . .  16
+   6.  Congestion Considerations . . . . . . . . . . . . . . . . . .  19
+   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
+   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
+   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
+     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  21
+     9.2.  Informative References  . . . . . . . . . . . . . . . . .  22
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  22
+   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  22
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Katz, et al.                 Standards Track                    [Page 3]
+
+RFC 8562               BFD for Multipoint Networks            April 2019
+
+
+1.  Introduction
+
+   The Bidirectional Forwarding Detection (BFD) protocol [RFC5880]
+   specifies a method for verifying unicast connectivity between a pair
+   of systems.  This document updates [RFC5880] by defining a new method
+   for using BFD.  This new method provides verification of multipoint
+   or multicast connectivity between a multipoint sender (the "head")
+   and a set of one or more multipoint receivers (the "tails").
+
+   As multipoint transmissions are inherently unidirectional, this
+   mechanism purports only to verify this unidirectional connectivity.
+   Although this seems in conflict with the "Bidirectional" in BFD, the
+   protocol is capable of supporting this use case.  Use of BFD in
+   Demand mode allows a tail to monitor the availability of a multipoint
+   path even without the existence of some kind of a return path to the
+   head.  As an option, if a return path from a tail to the head exists,
+   the tail may notify the head of the lack of multipoint connectivity.
+   Details of tail notification to the head are outside the scope of
+   this document and are discussed in [RFC8563].
+
+   This application of BFD allows for the tails to detect a lack of
+   connectivity from the head.  For some applications, such detection of
+   the failure at the tail is useful, for example, the use of multipoint
+   BFD to enable fast failure detection and faster failover in multicast
+   VPN as described in [MVPN-FAILOVER].  Due to its unidirectional
+   nature, virtually all options and timing parameters are controlled by
+   the head.
+
+   Throughout this document, the term "multipoint" is defined as a
+   mechanism by which one or more systems receive packets sent by a
+   single sender.  This specifically includes such things as IP
+   multicast and point-to-multipoint MPLS.
+
+   The term "connectivity" in this document is not being used in the
+   context of connectivity verification in a transport network but as an
+   alternative to "continuity", i.e., the existence of a forwarding path
+   between the sender and the receiver.
+
+   This document effectively updates and extends the base BFD
+   specification [RFC5880].
+
+2.  Keywords
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+
+
+Katz, et al.                 Standards Track                    [Page 4]
+
+RFC 8562               BFD for Multipoint Networks            April 2019
+
+
+3.  Goals
+
+   The primary goal of this mechanism is to allow tails to rapidly
+   detect the fact that multipoint connectivity from the head has
+   failed.
+
+   Another goal is for the mechanism to work on any multicast
+   technology.
+
+   A further goal is to support multiple, overlapping point-to-
+   multipoint paths, as well as multipoint-to-multipoint paths, and to
+   allow point-to-point BFD sessions to operate simultaneously among the
+   systems participating in multipoint BFD.
+
+   It is not a goal for this protocol to verify point-to-point
+   bidirectional connectivity between the head and any tail.  This can
+   be done independently (and with no penalty in protocol overhead) by
+   using point-to-point BFD.
+
+4.  Overview
+
+   The heart of this protocol is the periodic transmission of BFD
+   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
+   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
+   tail declares that the path has failed.  For some applications, this
+   is the only mechanism necessary; the head can remain ignorant of the
+   status of connectivity to the tails.
+
+   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
+   track of tails and how tails alert their connectivity to the head are
+   outside the scope of this document and are discussed in [RFC8563].
+
+   Although this document describes a single head and a set of tails
+   spanned by a single multipoint path, the protocol is capable of
+   supporting (and discriminating between) more than one multipoint path
+   at both heads and tails, as described in Sections 5.7 and 5.13.2.
+   Furthermore, the same head and tail may share multiple multipoint
+   paths, and a multipoint path may have multiple heads.
+
+5.  Protocol Details
+
+   This section describes the operation of Multipoint BFD in detail.
+
+
+
+
+
+
+Katz, et al.                 Standards Track                    [Page 5]
+
+RFC 8562               BFD for Multipoint Networks            April 2019
+
+
+5.1.  Multipoint BFD Control Packets
+
+   Multipoint BFD Control packets (packets sent by the head over a
+   multipoint path) are explicitly marked as such, via the setting of
+   the Multipoint (M) bit [RFC5880].  This means that multipoint BFD
+   does not depend on the recipient of a packet to know whether the
+   packet was received over a multipoint path.  This can be useful in
+   scenarios where this information may not be available to the
+   recipient.
+
+5.2.  Session Model
+
+   Multipoint BFD is modeled as a set of sessions of different types.
+   The elements of procedure differ slightly for each type.
+
+   The head has a session of type MultipointHead, as defined in
+   Section 5.4.1, that is bound to a multipoint path.  Multipoint BFD
+   Control packets are sent by this session over the multipoint path,
+   and no BFD Control packets are received by it.
+
+   Each tail has a session of type MultipointTail, as defined in
+   Section 5.4.1, associated with a multipoint path.  These sessions
+   receive BFD Control packets from the head over the multipoint path.
+
+5.3.  Session-Failure Semantics
+
+   The semantics of session failure is subtle enough to warrant further
+   explanation.
+
+   MultipointHead sessions cannot fail (since they are controlled
+   administratively).
+
+   If a MultipointTail session fails, it means that the tail definitely
+   has lost contact with the head (or the head has been administratively
+   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
+
+   Multipoint BFD introduces some new state variables and modifies the
+   usage of a few existing ones.
+
+5.4.1.  New State Variable Values
+
+   A number of new values of the state variable bfd.SessionType are
+   added to the base BFD [RFC5880] and base Seamless Bidirectional
+   Forwarding Detection (S-BFD) [RFC7880] specifications in support of
+   multipoint BFD.
+
+
+
+Katz, et al.                 Standards Track                    [Page 6]
+
+RFC 8562               BFD for Multipoint Networks            April 2019
+
+
+      bfd.SessionType
+
+         The type of this session as defined in [RFC7880].  Newly added
+         values are:
+
+            PointToPoint: Classic point-to-point BFD, as described in
+            [RFC5880].
+
+            MultipointHead: A session on the head responsible for the
+            periodic transmission of multipoint BFD Control packets
+            along the multipoint path.
+
+            MultipointTail: A multipoint session on a tail.
+
+         This variable MUST be initialized to the appropriate type when
+         the session is created.
+
+5.4.2.  State Variable Initialization and Maintenance
+
+   Some state variables defined in Section 6.8.1 of [RFC5880] need to be
+   initialized or manipulated differently depending on the session type.
+
+      bfd.RequiredMinRxInterval
+
+         This variable MUST be initialized to zero for session type
+         MultipointHead.
+
+      bfd.DemandMode
+
+         This variable MUST be initialized to 1 for session type
+         MultipointHead and MUST be initialized to zero for session type
+         MultipointTail.
+
+5.5.  State Machine
+
+   There are slight differences in how the BFD state machine works in
+   the multipoint application.  In particular, since there is a many-to-
+   one mapping, three-way handshakes for session establishment and
+   teardown are neither possible nor appropriate.  As such, there is no
+   Init state.  Sessions of type MultipointHead MUST NOT send BFD
+   Control packets with the State field being set to INIT, and those
+   packets MUST be ignored on receipt.
+
+   The following diagram provides an overview of the state machine for
+   session type MultipointTail.  The notation on each arc represents the
+   state of the remote system (as received in the State field in the BFD
+   Control packet) or indicates the expiration of the Detection Timer.
+
+
+
+
+Katz, et al.                 Standards Track                    [Page 7]
+
+RFC 8562               BFD for Multipoint Networks            April 2019
+
+
+                         DOWN, ADMIN DOWN,
+                       +------+  TIMER               +------+
+                  +----|      |<---------------------|      |----+
+             DOWN,|    | DOWN |                      |  UP  |    |UP
+       ADMIN DOWN,+--->|      |--------------------->|      |<---+
+            TIMER      +------+          UP          +------+
+
+   Sessions of type MultipointHead never receive packets and have no
+   Detection Timer; as such, all state transitions are administratively
+   driven.
+
+5.6.  Session Establishment
+
+   Unlike point-to-point BFD, multipoint BFD provides a form of the
+   discovery mechanism that enables tails to discover the head.  The
+   minimum 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 head transmits multipoint BFD packets on that path, and
+   the tails listen for BFD packets on that path.  All other information
+   can be determined dynamically.
+
+   A session of type MultipointHead is created for each multipoint path
+   over which the head wishes to run BFD.  This session runs in the
+   Active role, per Section 6.1 of [RFC5880].  Except when
+   administratively terminating BFD service, this session is always in
+   state Up and always operates in Demand mode.  No received packets are
+   ever demultiplexed to the MultipointHead session.  In this sense, it
+   is a degenerate form of a session.
+
+   Sessions on the tail MAY be established dynamically, based on the
+   receipt of a multipoint BFD Control packet from the head, and are of
+   type MultipointTail.  Tail sessions always take the Passive role, per
+   Section 6.1 of [RFC5880].
+
+5.7.  Discriminators and Packet Demultiplexing
+
+   The use of discriminators is somewhat different in multipoint BFD
+   than in point-to-point BFD.
+
+   The head sends multipoint BFD Control packets over the multipoint
+   path via the MultipointHead session with My Discriminator set to a
+   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
+   combination of the source address, My Discriminator, and the identity
+   of the multipoint path that the multipoint BFD Control packet was
+   received from.  Together they uniquely identify the head of the
+
+
+
+Katz, et al.                 Standards Track                    [Page 8]
+
+RFC 8562               BFD for Multipoint Networks            April 2019
+
+
+   multipoint path.  Bootstrapping a BFD session to multipoint MPLS
+   Label Switched Path (LSP) may use the control plane, e.g., as
+   described in [MVPN-FAILOVER], and is outside the scope of this
+   document.
+
+   Note that, unlike point-to-point sessions, the My Discriminator value
+   on the MultipointHead session MUST NOT be changed during the life of
+   a session.  This is a side effect of the more complex demultiplexing
+   scheme.
+
+5.8.  Packet Consumption on Tails
+
+   BFD packets received on tails for an IP multicast group MUST be
+   consumed by tails and MUST NOT be forwarded to receivers.  Nodes with
+   the BFD session of type MultipointTail MUST identify packets received
+   on an IP multipoint path as a BFD Control packet if the destination
+   UDP port value equals 3784.
+
+   For multipoint LSPs, when IP/UDP encapsulation of BFD Control packets
+   is used, MultipointTail MUST expect destination UDP port 3784.  The
+   destination IP address of a BFD Control packet MUST be in the
+   127.0.0.0/8 range for IPv4 or in the 0:0:0:0:0:FFFF:7F00:0/104 range
+   for IPv6.  The use of these destination addresses is consistent with
+   the explanations and usage in [RFC8029].  Packets identified as BFD
+   packets MUST be consumed by MultipointTail and demultiplexed as
+   described in Section 5.13.2.  Use of other types of encapsulation of
+   the BFD control message over multipoint LSP is outside the scope of
+   this document.
+
+5.9.  Bringing Up and Shutting Down Multipoint BFD Service
+
+   Because there is no three-way handshake in multipoint BFD, a newly
+   started head (that does not have any previous state information
+   available) SHOULD start with bfd.SessionState set to Down, and
+   bfd.RequiredMinRxInterval MUST be set to zero in the MultipointHead
+   session.  The session SHOULD remain in this state for a time equal to
+   (bfd.DesiredMinTxInterval * bfd.DetectMult).  This will ensure that
+   all MultipointTail sessions are reset (so long as the restarted head
+   is using the same or a larger value of bfd.DesiredMinTxInterval than
+   it did previously).
+
+   Multipoint BFD service is brought up by administratively setting
+   bfd.SessionState to Up in the MultipointHead session.
+
+
+
+
+
+
+
+
+Katz, et al.                 Standards Track                    [Page 9]
+
+RFC 8562               BFD for Multipoint Networks            April 2019
+
+
+   The head of a multipoint BFD session may wish to shut down its BFD
+   service in a controlled fashion.  This is desirable because the tails
+   need not wait for a Detection Time prior to declaring the multipoint
+   session to be down (and taking whatever action is necessary in that
+   case).
+
+   To shut down a multipoint session in a controlled fashion, the head
+   MUST administratively set bfd.SessionState in the MultipointHead
+   session to either Down or AdminDown and SHOULD set
+   bfd.RequiredMinRxInterval to zero.  The session SHOULD send BFD
+   Control packets in this state for a period equal to
+   (bfd.DesiredMinTxInterval * bfd.DetectMult).  Alternatively, the head
+   MAY stop transmitting BFD Control packets and not send any more BFD
+   Control packets with the new state (Down or AdminDown).  Tails will
+   declare the multipoint session down only after the Detection Time
+   interval runs out.
+
+5.10.  Timer Manipulation
+
+   Because of the one-to-many mapping, a session of type MultipointHead
+   SHOULD NOT initiate a Poll Sequence in conjunction with timer value
+   changes.  However, to indicate a change in the packets, a
+   MultipointHead session MUST send packets with the P bit set.  A
+   MultipointTail session MUST NOT reply if the packet has the M and P
+   bits set and bfd.RequiredMinRxInterval set to zero.  Because the Poll
+   Sequence is not used, the tail cannot negotiate down MultpointHead's
+   transmit interval.  If the value of Desired Min TX Interval in the
+   BFD Control packet received by MultipointTail is too high (that
+   determination may change in time based on the current environment),
+   it must be handled by the implementation and may be controlled by
+   local policy, e.g., close the MultipointTail session.
+
+   The MultipointHead, when changing the transmit interval to a higher
+   value, MUST send BFD Control packets with the P bit set at the old
+   transmit interval before using the higher value in order to avoid
+   false detection timeouts at the tails.  A MultipointHead session MAY
+   also wait some amount of time before making the changes to the
+   transmit interval (through configuration).
+
+   Change in the value of bfd.RequiredMinRxInterval is outside the scope
+   of this document and is discussed in [RFC8563].
+
+5.11.  Detection Times
+
+   Multipoint BFD is inherently asymmetric.  As such, each session type
+   has a different approach to Detection Times.
+
+
+
+
+
+Katz, et al.                 Standards Track                   [Page 10]
+
+RFC 8562               BFD for Multipoint Networks            April 2019
+
+
+   Since MultipointHead sessions never receive packets, they do not
+   calculate a Detection Time.
+
+   MultipointTail sessions cannot influence the transmission rate of the
+   MultipointHead session using the Required Min Rx Interval field
+   because of its one-to-many nature.  As such, the Detection Time
+   calculation for a MultipointTail session does not use
+   bfd.RequiredMinRxInterval.  The Detection Time is calculated as the
+   product of the last received values of Desired Min TX Interval and
+   Detect Mult.
+
+   The value of bfd.DetectMult may be changed at any time on any session
+   type.
+
+5.12.  State Maintenance for Down/AdminDown Sessions
+
+   The length of time the session state is kept after the session goes
+   down determines how long the session will continue to send BFD
+   Control packets (since no packets can be sent after the session is
+   destroyed).
+
+5.12.1.  MultipointHead Sessions
+
+   When a MultipointHead session transitions to states Down or
+   AdminDown, the state SHOULD be maintained for a period equal to
+   (bfd.DesiredMinTxInterval * bfd.DetectMult) to ensure that the tails
+   more quickly detect the session going down (by continuing to transmit
+   BFD Control packets with the new state).
+
+5.12.2.  MultipointTail Sessions
+
+   MultipointTail sessions MAY be destroyed immediately upon leaving Up
+   state, since the tail will transmit no packets.
+
+   Otherwise, MultipointTail sessions SHOULD be maintained as long as
+   BFD Control packets are being received by it (which by definition
+   will indicate that the head is not Up).
+
+5.13.  Base Specification Text Replacement
+
+   The following sections are meant to replace the corresponding
+   sections in the base specification [RFC5880] to support BFD for
+   multipoint networks while not changing processing for point-to-point
+   BFD.
+
+
+
+
+
+
+
+Katz, et al.                 Standards Track                   [Page 11]
+
+RFC 8562               BFD for Multipoint Networks            April 2019
+
+
+5.13.1.  Reception of BFD Control Packets
+
+   The following procedure replaces Section 6.8.6 of [RFC5880] entirely.
+
+   When a BFD Control packet is received, the following procedure MUST
+   be followed, in the order specified.  If the packet is discarded
+   according to these rules, processing of the packet MUST cease at that
+   point.
+
+      If the version number is not correct (1), the packet MUST be
+      discarded.
+
+      If the Length field is less than the minimum correct value (24 if
+      the A bit is clear, or 26 if the A bit is set), the packet MUST be
+      discarded.
+
+      If the Length field is greater than the payload of the
+      encapsulating protocol, the packet MUST be discarded.
+
+      If the Detect Mult field is zero, the packet MUST be discarded.
+
+      If the My Discriminator field is zero, the packet MUST be
+      discarded.
+
+      Demultiplex the packet to a session according to Section 5.13.2.
+      The result is either a session of the proper type, or the packet
+      is discarded (and packet processing MUST cease).
+
+      If the A bit is set and no authentication is in use (bfd.AuthType
+      is zero), the packet MUST be discarded.
+
+      If the A bit is clear and authentication is in use (bfd.AuthType
+      is nonzero), the packet MUST be discarded.
+
+      If the A bit is set, the packet MUST be authenticated under the
+      rules of Section 6.7 of [RFC5880], based on the authentication
+      type in use (bfd.AuthType).  This may cause the packet to be
+      discarded.
+
+      Set bfd.RemoteDiscr to the value of My Discriminator.
+
+      Set bfd.RemoteState to the value of the State (Sta) field.
+
+      Set bfd.RemoteDemandMode to the value of the Demand (D) bit.
+
+      Set bfd.RemoteMinRxInterval to the value of Required Min RX
+      Interval.
+
+
+
+
+Katz, et al.                 Standards Track                   [Page 12]
+
+RFC 8562               BFD for Multipoint Networks            April 2019
+
+
+      If the Required Min Echo RX Interval field is zero, the
+      transmission of Echo packets, if any, MUST cease.
+
+      If a Poll Sequence is being transmitted by the local system and
+      the Final (F) bit in the received packet is set, the Poll Sequence
+      MUST be terminated.
+
+      If bfd.SessionType is PointToPoint, update the transmit interval
+      as described in Section 6.8.2 of [RFC5880].
+
+      If bfd.SessionType is PointToPoint, update the Detection Time as
+      described in Section 6.8.4 of [RFC5880].
+
+      Else
+
+         If bfd.SessionType is MultipointTail, then update the Detection
+         Time as the product of the last received values of Desired Min
+         TX Interval and Detect Mult, as described in Section 5.11 of
+         this specification.
+
+      If bfd.SessionState is AdminDown
+
+         Discard the packet
+
+      If the received State is AdminDown
+
+         If bfd.SessionState is not Down
+
+            Set bfd.LocalDiag to 3 (Neighbor signaled session down)
+
+            Set bfd.SessionState to Down
+
+      Else
+
+         If bfd.SessionState is Down
+
+            If bfd.SessionType is PointToPoint
+
+               If received State is Down
+
+                  Set bfd.SessionState to Init
+
+               Else if received State is Init
+
+                  Set bfd.SessionState to Up
+
+
+
+
+
+
+Katz, et al.                 Standards Track                   [Page 13]
+
+RFC 8562               BFD for Multipoint Networks            April 2019
+
+
+            Else (bfd.SessionType is not PointToPoint)
+
+               If received State is Up
+
+                  Set bfd.SessionState to Up
+
+         Else if bfd.SessionState is Init
+
+            If received State is Init or Up
+
+               Set bfd.SessionState to Up
+
+         Else (bfd.SessionState is Up)
+
+            If received State is Down
+
+               Set bfd.LocalDiag to 3 (Neighbor signaled session down)
+
+               Set bfd.SessionState to Down
+
+      Check to see if Demand mode should become active or not (see
+      [RFC5880], Section 6.6).
+
+      If bfd.RemoteDemandMode is 1, bfd.SessionState is Up, and
+      bfd.RemoteSessionState is Up, Demand mode is active on the remote
+      system and the local system MUST cease the periodic transmission
+      of BFD Control packets (see Section 5.13.3).
+
+      If bfd.RemoteDemandMode is zero, bfd.SessionState is not Up, or
+      bfd.RemoteSessionState is not Up, Demand mode is not active on the
+      remote system and the local system MUST send periodic BFD Control
+      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
+      of the Detection Time expiration rules in Section 6.8.4 of
+      [RFC5880].
+
+
+
+
+
+
+
+
+
+
+
+Katz, et al.                 Standards Track                   [Page 14]
+
+RFC 8562               BFD for Multipoint Networks            April 2019
+
+
+5.13.2.  Demultiplexing BFD Control Packets
+
+   This section is part of the replacement for Section 6.8.6 of
+   [RFC5880]; it is separated for clarity.
+
+      If the Multipoint (M) bit is set
+
+         If the Your Discriminator field is nonzero, the packet MUST be
+         discarded.
+
+         Select a session based on the source address, My Discriminator,
+         and the identity of the multipoint path on which the multipoint
+         BFD Control packet was received.
+
+         If a session is found, and bfd.SessionType is not
+         MultipointTail, the packet MUST be discarded.
+
+         Else
+
+            If a session is not found, a new session of type
+            MultipointTail MAY be created, or the packet MAY be
+            discarded.  This choice can be controlled by the local
+            policy, e.g., by setting a maximum number of MultipointTail
+            sessions.  Use of the local policy and the exact mechanism
+            of it are outside the scope of this specification.
+
+      Else (Multipoint (M) bit is clear)
+
+         If the Your Discriminator field is nonzero
+
+            Select a session based on the value of Your Discriminator.
+            If no session is found, the packet MUST be discarded.
+
+         Else (Your Discriminator is zero)
+
+            If the State field is not Down or AdminDown, the packet MUST
+            be discarded.
+
+            Otherwise, the session MUST be selected based on some
+            combination of other fields, possibly including source
+            addressing information, the My Discriminator field, and the
+            interface over which the packet was received.  The exact
+            method of selection is application specific and is thus
+            outside the scope of this specification.
+
+            If a matching session is found, and bfd.SessionType is not
+            PointToPoint, the packet MUST be discarded.
+
+
+
+
+Katz, et al.                 Standards Track                   [Page 15]
+
+RFC 8562               BFD for Multipoint Networks            April 2019
+
+
+            If a matching session is not found, a new session of type
+            PointToPoint MAY be created, or the packet MAY be discarded.
+            This choice MAY be controlled by a local policy and is
+            outside the scope of this specification.
+
+         If the State field is Init and bfd.SessionType is not
+         PointToPoint, the packet MUST be discarded.
+
+5.13.3.  Transmitting BFD Control Packets
+
+   The following procedure replaces Section 6.8.7 of [RFC5880] entirely.
+
+   With the exceptions listed in the remainder of this section, a system
+   MUST NOT transmit BFD Control packets at an interval less than the
+   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
+   is zero and the system is taking the Passive role.
+
+   A system MUST NOT transmit any BFD Control packets if bfd.SessionType
+   is MultipointTail.
+
+   A system MUST NOT periodically transmit BFD Control packets if Demand
+   mode is active on the remote system (bfd.RemoteDemandMode is 1,
+   bfd.SessionState is Up, and bfd.RemoteSessionState is Up), and a Poll
+   Sequence is not being transmitted.
+
+   A system MUST NOT periodically transmit BFD Control packets if
+   bfd.RemoteMinRxInterval is zero.
+
+
+
+
+
+
+Katz, et al.                 Standards Track                   [Page 16]
+
+RFC 8562               BFD for Multipoint Networks            April 2019
+
+
+   If bfd.SessionType is MultipointHead, the transmit interval MUST be
+   set to bfd.DesiredMinTxInterval (this should happen automatically, as
+   bfd.RemoteMinRxInterval will be zero).
+
+   If bfd.SessionType is not MultipointHead, the transmit interval MUST
+   be recalculated whenever bfd.DesiredMinTxInterval changes, or
+   whenever bfd.RemoteMinRxInterval changes, and is equal to the greater
+   of those two values.  See Sections 6.8.2 and 6.8.3 of [RFC5880] for
+   details on transmit timers.
+
+   A system MUST NOT set the Demand (D) bit if bfd.SessionType is
+   MultipointTail.
+
+   A system MUST NOT set the Demand (D) bit if bfd.SessionType is
+   PointToPoint unless bfd.DemandMode is 1, bfd.SessionState is Up, and
+   bfd.RemoteSessionState is Up.
+
+   If bfd.SessionType is PointToPoint or MultipointHead, a BFD Control
+   packet SHOULD be transmitted during the interval between periodic
+   Control packet transmissions when the contents of that packet would
+   differ from that in the previously transmitted packet (other than the
+   Poll (P) and Final (F) bits) in order to more rapidly communicate a
+   change in state.
+
+   The contents of transmitted BFD Control packets MUST be set as
+   follows:
+
+      Version
+
+         Set to the current version number (1).
+
+      Diagnostic (Diag)
+
+         Set to bfd.LocalDiag.
+
+      State (Sta)
+
+         Set to the value indicated by bfd.SessionState.
+
+      Poll (P)
+
+         Set to 1 if the local system is sending a Poll Sequence or is a
+         session of type MultipointHead soliciting the identities of the
+         tails, or zero if not.
+
+
+
+
+
+
+
+Katz, et al.                 Standards Track                   [Page 17]
+
+RFC 8562               BFD for Multipoint Networks            April 2019
+
+
+      Final (F)
+
+         Set to 1 if the local system is responding to a BFD Control
+         packet received with the Poll (P) bit set, or zero if not.
+
+      Control Plane Independent (C)
+
+         Set to 1 if the local system's BFD implementation is
+         independent of the control plane (it can continue to function
+         through a disruption of the control plane).
+
+      Authentication Present (A)
+
+         Set to 1 if authentication is in use in this session
+         (bfd.AuthType is nonzero), or zero if not.
+
+      Demand (D)
+
+         Set to bfd.DemandMode if bfd.SessionState is Up and
+         bfd.RemoteSessionState is Up.  Set to 1 if bfd.SessionType is
+         MultipointHead.  Otherwise, it is set to zero.
+
+      Multipoint (M)
+
+         Set to 1 if bfd.SessionType is MultipointHead.  Otherwise, it
+         is set to zero.
+
+      Detect Mult
+
+         Set to bfd.DetectMult.
+
+      Length
+
+         Set to the appropriate length, based on the fixed header length
+         (24) plus any Authentication Section.
+
+      My Discriminator
+
+         Set to bfd.LocalDiscr.
+
+      Your Discriminator
+
+         Set to bfd.RemoteDiscr.
+
+      Desired Min TX Interval
+
+         Set to bfd.DesiredMinTxInterval.
+
+
+
+
+Katz, et al.                 Standards Track                   [Page 18]
+
+RFC 8562               BFD for Multipoint Networks            April 2019
+
+
+      Required Min RX Interval
+
+         Set to bfd.RequiredMinRxInterval.
+
+      Required Min Echo RX Interval
+
+         Set to zero if bfd.SessionType is MultipointHead or
+         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
+
+         Included and set according to the rules in Section 6.7 of
+         [RFC5880] if authentication is in use (bfd.AuthType is
+         nonzero).  Otherwise, this section is not present.
+
+6.  Congestion Considerations
+
+   As a foreword, although congestion can occur because of a number of
+   factors, it should be noted that high transmission rates are by
+   themselves subject to creating congestion either along the path or at
+   the tail end(s).  As such, as stated in [RFC5883]:
+
+      it is required that the operator correctly provision the rates at
+      which BFD is transmitted to avoid congestion (e.g link, I/O, CPU)
+      and false failure detection.
+
+   Use of BFD in multipoint networks, as specified in this document,
+   over multiple hops requires consideration of the mechanisms to react
+   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 does not form
+   part of the BFD protocol itself, and its specification is thus
+   outside the scope of this document.
+
+
+
+
+
+Katz, et al.                 Standards Track                   [Page 19]
+
+RFC 8562               BFD for Multipoint Networks            April 2019
+
+
+   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 a head
+   node has no BFD-based mechanism and thus is not 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 the
+   extension described in [RFC8563].
+
+7.  IANA Considerations
+
+   This document has no IANA actions.
+
+8.  Security Considerations
+
+   The same security considerations as those described in [RFC5880]
+   apply to this document.  Additionally, implementations that create
+   MultpointTail sessions dynamically upon receipt of multipoint BFD
+   Control packets MUST implement protective measures to prevent an
+   infinite number of MultipointTail sessions from being created.  Below
+   are some points to consider in such implementations.
+
+      If a multipoint BFD Control packet did not arrive on a multicast
+      path (e.g., on the expected interface, with the expected MPLS
+      label, etc.), a MultipointTail session should not be created.
+
+      If redundant streams are expected for a given multicast stream,
+      the implementations should not create more MultipointTail sessions
+      than the number of streams.  Additionally, when the number of
+      MultipointTail sessions exceeds the number of expected streams,
+      the implementation should generate an alarm to users to indicate
+      the anomaly.
+
+      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
+      upper bound potentially being computed based on the number of
+      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.
+
+
+
+Katz, et al.                 Standards Track                   [Page 20]
+
+RFC 8562               BFD for Multipoint Networks            April 2019
+
+
+   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 asymmetric message authentication to BFD for
+   multipoint networks is outside the scope of this specification and is
+   for further study.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
+              (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
+              <https://www.rfc-editor.org/info/rfc5880>.
+
+   [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, <https://www.rfc-editor.org/info/rfc7880>.
+
+   [RFC8029]  Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
+              Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
+              Switched (MPLS) Data-Plane Failures", RFC 8029,
+              DOI 10.17487/RFC8029, March 2017,
+              <https://www.rfc-editor.org/info/rfc8029>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Katz, et al.                 Standards Track                   [Page 21]
+
+RFC 8562               BFD for Multipoint Networks            April 2019
+
+
+9.2.  Informative References
+
+   [MVPN-FAILOVER]
+              Morin, T., Ed., Kebler, R., Ed., and G. Mirsky, Ed.,
+              "Multicast VPN fast upstream failover", Work in Progress,
+              draft-ietf-bess-mvpn-fast-failover-05, February 2019.
+
+   [RFC4082]  Perrig, A., Song, D., Canetti, R., Tygar, J., and
+              B. Briscoe, "Timed Efficient Stream Loss-Tolerant
+              Authentication (TESLA): Multicast Source Authentication
+              Transform Introduction", RFC 4082, DOI 10.17487/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>.
+
+   [RFC8563]  Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky,
+              Ed., "Bidirectional Forwarding Detection (BFD) Multipoint
+              Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019,
+              <https://www.rfc-editor.org/info/rfc8563>.
+
+Acknowledgments
+
+   The authors would like to thank Nobo Akiya, Vengada Prasad Govindan,
+   Jeff Haas, Wim Henderickx, Gregory Mirsky, and Mingui Zhang who have
+   greatly contributed to this document.
+
+Contributors
+
+   Rahul Aggarwal of Juniper Networks and George Swallow of Cisco
+   Systems provided the initial idea for this specification and
+   contributed to its development.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Katz, et al.                 Standards Track                   [Page 22]
+
+RFC 8562               BFD for Multipoint Networks            April 2019
+
+
+Authors' Addresses
+
+   Dave Katz
+   Juniper Networks
+   1194 N. Mathilda Ave.
+   Sunnyvale, California  94089-1206
+   United States of America
+
+   Email: dkatz@juniper.net
+
+
+   Dave Ward
+   Cisco Systems
+   170 West Tasman Dr.
+   San Jose, California  95134
+   United States of America
+
+   Email: wardd@cisco.com
+
+
+   Santosh Pallagatti (editor)
+   VMware
+
+   Email: santosh.pallagatti@gmail.com
+
+
+   Greg Mirsky (editor)
+   ZTE Corp.
+
+   Email: gregimirsky@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Katz, et al.                 Standards Track                   [Page 23]
+