Support of Point-to-Multipoint Bidirectional Forwarding Detection (BFD) in Transparent Interconnection of Lots of Links (TRILL)
updates
Extracted elements (16)
A new RBridge Channel message code point (0x007) was allocated for P2MP BFD rather than reusing 0x002 because P2MP BFD head-to-tail probing requires multicast (M bit = 1), which is explicitly rejected by the existing point-to-point BFD channel handler.
Multi-hop P2MP BFD sessions are expected to be configured by the network manager rather than bootstrapped automatically, because the TRILL adjacency mechanism only bootstraps one-hop BFD sessions.
As specified in RFC 7178, when a tail receives TRILL Data packets sent as BFD RBridge Channel messages, it absorbs the packets itself rather than delivering them to attached end stations.
RFC 7175 states that if the M bit of the TRILL Header containing a BFD Control packet is nonzero, the packet is generally dropped. P2MP BFD requires M=1 (multicast), making the existing 0x002 protocol code point unusable; hence the new 0x007 code point is required.
This document updates RFC 7177 (TRILL Adjacency) to clarify that BFD support references both RFC 7175 and RFC 8564, and adds a normative reference to this document.
An RBridge that supports P2MP BFD MUST support the new RBridge Channel message for P2MP BFD (protocol code point 0x007).
If the M bit in the TRILL Header of a P2MP BFD Control packet is zero, the packet MUST be discarded. If the M bit is one, it is processed.
If the tail needs to notify the head about the failure of a multipath, the tail is required to send unicast BFD Control packets using the same Data Label as used by the head.
A new RBridge Channel message for P2MP BFD Control is defined with protocol code point 0x007. This is distinct from the existing point-to-point BFD Control message (0x002) because P2MP BFD requires the M bit to be set to 1 in the TRILL Header.
P2MP BFD demultiplexing at the tail is based on a combination of source address, My Discriminator (per RFC 8562), and additionally the Data Label (inner VLAN or Fine-Grained Label per RFC 7172).
P2MP BFD uses two session types from RFC 8562: MultipointHead at the head end (bound to a multipoint path, sends BFD Control, receives none) and MultipointTail dynamically created per multipoint path at each tail (receives BFD Control from head).
The capability to support P2MP BFD is announced within the RBridge Channel Protocols sub-TLV in Link State PDUs (LSPs) as specified in RFC 7176.
When a tail loses connectivity (detected by not receiving the P2MP BFD RBridge Channel message from the head), it notifies the head using unicast BFD Control packets transmitted via the existing RBridge Channel message (protocol 0x002) assigned to BFD Control.
IANA allocated protocol number 0x007 ('P2MP BFD Control') from the Standards Action range of the 'RBridge Channel Protocols' registry within the 'Transparent Interconnection of Lots of Links (TRILL) Parameters' registry.
Multipoint BFD provides its own authentication but not encryption. RFC 7978 extends RBridge Channel messages with security but its encryption is only for point-to-point messages, so encryption is not available for P2MP BFD. RFC 7978 authentication is stronger than BFD's own mechanisms, so BFD security is redundant when RFC 7978 authentication is in use. Group keying support is expected in a future TRILL document to enable both encryption and authentication.
The head maintains a MultipointHead session per multipoint path; each tail dynamically creates a MultipointTail session per multipoint path. For tracking active tails, the head maintains a MultipointClient session per receiver of interest (per RFC 8563).