YANG Data Model for BIER Protocol

describes a new architecture for the forwarding of multicast data packets. Known as "Bit Index Explicit Replication"(BIER), that architecture provides optimal forwarding of multicast data packets through a "multicast domain". YANG is a data modeling language that was introduced to model the configuration and operational state of a device managed using network management protocols such as the Network Configuration Protocol (NETCONF) or RESTCONF . YANG is now also being used as a component of other management interfaces, such as command-line interfaces (CLIs). This document defines a YANG data model that can be used to configure and manage devices supporting Bit Index Explicit Replication"(BIER). The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA).

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.

The terminology for describing YANG data models is found in . The following abbreviations are used in this document and the defined model:

BIER:: Bit Index Explicit Replication
BFR:: Bit Forwarding Router
BIFT:: Bit Index Forwarding Table
BSL:: BitStringLength
SI:: Set Identifier
IS-IS:: Intermediate System-to-Intermediate System
OSPF:: Open Shortest Path First

Tree diagrams used in this document follow the notation defined in .

In this document, names of data nodes, actions, and other data model objects are often used without a prefix, as long as the context clearly indicates the YANG module in which each name is defined. Otherwise, names are prefixed using the standard prefix associated with the corresponding YANG module, as shown in Table 1. Prefixes and Corresponding YANG Modules

Prefix	YANG Module	Reference
yang	ietf-yang-types
inet	ietf-inet-types
if	ietf-interfaces
rt	ietf-routing

The data model can be used to configure and manage BIER protocol features. The operational state data and statistics can be retrieved by this model. The protocol-specific notifications are also defined in the model. This model is used to consistently provision the BIER parameters for one or more BIER subdomains across all BFIR/BFR/BFER. This configuration will also be read by BIER enabled IGPs, such as IS-IS , OSPFv2 and OSPFv3 to learn the BIER parameters. In scenarios where the IGP protocol is not used/available, this model defines the writeable BIFT and all BFIR/BFR/BFER can get the BIFT directly from the controller, or by any other ways such as configuration.

The ietf-bier YANG module augments the routing container in the ietf-routing model with a BIER container and defines generic BIER configuration and operational state. This module is augmented by modules supporting different data planes.

The ietf-bier YANG module augments the routing container in the ietf-routing model with a BIER container and defines generic BIER configuration. It includes: sub-domain:Defines the relevant BIER information of the BIER subdomain, such as configuring the BIER domain identifier, configuring the BFR prefix in the BIER subdomain, configuring the Underlay protocol for advertising BIER information, etc. It contains two in-bift-id generation methods, one is direct configuration, the other is calculated based on <BSL,SD,SI>. The leaf "in-bift-id" is the first BIFT-id of the BIFT-id range. The "BIFT-id range" is the set of 20-bit values beginning with the in-bift-id and ending with (in-bift-id + (Max SI)).The leaf "in-bift-id-encoding" is defined as a boolean, used to enable or disable whether to calculate in-bift-id based on < BSL,SD,SI>. bift: Defines the Bit Index Forwarding Table. The grouping "bfr-nbr" is to define the BFR neighbor, and it contains two bift-id generation methods, one is direct configuration, the other is calculated based on < BSL,SD,SI>. The leaf "out-bift-id-encoding" is defined as a boolean, used to enable or disable whether to calculate out-bift-id based on < BSL,SD,SI>.

Support of BIER extensions for a particular IGP control plane is achieved by augmenting routing-protocol configuration with BIER extensions. This augmentation SHOULD be part of the routing-protocol YANG modules as not to create any dependency for implementations to support BIER extensions for all routing protocols. This module defines groupings that SHOULD be used by IGP BIER modules. The "enabled" leaf enables BIER extensions for the routing-protocol instance. The "sub-domain" container controls the routing-protocol instance's advertisement of the relevant BIER information of the BIER subdomain and the processing of received the relevant BIER information of the BIER subdomain.

The model defines the following notifications for BIER. This module defines groupings that SHOULD be used by IGP BIER modules. bfr-id-collision: Raised when control-plane-advertised BFR ID have conflicts. bfr-id-out-of-range: Raised when control-plane-advertised BFR ID is larger than locally configured (bsl * max-si). bfr-zero: Raised when invalid value associated with prefix. sub-domain-id-collision: Raised when control-plane-advertised Sub domain ID have conflicts.

file "ietf-bier@2025-02-10.yang" module ietf-bier { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-bier"; prefix "bier"; import ietf-routing{ prefix "rt"; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA Version)"; } import ietf-interfaces{ prefix "if"; reference "RFC 8343: A YANG Data Model for Interface Management"; } import ietf-inet-types{ prefix "inet"; reference "RFC 6991: Common YANG Data Types"; } import ietf-isis{ prefix "isis"; reference "RFC 9130: YANG Data Model for the IS-IS Protocol"; } import ietf-ospf{ prefix "ospf"; reference "RFC 9129: YANG Data Model for the OSPF Protocol"; } organization "IETF BIER(Bit Indexed Explicit Replication) Working Group"; contact "WG Web: <https://datatracker.ietf.org/wg/bier/> WG List: <mailto:bier@ietf.org> WG Chair: Tony Przygienda <mailto:tonysietf@gmail.com> WG Chair: Greg Shepherd <mailto:gjshep@gmail.com> Editor: Ran Chen <mailto:chen.ran@zte.com.cn> Editor: Fangwei Hu <mailto:hu.fangwei@zte.com.cn> Editor: Zheng Zhang <mailto:zhang.zheng@zte.com.cn> Editor: Xianxian Dai <mailto:dai.xianxian@zte.com.cn> Editor: Mahesh Sivakumar <mailto:masivaku@cisco.com> "; description "The YANG module defines a generic configuration model for BIER.; This YANG module conforms to the Network Management Datastore Architecture (NMDA), as described in RFC 8242. 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 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices."; reference "RFC XXXX: YANG Data Model for BIER"; revision 2025-02-10 { description "initial version."; reference "RFC XXXX: YANG Data Model for BIER "; } /* Identities */ identity bier-encapsulation{ description "Base identity for BIER encapsulation."; } identity bier-encapsulation-mpls { base bier-encapsulation; description "This identity represents MPLS encapsulation for bier."; } identity bier-encapsulation-ipv6 { base bier-encapsulation; description "This identity represents ipv6 encapsulation for bier."; } identity bier-encapsulation-ethernet { base bier-encapsulation; description "This identity represents ethernet encapsulation for bier."; } identity address-family { description "Base identity from which identities describing address families are derived."; } identity ipv4 { base address-family; description "This identity represents an IPv4 address family."; } identity ipv6 { base address-family; description "This identity represents an IPv6 address family."; } /* typedef */ typedef underlay-protocol-type { type enumeration { enum IS-IS { description "This BIER subdomains configuration can be read and advertise by BIER enabled IS-IS."; } enum OSPF { description "This BIER subdomains configuration can be read and advertise by BIER enabled OSPF."; } enum BGP { description "This BIER subdomains configuration can be read and advertise by BIER enabled BGP."; } } description "List of the underlay protocol to be supported."; } typedef bsl { type enumeration { enum IS-IS { description "This BIER subdomains configuration can be read and advertise by BIER enabled IS-IS."; } enum OSPF { description "This BIER subdomains configuration can be read and advertise by BIER enabled OSPF."; } enum BGP { description "This BIER subdomains configuration can be read and advertise by BIER enabled BGP."; } } description "list of the underlay protocol to be supported."; } augment "/rt:routing" { description "This augments routing-instance configuration with bier."; container bier{ description "bier subdomain configuration."; list sub-domain { key "sub-domain-id address-family"; description "The parameters of the BIER subdomain. " leaf sub-domain-id { type uint16; description "The bier sub-domain-id"; } leaf address-family { type identityref { base address-family; } mandatory true; description "Address family."; } leaf bfr-prefix { type inet:ip-prefix; description "the bfr prefix."; } leaf underlay-protocol-type { type underlay-protocol-type; description "List of the underlay protocol to be supported.."; } leaf mt-id { type uint16; description "The multi-topology identifier"; } leaf bfr-id { type uint16; description "Configure the unique BFR-id value within the BIER subdomain for the BFIR/BFER device, and BFR doesnot need a BFR-id, but for diagnostics purposes of the IGP, highly recommended to assign one - but beyond max-si*bls."; } leaf bsl { type bsl; description "The length of the bitstring in the BIER encapsulation within the BIER subdomain."; } leaf igp-algorithm { type uint8; default "0"; description "Calculation type value ranges from 0 to 255 both inclusive from the IGP Algorithm Types registry defined under Interior Gateway Protocol (IGP) Parameters IANA registries.If the required calculation type is Shortest Path First, the value 0 SHOULD appear in this field."; } leaf bier-algorithm { type uint8; description "Calculation type value ranges from 0 to 255 both inclusive from the BIER Algorithm registry.Specifies a BIER-specific Algorithm and BIER-specific Constraints used to either modify, enhance, or replace the calculation of underlay paths to reach other BFRs as defined by the IPA value as defined in RFC9272."; } leaf load-balance-num { type uint8; description "The multicast load balance num."; } list encapsulation { key "bsl encapsulation-type"; description "The BIER encapsulation type.When MPLS is used as the transport, the Bit Indexed Forwarding Table (BIFT) is identified by a MPLS Label. When non-MPLS transport is used, the BIFT is identified by a 20bit value."; leaf bsl{ type bsl; description "The length of the bitstring in the BIER encapsulation within the BIER subdomain."; } leaf encapsulation-type { type identityref { base bier-encapsulation; } description "The BIER encapsulation that can be used in either MPLS networks or non-MPLS networks."; } leaf max-si { type uint16; description "Maximum Set Identifier.The SI value in the subdomain is an integer from 0 to max-si."; } container in-bift-id { description "In BIFT-ID specification."; choice in-bift-id { default "in-bift-id-base"; description "Options for specifying in-bift-id"; case in-bift-id-base { leaf in-bift-id-base { type uint32; description "The first BIFT ID value, there are maximum SI+1 BIFT IDs in total as define in RFC8401."; } } case in-bift-id-encoding { leaf in-bift-id-encoding { type boolean; default "false"; description "setting this attribute to 'true' will enable calculation of in-bift-id based on ."; } } } } } } list bift { key "bfr-id"; description "BIER forwarding tabel." leaf bfr-id { type uint16; description "The unique BFR-id value within the BIER subdomain for the BFIR/BFER device."; } list birt-bitstringlength { key "bsl"; description "specify BSL's bfr-nbr, encapsulation-type and out-bift-id in the BIER forwarding tabel."; leaf bsl { type bsl; description "Configure the bitstring length in BIFT in the BIER subdomain"; } list bfr-nbr { key bfr-nbr; description "bfr-nbr."; leaf bfr-nbr { type inet:ip-prefix; description "bfr-nbr."; } leaf encapsulation-type { type identityref { base bier-encapsulation; } description "The BIER encapsulation that can be used in either MPLS networks or non-MPLS networks."; } container out-bift-id { description "Out BIFT-ID specification."; choice out-bift-id { default "out-bift-id"; description "Options for specifying out-bift-id"; case out-bift-id { leaf out-bift-id { type uint32; description "Configure the out-bift-id"; } } case out-bift-id-encoding { leaf out-bift-id-encoding { type boolean; default "false"; description "setting this attribute to 'true' will enable calculation of out-bift-id based on ."; } } } } } } } } } notification bfr-id-collision { description "This notification is sent when BFR-id received from different routers collide."; list bfr-id-collision { description "List of BFR-id that collide."; leaf received-bfr-id { type uint16; description "Value of the BFR-id received."; } } } notification bfr-id-out-of-range { description "This notification is sent when a BFR-id is received that is is larger than locally configured (bsl*max-si). The notification generation must be throttled with at least a 5-second gap between notifications."; leaf received-bfr-id { type uint16; description "Value of the BFR-id received."; } } notification bfr-zero { description "This notification is sent when an invalid value associated with prefix."; leaf ipv4-bfr-prefix { type inet:ipv4-prefix; description "BIER ipv4 bfr prefix"; } leaf ipv6-bfr-prefix{ type inet:ipv6-prefix; description "BIER ipv6 bfr prefix"; } } notification sub-domain-id-collision { description "This notification is sent when sub-domain-id received from different routers collide."; leaf received-sub-domain-id { type uint16; description "Value of the sub-domain-id received."; } leaf received-mt-id{ type uint16; description "Value of the multi-topology ID received.; } } }

]]>



        

        
           This document registers a URI in the "IETF XML Registry" . Following the format in , the following registration is requested to be made:

                
          
    This document registers YANG modules in the "YANG Module Names"registry .
    
    
        

        
            The YANG module specified in this document defines a schema for data that is designed
                to be accessed via network management protocols such as NETCONF  or RESTCONF  . The lowest NETCONF
                layer is the secure transport layer, and the mandatory-to-implement secure transport
                is Secure Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the
                mandatory-to-implement secure transport is TLS .
        

        
            TBD.