IS-IS and OSPF extensions for BIER-TE (Tree Engineering for Bit Index Explicit Replication) with MPLS and non-MPLS Encapsulation

Introduction describes per-packet stateless strict and loose path steered replication and forwarding for "Bit Index Explicit Replication" (BIER, ) packets. It is called BIER Tree Engineering (BIER-TE) and is intended to be used as the path steering mechanism for Traffic Engineering with BIER. BIER-TE introduces a new semantic for "bit positions" (BP) of link. , , and describe IS-IS, OSPF, OSPFv3 extensions respectively for distributing BitPositions configured on the links in "Bit Index Explicit Replication Traffic Engineering" (BIER-TE) domain. As described in section 2.4 in , BIER-TE inherits the encapsulation supporting from BIER unchanged. The encapsulation defined in , which specifies a common header format for both MPLS and non-MPLS networks, though the first 20-bits (referred to as BIFT-id) of the header is an "MPLS Label" in case of MPLS networks and is a local 20-bit opaque value in case of non-MPLS networks. As described in section 4.3 of , it is necessary to distinguish the BIER and BIER-TE packet and forwarding. like , , , and , the MPLS and non-MPLS encapsulation needs to be advertised for BIER-TE packet encapsulation. The advertisement can follow the BIER-TE BP advertisement, like the description in , , and . But it does not work well if there are many BIER-TE links need to be advertised. Too many octets in the advertisement will be consumed even if the same BIFT-id is used for different links. This document describes the IS-IS and OSPF protocol extensions that are required for BIER-TE with MPLS and non-MPLS encapsulation associated with prefix distributing.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

Terminology This document does not introduce more terminologies than , , , and , , .

Flooding of the BIER-TE Encapsulation Information in IS-IS A configured or selected prefix is used for the advertisement. When the associated prefix reachability is advertised, the BIER-TE Encapsulation sub-TLV and associated MPLS or non-MPLS Encapsulation Sub-sub-TLV is carried. In case both of the two encapsulation sub-sub-TLVs are advertised by one node, the label in MPLS encapsulation sub-sub-TLV and BIFT-id in non-MPLS encapsulation sub-sub-TLV SHOULD NOT be overlapped. The format is defined in . The flooding scope is the same with section 5 in .

Flooding of the BIER-TE Encapsulation Information in OSPF Same with IS-IS, a configured or selected prefix is used for the advertisement. When the associated OSPFv2 Extend Prefix TLV is advertised, the BIER-TE Encapsulation sub-TLV and associated MPLS or non-MPLS Encapsulation Sub-sub-TLV is carried. It is similar for OSPFv3, When the associated OSPFv3 Extend Prefix TLV for a configured or selected prefix is advertised, the BIER-TE Encapsulation sub-TLV and associated MPLS or non-MPLS Encapsulation Sub-sub-TLV is carried. In case both of the two encapsulation sub-sub-TLVs are advertised by one node, the label in MPLS encapsulation sub-sub-TLV and BIFT-id in non-MPLS encapsulation sub-sub-TLV SHOULD NOT be overlapped. The format defined in works for both OSPFv2 and OSPFv3. The flooding scope for OSPFv2 is the same with section 2.3 in . The flooding scope for OSPFv3 is the same with section 2.2 in .

Formats As described in section 4.3 in , the label for MPLS encapsulation or the BIFT-ID for non-MPLS encapsulation is allocatd per SD:BSL. A BIER-TE encapsulation sub-tlv is defined for indicating the following MPLS or non-MPLS encapsulation sub-sub-tlv.

Type: TBD0 (To be assigned by IANA).
Length: 2-octet. This field indicates the total length of the following MPLS or non-MPLS encapsulation sub-sub-tlvs.

BIER-TE MPLS Encapsulation Sub-sub-TLV

Type: TBD1 (To be assigned by IANA).
Length: 2-octet. This field indicates the following encapsulation information and potential sub-sub-sub-tlvs.
subdomain-id: A 1-octet field encoding the Unique value identifying the BIER subdomain. The values allowed in this field are specified in Section 1 of .
BS Len (BitString Length): A 4-bit field encoding the supported BitString length associated with this BFR-prefix. The values allowed in this field are specified in Section 2 of .
resv: A 8-bit field encoding for the reserving. The bit may be used to indicated the following sub-sub-sub-tlv.
Label: A 3-octet field, where the 20 rightmost bits represent the value of label. The 4 leftmost bits MUST be ignored. The labels are as defined in .

The BIER-TE MPLS encapsulation sub-sub-TLV may be advertised many times for different subdomain-id or BS Len.

BIER-TE Non-MPLS Encapsulation Sub-sub-TLV

Type: TBD2 (To be assigned by IANA).
Length: 2-octet. This field indicates the following encapsulation information and potential sub-sub-sub-tlvs.
subdomain-id: A 1-octet field encoding the Unique value identifying the BIER subdomain. The values allowed in this field are specified in Section 1 of .
BS Len (BitString Length): A 4-bit field encoding the supported BitString length associated with this BFR-prefix. The values allowed in this field are specified in Section 2 of .
resv: A 8-bit field encoding for the reserving. Now the leftmost bit is defined for indicating the existing of BIER-TE IPv6 Encapsulation sub-sub-sub-tlv.
BIFT-ID: A 3-octet field, where the 20 rightmost bits represent the BIFT-ID. The 4 leftmost bits MUST be ignored. The BIFT-ID is as defined in .

The BIER-TE non-MPLS encapsulation sub-sub-TLV may be advertised many times for different subdomain-id or BS Len.

BIER-TE IPv6 Encapsulation sub-sub-sub-tlv As described in section 4 of , which describes how the existing BIER encapsulation specified in works in a non-MPLS IPv6 network, a node that requires IPv6 encapsulation MUST advertise the BIER-TE IPv6 encapsulation sub-sub-sub-TLV, which follows the associated Non-MPLS Encapsulation, according to local configuration or policy in the BIER domain to request other BFRs to always use IPv6 encapsulation.

Type: TBD3 (To be assigned by IANA).
Length: 0.

IANA Considerations TBD.

Security Considerations This document does not introduce more security considerations than and , , and .