Hello BIRD team, This patch (for master branch / 2.18) adds negotiation for the Multiple Labels capability (Capability Code 8, RFC 8277) to control MPLS label stack encoding in BGP NLRI updates. BIRD currently reads labels until BOS unconditionally, as specified by RFC 3107. This works fine with peers that do the same (including previous BIRD versions) but does not conform to RFC 8277 when interoperating with peers that only expect a single label. Note that this also matters for SRv6: when an SRv6 service TLV is present (RFC 9252), the NLRI label field carries raw 24-bit values used for SID transposition, and the BOS bit is not set, so it cannot be used to delimit the label stack. The patch adds a new "multiple labels" channel option with 4 modes: - always (default): always read/write label stacks until BOS. The capability is not advertised. This preserves compatibility with existing BIRD peers and RFC 3107 implementations that send multiple labels. - advertise: same as always, but also advertises the capability to the peer. - yes / negotiated: advertise the capability and only use BOS-delimited stacks when the peer also advertises it (strict RFC 8277 behavior). If the peer does not support the capability, only a single label is read and sent. - no / disabled: no capability advertised, only single labels used. The default "always" preserves the existing BIRD behavior, so this is a no-op change for existing configurations. "require multiple labels yes" rejects sessions where the peer does not advertise the capability. Additional RFC 8277 compliance: - Duplicate AFI/SAFI triples in the capability are handled by keeping the first value and ignoring duplicates (Section 2.1) - Excess labels on receive trigger treat-as-withdraw per RFC 7606 (Section 2.1) - Routes with more labels than the peer's advertised count are rejected on export (Section 3.2.1/3.2.2) Thanks! -- Sébastien