﻿<?xml version="1.0" encoding="UTF-8"?>
<!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="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-ietf-bier-ipv6-requirements-09"
     ipr="trust200902">
  <front>
    <title abbrev="BIER IPv6 Requirements">BIER IPv6 Requirements</title>

    <author fullname="Mike McBride" initials="M" surname="McBride">
      <organization>Futurewei</organization>

      <address>
        <email>michael.mcbride@futurewei.com</email>
      </address>
    </author>

    <author fullname="Jingrong Xie" initials="J" surname="Xie">
      <organization>Huawei</organization>

      <address>
        <email>xiejingrong@huawei.com</email>
      </address>
    </author>
    
       <author fullname="Xuesong Geng" initials="X" surname="Geng">
      <organization>Huawei</organization>

      <address>
        <email>gengxuesong@huawei.com</email>
      </address>
    </author>

    <author fullname="Senthil Dhanaraj" initials="S" surname="Dhanaraj">
      <organization>Huawei</organization>

      <address>
        <email>senthil.dhanaraj@huawei.com</email>
      </address>
    </author>

    <author fullname="Rajiv Asati" initials="R" surname="Asati">
      <organization>Cisco</organization>

      <address>
        <email>rajiva@cisco.com</email>
      </address>
    </author>
    
       <author fullname="Yongqing Zhu" initials="Y" surname="Zhu">
      <organization>China Telecom</organization>

      <address>
        <email>zhuyq8@chinatelecom.cn</email>
      </address>
    </author>
 
     <author fullname="Gyan Mishra" initials="G. " surname="Mishra">
      <organization>Verizon Inc.</organization>
      <address>
        <email>gyan.s.mishra@verizon.com</email>
      </address>
    </author>
       
        <author fullname="Zhaohui Zhang" initials="Z" surname="Zhang">
      <organization>Juniper</organization>

      <address>
        <email>zzhang@juniper.net</email>
      </address>
    </author>

    <date day="28" month="September" year="2020"/>

    <abstract>
      <t>There have been several proposed solutions with BIER being used in IPv6. But there
      hasn't been a document which describes the problem and lists the requirements. 
      The goal of this document is to describe the general BIER IPv6 encapsulation problem and 
      detail solution requirements, thereby assisting the working group in the development of acceptable 
      solutions.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>Bit Index Explicit Replication (BIER) <xref target="RFC8279"/> is an
      architecture that provides optimal multicast forwarding, without
      requiring intermediate routers to maintain per-flow state, through the
      use of a multicast-specific BIER header. <xref target="RFC8296"/>
      defines two types of BIER encapsulation: one is
      BIER MPLS encapsulation for MPLS environments,
	  the other is non-MPLS BIER encapsulation to run without MPLS.
	  This document describes non-MPLS BIER encapsulation in IPv6 environments. 
	  We explain the requirements of transporting multicast flow overlay payload through 
	  an IPv6 network underlay using BIER. The solutions may use IPv6
	  forwarding plane and may include IPv6 encapsulation and/or generic
	  IPv6 tunnelling. 
      </t>

      <section anchor="requirements-language" 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 anchor="terminology" title="Terminology">
        <t><list style="symbols">
            <t>BIER: Bit Index Explicit Replication. Provides optimal
            multicast forwarding through adding a BIER header and removing
            state in intermediate routers.</t>
          </list></t>
      </section>
    </section>

    <section title="Problem Statement">
      
      <t>The problem is how to transport multicast packets, with non-MPLS BIER encapsulation, in an IPv6 environment. 
      We need to determine where to put the BIER header in this IPv6 environment. With IPv6 encapsulation being increasingly used for 
      unicast services, such as VPN or L2VPN, it may be desirable to have IPv6 encapsulation also used in BIER deployments for multicast 
      services such as MVPN. It may also be desirable to not use IPv6 encapsulation except when IPv6 tunneling (native or GRE/UDP-like) is 
      used to transport BIER packets over BIER-incapable routers. </t>
      
      <t>Below is a simple scenario that needs BIER IPv6-based forwarding:</t>

      <t><figure align="center">
          <artwork><![CDATA[      
      +--------------------------------------------+
      |                                            |
      |                                         +------+
      |                                         | BFER |
  +------+       +-------+       +-----+        +------+
  | BFIR |       |Non-BFR|       | BFR |           |
  +------+       +-------+       +-----+        +------+
      |                                         | BFER |
      |                IPv6 Network             +------+
      |                                            |
      +--------------------------------------------+
      ]]></artwork>
        </figure></t>

      <t>This scenario depicts the need to replicate BIER packets from a
      BFIR to BFERs across an IPv6 Service Provider core.   
	  Inside the IPv6 network, the BIER header is used to direct the packet from one BFR to the next BFRs, 
	  and either a IPv6 header or an L2/tunnel header is used to provide reachability between BFRs.
	  The IPv6 environment may include a variety of link types, may be entirely IPv6, 
	  or may be dual stack. There may be cases where not all routers 
	  are BFR capable in the IPv6 environment but still want to deploy BIER.
	  Regardless of the environment, the problem is to deploy BIER, with non-MPLS BIER encapsulation, in an  IPv6 network.
      </t>
      
    </section>


    <section title="Requirements">
      <t>There are several suggested requirements for BIER IPv6 solutions. </t>
      
      <t>In this document, the requirements are divided into two levels: Mandatory and Optional. 
      The requirement levels are determined based on the following factors: </t>
      <t></t>
       <t><list style="">
       <t>If the requirement is required for a feature that is likely to be a potential deployment, the requirement level will be considered mandatory. </t>
       <t>If the impact of not implementing the requirement may block BIER from been deployed, the requirement level will be considered mandatory.</t>
       </list></t>
      <t></t>
      
    <section title="Mandatory Requirements">  
      <t>Considering that these mandatory requirements are all well-known to the working group, and practical in normal deployment, 
      they will be listed without a detailed description.
      </t>
      <section title="Support various L2 link types">
        <t>The solution should support various kinds of L2 data link types.</t>
      </section>
      
      <section title="Support BIER architecture">
        <t>The solution must support the BIER architecture. </t>

        <t>Supporting different multicast flow overlays, multiple sub-domains, multi-topologies,
		multiple sets, multiple Bit String Lengths,
		and deterministic ECMP are considered essential functions of BIER and need to be supported.</t>
      </section>

      <section title="Support deployment with Non-BFR routers">
        <t>The solution must support deployments with BIER-incapable routers.
        This is beneficial to the deployment of BIER, especially 
        in early deployments when some routers do not support 
        BIER forwarding but support IPv6 forwarding. </t>
      </section>
      
      <section title="Support OAM">
            <t>BIER OAM tools like <xref target="I-D.ietf-bier-ping"/> and <xref target="I-D.ietf-bier-pmmm-oam"/> 
          should be supported, either directly using existing methods, 
      or by specifying a new method for the same functionality.
      They are likely to be needed in normal BIER deployment for diagnostics. </t>

      </section>
      
      </section>
      
    <section title="Optional Requirements">
      <t>The requirements in this section are listed as optional, and each requirement is explained with a detailed scenario.
      Note that fragmentation and IPSEC ESP are not BIER functions, they are provided by the upper IP layer.
      </t>
      
      <section title="Support Fragmentation">
      <t>There are some cases where the Fragmentation/Assembly function is needed for BIER to work in an IPv6 network. </t>
      <t>For example, a customer IPv6 multicast packet may be 1280 bytes and is required to be transported through an IPv6 network using BIER. 
         Every link of the IPv6 network is no less than the requisite 1280 bytes <xref target="RFC8200"/>, 
         but the size of the payload that can be encapsulated in BIER (BIER-MTU) is less than 1280 bytes.
         In this case, it is not the appropriate action for a BFIR to drop the packet and advertise an MTU to the source <xref target="RFC8296"/>. 
         Instead, some transport mechanism needs to provide the fragmentation and assembly function.
      </t>
  		
      </section>
      
      <section title="Support IPSEC ESP">
      <t>There are some cases where the IPSEC ESP function may be needed to transport c-multicast packets through an IPv6 network with 
      confidentiality using BIER technology.</t>
      <t>A service provider may want to provide additional security SLA to its customer to ensure that the unencrypted c-multicast packet is 
      not altered in the service provider's network. In this case, if the BIER technology is preferred for the multicast service, BIER with IPSEC 
      ESP support may be a candidate solution. On the other hand, the traffic
	  protection may be better provided via IPSEC or MACSEC at multicast flow overlay
	  over and beyond the BIER domain.
      </t>
      </section>
    </section>

    </section>

    <section title="IANA Considerations">
      <t>Some BIER IPv6 encapsulation proposals do not require any action from
      IANA while other proposals require new IPv6 Option
      codepoints from IPv6 sub-registries, new "Next header" values, or
      require new IP Protocol codes. This document, however, does not require
      anything from IANA.</t>
    </section>

    <section title="Security Considerations">
      <t/>
      <t>There are no security issues introduced by this draft.</t>
    </section>

    <section title="Acknowledgement">
      <t/>

      <t>Thanks to Eric Rosen for his listed set of initial requirements on the
      BIER WG mailing list.</t>
    </section>
  </middle>

  <back>
     <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
      <?rfc include='reference.RFC.8279'?>
      <?rfc include='reference.RFC.8296'?>
      <?rfc include='reference.RFC.8200'?>
      <?rfc include='reference.I-D.ietf-bier-ping'?>
      <?rfc include='reference.I-D.ietf-bier-pmmm-oam'?>
    </references>

    
    
  </back>
</rfc>