<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2784 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2784.xml">
<!ENTITY RFC3036 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3036.xml">
<!ENTITY RFC3906 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3906.xml">

<!ENTITY RFC4364 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml">
<!ENTITY RFC5120 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5120.xml">
<!ENTITY RFC5286 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5286.xml">

<!ENTITY RFC6514 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6514.xml">
<!ENTITY RFC7432 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml">
<!ENTITY RFC8279 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8279.xml">
<!ENTITY RFC8296 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8296.xml">

<!ENTITY RFC8401 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8401.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-przygienda-bier-migration-options-00" ipr="trust200902">
  <front>
    <title abbrev="BIER Migration">BIER Migration Frameworks</title>

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

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

    <date day="21" month="Jun" year="2018"/>

    <workgroup>BIER</workgroup>

    <abstract>
        <t>BIER is a new architecture for the forwarding and replication of
            multicast data packets. This document defines possible
        approaches to introduce BIER into networks consisting of
        a mixture of BFRs and non-BFRs and their respective preconditions
            and properties.</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="Introduction">
        <t>BIER <xref target="RFC8279"></xref>
            is a new architecture for the
            forwarding of multicast data packets. It allows
            replication through a "multicast domain" and it does not
            precondition construction of a multicast
            distribution tree, nor does it precondition intermediate nodes
            to maintain any per-flow state.
        </t>
        <t>Given that BIER encompasses a novel switching
            path it can be reasonably expected that in many deployment
            scenarios,
            at least initially,
            a mixture of
            BFRs and non-BFR (i.e. routers having all or some of the interfaces
            not being capable of BIER forwarding) will be used and
            represent what we will call "mixed environments".

            <xref target="RFC8279"></xref>
            offers several suggestions how a mixture
            of such routers can be handled in the network. The purpose
            of this memo is
            to cover other possible deployment options with explanation
            what preconditions are necessary to apply each of those and what
            properties and requirements they bring  in operational
            considerations respectively.
        </t>
        <t>The presented sequence of possible solutions follows very loosely an ordering
            starting with
            the ones that use "least" amount of additional technologies beside BIER to
            deploy a "mixed environment".
            This serves subsequently to facilitate
            the introduction of consecutive, more interdependent solutions.
            Nevertheless, this does not imply
            that any of the solutions is better or simpler.
            The "optimal" solution will depend every time
            on operational realities of the network performing a migration towards
            BIER deployment.
        </t>

<t>Any tunnelling technology used when deploying BIER in a
    "mixed environment" must ensure that in case
    the tunnel carries other types of traffic beside
    BIER the tunnel termination point MUST be capable of identifying BIER frames
    by some means. In case of tunnel carrying only Ethernet frames
    or MPLS encapsulated traffic <xref target="RFC8296"/> allows to distinguish
    BIER from other frames.
</t>


        <t>
            This document uses terminology defined in
            <xref target="RFC8279"></xref>.
        </t>
    </section>

    <section title="`Naked` MT">

        <t>
            Strictly speaking BIER can be deployed in "mixed environments"
            without any additional extensions
            or new technologies in its basic form. Proper use of multi-topology
            <xref target="RFC5120"/>
            configuration in IGPs will allow separation of BIER capable routers
            and interfaces
            in the topology, possibly connected via IGP tunnels to create
            at minimum a graph of BFRs.
        </t>

        <section title="Preconditions">
            <t><list style="symbols">
                <t>BIER IGP signalling via <xref target="I-D.ietf-bier-ospf-bier-extensions"/> or
<xref target="RFC8401"/>
                and</t>
            <t> implementation of multi-topology and </t>
            <t>any kind of tunneling
                technology that can be viewed as adjacency in IGP.
            </t>
            </list>
            </t>
        </section>

        <section title="Properties">
            <t><list style="symbols">
                <t>Multi-topology has been
                    standardized and used for many years in IGPs and other
                    signalling protocols.</t>
                <t>The use
                    of multi-topology allows for multicast and unicast traffic to
                    follow (per subdomain)
                    different paths if necessary in case such a behavior is
                    desired operationally.
                </t>
                <t>Normal IGP computation results are used as BIER nexthops,
                    i.e. normal SPF nexthops or even
                    TE computation nexthops and techniques like <xref target="RFC3906"/>
                    are applicable.
                </t>
                <t>Reconfiguring multi-topology preconditions the touching of both
                    sides of a link in the multi-topology and recomputation of BIER
                    nexthops for the given topology on all routers. On changes in
                    topology the tunnels may need to be reprovisioned depending
                    on technology and protection scheme used.
                </t>
                <t>Physical links configured as members of several multi-topologies
                    can be "shared" between
                    subdomains for e.g. protection purposes, i.e. if multi topologies
                    used for different sub-domains are using same physical links, the
                    links will be used by the according sub-domains as well. By adjusting
                     IGP metrics the traffic can be kept separate per
                    subdomain with the possiblity of a "fail-over" onto the links
                    with high IGP metric in case of failures. It is even
                    possible to use the same physical topology with each multi-topology
                    carrying different metrics to make different links having
                    different preference for each sub-domain and "separate" traffic
                    per sub-domain that way.</t>
                <t>Since multi-topology membership is a "per interface" property it
                    allows to manage "partial BFR" routers, i.e. routers where
                    only a subset of interfaces is BIER capable.
                </t>
                <t>Multi-topology solution can be combined in case of "mixed environment" with
                    any other solution described in this document that is multi-topology
                    aware.
                </t>
                <t>If tunnel metrics are chosen based on purely IGP metrics the solution
                    may load-balance between hop-by-hop BIER path and tunnels which can
                    lead to different timing
                    behavior on each path
                    albeit in case of BIER entropy encompassing a
                    logical flow this should be benign.
                </t>
                <t>Multi-topology provides inherently
                    separate routing tables and according statistics.
                </t>
            </list>
            </t>
        </section>

    </section>

    <section title="RFC8279 Section 6.9">

        <t>
            This section deals with the "re-parenting" solution outlined in Section 6.9
            of <xref target="RFC8279"></xref>. We will deal with the modified step 2)
            solution in <xref target="bar"/>.
        </t>

        <section title="Preconditions">
            <t><list style="symbols"><t>
                BIER IGP signalling via <xref target="I-D.ietf-bier-ospf-bier-extensions"/> or
                <xref target="RFC8401"/>
                and</t>
            <t>pre-provisioned "static" tunnels that allows "re-parenting" in any
                possible failure scenario and/or</t>
            <t>a "dynamic tunneling" technology that can
                use a unicast tunnel between any pair of nodes in the domain
                without configuration or setup,
                e.g. <xref target="RFC2784">"soft" GRE</xref>, <xref target="RFC3036">LDP</xref>
                in Downstream Unsolicited mode or
                <xref target="I-D.ietf-spring-segment-routing">Segment Routing</xref>
                are assumed to be deployed through the whole BIER domain.
            </t>
            </list>
            </t>
        </section>

        <section title="Properties">
            <t><list style="symbols">
                <t>When used with dynamic tunnels
                    the solution can automatically "bridge" disconnected areas
                    without necessity to provision multi topology or static tunnel configuration, i.e.
                    this solution can deal with any arbitrary breakage of topology as long
                    the network does not become partitioned. It is equivalent to
                    node protection <xref target="RFC5286"/>.
                </t>
                <t>IGPs do not have to be aware of the tunnels.</t>
                <t>BIER traffic strictly follows unicast path only
                    (assuming that
                    the "dynamic tunnels" are following IGP unicast nexthops as well) and with that
                    <list>
                        <t>all BIER capable routers MUST have enough scale to carry
                            unicast load and</t>

                        <t>if the unicast next-hop is a non-BIER capable router the
                            router upstream will ingress replicate to all the children
                            on the unicast tree of that next-hop and
                        </t>
                        <t>BIER may load balance between tunneled and BIER native
                            forwarding paths which can lead to different timing
                            behavior albeit in case of BIER entropy encompassing a
                            logical flow this should be benign.</t>

                    </list>
                </t>

                <t>All interfaces on BFRs MUST be capable of BIER forwarding.</t>

                <t>Dynamic tunneling topologies do not provide extensive OAM normally
                    albeit they may provide
                    node and link failure protection. On the other hand,
                    some "dynamic tunnelling" technologies like segment routing will hold
                    minimum amount of state in the network, i.e. no per-tunnel specific
                    state while providing coverage for any non-partitioning failure.
                </t>
                <t>If a tunnel is used to reach the next BFR, the tunnel's own
                    node/link protection provides FRR.
                </t>
                <t>Each change in dynamic tunnel signalling (such as LDP) may lead to
                    recomputation of BIFT entries.
                </t>

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

    </section>

    <section title="BIER Specific Algorithm Based Solutions" anchor="bar">

        <t> BIER can support a multitude of
            BIER Algorithms (BAR)
            as specified in IGP drafts and <xref target="I-D.ietf-bier-bar-ipa"/>
            to operate in "mixed environments" and take into consideration
            BIER specific constraints and properties.

            While doing that BFRs signal which algorithm they use so the distributed
            computation delivers consistent results on all BFRs.
            In its simplest form BAR can defined an SPF where non-BFRs are not
            being put on the candidate list which we denote for the moment as BAR=1
            and consider further.
        </t>

        <section title="Preconditions">

<t><list style="symbols"><t>BIER IGP signalling via <xref target="I-D.ietf-bier-ospf-bier-extensions"/> or
    <xref target="RFC8401"/>
    and</t>
            <t> Implementation of non-zero BAR values and </t>
            <t>any kind of tunneling
                technology that can be viewed as an adjacency in IGP.
            </t>
            </list>
            </t>

        </section>

        <section title="Properties">
            <t><list style="symbols">
            <t>BAR allows for multicast and unicast traffic to
                follow different paths if necessary in case such a behavior is
                desired operationally. </t>
            <t>BAR could take into accounts different limitations like e.g. maximum possible fan-out
                degree on nodes or inter-dependency of sub-domains in same BIER domain. </t>
            <t>Normal IGP computation can be used easily to compute BAR BIER nexthops while
                preserving all unicast node and link-protection schemes.
            </t>
            <t>Reconfiguring BAR preconditions the touching of all participating BFR.
            </t>

            <t>BAR can allow to manage "partial BFR" routers, i.e. routers where
                only a subset of interfaces is BIER capable if additional information
                is advertised with BIER sub-TLVs.
            </t>

            <t>All interfaces on BFRs MUST be capable of BIER forwarding unless the
                static tunnels can be "homed" on BIER capable interfaces only.</t>

            </list></t>

        </section>
    </section>

    <section title="Controller Based Solutions" anchor="controller">

        <t>Ultimately, the according BIRTs and BIFTs can be precomputed by an
            off-line controller via any algoirthm desirable (in a sense similar
            to <xref target="bar"/> but being able to take other metrics and
            constraints in the computation than distributed by IGP possibly) and
            downloaded.
        </t>

        
        <section title="Preconditions">
            <t><list style="symbols">
                <t>Controller computing BIRTs and/or BIFTs and downloading them into
                all BIER nodes and</t>
            <t>Preferrably signalling of a special BAR value on each router to ensure
                that it is configured to use the according controller downloaded
                tables.
            </t>
            </list>
            </t>
        </section>
        
        <section title="Properties">
            <t><list style="symbols">
            <t>Controller based solution can take into account many constraints
                and metrics that are not distributed network-wide such as provisioning
                constraints depending on time of day.</t>
            <t>Centralized cntroller computation cannot normally react quickly
                to node or link
                failures due to delays involved. It is possible that a centralized
                computation precomputes and installs according link- and node-protection
                BIER next-hops and installs those in the forwarding path. Depending
                on delays two set of tables may be necessary where after download to
                all routers a `fast switch-over` is performed to minimize holes and
                traffic losses.
            </t>

            </list></t>
            
        </section>
        
    </section>
    
    <section title="IANA Considerations">
        <t>None.
        </t>
    </section>
    
    <section title="Security Considerations">
        <t>
            General BIER security considerations apply and this document does
            not introduce any new security relevant topics.
        </t>
        <t>Controller based solutions may introduce new security considerations.</t>
    </section>
</middle>

  <back>
    <references title="Normative References">
        &RFC2784;
&RFC3036;
&RFC3906;
            <?rfc include="reference.I-D.ietf-bier-ospf-bier-extensions"?>
            <?rfc include="reference.I-D.ietf-spring-segment-routing"?>
            <?rfc include="reference.I-D.ietf-bier-bar-ipa"?>
&RFC5120;
&RFC5286;
&RFC8279;
&RFC8296;
&RFC8401;

    </references>

      </back>
</rfc>
