<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
    There has to be one entity for each item to be referenced. 
    An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC8279 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8279.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
    please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
    (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
    (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-shepherd-bier-standards-track-00" ipr="trust200902">
 <!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
       or pre5378Trust200902
    you can add the attributes updates="NNNN" and obsoletes="NNNN" 
    they will automatically be output with "(if approved)" -->

 <!-- ***** FRONT MATTER ***** -->

 <front>
   <!-- The abbreviated title is used in the page header - it is only necessary if the 
        full title is longer than 39 characters -->

   <title abbrev="Justification for BIER on Standards Track">Justification for BIER on Standards Track</title>

   <!-- add 'role="editor"' below for the editors if appropriate -->

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

   <author fullname="Greg Shepherd" initials="G.S." role="editor"
           surname="Shepherd">
     <organization>Cisco</organization>

     <address>
       <postal>
         <street></street>

         <!-- Reorder these if your country does things differently -->

         <city>San Jose</city>

         <region></region>

         <code></code>

         <country>US</country>
       </postal>

       <phone></phone>

       <email>gjshep@gmail.com</email>

       <!-- uri and facsimile elements may also be added -->
     </address>
   </author>
      <author fullname="Anrew Dolganow" initials="A.D."
           surname="Dolganow">
     <organization>Nokia</organization>

     <address>
       <postal>
         <street>438B Alexandra Road 08-07/10, 
         Alexandra Technopark</street>

         <!-- Reorder these if your country does things differently -->

         <city></city>

         <region></region>

         <code>119968</code>

         <country>Singapore</country>
       </postal>

       <phone></phone>

       <email>andrew.dolganow@nokia.com</email>

       <!-- uri and facsimile elements may also be added -->
     </address>
   </author>

   <date year="2017" />

   <!-- 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>General</area>

   <workgroup>Internet Engineering Task Force</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>template</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 is intended to provide justification for re-chartering the BIER Working Group as Standards Track, 
     and to move all BIER WG previously published documents to Standards Track. 
     </t>
   </abstract>
 </front>

 <middle>
   <section title="Introduction">
     <t><xref target="RFC8279">IER</xref>(Bit Index Explicit Replication) is an alternative method of
     multicast forwarding.  It does not require any multicast-specific
     trees, and hence does not require any multicast-specific tree
     building protocols.  Due to the particular sensitivity of adding new
     significant functionality into the data-plane, the BIER work began
     progress as Experimental.  The current status of the experiment is documented
     in this draft and is intended to provide justification for re-charting
     the BIER Working Group (WG) as Standards Track and to move all
     published documents of the BIER WG to Standards Track. This document will detail 
     the benefits, problems, and trade-offs for using BIER instead of traditional 
     multicast forwarding mechanisms, as required by the BIER WG Charter charter-ietf-bier-01</t>

     <section 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
       target="RFC2119">RFC 2119</xref>.</t>
     </section>
   </section>

   <section title="IP Multicast Challenges">
     <t>Current IP Multicast solutions require a tree-building control plane to build and maintain
     end-to-end tree state per flow, impacting router state capacity and network convergence times.  
     Multi-point tree building protocols are often considered complex to deploy and debug and may 
     include mechanics from legacy use-cases and/or assumptions which no longer apply to the current 
     use-cases.  When multicast services are transiting a provider network through an overlay, the 
     core network has a choice to either aggregate customer state into a minimum set of core states 
     resulting in flooding traffic to unwanted network end-points, or to map per-customer, per-flow 
     tree state directly into the provider core state amplifying the network-wide state problem. Though 
     the value proposition of network replication is high, the cost of deploying IP Multicast is often 
     considered too high to justify deployment.
     </t>
   </section>

   <section title="Benefits of BIER">
   <t>BIER is a radical simplification of IP Multicast. BIER has no tree-building protocol. BIER has no
   end-to-end tree/flow state. BIER has no RPF requirements. BIER packets follow the same path to a destination
   as a unicast packet would take to the same destination. BIER provides 
   deterministic convergence times regardless of how many (S,G)s are being transported through the BIER network. 
   BIER can be deployed in SDN-driven deployment models, that minimize protocols required in a network as well by
   eliminating multicast protocols and relying on IGP infrastructure or direct SDN programmability.
   </t>
   </section>

   <section title="Trade Offs">
   <t>BIER is intended to carry IP Multicast packets - though not explicitly restricted to this - across an overlay. 
   Therefore, BIER is not end-to-end like IP Multicast. This isn't an inherent tradeoff, but it does focus the scope 
   of the solution and the discussion. The lack of (S,G) state often comes up as a perceived limitation. But considering 
   IP Unicast does not have active flow state in the Forwarding Information Base (FIB) of each node, the expectation 
   that Multicast needs flow state for debugging purposes is more of an artifact of legacy solutions rather than a requirement. 
   Debugging individual flows in BIER will require unicast techniques such as flow export tools rather than forwarding 
   state entries of IP Multicast. BIER's primary limitation is the size of the bitmask. The BIER architecture requires 256 
   bit mask support, but can accommodate larger and smaller masks. As the masks get larger (+1024 bits) transport tax 
   begins to exceed what is reasonable. 256 to 1024 end nodes of a BIER domain could then be considered a limitation. 
   Larger numbers of end nodes can be addressed with the use of BIER Sets or via multiple BIER domains.
   </t>
   <t>
   Because BIER is a forwarding plane feature significantly different from IP Unicast or Multicast, not all routers today 
   can be programmed to support BIER. Transition mechanisms have already been introduced to facility migration to an 
   expanding BIER domain.
   </t>
   </section>

   <section title="Impact of BIER on the Forwarding Plane">
   <t>Bitmask forwarding techniques have been used in embedded systems and software communication for decades.
   BIER is the first time the mechanism has been extended to address distributed forwarding and
   replication across a network. Though the BIER forwarding rules are different than IP forwarding,
   it is significantly simpler than IP Multicast forwarding. Detailed description of BIER forwarding
   is documented in RFC8279. The BIER forwarding logic is simple, and the state requirements minimal
   enough, that some existing micro-codable forwarding hardware is programmable to support BIER today. It is 
   expected that dedicated BIER forwarding hardware will be developed to extend the solution beyond micro-codable
   forwarding hardware - that is expected to then further reduce hardware costs. Multiple router vendors and chip 
   vendors either have plans to support BIER or will be announcing new products with BIER support very soon. 
   In addition, multiple operators are now actively evaluating and planning the deployment of BIER for multicast 
   delivery in their networks. This validates BIER as next generation technology for multicast delivery.
   </t>
   </section>

   <section title="Conclusion">
   <t>The overall benefits of BIER over traditional IP Multicast are quite significant, and the value 
   of network replication is so well understood, that operator and vendor engagement and support 
   for BIER was strong from the beginning and has only grown over time. It is expected that BIER adoption will 
   begin to take over as the dominant network replication transport in all networks where traditional 
   IP Multicast is used today. It is our recommendation that the BIER work and all existing BIER published RFCs 
   be moved from the Experimental track to the Standards track.
   </t>
   </section>
   
   
   <!-- This PI places the pagebreak correctly (before the section title) in the text output. -->

   <?rfc needLines="8" ?>

   <section anchor="Acknowledgements" title="Acknowledgements">
     <t>TBD
     </t>

   </section>

   <!-- Possibly a 'Contributors' section ... -->

   <section anchor="IANA" title="IANA Considerations">
     <t>This memo includes no request to IANA.</t>
   </section>

   <section anchor="Security" title="Security Considerations">
     <t>This draft is Informational and has no impact on security.
     </t>
   </section>
 </middle>

 <!--  *****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 title="Normative References">
     <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
     &RFC2119;

     <reference anchor="min_ref">
       <!-- the following is the minimum to make xml2rfc happy -->

       <front>
         <title>Minimal Reference</title>

         <author initials="authInitials" surname="authSurName">
           <organization></organization>
         </author>

         <date year="2006" />
       </front>
     </reference>
   </references>

   <references title="Informative References">
     <!-- Here we use entities that we defined at the beginning. -->

     &RFC2629;

     &RFC3552;

     &RFC5226;

     &RFC8279;
     
   </references>

 </back>
</rfc>