<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="no"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-prz-bier-bfrid-assignment-00" ipr="trust200902"
		obsoletes="" submissionType="IETF" updates="" xml:lang="en">

	<front>
		<title abbrev="draft-prz-bier-bfrid-assignment-00">Automatic Assignment of BIER BFR-ids in ISIS</title>
		<author fullname="Tony Przygienda" initials="A." surname="Przygienda">
			<organization>Ericsson</organization>
			<address>
				<postal>
					<street>300 Holger Way</street>
					<city>San Jose</city>
					<region>CA</region>
					<code>95134</code>
					<country>USA</country>
				</postal>
				<phone/>
				<facsimile/>
				<email>antoni.przygienda@ericsson.com</email>
				<uri/>
			</address>
		</author>

		<author fullname="Jeff Tantsura" initials="J." surname="Tantsura">
			<organization>Ericsson</organization>
			<address>
				<postal>
					<street>300 Holger Way</street>
					<city>San Jose</city>
					<region>CA</region>
					<code>95134</code>
					<country>USA</country>
				</postal>
				<phone/>
				<facsimile/>
				<email>jeff.tantsura@ericsson.com</email>
				<uri/>
			</address>
		</author>
		
		<date day="09" month="Mar" year="2015"/>
		<workgroup>Internet Engineering Task Force</workgroup>
		<abstract>
			<t>Specification of an ISIS extension to support auto-election of BFR IDs in BIER using ISIS.</t>
		</abstract>
		<note title="Requirements Language">
			<t>
				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
				<xref format="default" pageno="false" target="RFC2119">RFC 2119</xref>
				.
			</t>
		</note>
	</front>
	<middle>
		<section title="Introduction" toc="default">
			<t>
				Bit Index Explicit Replication (BIER)
				<xref format="default" pageno="false" target="I-D.draft-wijnands-bier-architecture-04"/>
				defines an architecture where all intended multicast receivers are encoded as bitmask
				in the Multicast packet header within different encapsulations such as
				<xref format="default" pageno="false" target="I-D.draft-wijnands-mpls-bier-encapsulation-02"/>.
				A router that receives such a packet will forward the packet based on the Bit Position
				in the packet header towards the receiver(s), following a precomputed tree for
				each of the bits in the packet. Each receiver is represented by a unique bit in
				the bitmask corresponding to its BFR-id. BFR-ids are sub-domain specific.
			</t>

			<t>
				Once the number of receivers becomes large (i.e. many sets are present)
				or receivers choose to participate in many independent sub-domains,
				assignment of
				a unique BIER bit to a node is a non-trivial problem that can benefit highly 
							from an automated solution. The usual trade-offs are either a 
												 centralized (server) approach
				or a distributed approach which (from experience with other protocols such as 
							DHCP or OSPF), provide at the cost of additional protocol complexity
				higher availability.  
			</t>
			
			<t>
				This document presents
				necessary, optional extensions to the currently deployed ISIS for IP
				<xref format="default" pageno="false" target="RFC1195"/>
				protocol to support automatic election of BFR-ids by means of a distributed protocol.
				This document defines new TLVs to be advertised by every router participating
				in BIER signaling and supporting such an election.
				In case some nodes are statically configured with a BFR-id, 
							the protocol can detect misconfiguration, i.e. overlapping bit assignments or
												 otherwise respects statically assigned BFR ids.
			</t>
			<t>
				   This extension operates seamlessly in a backwards compatible fashion with BIER procedures for ISIS as defined in 
							   
							   <xref format="default" pageno="false" target="I-D.draft-przygienda-bier-isis-ranges-02"/>. Only BFRs implementing this extensions benefit from automatic assignment. 
			   </t>
		</section>
		<section title="Terminology" toc="default">
			<t>
				Some of the terminology specified in
				<xref format="default" pageno="false" target="I-D.draft-wijnands-bier-architecture-04"/>
				is replicated here and extended
				by necessary definitions:
			</t>
			<t>
				<list style="hanging">
					<t hangText="BIER:">
						Bit Index Explicit Replication (The overall architecture of forwarding multicast using
						a Bit Position).
					</t>
					<t hangText="BIER-OL:">BIER Overlay Signaling. (The method for the BFIR to learn about BFER's).</t>
					<t hangText="BFR:">
						Bit Forwarding Router (A router that participates in Bit Index Multipoint Forwarding). A BFR
						is identified by a unique BFR-prefix in a BIER domain.
					</t>
					<t hangText="BFIR:">
						Bit Forwarding Ingress Router (The ingress border router that inserts the BM into
						the packet).
					</t>
					<t hangText="BFER:">
						Bit Forwarding Egress Router. A router that participates in Bit Index Forwarding as
						leaf. Each BFER must be a BFR. Each BFER must have a valid BFR-id assigned.
					</t>
					<t hangText="BFT:">Bit Forwarding Tree used to reach all BFERs in a domain.</t>
					<t hangText="BIFT:">Bit Index Forwarding Table.</t>
					<t hangText="BMS:">Bit Mask Set. Set containing bit positions of all BFER participating in a set.</t>
					<t hangText="BMP:">Bit Mask Position, a given bit in a BMS.</t>

					<t hangText="Invalid BMP:">Unassigned Bit Mask Position, consisting of all 0s.</t>

					<t hangText="IGP signalled BIER domain:">
						A BIER underlay where the BIER synchronization information is carried in IGP. Observe that a multi-topology
						is NOT a separate BIER domain in IGP.
					</t>
					<t hangText="BIER sub-domain:">
						A further distinction within a BIER domain identified by its unique sub-domain identifier.
						A BIER sub-domain can support multiple BitString Lengths.
					</t>
					<t hangText="BFR-id:">An optional, unique identifier for a BFR within a BIER sub-domain.</t>

					<t hangText="Invalid BFR-id:">Unassigned BFR-id, consisting of all 0s.</t>

				</list>
			</t>

		</section>

		<section anchor="IANA" title="IANA Considerations" toc="default">
			<t>
				This document adds the following new sub-sub-TLVs to the registry of sub-TLVs for BIER Info sub-TLV.
				<list style="hanging">
				<t hangText="BIER Protocol Election sub-sub-TLV">
					Value: TBD (suggested - to be assigned by IANA)
				</t>
			</list>
				This document adds the following new TLV to the registery of ISIS TLVs. 
				
				<list style="hanging">
					
					<t hangText="BIER PE BMP Assignments TLV">
						Value: TBD (suggested - to be assigned by IANA)
					</t>
				</list>
			</t>			

		</section>

		<section title="Procedures">

			<t>
				The following sections present BIER IGP protocol procedures for the
				auto-election and maintainance of unique BIER BFR-ids across subdomains. Compared to
				purely administrative assignment of the bitmask use of those procedures
				largely facilitates deployment of BIER in large setups. The election and
				bit assignment procedures described in the according sections indicate
				how the BFRs participate in an election mechanism that allows them to<list style="symbols">
					<t>
						use a dynamically chosen Designated and Backup Designated router
						for coordination and distribution of necessary state across all participants in the set
						across the network in a robust fashion
					</t>
					<t>allocate the necessary BMP in a sub-domain for each BFER</t>
					<t>
						automatically or administratively partition the elections for different sub-domains
						across the set of BFRs
						for maximum reliability
					</t>
					<t>discover administrative misconfiguration of BFERs</t>
				</list>
			</t>

			<section title="Election Algorithm " toc="default">
				<t>
					After a sub-domain &lt;MT,SD,MLs&gt; <xref format="default" pageno="false" target="I-D.draft-przygienda-bier-isis-ranges-02"/>
					is enabled, the according election procedures for D-BFR and Backup D-BFR are performed based upon the set of available
					BIER-PE sub-sub-TLVs. Given the fact that SD is uniquely tied to its MT per today's architecture and MLs are of no further importance
					to the introduced procedures, a sub-domain will be abbreviated without loss of generality as &lt;SD&gt;.
				</t>
				<t>
					The election is indebted to and largely modeled (to the point of quoting
					parts of it verbatim) after the DR OSPF
					Election procedure in <xref format="default" pageno="false" target="RFC2328">OSPF</xref>
					which has proven to work exceedingly well over many years in the
					field.
				</t>
				<t>
					This section describes the algorithm used for calculating a
					network's Designated BFR and Backup Designated BFR and procedures that
					allow those to allocate bit mask bits to a participating BFER in a
					sub-domain SD which we designate as
					BFER&lt;SD&gt;. The election runs per SD the
					router is participating in. The initial time a router runs the
					election algorithm, the D-BFR&lt;SD&gt; and BD-BFR&lt;SD&gt;
					are initialized to 0.0.0.0 or equivalent empty router ID. This
					indicates the lack of both a Designated BFR&lt;SD&gt; and a Backup
					Designated BFR&lt;SD&gt;.
				</t>
				<t>The D-BFR&lt;SD&gt; election algorithm proceeds as follows:</t>
				<t>
					<list style="symbols">
						<t>
							Call the router doing the calculation Router X&lt;SD&gt;. A
							router can participate in multiple elections for other BMS and
							multi-topologies at varying priorities.
						</t>
						<t>
							The list of BFRs participating in &lt;SD&gt; whose according
							BIER-PEs&lt;SD&gt; have been received by Router X&lt;SD&gt; and
							are connected (i.e. reachable via SPF computation)
							in standard topology MUST be
							examined.
						</t>
						<t>
							Router X&lt;SD&gt; itself MUST be also considered to be on the
							list.
						</t>
						<t>
							Discard all routers from the list that are ineligible to become
							D-BFR&lt;SD&gt;. (Routers having Router Priority of 0 for &lt;SD&gt;
							MUST NOT be eligible to become D-BFR&lt;SD&gt;.)
						</t>
					</list>
				</t>
				<t>
					The following steps MUST then be executed, considering only those
					routers that remain on the list:
				</t>
				<t>
					<list style="numbers">
						<t>
							Note the current values for D-BFR&lt;SD&gt; and Backup
							D-BFR&lt;SD&gt;. This is used later for comparison purposes.
						</t>
						<t>
							Calculate the new Backup D-BFR&lt;SD&gt; as follows. <list style="symbols">
								<t>
									Only those routers on the list that have not declared
									themselves to be D-BFR&lt;SD&gt; MUST be eligible to become
									Backup D-BFR&lt;SD&gt;.
								</t>
								<t>
									If one or more of these routers have declared themselves
									Backup D-BFR&lt;SD&gt; (i.e., they are currently listing
									themselves as Backup D-BFR&lt;SD&gt;, but not as
									D-BFR&lt;SD&gt;, in their according BIER-PE packets) the one
									having highest Router Priority for &lt;SD&gt; MUST be
									declared to be Backup D-BFR&lt;SD&gt;.
								</t>
								<t>
									In case of a tie, the one having the highest Router ID
									XOR'ed with SD (assuming big endian order, both values
									right-aligned and all bits of the shorter value filled up with
									zeroes to the length of the longer value) MUST be chosen.
								</t>
								<t>
									If no routers have declared themselves Backup
									D-BFR&lt;SD&gt;, the router having highest Router Priority
									for &lt;SD&gt; MUST be chosen, (again excluding those routers
									who have declared themselves D-BFR&lt;SD&gt;), and again use
									the Router ID XOR'ed with SD to break ties.
								</t>
							</list>
						</t>
						<t>
							Calculate the new D-BFR&lt;SD&gt; for the network as follows.
							If one or more of the routers have declared themselves
							D-BFR&lt;SD&gt; (i.e., they are currently listing themselves as
							D-BFR&lt;SD&gt; in their BIER-PE advertisements) the one having
							highest Router Priority for &lt;SD&gt; is declared to be
							D-BFR&lt;SD&gt;. In case of a tie, the one having the highest
							Router ID XOR'ed with SD is chosen. If no routers have declared
							themselves D-BFR&lt;SD&gt;, assign the D-BFR&lt;SD&gt; to be the
							same as the newly elected BD-BFR&lt;SD&gt;.
						</t>
						<t>
							If Router X&lt;SD&gt; is now newly the D-BFR&lt;SD&gt; or
							newly the BD-BFR&lt;SD&gt;, or is now no longer the
							D-BFR&lt;SD&gt; or no longer the BD-BFR&lt;SD&gt;, repeat steps
							2 and 3, and then proceed to step 5. For example, if Router
							X&lt;SD&gt; is now the D-BFR&lt;SD&gt;, when step 2 is repeated
							X&lt;SD&gt; will no longer be eligible for BD-BFR&lt;SD&gt;
							election. Among other things, this will ensure that no router will
							declare itself both BD-BFR&lt;SD&gt; and D-BFR&lt;SD&gt;.
						</t>
						<t>
							As a result of these calculations, the router itself may now be
							D-BFR&lt;SD&gt; or BD-BFR&lt;SD&gt;. See  <xref target="DBFR"/>
							and <xref target="BDBFR"/> for the additional duties this would entail.
						</t>
						<t>
							If the above calculations have caused the identity of either
							the D-BFR&lt;SD&gt; or BD-BFR&lt;SD&gt; to change, all routers must
							re-evaluate whether they have been elected D-BFR&lt;SD&gt; or BD-BFR&lt;SD&gt; and initiate according procedures.
							In case the new D-BFR&lt;SD&gt; or BD-BFR&lt;SD&gt; is not advertising according bitmask assignment and they
							are needed, they initiate according procedures in <xref target="ASSIGNBMP"/>.
						</t>
					</list>
				</t>
				<t>
					The reason behind the election algorithm's complexity is the desire
					for an orderly transition from BD-BFR&lt;SD&gt; to D-BFR&lt;SD&gt;,
					when the current D-BFR&lt;SD&gt; fails. This orderly transition is
					ensured through the introduction of hysteresis: no new
					BD-BFR&lt;SD&gt; can be chosen until the old Backup accepts its new
					D-BFR&lt;SD&gt; responsibilities.
				</t>
				<t>
					The above procedure may elect the same router to be both
					D-BFR&lt;SD&gt; and BD-BFR&lt;SD&gt;, although that router will
					never be the calculating router (Router X&lt;SD&gt;) itself. The
					elected D-BFR&lt;SD&gt; may not be the router having the highest
					Router Priority for &lt;SD&gt;, nor will the BD-BFR&lt;SD&gt;
					necessarily have the second highest Router Priority. If Router
					X&lt;SD&gt; is not itself eligible to become D-BFR&lt;SD&gt;, it is
					possible that neither a BD-BFR&lt;SD&gt; nor a D-BFR&lt;SD&gt; will
					be selected in the above procedure. Note also that if Router
					X&lt;SD&gt; is the only router that is eligible to become
					D-BFR&lt;SD&gt;, it will select itself as D-BFR&lt;SD&gt; and there
					will be no BD-BFR&lt;SD&gt; for the network.
				</t>
				<t/>
				<t/>
			</section>

			<section title="D-BFR Procedures" toc="default" anchor="DBFR">
				<t/>
				<t>
					A router that assumes D-BFR role for a given &lt;SD&gt;
					combination invokes additional set of procedures as synchronization
					and election point for all the BFRs in &lt;SD&gt;.
				</t>


				<section title="Assignment of BMPs to BFERs in &lt;SD&gt;" toc="default" anchor="ASSIGNBMP">
					<t/>
					<t>
						Each BFER includes a strongly abbreviated DHCP-like FSM to obtain
						from the D-BFR&lt;SD&gt; its BMP or to advertise an administrative preference
						of its BMP.
					</t>
					<t>
						The procedure is initiated by a BFER&lt;SD&gt; announcing in BIER Info sub-TLV for &lt;SD&gt; its assigned bit (or request for
						BMP assignment). The D-BFR&lt;SD&gt; initiates then a set of procedures to assign BMPs
						to such BFER in the &lt;SD&gt; or announces collisions.
					</t>
					<t>
						Observe that BFERs can request (or announce) the bits even before a BDR&lt;SD&gt; has been chosen so
						the election and assignment are largely orthogonal sets of procedures.
					</t>
				</section>

			</section>
			<section title="BD-BFR Procedures" toc="default" anchor="BDBFR">
				<t/>
				<t>
					A router that is elected BD-BFR&lt;SD&gt; MUST mirror in its advertisements the
					exact state of the D-BFR&lt;SD&gt; and on each received advertisement maintains
					its internal states to use as starting point in all D-BFR&lt;SD&gt; procedures in
					case it looses connectivity (i.e. it cannot compute SPF reachability to the D-BFR in standard topology) to the D-BFR&lt;SD&gt;.
				</t>
			</section>

			<section title="BFER Procedures" toc="default">

				<t>
					A BFER in &lt;SD&gt; controls its BMP in the set by providing values in its BIER Info sub-TLV for &lt;SD&gt; and signalling towards B-DR using A and R bits per <xref target="BIERINFO"/>.
					If it advertises the BFR-id without A or R bit set it indicates a fixed value it has chosen
					administratively.
				</t>
				<t>
					It may request the assignment of a BMP by setting the R bit. The prefered BFR-id is signalled by
					providing a BFR-id value. The D-BFR MUST try to keep the preferred setting value
					when choosing BMP for the BFER. All other BFRs MUST NOT use the BFR-id value when the R bit is set. In case of routers not understanding this extensions, the behavior is enforced by the
					means of the C bit.

				</t>
				<t>
					Once the BFER has been assigned a value from D-BFR and is willing to accept it, it MUST copy the
					value into the BFR-id field in the BIER-PE-BMPs it receives and set the A bit while clearing the R bit.

				</t>

				<t>
					On the other side, the D-BFR for &lt;SD&gt; advertises the BMP assignments by the means of
					advertising BIER-PE-BMP for &lt;SD&gt;.
				</t>



			</section>
		</section>

		<section title="Special Considerations">
			<section title="BD-BFER to D-BFER Transition" toc="default">
				<t>
					In the normal case a router will assume its role as D-BFR&lt;SD&gt;
					promoting itself from BD-BFR&lt;SD&gt; with its own set of procedures. Based
					on those it will hold the state of the abdicating D-BFR&lt;SD&gt; and it MUST
					use this state as initial state for the D-BFR procedures it
					initiates per <xref target="DBFR"/> . This should warranty a seamless fall-over without changes
					in the assignments of bits for BFERs
					for the according &lt;SD&gt; which SHOULD take preference over
					all other considerations. Observe that the implication is that a
					configured administrative preference MUST NOT be used unless changed
					or set explicitly again. The FSMs visualize this behavior more
					explicitly.

				</t>
			</section>

			
		</section>


		<section title="Election FSM for BFR&lt;SD&gt;" toc="default" anchor="BFRFSM">
			
			<figure align="left" alt="" height="" suppress-title="false" title="" width="">
				<artwork align="center" alt="" height="" name="" type="" width="" xml:space="preserve">
								<![CDATA[
+------+
| ==== |                      E1 = PE Expired OR
| Init |                           PI Expired         New Admin
| ==== |                                              Pref
+-+----+                                             +--+
  |                                                  |  |
  | Joined SD                               +--------++ |
  | Rcvd First PE for SD          Lost DR   | ======= <-+
  |                          +--------------+ Passive |
+-v----+                     |              | ======= |
| ==== |                     |              +^--------+
| Wait |Timer       +--------v-+ Lost        |
| ==== +------------> ======== +-------------+
+------+            | Election |
          +---------+ ======== +--------+
          | Won BDR +^-------^-+ Won DR |
          |          |       |          |
          |          |       |New DR    |
     +----v+         |       |Seen     +v---+
     | === +---------+       +---------+ == |
     | BDR |  New BDR                  | DR |
  +--> === |  Lost DR              +---+ == |
  |  ++----+                       |   +^---+
  |   |                        E1  |    |
  +---+               Diff R Flag  |    |
New DR PE             Diff A Flag  |    |
New Admin Pref             +-------v+   |
                           | BMP    +---+
                           | Assign |
                           +--------+
						   ]]>
</artwork>
			</figure>
			
			<t>
				The full set of procedures can be described as a finite state
				machine per &lt;SD&gt; run within each participating BFR with the following events and transitions
			</t>
			<section title="States">
				<t>
					<list style="hanging">
						<t hangText="Init">Initial State of the Machine</t>
						<t hangText="Wait">
							State waiting for routers to update their PEs for &lt;SD&gt; on startup
						</t>
						<t hangText="Election">
							State that runs the election procedures and
							generates according events that progress it into another state
							immediately
						</t>
						<t hangText="Passive">
							State entered when lost both DR and BDR in
							election.
						</t>
						<t hangText="Elected DR"/>
						<t hangText="Elected BDR"/>
						<t hangText="BMP Assign">
							State in which the assignment of bits happens upons requests from BFERs.
						</t>
					</list>
				</t>
			</section>
			<section title="Events">
				<t>
					<list style="hanging">
						<t hangText="Timer">
							Initial timer waiting for s of other routers
							before election is triggered.
						</t>
						<t hangText="Signalling/Rcvd First PE">
							First PE for &lt;SD&gt; has been received or signalling enabled for the set S on BFR.
						</t>
						<t hangText="Lost DR">
							Current D-BFR&lt;SD&gt; cannot be reached anymore via SPF computation in standard topology.
						</t>
						<t hangText="Lost">
							Lost election for D-BFR and BD-BFR.
						</t>
						<t hangText="Won BDR">
							Won election for BD-BFR.
						</t>
						<t hangText="Won DR">
							Won election for D-BFR.
						</t>
						<t hangText="New BDR">
							A new BD-BFR has been elected by the D-BFR.
						</t>
						<t hangText="New DR PE">
							New BIER-PE Instance from D-BFR.
						</t>
						<t hangText="New Admin Pref">
							Changed Administrative preference.
						</t>
						<t hangText="Diff R Flag">
							R flag has been announced by a BFR which was not present before. In case of a new R flag, 
												 an assignment should be attempted. In case of R flag being deleted 
																					 <list>
																						 <t>if the A flag is set, the validity of the copied BFR-id with the assignment is checked</t>
																						 <t>if the A flag is clear, the value is assumed non-negotiable and re-assignments may be necessary</t>
																							  </list>
																					  
						</t>
						<t hangText="Diff A Flag">
							A flag has been withdrawn or announced. If A flag was present before and 
												 <list>
							<t>
								R flag is clear, the value is assumed non-negotiable and re-assignments may be necessary.
							</t>
													 <t>
															R flag is set, a new assignment is requested.
														</t>
						</list>
							If A flag was not present before and
							<list>
								<t>
									R flag is clear, the validity of the copied BFR-id with the assignment is checked
								</t>
								<t>R flag is set, the client MUST be declared faulty and disregarded.</t>
									 </list>
							
							</t>
													 

						<t hangText="To Be Completed">
							TBD
						</t>

					</list>
				</t>
			</section>
		</section>
		
		

		<section title="FSM Figure/Events for BFER: TBD">
		<t></t>
		</section>

		<section title="Backwards Compatiblity">
				  <t>
						The procedures prescribed guarantee a complete backwards compatiblity to  <xref format="default" pageno="false" target="I-D.draft-przygienda-bier-isis-ranges-02"/>. During 
						the assignment procedure the according values are hidden from BFRs lacking this extension by the means of the C bit. Once assigned, they become visible. On the other hand, 
										  BFR-id values chosen by the BFRs without election extensions are respected in assignment. 
					 </t>
		</section>
		
		<section title="Packet Formats" toc="default">
			<t>
				Some of the new information is carried within the
				the existing BIER Info sub-TLV per <xref format="default" pageno="false" target="I-D.draft-przygienda-bier-isis-ranges-02"/> and some presents a new ISIS TLV.
		</t>


			<section title="BIER-PE: BIER Protocol Election sub-sub-TLV" toc="default">
				<t>
					This sub-sub-TLV is included in the BIER Info sub-TLV of the according sub-domain as specified by <xref format="default" pageno="false" target="I-D.draft-przygienda-bier-isis-ranges-02"/>. 
					It MUST be included in the BIER Info sub-TLV only once, otherwise the first instance 
								   is used.
				</t>
				<figure align="left" alt="" height="" suppress-title="false" title="" width="">
					<artwork align="left" alt="" height="" name="" type="" width="" xml:space="preserve"> 
<![CDATA[
 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        | D-BFR Priority| Reserved      |                                    
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                      D-BFR ID                                 |          
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          
|                      BD-BFR ID                                |          
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                                                               
]]>
</artwork>
				</figure>
				<t>
					<list style="hanging">
						<t hangText="Type:">TBD1.</t>
						<t hangText="Length:">1 octet.</t>
						<t>
							<list>
								<t hangText="Priority">
									Priority at which this router is set to
									become D-BFR for the &lt;SD&gt;.
								</t>
								<t hangText="D-BFR ID">
									ID of the router chosen as D-BFR. If the
									router elected itself as D-BFR it MUST set it to its own ID.
								</t>
								<t hangText="BD-BFR ID">
									ID of the router chosen as BD-BFR. If the
									router elected itself as BD-BFR it MUST set it to its own ID.
								</t>
							</list>
						</t>
					</list>
				</t>
			</section>

			<section title="Reuse of the Reserved Bits in BIER Info sub-TLV" anchor="BIERINFO">
						 
				
				<figure align="left" alt="" height="" suppress-title="false" title="" width="">

					<artwork align="left" alt="" height="" name="" type="" width="" xml:space="preserve">


						<![CDATA[
					 
       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      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Ver|C|0 0 0 A R| subdomain-id  |   BFR-id                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+										

																]]>
						</artwork>
				</figure>

				<t>
				   
					<list style="hanging">
						<t hangText="Version">Version of the protocol. It remains at 0.</t>
						<t hangText="C">The compatiblity bit. It is set according to following rules:
						<list>
							<t>
								   If the R bit is set, C is set to 0, i.e. the TLV is not compatible with version 0 of the BIER information. This will prevent routers not implementing this specification from looking at this advertisement. 
							   </t>
							<t>
								   If the R bit is clear, C is set to 1. In case the BFR-id has been obtained without an error by requesting it from a D-BFR, the value is copied into BFR-id of this sub-TLV, otherwise it is set to invalid BFR-id. 
							   </t>
												  </list>				  
						
						</t>
						
						<t hangText="R">
							Request Bit. When set, this bit advertises that the BFER is
							willing to accept another BMP than the one administratively
							desired from D-BFR&lt;SD&gt;. The value of BMP is then determined by the according element in BIER-PE-BMP of the D-BFR&lt;SD&gt;.
						</t>
						<t hangText="A">
							When this bit is set, the BFER advertises that
							the value indicated in the BFR-id has been copied 
												 from the assignment provided by D-BFR. If clear and BFR-id is set, the value is administratively assigned and is non-negotiable.
						</t>
						
						<t hangText="BFR-id">
											  If set and R bit is clear, it indicates the BFR-id the BFR is occupying to the D-BFR. If the R bit is set, it indicates the desired BFR-id to be assigned or no preference. 
										  </t>
						
					</list>
				   </t>
				
					 </section>
								
			
			<section title="BIER-PE-BMP: BIER PE BMP Assignments TLV" toc="default">
				<t>
					This TLV is advertised only for the &lt;SD&gt; for which the router has been elected to be D-BDR&lt;SD&gt; or BD-BDR&lt;SD&gt;.
					 It can repeat multiple times. 
				</t>
				<figure align="left" alt="" height="" suppress-title="false" title="" width="">
					<artwork align="center" alt="" height="" name="" type="" width="" xml:space="preserve">
						<![CDATA[
 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        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|R R R R| MT-ID                 | subdomain-id  |# of Assigments|       
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       
                                                                 <---+  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |  
|  AF   |E|Stats| Assigned BFR-id             | Prefix Length   |  # Bit                                
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  Mask 
|                     Address Prefix (variable)                 |  Assgn
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |  
                                                                 <---+
]]>
</artwork>
				</figure>
				<t>
					<list style="hanging">
						<t hangText="Type">TBD</t>
						<t hangText="MT-ID">Multi topology for which the assignments are provided</t>
						<t hangText="subdomain-id">subdomain-id for which the assignments are provided</t>

						<t hangText="AF">identifies address family of the prefix for which the assignment is provided. Values TBD</t>
						<t hangText="Prefix Length">Prefix length of the prefix for which the assignment is provided.</t>
						<t hangText="Prefix">Prefix containing the identifying prefix from TLVs 235, 237, 135 or 236 for which the 
										  assignment is provided. 
							   
						   </t>
						
						<t hangText="Assigned BFR-id">
							Bit Mask Position assigned by
							D-BFR, set to invalid BMP on an error status. 2 octets.
						</t>
						<t hangText="E">Bit indicating assignment error, i.e. the BFER does NOT have a valid assignment.</t>

						<t hangText="Status">
							Status of the assignment, 3 bits. 
							<list style="hanging">
								<t hangText="0">
									Assignment is OK and can be used (based on
									either administratively requested BMP or chosen by D-BFR for
									the requesting BFER). E-bit MUST be clear.
								</t>
								<t hangText="1">
									error: Unresolvable collision with other
									administratively set values, Bit Mask Position cannot be
									used.  E-bit MUST be set.
								</t>
								<t hangText="2">
									error: Out of Bit Mask Positions for the
									Topology and Set, Bit Mask Position cannot be used.  E-bit MUST be set.
								</t>
								<t hangText="all other values">
									reserved, MUST NOT be used. 
								</t>								
							</list>
						</t>
						
						
					</list>
				</t>
				<t>
					The assignments SHOULD be sorted on BFER-ID. Assignments MUST NOT repeat when the TLV is advertised multiple times and 
								   a router discovering such condition MUST issue an adequate warning. When multiple assignments for the same
								BFR are found, the first one in first TLV MUST be used and all others disregarded. 					   
				</t>
				<t>
					The assignments MUST NOT repeat any BIER Info sub-TLVs that have the R and A bit cleared, e.g. purely administrative assignments.
					A router discovering such condition MUST issue an adequate warning and disregard such assignments. 
				</t>
				<t>
					The assignments MUST repeat all assigned BIER Info sub-TLVs (that have A bit set). When such assignment is not advertised anymore,
								   the according BFER MUST interpret that as loss as assignment, i.e. start with R bit again or set the BFR-id to 
														   invalid BFR-id. 
				</t>
			</section>


		</section>
		<section anchor="Security" title="Security Considerations" toc="default">
			<t>
				Implementations must assure that malformed TLV and sub-TLV
				permutations do not result in errors which cause hard protocol failures.
			</t>
		</section>
		<section anchor="Acknowledgements" title="Acknowledgements" toc="default">
			<t>
				TBD.</t>
		</section>
	</middle>

	<back>

		<references title="Normative References">

			<?rfc include="reference.RFC.1195"?>
			<?rfc include="reference.RFC.4971"?>
			<?rfc include="reference.RFC.2119"?>
			<?rfc include="reference.RFC.5120"?>
			<?rfc include="reference.RFC.6513"?>
			<?rfc include="reference.RFC.5305"?>
			<?rfc include="reference.RFC.5308"?>
			<?rfc include="reference.RFC.2328"?>

			<reference anchor="I-D.draft-wijnands-bier-architecture-04">
				<front>
					<title>
						Stateless Multicast using Bit Index Explicit Replication
						Architecture
					</title>
					<author initials="IJ" surname="Wijnands">
						<organization/>
					</author>
					<date month="February" year="2015"/>
				</front>
				<seriesInfo name="internet-draft" value="draft-wijnands-bier-architecture-04.txt"/>
				<format target="http://tools.ietf.org/id/draft-wijnands-bier-architecture-04.txt"
					type="TXT"/>
			</reference>

			<reference anchor="I-D.draft-wijnands-mpls-bier-encapsulation-02">
				<front>
					<title>
						Bit Index Explicit Replication using MPLS
						encapsulation
					</title>
					<author initials="IJ" surname="Wijnands et al.">
						<organization/>
					</author>
					<date month="December" year="2014"/>
				</front>
				<seriesInfo name="internet-draft" value="draft-wijnands-mpls-bier-encapsulation-02.txt"/>
				<format target="http://tools.ietf.org/id/draft-wijnands-mpls-bier-encapsulation-02.txt"
					type="TXT"/>
			</reference>

			<reference anchor="I-D.draft-przygienda-bier-isis-ranges-02">
				<front>
					<title>
						BIER support via ISIS
					</title>
					<author surname="Przygienda et al." initials="A">
						<organization/>
					</author>
					<date year="2015" month="Jan"/>
				</front>
				<seriesInfo name="internet-draft" value="draft-przygienda-bier-isis-ranges-02.txt"/>
				<format target="http://tools.ietf.org/id/draft-przygienda-bier-isis-ranges-02.txt"
					type="TXT"/>
			</reference>


		</references>
	</back>



</rfc>
