<?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-przygienda-bier-isis-ranges-00" ipr="trust200902" obsoletes="" submissionType="IETF" updates="" xml:lang="en">
	<front>
		<title abbrev="draft-przygienda-bier-isis-ranges-00">BIER support via 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>
		<date day="27" month="Sep" year="2014"/>
<workgroup>Internet Engineering Task Force</workgroup>
		<abstract>
			<t>Specification of an ISIS extension to support BIER domains.
			</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-00"/>
   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-00"/>.
   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. 

    </t>
			
			<t>
This document presents necessary extensions to the currently deployed ISIS for IP <xref format="default" pageno="false" target="RFC7142"/> protocol to support distribution of information necessary for operation of BIER domains. 
This document defines a new TLV to be distributed by 
every router participating in such BIER domains.
 
</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-00"/> 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="BM:">Bit Mask (A bit stream of a certain fixed
          length. Each Bit represents a receiver).</t>
					<t hangText="P-BM:">Packet Bit Mask (A Bit Mask included in the
          Multicast Packet).</t>
					<t hangText="BP:">Bit Position (A single Bit from the Bit Mask
          that represents a receiver).</t>
					<t hangText="BFR:">Bit Forwarding Router (A router that
          participates in Bit Index Multipoint Forwarding).</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.</t>
<t hangText="BFT:">Bit Forwarding Tree used to reach all BFERs in a domain.</t>
					<t hangText="BIFT:">Bit Index Forwarding Table (A 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>
					
				</list>
			</t>

		</section>
		
		<section anchor="IANA" title="IANA Considerations" toc="default">
			<t>This document requests IANA to assign sub-TLV type values from the ISIS router capability TLV <xref format="default" pageno="false" target="RFC4971"/> registry.</t>
			
		</section>

		<section title="Concepts">
		<section title="BIER as Capability">
<t>This draft introduces a sub-TLV in the router capabilites TLV <xref format="default" pageno="false" target="RFC4971"/> to distribute the information. 
Any of the router's loopback addresses that it originates are considered BFR prefixes as required by <xref format="default" pageno="false" target="I-D.draft-wijnands-bier-architecture-00"/>. The question whether 
a particular loopback address is routable in a specific topology <xref format="default" pageno="false" target="RFC5120"/> can be resolved by <xref format="default" pageno="false" target="I-D.draft-xu-isis-routable-ip-address-01"/>.
</t>
		</section>
		<section title="BIER Domain Identifier">
<t>
		ISIS can carry BIER information not only for a single BIER domain but for multiple, distinct domains. 
		This allows to run many disjoint BIER layers within the same <xref format="default" pageno="false" target="RFC5120">Multi-Topology</xref> easily instead 
		of always forcing different multicast overlays to share the exactly same set of BFRs and resources. Moreover, multi topology <xref format="default" pageno="false" target="RFC5120"/>  
		can be used for the purpose of restricting links that certain set of BIER domains can use or change metrics of such links.  A BIER set is therefore always uniquely identified by 
		the tuple of topology T, domain D it belongs to and its number S, denoted as &lt;T,D,S&gt;. The domain itself has as its unique attributes the encapsulation, bitmask length 
		and the type of tree it is using to forward BIER frames (currently always SPF). 
</t>
	        </section>
		</section>
		
		<section title="Procedures">
		<section title="Enabling a BIER Domain">

 <t>A given domain D in a multi-topology T <xref format="default" pageno="false" target="RFC5120"/> 
				(denoted as &lt;T,D&gt; from now on) is normally not advertised to preserve the scaling of the protocol (i.e. ISIS 
		carries no TLVs containing any of the elements related to &lt;T,D&gt;)  and 
		is enabled by a first BIER sub-TLV (<xref target="S2L"></xref>) containing &lt;T,D&gt; being advertised into the area.  
		The trigger itself is outside the scope of this draft but can be .e.g. a VPN desiring to initiate a domain 
		as MP2MP or P2MP tree or a BMP being administratively assigned to a BFER and 
		advertised via BIER TLV into the area or any other means within Multicast BIER Overlay(s) using BIER domains.</t>
   
   </section>
		<section title="Length of Bitmasks" anchor="BML">
<t>		All routers in the flooding scope of the BIER TLVs SHOULD advertise the same bit mask length for a given &lt;T,D&gt;. 
		A router discovering bitmask lengths advertised that are shorter 
		than its own MUST report a misconfiguration of a specific &lt;T,D&gt;.  
		Each router MUST compute BFTs for &lt;T,D&gt; using only routers having the same mask length as its own 
		advertised Bit Mask Length in BIER sub-TLV for &lt;T,D&gt;.  
		</t>

			<section title="Special Consideration">
			<t>
			The same router MAY advertise for different &lt;T,D&gt; combinations two different mask lengths. This allows 
			to cleanly delineate domains crossing the same router but using different mask lengths in the encoding, even within the same topology. 
			</t>
			</section>
</section>

		<section title="Encapsulation">
		<t>Since encapsulation is an attribute of a domain &lt;T,D&gt; just like bitmask length, all rules that apply to Bitmask Length per <xref target="BML"/> apply to it well.</t>
		</section>

		<section title="Label Advertisements">
		<t>
		Each router MAY advertise within the sub-TLV of an according &lt;T,D&gt; (denoted further as TLV&lt;T,D&gt;) a valid starting label value and a non-zero range length. 
		It MUST advertise a valid label value and a non-zero range length IF it 
		has computed itself as being on the BFT rooted at any of the BFRs with valid BFR-ids (except itself) participating in &lt;T,D&gt;.
		</t>
		<t>A router CAN withdraw its TLV&lt;T,D&gt; if it does not want to participate in the domain due to resource constraints, label space optimization, 
		administrative configuration or any other reasons. In case a router advertises a label range size of 0 for &lt;T,D&gt; it MUST be excluded from the 
		BIER BFTs for &lt;T,D&gt;. 
		</t>		

			<section title="Special Consideration">
			<t>A router MUST advertise a for &lt;T,D&gt; label range size that guarantees to cover the 
			maximum BFR-id injected into &lt;T,D&gt; 
			(which implies a certain set id as described in <xref format="default" pageno="false" target="I-D.draft-wijnands-bier-architecture-00"/>). Any router 
			that violates this condition MUST be excluded from BIER BFTs for &lt;T,D&gt;. 
			</t>
			</section>

		</section>
		
		<section title="BFR-id Advertisements">
		<t>
		Each BFER MAY advertise with its TLV&lt;T,D&gt; the according BFR-id that it has administratively chosen. 
		</t>
		<t>If two BFRs advertise in their TLV&lt;T,D&gt; the same value for BFR-id, all routers MUST report it as misconfiguration and disregard those routers for all 
		BIER calculations and procedures to align with <xref format="default" pageno="false" target="I-D.draft-wijnands-bier-architecture-00"/>. 
		Such routers with colliding assignments MAY still act as BFIRs but will be never able to receive traffic.
		</t>
		</section>

		</section>
		
		<section title="Packet Formats" toc="default">
		<t>All ISIS BIER information is carried within the router capability TLV <xref format="default" pageno="false" target="RFC4971"/> with S bit clear.</t>
		
		<section title="BIER BFR sub-TLV" anchor="S2L">
			<t>
			This sub-TLV carries the information for the BIER domains that the router participates in as BFR. It can repeat multiple times. If the same &lt;T,D&gt; is 
			advertised more than once, the first one in the first sub-TLV in the fragment with the  lowest ID MUST be 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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     MT-ID     |   Bier Domain ID              |   Bit Msk Len |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Lbl Range Size|                    Label                      |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |   BFR-id                      |A|R|T| Reserv  |  Encaps       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                
]]>
</artwork>
</figure>
<t>
					<list style="hanging">
						<t hangText="Type:">TBD1.</t>
						<t hangText="Length:">2 octets.</t>
						<t hangText="MT-ID:">  <xref format="default" pageno="false" target="RFC5120">Multi-Topology</xref>, 1 octet.</t>
						<t hangText="BIER Domain ID:">  Unique identifier for a BIER domain, 2 octets.</t>
						<t hangText="Label Range Size:">Number of labest in the range used on encapsulation for this BIER domain, 1 octet. </t> 

						<t hangText="Label:">First label of the range used on encapsulation for this BIER domain, 20 bits.  
						The label is used by e.g. <xref format="default" pageno="false" target="I-D.draft-wijnands-mpls-bier-encapsulation-00"/> to forward traffic to sets of BFERs.
              </t>
						<t hangText="Local BitMask Length:">Bitmask length for this BFR per <xref format="default" pageno="false" target="I-D.draft-wijnands-bier-architecture-00"/>.</t>
						<t hangText="Encapsulation Type:">The BIER encapsulation type,
              1 octet. Allowed values are:
              
              					<list style="hanging">
								<t hangText="0">MPLS per <xref format="default" pageno="false" target="I-D.draft-wijnands-mpls-bier-encapsulation-00"/>.</t>
							</list>
</t>

			<t hangText="A">Indicates administratively set value if set, otherwise the BFR-id value MUST be considered as not assigned in this TLV.</t> 
			<t hangText="R">Reserved for future use. MUST be 0.</t> 
			<t hangText="T">Reserved for future use. MUST be 0.</t> 
			<t hangText="Reserved">MUST be 0 on send, ignored on receive.</t>
					</list>
				</t>


		</section>
		</section>
		<section anchor="Security" title="Security Considerations" toc="default">
			<t>
			The extension does not introduce any known new protocol vulnerabilities. 
			</t>
		</section>
		<section anchor="Acknowledgements" title="Acknowledgements" toc="default">
			<t>The draft is aligned with the <xref format="default" pageno="false" target="I-D.draft-kumar-ospf-bier-extension-00"/> 
			   draft as far as the protocol mechanisms overlap. 
			</t>
		</section>
	</middle>
	<back>
		<references title="Normative References">
			<?rfc include="reference.RFC.2119"?>
			<?rfc include="reference.RFC.5120"?>
			<?rfc include="reference.RFC.4971"?>
			<?rfc include="reference.RFC.7142"?>
			<reference anchor="I-D.draft-wijnands-bier-architecture-00">
				<front>
					<title>Stateless Multicast using Bit Index Explicit Replication
          Architecture</title>
					<author initials="IJ" surname="Wijnands">
						<organization/>
					</author>
					<date month="February" year="2014"/>
				</front>
				<seriesInfo name="internet-draft" value="draft-wijnands-bier-architecture-00.txt"/>
				<format target="http://tools.ietf.org/id/draft-wijnands-bier-architecture-00.txt" type="TXT"/>
			</reference>
			
<reference anchor="I-D.draft-wijnands-mpls-bier-encapsulation-00">
				<front>
					<title>Bit Index Explicit Replication using MPLS
          encapsulation</title>
					<author initials="IJ" surname="Wijnands et al.">
						<organization/>
					</author>
					<date month="February" year="2014"/>
				</front>
				<seriesInfo name="internet-draft" value="draft-wijnands-mpls-bier-encapsulation-00.txt"/>
				<format target="http://tools.ietf.org/id/draft-wijnands-mpls-bier-encapsulation-00.txt" type="TXT"/>
			</reference>

<reference anchor="I-D.draft-xu-isis-routable-ip-address-01">
				<front>
					<title>Carrying Routable IP Addresses in IS-IS Router Capability TLV</title>
					<author initials="U" surname="Chunduri et al.">
						<organization/>
					</author>
					<date month="September" year="2014"/>
				</front>
				<seriesInfo name="internet-draft" value="draft-xu-isis-routable-ip-address-01.txt"/>
				<format target="http://tools.ietf.org/id/draft-xu-isis-routable-ip-address-01.txt" type="TXT"/>
			</reference>
			
			<reference anchor="I-D.draft-kumar-ospf-bier-extension-00"> 
    <front> <title>OSPF Extension for Bit Index Explicit Replication</title> 
    <author surname="Psenak" initials="P"> <organization/> </author> 
    <author surname="Wijnands" initials="IJ"> <organization/> </author> 
    <date year="2014" month="September"/> </front> 
    <seriesInfo name="internet-draft" value="draft-ietf-ospf-prefix-link-attr-00.txt"/> 
    <format target="http://tools.ietf.org/id/draft-ietf-ospf-prefix-link-attr-00.txt" type="TXT"/> </reference>

			
						
		</references>
	</back>
</rfc>
