<?xml version="1.1" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8279 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8279.xml">
<!ENTITY RFC5120 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5120.xml">
<!ENTITY RFC1925 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1925.xml">
<!ENTITY RFC8279 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8279.xml">

]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-zzhang-bier-algorithm-00" ipr="trust200902">
  <front>
    <title abbrev="bier-algorithm">BIER Algorithms</title>

    <author fullname="Zhaohui Zhang" initials="Z." surname="Zhang">
      <organization>Juniper Networks</organization>
      <address>
        <email>zzhang@juniper.net</email>
      </address>
    </author>


<author fullname="Andrew Dolganow" initials="A." surname="Dolganow">
    <organization>Nokia</organization>
    <address><email>andrew.dolganow@nokia.com</email>
    </address>
</author>


    <author fullname="Antoni Przygienda" initials="A." surname="Przygienda">
      <organization>Juniper Networks</organization>
      <address>
        <email>prz@juniper.net</email>
      </address>
    </author>

    <date year="2018"/>

    <workgroup>BIER</workgroup>

    <abstract>
      <t>This document specifies signaling and procedures for non-SPF BIER tree
         computation covering several practical use cases discussed in
         deployment scenarios.
      </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 RFC2119.
      </t>
    </note>
  </front>

  <middle>
    <section title="Terminologies">
    <t>Familiarity with BIER protocols and procedures is assumed.
       Some terminologies are listed below for convenience.
    </t>
    </section>
    <section title="Introduction">
    <t>In the BIER architecture, a multicast specific routing underlay
       (not necessarily congruent with the unicast topology), or multiple
       routing underlays
       (again not necessarily congruent with the unicast topologies) could
       be used for
       forwarding BIER packets. A routing underlay used for BIER is specified
       today as combination of a routing topology [RFC5120] and
       a calculation algorithm
       (BAR <xref target="I-D.ietf-bier-isis-extensions"/>) per sub-domain.
       Currently, BAR is unspecified beside a single codepoint taken for
       basic unicast SPF alignment.
    </t>
</section>

    <section title="BIER Tree Computation Algorithms" anchor="bar">
    <t>OSPF Extensions for BIER <xref target="I-D.ietf-bier-ospf-bier-extensions"/>
       and
       ISIS Extensions for BIER <xref target="I-D.ietf-bier-isis-extensions"/>
       specify currently
       an BIER AlgoRithm (BAR, originally Tree-ID) field in the BIER sub-TLV:
</t>

<figure>
    <artwork>
        """ BAR: ... 0 is the only supported value defined in this
                 document and represents Shortest Path First (SPF)
                 algorithm based on IGP link metric.  This is the
                 standard shortest path algorithm as computed by
                 the OSPF protocol. ... """
    </artwork>

	</figure>

    <t>This document proposes to define codepoints for additional algorithms
        outlined in the architecture document to
       handle BIER incapable routers within BIER topologies and solve other
       challenges that BIER faces when deployed over standard SPF. Moreover we
       describe the need for an algorithm that deals with computations where
       subdomains can
       share the same multi topology for protection purposes while computing
       disjoint trees. We also mention a more difficult fanout limitation
       problem that can
       benefit from a new algorithm and quickly mention possible traffic
       engineering implications.
    </t>

<t> Whatever the computation algorithm used, all routers in the same area
    are recommended to use the same method to prevent blackholes or stable loops.
    If a mix is used (for example by using different BAR for different stream forwarding
    or using different BAR on different BFIRs), a special care must be given
    to prevent blackholes and/or loops.</t>

    <t>If an alternative method to BAR 0 is used, then the
    routers MUST signal that method by the means of a different
    BAR value. The method is expected to specify compatibility to other
    BAR values if so desired.</t>

    <t>In case where multiple BAR values are present in the same routing
    underlay each set of routers with same BAR may split from the
    routers with a different BAR value, effectively partitioning the
    network for a given multicast stream forwarding.</t>

    </section>



    <section title="Specification">
    <section title="Handling BIER Incapable Routers via a different SPF Tree">
        <t>Section 6.9 of the BIER Architecture Specification <xref target="RFC8279"/>
            touches on possible
            methods of dealing with BIER incapable routers. As
            most practical alternative BIER incapable routers can be simply pruned
            during the SPF calculation from the candidate list. This case presents
            itself if multi topology cannot be deployed due to some considerations
            or it is desired to cross non BIER routers via tunneling.
        </t>
    <t>To be exact, in the rest of the document, a BIER incapable router
       refers to any of the following:
    <list style="symbols">
    <t>A router that does not support BIER at all.</t>
    <t>A BFR that does not advertise the specific &lt;subdomain, multi topology, BAR,
       encapsulation, BSL> for which a particular calculation is
       being performed. We denote this for simplicity as &lt;SD,MT,BAR,ENC,BSL&gt;
           combination in further discourse.
    </t>
    </list>
    </t>
    <t>A new BAR value (suggested value of 1)
        is defined in this document to specify the method of pruning
       BIER incapable routers (not putting them onto the candidate list when
       encountered during SPF). Any
       router supporting this method and provisioned to use this method MUST
       signal this BAR value.
    </t>

    <t>Observe further that this allows to use in brown field deployments routers
        that do not support BIER at all but can easily tunnel it. The modification
        of the algorithm will use any forwarding adjacency to a BIER capable
        router then.</t>
    </section>
<!--
    <section title="Handling BIER Incapable Routers RFC8279 Section 6.9">
        <t>Another possible computation to deal with BIER incapable routers
            is specified in <xref target="RFC8279"/> today. This computation cannot
            be "mixed" with normal SPF or BAR=1 and hence to support it a BAR value
            (suggested value 2) should be allocated to it.
    </t>
        <t>The disadvantage of this method is that it is non-trivial to use
            existing node and link protection algorithm results when the trees
            are modified as described in the algorithm.</t>
        </section>
-->
    <section title="Computing Maximum Disjoint Trees for Subdomains Sharing a Topology">

<t>For certain class of multicast deployments it is desirable to send data across
    two BIER subdomains that are maximally disjoint. While this can be addressed by
    using multiple completely disjoint topologies, such a method has to basically
    partition the
    network
    and precondition multi topology deployments or multiple IGPs. A more
    efficient method is to
    compute the tree for a subdomain while avoiding another subdomain on the
    same multi-topology. Future version of this document will provide a detailed
    algorithm to calculate the tree and claim a BAR registry value.
    </t>
        </section>

<section title="Dealing with Ingress Replication Degradation">

    <t>BIER, when following strict SPF unicast routing is bound to degrade into ingress
        replication in certain topologies when it follows SPF
        or the fanout may overwhelm the replication
        capacity of a specific system.
        One possibility is to prune the topology using
        multi topology deployment which may limit the recovery potential
        on link failures, a better one is obviously to compute a
        specialized tree that limits the fanout. Future version of this document
        will provide a detailed
        algorithm to calculate the tree and claim a BAR registry value.

    </t>
</section>

<section title="Scaling up BIER with Traffic Engineering">
<t>Suggested traffic engineering architecture for BIER <xref target="I-D.ietf-bier-te-arch"/>
    offers a very limited scalability only. It would be desirable to subject
    BIER to proper TE point-to-multipoint computation. Albeit BIER results can
    be shaped with multi topology again, a computation including TE metrics and
    constraints and maybe even multicast specific metrics like node fanouts could
    introduce a distributed, scalable TE for BIER. Such a computation could
    be performed in a centralized fashion of course and resulting BIFTs downloaded
    to routers as well but such an approach is outside the scope of this document.
</t>

    </section>

</section>

    <section title="IANA Considerations">
    <t>This document proposes to create BIER AlgoRithm registry with the
       following initial values.
    <list style="hanging">
    <t hangText="0:"> Default SPF calculation that includes all nodes.
    </t>
    <t hangText="1:">SPF calculation that prunes routers that do not support the
          &lt;SD,MT,BAR,ENC,BSL&gt; combination for which the calculation
          is performed before putting them on the candidate list.
    </t>
<!--
    <t hangText="2:">SPF calculation that modifies the SPF tree to avoid
        BIER incapable routers using RFC8279 Section 6.9 algorithm.
    </t>
-->
    </list>
    </t>

    </section>
    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>To be provided.
      </t>
    </section>
   </middle>

  <back>
    <references title="Normative References">
      &RFC1925;
	  &RFC2119;
      &RFC5120;
	  &RFC8279;
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.ietf-bier-isis-extensions'?>
      <?rfc include='reference.I-D.ietf-bier-ospf-bier-extensions'?>
      <?rfc include='reference.I-D.ietf-bier-te-arch'?>
    </references>

  </back>
</rfc>
