The Use of Bidirectional Forwarding Detection (BFD) for Multipoint Networks in Protocol Independent Multicast - Sparse Mode (PIM-SM)

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

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 https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 5 February 2022.¶

Copyright Notice

Copyright (c) 2021 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.¶

Table of Contents

1. Introduction

Faster convergence in the control plane, in general, is beneficial and allows minimizing periods of traffic blackholing, transient routing loops, and other scenarios that may negatively affect service data flow. That equally applies to unicast and multicast routing protocols.¶

[RFC7761] is the current specification of the Protocol Independent Multicast - Sparse Mode (PIM-SM) for IPv4 and IPv6 networks. A conforming implementation of PIM-SM elects a Designated Router (DR) on each PIM-SM interface. When a group of PIM-SM nodes is connected to a shared-media segment, e.g., Ethernet, the node elected as DR is to act on behalf of directly connected hosts in the context of the PIM-SM protocol. Failure of the DR impacts the quality of the multicast services it provides to directly connected hosts because the default failure detection interval for PIM-SM routers is 105 seconds. Introduction of Backup DR (BDR) ([I-D.ietf-pim-dr-improvement]) improves convergence time in PIM-SM over shared-media segment but still depends on a long failure detection interval.¶

Bidirectional Forwarding Detection (BFD) [RFC5880] had been originally defined to detect failure of point-to-point (p2p) paths - single-hop [RFC5881], multihop [RFC5883]. In some PIM-SM deployments, a p2p BFD can be used to detect a failure and enable faster conversion. [RFC8562] extends the BFD base specification [RFC5880] for multipoint and multicast networks precisely characterizes deployment scenarios for PIM-SM over a LAN segment. Among specific characteristics of p2mp BFD that particularly benefit PIM-SM over a LAN segment is a faster transition to the Up state of the p2mp BFD session due to avoidance of the three-way handshake required in p2p BFD [RFC5880]. Also, because the router that transmits BFD Control messages uses the BFD Demand mode [RFC5880], it maintains less BFD state comparing to the Asynchronous mode. Point-to-multipoint (p2mp) BFD can enable faster detection of PIM-SM router failure and thus minimize multicast service disruption. The monitored PIM-SM router acts as the head and other routers as tails of a p2mp BFD session. This document defines the monitoring of PIM-SM DR and BDR using p2mp BFD. Other cases of using p2mp BFD in PIM-SM are outside the scope of this specification. The document also defines the extension to PIM-SM [RFC7761] to bootstrap a PIM-SM router to join in p2mp BFD session over shared-media link.¶

2. BFD Discriminator PIM Hello Option

Figure 1 displays the new optional BFD Discriminator PIM Hello option to bootstrap a tail of the p2mp BFD session.¶

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          OptionType           |         OptionLength          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       My  Discriminator                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where new fields are interpreted as:¶

• OptionType: TBA.¶
• OptionLength: MUST be set to 4.¶
• My Discriminator: My Discriminator ([RFC5880]) value allocated by the head.¶

If the value of the OptionLength field is not equal to 4, the BFD Discriminator PIM Hello option is considered malformed, and the receiver MUST stop processing PIM Hello options. If the value of the My Discriminator field equals zero, then the BFD Discriminator PIM Hello option MUST be considered invalid, and the receiver MUST ignore it. The receiver SHOULD log the notification regarding the malformed or invalid BFD Discriminator Hello option under the control of a throttling logging mechanism.¶

3. IANA Considerations

IANA is requested to allocate a new OptionType value from PIM-Hello Options registry according to:¶

4. Security Considerations

The security considerations discussed in [RFC7761], [RFC5880], [RFC8562], [RFC8775], and [I-D.ietf-pim-dr-improvement] apply to this document.¶

An implementation that supports this specification SHOULD use a mechanism to control the maximum number of BFD sessions that can be active at the same time.¶

Authors' Addresses