<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-bier-bier-yang-09" indexInclude="true" ipr="trust200902" prepTime="" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <front>
   <title abbrev="BIER YANG">YANG Data Model for BIER Protocol</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-bier-bier-yang-09"/>
    <!-- add 'role="editor"' below for the editors if appropriate -->

   <!-- Another author who claims to be an editor -->

   <author fullname="Ran Chen" initials="R." surname="Chen">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city>Nanjing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <email>chen.ran@zte.com.cn</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>

	<author fullname="Fangwei Hu" initials="Fangwei" surname="Hu">
      <organization> Individual</organization>
      <address>
        <postal>
         <street/>
          <city>Shanghai</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <email>hufwei@gmail.com</email>
      </address>
     </author>
    
<author fullname="Zheng Zhang" initials="Zheng" surname="Zhang">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city>Nanjing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <email>zhang.zheng@zte.com.cn</email>
      </address>
    </author>

<author fullname="Xianxian Dai" initials="Xianxia" surname="Dai">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city>Nanjing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <email>Dai.xianxian@zte.com.cn</email>
      </address>
    </author>
	
<author fullname="Mahesh Sivakumar" initials=" Mahesh" surname="Sivakumar">
      <organization>Juniper networks</organization>
      <address>
        <postal>
         <street/>
          <city>Sunnyvale, CALIFORNIA 94089</city>
          <region/>
          <code/>
          <country>United States</country>
        </postal>
        <email>sivakumar.mahesh@gmail.com</email>
      </address>
    </author>
    <date year="2024"/>
    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
        in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

   <!-- Meta-data Declarations -->

   <area>Routing</area>
    <workgroup>BIER Working Group</workgroup>
    <!-- WG name at the upperleft corner of the doc,
        IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
        which is used by the RFC Editor as a nod to the history of the IETF. -->

   <keyword>Internet Draft</keyword>
    <!-- Keywords will be incorporated into HTML output
        files in a meta tag but they have no effect on text or nroff
        output. If you submit your draft to the RFC Editor, the
        keywords will be used for the search engine. -->
   
   <abstract>
	   <t>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).</t>
    </abstract>
  </front>
  <middle>
  
    <section numbered="true" toc="default">
      <name>Introduction</name>
	 <t><xref target="RFC8279"/> 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".</t>
	 <t>YANG <xref target="RFC7950"/> 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) <xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/>. YANG is now also being used as a component of other management interfaces, such as command-line interfaces (CLIs).</t>
	 <t>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).</t>
	  <section numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>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 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/>
        when, and only when, they appear in all capitals, as shown here.</t>
      </section>
	 <section numbered="true" toc="default">
      <name>Terminology</name>
	  <t>The terminology for describing YANG data models is found in <xref target="RFC7950"/>.</t>
	  <t>
      The following abbreviations are used in this document and
      the defined model:
        </t>
        <dl>
          <dt>BIER:</dt>
          <dd>Bit Index Explicit Replication
        <xref target="RFC8279" format="default" ></xref> 
          </dd>
          <dt>BFR:</dt>
          <dd>Bit Forwarding Router <xref target="RFC8279" format="default"></xref>
          </dd>
          <dt>BIFT:</dt>
          <dd>Bit Index Forwarding Table
        <xref target="RFC8279" format="default"></xref>
          </dd>
		    <dt>BSL:</dt>
          <dd>BitStringLength
        <xref target="RFC8279" format="default"></xref>
          </dd>
		    <dt>SI:</dt>
          <dd>Set Identifier
        <xref target="RFC8279" format="default"></xref>
          </dd>
		    <dt>IS-IS:</dt>
          <dd>Intermediate System-to-Intermediate System
          </dd>
		  <dt>OSPF:</dt>
          <dd>Open Shortest Path First</dd> 
	  </dl>
      </section> 
	  <section numbered="true" toc="default">
      <name>Tree Diagrams</name>
	   <t>Tree diagrams used in this document follow the notation defined in
      <xref target="RFC8340" format="default"></xref>.
        </t>
	  </section>
	  <section numbered="true" toc="default">
      <name>Prefixes in Data Node Names</name>
	   <t>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 <xref target="table_prefixes" format="default" sectionFormat="of" derivedContent="Table 1"/>.</t>
	  <table anchor="table_prefixes" align="center" pn="table-1">
          <name slugifiedName="name-prefixes-and-corresponding-">Prefixes and Corresponding YANG Modules</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Prefix</th>
              <th align="left" colspan="1" rowspan="1">YANG Module</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">yang</td>
              <td align="left" colspan="1" rowspan="1">ietf-yang-types</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC6991" format="default" sectionFormat="of" derivedContent="RFC6991"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">inet</td>
              <td align="left" colspan="1" rowspan="1">ietf-inet-types</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC6991" format="default" sectionFormat="of" derivedContent="RFC6991"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">if</td>
              <td align="left" colspan="1" rowspan="1">ietf-interfaces</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC8343" format="default" sectionFormat="of" derivedContent="RFC8343"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">rt</td>
              <td align="left" colspan="1" rowspan="1">ietf-routing</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC8349" format="default" sectionFormat="of" derivedContent="RFC8349"/></td>
            </tr>
          </tbody>
        </table>
	  </section>
	 </section>
   <section numbered="true" toc="default">
   <name>Design of Data Model</name>
   <t>The data model can be used to configure and manage BIER protocol <xref target="RFC8279"/>
   features. The operational state data and statistics can be retrieved by this model. The protocol-specific notifications are also defined in the model.</t>
   <t>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 <xref target="RFC8401"/> ，OSPFv2 <xref target="RFC8444"/> and OSPFv3<xref target="I-D.ietf-bier-ospfv3-extensions"/> 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.</t>
    </section>
   <section numbered="true" toc="default">
   <name> Module Structure</name>
   <t>The ietf-bier YANG module augments the routing container in the ietf-routing model <xref target="RFC8349"/> with a BIER container and defines generic BIER configuration and operational state. This module is augmented by modules supporting different data planes.</t>
  <artwork>
module: ietf-bier
  augment /rt:routing:
    +--rw bier
       +--rw sub-domain* [sub-domain-id address-family]
       |  +--rw sub-domain-id                   uint8
       |  +--rw address-family                  identityref
       |  +--rw bfr-prefix?                     inet:ip-prefix
       |  +--rw underlay-protocol-type?         underlay-protocol-type
       |  +--rw mt-id?                          uint16
       |  +--rw bfr-id?                         uint16
       |  +--rw bsl?                            bsl
       |  +--rw igp-algorithm?                  uint8
       |  +--rw bier-algorithm?                 uint8
       |  +--rw load-balance-num?               uint8
       |  +--rw encapsulation* [bsl encapsulation-type]
       |     +--rw bsl                          uint16
       |     +--rw encapsulation-type           identityref
       |     +--rw max-si?                      uint8
       |     +--rw in-bift-id?                  
	   |        +--rw:(in-bift-id-base)
	   |        |  +--rw in-bift-id-base?       uint32  
	   |        +--rw (in-bift-id-encoding)         
	   |     	   +--rw in-bift-id-encoding    boolean
       +--rw bift* [bfr-id]
            +--rw bfr-id                        bsl
            +--rw birt-bitstringlength* [bsl]
               +--rw bsl                        bsl
			   +--rw bfr-nbr* [bfr-nbr]          
			      +--rw bfr-nbr                inet:ip-prefix  
				  +--rw encapsulation-type?    identityref
				  +--rw our-bift-id?                  
	                 +--rw:(out-bift-id)
	                 |  +--rw out-bift-id?       uint32  
	                 +--rw:(out-bift-id-encoding)         
	       	            +--rw out-bift-id-encoding    boolean
	 
notifications:
    +---n bfr-id-collision
    |  +--ro bfr-id-collisions*[]  
	|     +--ro received-bfr-id?         uint16
	+---n bfr-id-out-of-range
	|   +--ro received-bfr-id?            uint16  
    +---n bfr-zero
    |   +--ro ipv4-bfr-prefix?            inet:ipv4-prefix
    |   +--ro ipv6-bfr-prefix?            inet:ipv6-prefix
    +---n sub-domain-id-collision
        +--ro received-sub-domain-id?     uint16
        +--ro received-mt-id?             uint16					 
</artwork>
 </section>
   <section numbered="true" toc="default">
   <name>Configuration</name>
   <t>The ietf-bier YANG module augments the routing container in the ietf-routing model <xref target="RFC8349"/> with a BIER container and defines generic BIER configuration. It includes:</t>
   <t>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 &lt;BSL,SD,SI&gt;. 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 &lt; BSL,SD,SI&gt;.</t>
	<t>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 &lt; BSL,SD,SI&gt;. The leaf "out-bift-id-encoding" is defined as a boolean, used to enable or disable whether to calculate out-bift-id based on &lt; BSL,SD,SI&gt;.</t>
	</section>
	
   <section numbered="true" toc="default">
   <name>IGP Control-Plane Configuration</name>
   <t> 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.</t>
   <t> This module defines groupings that SHOULD be used by IGP BIER modules.</t>
   <t> The "enabled" leaf enables BIER extensions for the routing-protocol instance.</t>
   <t> 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. </t>
	</section>
	
 <section numbered="true" toc="default">
   <name>Notifications</name>
   <t> The model defines the following notifications for BIER.</t>
   <t> This module defines groupings that SHOULD be used by IGP BIER modules.</t>
   <t> bfr-id-collision: Raised when control-plane-advertised BFR ID have conflicts.</t>
   <t> bfr-id-out-of-range: Raised when control-plane-advertised BFR ID is larger than locally configured (bsl * max-si).</t>
   <t> bfr-zero: Raised when invalid value associated with prefix.</t>
   <t> sub-domain-id-collision: Raised when control-plane-advertised Sub domain ID have conflicts.</t>
	</section>
	
   <section numbered="true" toc="default">
   <name>YANG Module for BIER</name>
   <figure>
 <artwork><![CDATA[<CODE BEGINS> file "ietf-bier@2023-09-16.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:   &lt;https://datatracker.ietf.org/wg/bier/&gt;
     WG List:  &lt;mailto:bier@ietf.org&gt;

     WG Chair: Tony Przygienda
                   &lt;mailto:tonysietf@gmail.com&gt;

     WG Chair: Greg Shepherd
                   &lt;mailto:gjshep@gmail.com&gt;


     Editor:   Ran Chen
                   &lt;mailto:chen.ran@zte.com.cn&gt;
     Editor:   Fangwei Hu
                   &lt;mailto:hu.fangwei@zte.com.cn&gt;
     Editor:   Zheng Zhang
                   &lt;mailto:zhang.zheng@zte.com.cn&gt;
     Editor:   Xianxian Dai
                   &lt;mailto:dai.xianxian@zte.com.cn&gt;
     Editor:   Mahesh Sivakumar
                   &lt;mailto:masivaku@cisco.com&gt;
	";
  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 2023-09-12 {
      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 <BSL, SD, SI>.";
               }
            }
           }
        }		   
      }
    }
	  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 <BSL,SD,SI>.";
                    }
                }
              }
            }
          }
		}
	  }
     }
	}
	 
  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.;
     }
    }
  }
  <code end>
 ]]></artwork>
        </figure>

  </section>
	
	
   <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
	<t>This document registers a URI in the "IETF XML Registry" <xref target="RFC3688"/>. Following the format in <xref target="RFC3688"/>, the following registration is requested to be made:</t>
	<artwork>
    ID:  yang:ietf-bier
    URI:  urn:ietf:params:xml:ns:yang:ietf-bier
    Registrant Contact:  The IESG.
    XML:  N/A, the requested URI is an XML namespace.
	</artwork>
	<t>This document registers YANG modules in the "YANG Module Names"registry <xref target="RFC6020"/>.</t>
	<artwork>
	Name:  ietf-bier
    Maintained by IANA:  N
    Namespace:  urn:ietf:params:xml:ns:yang:ietf-bier
    Prefix:  bier
    Reference:  RFC ****
	</artwork>
	 </section>
	 
	 
    <section anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>
     <t>TBD.</t>
    </section>
	
	  <section anchor="Acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>TBD.</t>
    </section>
  </middle>
 
  
    <!-- Possibly a 'Contributors' section ... -->
  <!--  *****BACK MATTER ***** -->

 <back>
    <!-- References split into informative and normative -->

   <!-- There are 2 ways to insert reference entries from the citation libraries:
    1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
    2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
       (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

    Both are cited textually in the same manner: by using xref elements.
    If you use the PI option, xml2rfc will, by default, try to find included files in the same
    directory as the including file. You can also define the XML_LIBRARY environment variable
    with a value containing a set of directories to search.  These can be either in the local
    filing system or remote ones accessed by http (http://domain/dir/... ).-->

 <references>
        <name>Normative References</name>
        <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
      <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
	        <reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3688" quoteTitle="true" derivedAnchor="RFC3688">
          <front>
            <title>The IETF XML Registry</title>
            <author initials="M." surname="Mealling" fullname="M. Mealling">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2004" month="January"/>
            <abstract>
              <t indent="0">This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="81"/>
          <seriesInfo name="RFC" value="3688"/>
          <seriesInfo name="DOI" value="10.17487/RFC3688"/>
        </reference>
        <reference anchor="RFC6020" target="https://www.rfc-editor.org/info/rfc6020" quoteTitle="true" derivedAnchor="RFC6020">
          <front>
            <title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="October"/>
            <abstract>
              <t indent="0">YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6020"/>
          <seriesInfo name="DOI" value="10.17487/RFC6020"/>
        </reference>
	  <reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6241" quoteTitle="true" derivedAnchor="RFC6241">
          <front>
            <title>Network Configuration Protocol (NETCONF)</title>
            <author initials="R." surname="Enns" fullname="R. Enns" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Schoenwaelder" fullname="J. Schoenwaelder" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Bierman" fullname="A. Bierman" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="June"/>
            <abstract>
              <t indent="0">The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices.  It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages.  The NETCONF protocol operations are realized as remote procedure calls (RPCs).  This document obsoletes RFC 4741.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6241"/>
          <seriesInfo name="DOI" value="10.17487/RFC6241"/>
        </reference>
	         <reference anchor="RFC6991" target="https://www.rfc-editor.org/info/rfc6991" quoteTitle="true" derivedAnchor="RFC6991">
          <front>
            <title>Common YANG Data Types</title>
            <author initials="J." surname="Schoenwaelder" fullname="J. Schoenwaelder" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2013" month="July"/>
            <abstract>
              <t indent="0">This document introduces a collection of common data types to be used with the YANG data modeling language.  This document obsoletes RFC 6021.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6991"/>
          <seriesInfo name="DOI" value="10.17487/RFC6991"/>
        </reference>
	          <reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7950" quoteTitle="true" derivedAnchor="RFC7950">
          <front>
            <title>The YANG 1.1 Data Modeling Language</title>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="August"/>
            <abstract>
              <t indent="0">YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols.  This document describes the syntax and semantics of version 1.1 of the YANG language.  YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification.  There are a small number of backward incompatibilities from YANG version 1.  This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7950"/>
          <seriesInfo name="DOI" value="10.17487/RFC7950"/>
        </reference>
	    <reference anchor="RFC8040" target="https://www.rfc-editor.org/info/rfc8040" quoteTitle="true" derivedAnchor="RFC8040">
          <front>
            <title>RESTCONF Protocol</title>
            <author initials="A." surname="Bierman" fullname="A. Bierman">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Watsen" fullname="K. Watsen">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="January"/>
            <abstract>
              <t indent="0">This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8040"/>
          <seriesInfo name="DOI" value="10.17487/RFC8040"/>
        </reference>
	       <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
	  <reference anchor="RFC8279" target="https://www.rfc-editor.org/info/rfc8279" quoteTitle="true" derivedAnchor="RFC8279">
          <front>
            <title>Multicast Using Bit Index Explicit Replication (BIER)</title>
            <author initials="IJ." surname="Wijnands" fullname="IJ. Wijnands">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="November"/>
            <abstract>
              <t indent="0">This document specifies a new architecture for the forwarding of multicast data packets.  It provides optimal forwarding of multicast packets through a "multicast domain".  However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state.</t>
              <t indent="0"> This architecture is known as "Bit Index Explicit Replication" (BIER).  When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent.  The ingress router then encapsulates the packet in a BIER header.  The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header.  The procedures for forwarding a packet based on its BIER header are specified in this document.  Elimination of the per-flow state and the explicit tree-building protocols results in a considerable simplification.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8279"/>
          <seriesInfo name="DOI" value="10.17487/RFC8279"/>
        </reference>
      <reference anchor="RFC8340" target="https://www.rfc-editor.org/info/rfc8340" quoteTitle="true" derivedAnchor="RFC8340">
          <front>
            <title>YANG Tree Diagrams</title>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="March"/>
            <abstract>
              <t indent="0"> This document captures the current syntax used in YANG module tree diagrams.  The purpose of this document is to provide a single location for this definition.  This syntax may be updated from time to time based on the evolution of the YANG language.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8340"/>
          <seriesInfo name="DOI" value="10.17487/RFC8340"/>
        </reference>
	         <reference anchor="RFC8343" target="https://www.rfc-editor.org/info/rfc8343" quoteTitle="true" derivedAnchor="RFC8343">
          <front>
            <title>A YANG Data Model for Interface Management</title>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="March"/>
            <abstract>
              <t indent="0">This document defines a YANG data model for the management of network interfaces.  It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes definitions for configuration and system state (status information and counters for the collection of statistics).</t>
              <t indent="0">The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.</t>
              <t indent="0">This document obsoletes RFC 7223.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8343"/>
          <seriesInfo name="DOI" value="10.17487/RFC8343"/>
        </reference>
	   <reference anchor="RFC8349" target="https://www.rfc-editor.org/info/rfc8349" quoteTitle="true" derivedAnchor="RFC8349">
          <front>
            <title>A YANG Data Model for Routing Management (NMDA Version)</title>
            <author initials="L." surname="Lhotka" fullname="L. Lhotka">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Lindem" fullname="A. Lindem">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Y." surname="Qu" fullname="Y. Qu">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="March"/>
            <abstract>
              <t indent="0">This document specifies three YANG modules and one submodule. Together, they form the core routing data model that serves as a framework for configuring and managing a routing subsystem.  It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions.  The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols.</t>
              <t indent="0">The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA).  This document obsoletes RFC 8022.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8349"/>
          <seriesInfo name="DOI" value="10.17487/RFC8349"/>
        </reference>
	   <reference anchor="RFC8401" target="https://www.rfc-editor.org/info/rfc8401" quoteTitle="true" derivedAnchor="RFC8349">
          <front>
            <title>Bit Index Explicit Replication (BIER) Support via IS-IS</title>
            <author initials="L." surname="Ginsberg" fullname="L. Ginsberg">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Przygienda" fullname="T. Przygienda">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Aldrin" fullname="S. Aldrin">
              <organization showOnFrontPage="true"/>
            </author>
			 <author initials="J." surname="Zhang" fullname="J. Zhang">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="June"/>
            <abstract>
              <t indent="0"> This document defines IS-IS extensions to support multicast forwarding using the Bit Index Explicit Replication (BIER) architecture.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8401"/>
          <seriesInfo name="DOI" value="10.17487/RFC8401"/>
        </reference>
	  <reference anchor="RFC8444" target="https://www.rfc-editor.org/info/rfc8444" quoteTitle="true" derivedAnchor="RFC8444">
          <front>
            <title>OSPFv2 Extensions for Bit Index Explicit Replication (BIER)</title>
            <author initials="P." surname="Psenak" fullname="P. Psenak">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="IJ." surname="Wijnands" fullname="IJ. Wijnands">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Dolganow" fullname="A. Dolganow">
              <organization showOnFrontPage="true"/>
            </author>
			<author initials="T." surname="Przygienda" fullname="T. Przygienda">
              <organization showOnFrontPage="true"/>
            </author>
			 <author initials="J." surname="Zhang" fullname="J. Zhang">
              <organization showOnFrontPage="true"/>
            </author>
			<author initials="S." surname="Aldrin" fullname="S. Aldrin">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="November"/>
            <abstract>
              <t indent="0">Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast-related, per- flow state.  BIER also does not require an explicit tree-building protocol for its operation.  A multicast data packet enters a BIER domain at a Bit-Forwarding Ingress Router (BFIR) and leaves the BIER domain at one or more Bit-Forwarding Egress Routers (BFERs).  The BFIR adds a BIER packet header to the packet.  The BIER packet header contains a BitString in which each bit represents exactly one BFER to forward the packet to.  The set of BFERs to which the multicast packet needs to be forwarded is expressed by the set of bits in the BIER packet header.</t>
			   <t indent="0">This document describes the OSPF protocol extension (from RFC 2328) that is required for BIER with MPLS encapsulation (which is defined in RFC 8296).  Support for other encapsulation types and the use of multiple encapsulation types are outside the scope of this document.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8441"/>
          <seriesInfo name="DOI" value="10.17487/RFC8441"/>
        </reference>
	 <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-bier-ospfv3-extensions.xml"/>
	  </references>
    <!-- Change Log

v00 2006-03-15  EBD   Initial version

v01 2006-04-03  EBD   Moved PI location back to position 1 -
                     v3.1 of XMLmind is better with them at this location.
v02 2007-03-07  AH    removed extraneous nested_list attribute,
                     other minor corrections
v03 2007-03-09  EBD   Added comments on null IANA sections and fixed heading capitalization.
                     Modified comments around figure to reflect non-implementation of
                     figure indent control.  Put in reference using anchor="DOMINATION".
                     Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH     Major changes: shortened discussion of PIs,
                     added discussion of rfc include.
v05 2007-03-10 EBD    Added preamble to C program example to tell about ABNF and alternative 
                     images. Removed meta-characters from comments (causes problems).

v06 2010-04-01 TT     Changed ipr attribute values to latest ones. Changed date to
                     year only, to be consistent with the comments. Updated the 
                     IANA guidelines reference from the I-D to the finished RFC.
v07 2020-01-21 HL    Converted the template to use XML schema version 3.
    -->
 </back>
</rfc>
