bgp nlri ls

Pre-Alpha. This page describes behavior that may change.

BGP Link-State (RFC 7752) and its VPN variant. Decode-only: Ze parses received BGP-LS NLRI. Encoding is not implemented.

Configuration

plugin {
    internal nlri-ls { use bgp-nlri-ls }
}

bgp {
    peer bgpls-collector {
        family {
            bgp-ls/bgp-ls     { prefix { maximum 100000; } }
            bgp-ls/bgp-ls-vpn { prefix { maximum 100000; } }
        }
    }
}

Behaviour

The plugin decodes BGP-LS NLRI (AFI 16388, SAFI 71 and 72), covering node, link, and prefix types with 40 TLV decoders. Received BGP-LS routes are surfaced through the event stream as structured JSON, which is useful for building topology visualisers, traffic-engineering controllers, and route analytics.

Unknown NLRI types are skipped, not fatal. An unrecognized type is preserved and propagated, and the decoder moves on to the next NLRI in the same UPDATE. The 4-octet header carries a Total NLRI Length, so the next NLRI can be located without understanding the type. This matters for densely packed UPDATEs: previously one unknown type early in the message erased the structured view of every NLRI after it, across the looking glass, the API, and the CLI. RFC 9552 section 5.1 requires preserve-and-propagate here, using RFC 7606 section 5.4's own "unless the relevant specification specifies otherwise" clause. For this family, meeting an unrecognized type is the expected case rather than an exceptional one.

Encoding is not implemented. Ze cannot send BGP-LS routes. If you need to originate BGP-LS updates, Ze is not the answer.

Interactions

Decode-only. bgp-rib stores the parsed NLRI but does not run best-path selection on BGP-LS.
Pairs with external analytics tools that subscribe to the event stream.