| Internet-Draft | Abbreviated Title | July 2022 |
| Zhang, et al. | Expires 6 January 2023 | [Page] |
This document describes the OSPF protocol extension that is required for BIER-TE with MPLS and non-MPLS encapsulation.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 6 January 2023.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[I-D.ietf-bier-te-arch] describes per-packet stateless strict and loose path steered replication and forwarding for "Bit Index Explicit Replication" (BIER, [RFC8279]) 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. [I-D.ietf-bier-te-ospf] describes OSPF extensions for distributing BitPositions configured on the links in "Bit Index Explicit Replication Traffic Engineering" (BIER-TE) domain.¶
As described in section 2.3 in [I-D.ietf-bier-te-arch], BIER-TE inherits the encapsulation supporting from BIER unchanged. The encapsulation defined in [RFC8296], 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 [I-D.ietf-bier-te-arch], it is necessary to distinguish the BIER and BIER-TE packet and forwarding. like [RFC8444] and [I-D.ietf-bier-lsr-non-mpls-extensions], the MPLS and non-MPLS encapsulation needs to be advertised for BIER-TE packet encapsulation.¶
This document describes the OSPF protocol extension that is required for BIER-TE with MPLS and non-MPLS encapsulation associated with link BitPosition distributing.¶
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 [RFC2119].¶
This document does not introduce more terminologies than [RFC8279], [RFC8296], [RFC8444], [I-D.ietf-bier-te-arch] and [I-D.ietf-bier-te-ospf].¶
[I-D.ietf-bier-te-ospf] defines a BIER-TE Sub-TLV to distribute the Link BitPosition information about the link. This document defines the MPLS Encapsulation Sub-sub-TLV and the Non-MPLS Encapsulation Sub-sub-TLV associate with the BIER-TE Sub-TLV to carry the MPLS and non-MPLS encapsulation information.¶
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 following description is the almost same with [RFC8444] since [I-D.ietf-bier-te-arch] inherit the encapsulation of BIER header.¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max SI | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |BS Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "label range" is the set of labels beginning with the Label and ending with (Label + (Max SI)). A unique label range is allocated for each BitString length and sub-domain-id.¶
The size of the label range is determined by the number of SIs (Section 1 of [RFC8279]) that are used in the network. Each SI maps to a single label in the label range: the first label is for SI=0, the second label is for SI=1, etc.¶
If the label associated with the Maximum Set Identifier exceeds the 20-bit range, the BIER MPLS Encapsulation Sub-TLV containing the error MUST be ignored.¶
If the BitString length is set to a value that does not match any of the allowed values specified in [RFC8296], the BIER MPLS Encapsulation Sub-TLV containing the error MUST be ignored.¶
The "BIFT-id range" is the set of 20-bit values beginning with the BIFT-id and ending with (BIFT-id + (Max SI)).¶
The flooding scope of this information is the same with section 2.3 in [RFC8444].¶
The following description is the almost same with section 3.2 in [I-D.ietf-bier-lsr-non-mpls-extensions] since [I-D.ietf-bier-te-arch] inherit the encapsulation of BIER header.¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max SI | BIFT-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |BS Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The BIFT-id range, limitation and flooding scope is the same with the MPLS encapsulation sub-sub-TLV.¶
TBD.¶
This document does not introduce more security considerations than [I-D.ietf-bier-te-arch] and [I-D.ietf-bier-te-ospf].¶