Difference between revisions of "VPP/BIER"

Latest revision as of 12:44, 12 December 2018

BIER

BIER is a multicast transport technology as described in https://tools.ietf.org/html/rfc8279

there are three actions to consider when programming BIER; imposition, mid-point and disposition. Imposition is the act of entering a BIER domain, IP multicast traffic that is intended to be transported over a BIER domain will therefore result in an imposition (the act of pre-prending a BIER header). Conversely, disposition is the act of leaving a BIER domain and hence stripping the BIER header. Mid-point forwarding uses the BIER header and the bits therein to forward packets to BIER neighbours.

A BIER table is a data-structure that holds entries corresponding to devices that have a bit-position. A lookup in the table (or FIB) is based on the destination bit-position as retrieved from the packet to be forwarded. There is one BIER table per-set, per-subdomain and per-Bit-string-length (BSL), therefore a BIER table's ID is composed of the corresponding set, sub-domain and BSL it represents. This is the ID that API clients will see. internally VPP constructs tables for ECMP, so the extended internally key includes the ECMP ID.

As a transport protocol BIER can run over MPLS or non-MPLS (https://tools.ietf.org/html/rfc8296) networks. in MPLS networks the packet's local label will map to a BIER table. To add a BIER table that has such an associated label do:

 # mpls table add 0
 # bier table add sd 1 set 2 bsl 256 mpls 56

the result is:

 # sh bier fib
   [@0] bier-table:[sub-domain:1 set:2 ecmp:65535 bsl:256 local-label:56]
   [@1] bier-table:[sub-domain:1 set:2 ecmp:0 bsl:256 local-label:1048576]
   [@2] bier-table:[sub-domain:1 set:2 ecmp:1 bsl:256 local-label:1048576]
   ...

this output shows the 'main' table, the one the API/CLI call created, with a ECMP ID of ~0 and a defined local label, plus the tables VPP created internally for ECMP, which have valid ECMP-IDs.

To create a table that does not use an MPLS label, just omit the label from the CLI.

Impostion

imposition is modelled by a BIER-imposition object; these represent both the BIER header to impose, the bit-position of the node from which the BIER packet originates (i.e. this node) and the subsequent table in which the resulting BIER packet will be forwarded.

 # bier imp table sd 1 set 2 bsl 256 header <BIT-STRING> source <BIT-POSITION>

n.b. CLI is under construction but the API is available

the value returned from the CLI/API is the ID of the imposition object which can be used to describe a path in the mFIB.

Disposition

When a BIER packets leaves a BIER domain it is forwarded based on 1) when it originated and 2) the next header in the stack. To forward based on the originator a BIER-dispoition table contains entries for each originator.

 # bier disp table add X

where X is the user's choice of table-ID. Entries are added to the disposition table for each originator from which packets should be accepted.

 # bier disp entry add table X source Y payload-proto [v4|v6|mpls] via ...

where X is the table-ID previously created, Y the originator to accept from and "via ..." is a description of the 'path', i.e. result, the packet should take - the usual description used by IP and MPLS are valid here; i.e. "via 192.168.1.1 GigEthernet0/0/0" or "via mpls-lookup 5"

Mid-point

In a similar manner to IP and MPLS, routes are added to the BIER FIB to describe reachability to each destination bit-position. BIER routes can also be ECMP.

# bier route sd X set Y bsl Z bp K via ...

adds the route to the table whose ID is [sd:X, set:Y, BSL:Z] for the destination bit-position, K. Again "via ... ' describes the peer to which to send the packets matching the route. In order to perform disposition, i.e. to say that 'bp K' is this nodes bit-position the path is "via bier-disp-table Q".

Counters

Still under development, but, counters are currently collected per-neighbour, which is per "via ...." in the route. However, how the control plane maps this information to its own data structures is TBD. Counters could also be collected per-imposition object and/or per-disposition entry relatively cheaply. Due to the mechanics of BIER forwarding (see the RFC) collecting counters per destination bit-position (per-route), which while possible would be expensive, since it would involve another pass through the header counting bits, is not currently done, but this could be a additional knob to enable.