Tethering A BIER Router To A BIER Incapable Router

Familiarity with BIER {{!RFC8279}} architecture, protocols and procedures is assumed. Some terminologies are listed below for convenience. BIER: Bit Indexed Explicit Replication BFR: BIER Forwarding Router BFER: BIER Forwarding Egress Router BFR-prefix: Each BFR is assigned a single "BFR-prefix" for each sub-domain to which it belongs. It is recommended that the BFR-prefix be a loopback address of the BFR.

Consider the scenario in where router X does not support BIER. BFER1..n and BFR1..n are BIER capable - implied by their names.

------ BFR2 ------- BFER2 / BFER1 --- BFR1 ---- X ------- BFR3 ------- BFER3 ......... \ ------ BFRn ------- BFERn For BFR1 to forward BIER traffic towards BFR2...BFRn, it needs to tunnel individual copies through X. This degrades to "ingress" replication to those BFRs. If X's connections to BFRs are long distance or bandwidth limited, and n is large, it becomes very inefficient. A solution to the inefficient tunneling is to attach (tether) a BFRx to X as depicted in :

------ BFR2 ------- BFER2 / BFER1 --- BFR1 ---- X ------- BFR3 ------- BFER3 / \ ......... / \ BFRx ------ BFRn ------- BFERn Instead of BFR1 tunneling to BFR2, ..., BFRn directly, BFR1 will tunnel BIER packets to BFRx, which will then tunnel to BFR2, ..., BFRn. For the ingress replication from BFRx to BFR2..n to be acceptable, the bandwidth between BFRx and X needs to be adequate. That should not be a problem with local and fat pipes between them. For BFR1 to tunnel BIER packets to BFRx, the BFR1-BFRx tunnel needs to be announced in Interior Gateway Protocol (IGP) as a forwarding adjacency so that BFRx will appear on the Shortest Path First (SPF) tree. This needs to happen in a BIER-specific topology so that unicast traffic would not be tunneled to BFRx. Obviously, this is operationally cumbersome. Section 6.9 of the BIER architecture specification delineates a methodology for tunneling BIER packets through incapable routers without the need to explicitly announce tunnels. Nonetheless, this method is inapplicable in the current context, as BFRx is not a node in the SPF tree rooted at BFR1 This document specifies the tethering solution that addresses the above-mentioned problems. In the case of IGP, BFRx could advertise that it is X's helper and other BFRs will use BFRx (instead of X's children on the SPF tree) to replace X during its post-SPF processing as described in section 6.9 of the BIER architecture specification . X does not need to be BIER-aware at all. In the case of BGP, X does need to be "slightly BIER-aware" in the control plane, as described in .

While the scenario in has a direct connection between BFRx and X, other network configurations are possible. As long as BIER packets can be tunneled to BFRx without requiring X to do BIER forwarding and BFRx will not send them back to X's upstream BFR, the tethering solution works. Additionally, the helper BFRx can be a transit helper, i.e., it has other connections (instead of being a stub helper that is only connected to X), as long as BFRx won't send BIER packets tunneled to it back to the tunnel ingress. shows an example topology:

------ BFR2 ------- BFER2 / BFER1 --- BFR1 ---- X ------- BFR3 ------- BFER3 | | BFRx ------ BFR4 ------- BFER4 \ ------ BFR5 ------- BFER5 In the above example, BFR1 can tunnel one copy to BFRx, which will tunnel to BFR2/BFR3 and send natively to BFR4/BFR5 respectively. In the example of , there is a connection between BFR1 and BFRx. If the link metrics are all 1 on the three sides of BFR1-X-BFRx triangle, a loop won't happen but if the BFRx-X metric is 3 while the other two sides of the triangle have metric 1 then BFRx will send BIER packets tunneled to it from BFR1 back to BFR1, causing a loop.

------ BFR2 ------- BFER2 / BFER1 --- BFR1 ---- X ------- BFR3 ------- BFER3 \ / \ ......... \ / \ BFRx ------ BFRn ------- BFERn This can easily be prevented if BFR1 does an SPF calculation with the helper BFRx as the root. For any BFERn reached via X from BFR1, if BFRx's SPF path to BFERn includes BFR1 then BFR1 must not use the helper. Instead, BFR1 must directly tunnel packets for BFERn to X's BFR (grand-)child on BFR1's SPF path to BFERn, per section 6.9 of . Notice that this SPF calculation on BFR1 with BFRx as the root is not different from the SPF done for a neighbor as part of Loop-Free Alternate (LFA) calculation. In fact, BFR1 tunneling BIER packets to X's helper is not different from tunneling unicast packets to a TI-LFA backup. Also notice that, instead of a dedicated helper BFRx, any one or multiple ones of BFR2..n can also be the helper (as long as the connection between that BFR and X has enough bandwidth for replication to multiple helpers through X). To allow multiple helpers to help the same non-BFR, the "I am X's helper" advertisement carries a priority. BFR1 will choose the helper advertising the highest priority among those satisfying the loop-free condition described above. When there are multiple helpers advertising the same priority and satisfying the loop-free condition, any one or multiple ones could be used solely at the discretion of BFR1. The tethering solution works for the situation in as well, where a helper BFRxy helps two different non-BFRs X and Y.

----- BFR2 ------- BFER2 / X ------- BFR3 ------- BFER3 / | \ / \ ----- BFR4 ------- BFER4 / \ BFER1 -- BFR1 BFRxy ------------- BFERxy \ / \ / ----- BFR5 ------- BFER5 \ | / Y ------- BFR6 ------- BFER6 \ ----- BFRn ------- BFERn

The procedures in this document apply when a BFRx is tethered to a BIER incapable router X as X's helper for BIER forwarding. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Suppose that the BIER domain uses BIER signaling extensions to ISIS or OSPF . A helper node (BFRx) MUST advertise a BIER Helped Node sub-sub-TLVs in the BIER Info sub-TLV in the case of ISIS or a BIER Helped Node sub-TLV in the BIER sub-TLV in the case of OSPFv2/OSPFv3:

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List of <Router-ID, Priority> for the Helped Nodes (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Type is TBD1 in the case of ISIS, TBD2 in the case of OSPFv2, or TBD3 in the case of OSPFv3, to be assigned by IANA. In the case of ISIS, the Value field is a list of <6-octet ISIS System-ID, 1-octet Priority> tuples, one for each helped node. The number of tuples is derived from the Length field of the sub-sub-TLV. In the case of OSPFv2 or OSPFv3, the Value field is a list of <4-octet OSPF Router-ID, 1-octet Priority> tuples, one for each helped node. The number of tuples is derived from the Length field of the sub-TLV. When there are more than one helper nodes for a helped non-BFR node, the helper advertising a higher priority MUST be preferred. If there are multiple helpers advertising the same highest priority, ECMP through some or all of those equal-priority helpers MAY be used. Alternatively, any one of them MAY be used. The post-SPF processing procedures in Section 6.9 of the BIER architecture specification are modified as follows for BIER tethering purposes. Note that, BFR-B refers to the calculating node in Section 6.9 of . BFR-B looks in turn at each of its child nodes on the BIER-SPF tree. If one of the child nodes, say X, does not support BIER, BFR-B removes X from the tree. The child nodes of X that has just been removed are then re-parented on the tree, so that BFR-B now becomes their parent. Each child of X that is re-parented, say Cx, maintains an ordered list of nodes and X is added to the tail of that list. It is possible that X itself may be a re-parented child and has a non-empty list already. In that case, X's list is copied to Cx, and X is added to the tail of the list. BFR-B then continues to look at each of its child nodes, including any nodes that have been re-parented to BFR-B as a result of the previous step. At the end of the above iterations, BFR-B's children on the BIER-SPF tree will all be BFRs. Some of them may be non-adjacent (not directly connected to BFR-B) and BFR-B could just tunnel to them as described in Section 6.9 of , i.e., without the tethering benefit. A non-adjacent child has a non-empty list built in Step 2, which is a list of BIER-incapable nodes between BFR-B and the child. That list is used for the tethering purposes as follows. For each non-adjacent child (with a non-empty list), the following additional procedures are performed: Starting with the first node in the ordered list of incapable nodes, say N1, check if there is one or more helper nodes for N1. If not, go to the next node in the list. Order all the helper nodes of N1 in descending order based on the numeric values of priority and BIER prefix. Starting with the first one, say H1, check if BFR-B could use H1 as an LFA next hop to reach the child. If yes, tunneling to H1 (which is a helper to a node upstream of the child) instead of to the child itself can be used and the procedure stops for the child unless there is another helper in the list with the same priority (in which case ECMP could be used). Otherwise, go to the next helper in order and repeat. If none of the helper nodes of N1 can be used, go to the next node in the list of incapable nodes and repeat. If the above procedure finishes without finding any usable helper, then direct tunneling to the child has to be used. The problem posited in is not solved for this child, but nothing is lost and forwarding continues as if there were no helpers available. Notice that only the building and use of the list for the non-adjacent children are the extensions to the original Section 6.9 procedures.

Suppose that the BIER domain uses BGP signaling instead of IGP. BFR1..n advertise BFR-prefixes that are reachable through them, with BIER Path Attributes (BPA) attached. There are two situations regarding X's involvement: X does not participate in BGP peering at all X re-advertises the BFR-prefixes but it does not update the BPA. In either case, the BFR1..n will tunnel BIER packets directly to each other. This may not be desired as explained earlier. To make BFR1 tunnel one copy to BFRx which then tunnel to BFR2...n, the following MUST be done in the case of BGP (no new signaling is needed): Configure BGP sessions between X and BFR1..n and BFRx. BFRx advertises its own BFR-prefix with BPA to X, and sets the BIER Nexthop to itself. When X re-advertises BFR-prefixes to its helper BFRx, it does not change the BPA. This allows BFRx to tunnel BIER packets to BFR1..n. When X re-advertises BFR-prefixes to BFR1..n, it replaces the BPA with the one attached to BFRx's BFR-prefix. Notice that if X supported BIER forwarding, it'd re-advertise the BFR-prefixes with its own BPA so that BFR1..n would send BIER traffic to itself. Since X does not BIER forwarding, using BFRx's BPA instead allows BFR1..n to tunnel BFRx.

This specification does not introduce additional security concerns beyond those already discussed in BIER architecture and OSPF/ISIS/BGP extensions for BIER signaling.

explains the motivation and benefits of BIER tethering. Configuring a BIER helper is simple and other BFRs can automatically tunnel relevant BIER packets to the helper nodes. Tethering a stub helper to a helped node is most straightforward (). Other deployment scenarios are also possible and discussed in . In the case of using multiple helpers for one helped node, the helpers may be provisioned with the same or different priorities, depending on which one should be preferred.

This document requests a new sub-sub-TLV type value from the "Sub-sub-TLVs for BIER Info Sub-TLV" registry in the "IS-IS TLV Codepoints" registry:

Type Name ---- ---- TBD1 BIER Helped Node This document requests a new sub-TLV type value from the OSPFv2 Extended Prefix TLV Sub-TLV registry:

Type Name ---- ---- TBD2 BIER Helped Node This document also requests a new sub-TLV type value from the OSPFv3 Extended-LSA Sub-TLVs registry:

Type Name ---- ---- TBD3 BIER Helped Node

The following also contributed to this document.

Zheng(Sandy) Zhang ZTE Corporation EMail: zzhang_ietf@hotmail.com Hooman Bidgoli Nokia EMail: hooman.bidgoli@nokia.com

The author wants to thank Eric Rosen and Antonie Przygienda for their review, comments and suggestions.