<?xml version="1.0" encoding="US-ASCII"?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="yes"?>
<rfc category="std" docName="draft-anish-spring-bimap-multicast-00" ipr="trust200902" submissionType="IETF">

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

  <front>
    <title>SRv6 Bitmap Multicast.</title>

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

    <author initials="A." surname="Peter" fullname="Anish Peter" role="editor">
      <organization>Individual Contribution</organization>
      <address>
      <postal>
      <code>560043</code>
      <city>Bangalore</city>
      <region>KA</region>
      <country>India</country>
      </postal>
    <!--
      <organization>Mavenir Systems</organization>
      <address>
      <postal>
      <street>Manyata Tech Park</street>
      <code>560045</code>
      <city>Bangalore</city>
      <region>KA</region>
      <country>India</country>
      </postal>
      -->
      <email>anish.ietf@gmail.com</email>
      </address>
    </author>

    <date day="26" month="February" year="2023"/>

    <area>Routing</area>

    <workgroup> </workgroup>

    <keyword>SRv6</keyword>
    <keyword>Multicast</keyword>
    <keyword>Bitmap</keyword>
    <keyword>BIER</keyword>
    <keyword>Broadcast</keyword>

    <abstract>
  <t>Multicast forwarding in a network provides advantages in improving 
  the network usage and performance. In some cases it helps improve the
  operations in managing network. The major challenge in multicast operations
  is in managing the per-flow states in the network as required by all the
  legacy multicast frameworks. </t>
  <t>This document specifies a bitmap forwarding extension to SRv6 to support
  state-free forwarding model in a network.</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
      target="RFC2119">RFC2119</xref>.</t>
    </note>
  </front>

  <middle>
  <section title="Introduction">
      <t>Segment routing with IPv6 as specified in 
      <xref target="RFC8689">RFC8689</xref>
      provides a source-routing solution for next
      generation network requirements. More applications and use-cases are
      finding a better solutions using SRv6. Along with this comes the need to
      support multicasting and broadcasting in such networks. The various
      use-cases for this would be stated in the subsequent sections.</t>
      <t>Broadcasting typically needs a point-to-multipoint (p2mp)
    distribution with all the nodes in the network being receivers.
    Multicasting would imply p2mp distribution along with
    multipoint-to-multipoint (mp2mp) packet distribution with the participants
    being pre-determined via a discovery or provisioning mechanism.</t>
      <t>Bit-Index-Explicit-Replication specified in 
      <xref target="RFC8279">RFC8279</xref>
      introduced a per-flow-state-free
      forwarding for multicast using a bit-indexed addressing of multicast
      receivers.</t>
      <t>This document introduces a bit-map based distribution schema in
      IPv6 networks to achieve p2mp distribution patterns. SRv6 introduced
      a new semantic to IPv6 address by fragmenting the address space into
      Locator:Function:Argument construct to achieve the desired SR
      functionality. This document proposes a similar treatment of IPv6
      address to achieve BIER forwarding.</t>
  </section>

  <section title="IPv6 Bit-Index Format">
  <t>This document provides a new semantic to the IPv6 address as
  SI_LOCATOR:BITSTRING:FUNCTION:ARGUMENT. This structure is partly borrowed from
  SRv6. The BITSTRING part is newly introduced to address the egress routers in
  the BIER subdomain by its bit index. From here on this format is called as
  Bit-Index-6 format (BI6) </t>
  <t>BIER architecture envisages forwarding by identifying each egress router
  with an BFR-id. These BFR-id in forwarding translates to a Set-Identifier
  (SI) and Bitstring. In the IPv6 Bit-Index format, the SI is identified by
  the SI_LOCATOR and bitstring is encoded in the BITSTRING part of the BI6.
  The FUNCTION and ARGUMENT bits are part of the format. But depending on the
  network requirement their lengths may be set to 0 for using this bits for
  extended bitstring. </t>
  <t>SI_LOCATOR is defined as a routable prefix to reach the specific set of
  routers in a SetIdentifier. Once a BI6 packet reaches a router that is part
  of a SI, The bit-index based part is referred to for forwarding towards the
  BFER's with the BIER forwarding principles. The semantics of the FUNC and
  ARG bits is global in the Sub-domain. The attributes of
  FUNCTION and ARGUMENT bits must be pre-determined.
  </t>
  <figure anchor="BIER6 address structure" title="Syntax of BIER6 address">
  <artwork>
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | SI_LOCATOR |             BITSTRING              | FUNC | ARG  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  </artwork>
  </figure>

  </section>
  <section title="Network Overview">
    <t>BIER architecture puts forward a multicast forwarding based on
    "Bit-Index-Explicit-Replication". This architecture defines a BIER domain
    in which an ingress router would encapsulate p2mp packet with a BIER
    header
    <xref target="RFC8296">RFC8296</xref>
    . This BIER packet would be replicated to the egress routers identified
    by the ingress in its BIER header, over an optimal per-flow-stateless tree
    discovered with the underlay. </t>
  <t></t>
  </section>

  <section title="Use-Cases">
  </section>

  <section title="Subscriber management">
  <t>In BIER architecture the multicast egress routers must be learned by the
  ingress router. This discovery may happen via some out-of-band mechanism
  beyond the scope of this document.
  </t>
  </section>

  <!--
  <section title="BI6 with multiple sub-domains">
  </section>

  <section title="OAM">
  </section>
  -->

  <section title="Interworking with non compatible BI6 Routers">
  <t>A network topology may have legacy devices which may not be capable of
  BI6 processing. When deploying BI6 the traffic may have to pass through some
  of these devices for loop-free forwarding. 
  </t>
  <t>A router may come to know about the BI6 capability of a neighbouring
  device via the capabilities it has published in its IGP advertisement. Based
  on this IGP may form a map of BFER to the nearest BFR on the path to egress. If the BFR is
  not directly connected, then that BFR's node sid may be inserted into the
  SRH prior to forwarding the packet. 
  </t>
  </section>

  <!--
  <t>
  a device indentifies the that the packet has to pass a device incapable of
  BI6 forwarding it may apply the procedures mentioned below. The procedures
  considers the case of the legacy device being branching point or a
  non-branching forwarder. 
  </t>
  <t> TODO continue</t>

  <section title="Multicast FRR">

  </section>
  -->

  <section title="Scope for future work">
      <section title="Routing extension header for BIER">
      </section>
      <section title="Define egress functions based on FUNC and ARG bits">
      </section>
      <section title="IGP extension to support underlay">
      </section>
      <section title="Discovery mechanism for receivers">
      </section>
  </section>

  <section title="Management Considerations">
  <t></t>
  </section> 
  <!-- TODO TBW
  <section anchor="Acknowledgements" title="Acknowledgements">
  </section>
  -->

  <section anchor="IANA" title="IANA Considerations">
  <t>This specification introduces new semantics for IPv6 address. Though this
  draft does not need any allocations, New IANA
  allocations would be required for the supplimentary specifications. 
  </t> 
  </section>

  <section anchor="Security" title="Security Considerations">
  <t>This document proposes a semantic for IPv6 address. The security
  challenges that apply to IPv6 and in the BIER architecture applies to the
  intended BI6 forwarding model specified here. 
  </t>
  <t>The further security scenarios would be added in the due course. </t>
  </section>

  <section title="Appendix 1: Bit-Index string length">
      <section title="Private IPv6 address for operations">
      <t>The Unique Local IPv6 address allocation 
	  <xref target="RFC4193">RFC4193</xref>
      provides free to use address blocks with
      SI_LOCATOR size of 48. This provides a maximum BI6 addressing space of 80 bit length. 
      </t>
      <t>The Bit-index string length that can be used would be determined by the
      SI_locator prefix length and the need for FUNC and ARG bits. Hence if Unique
      local address space is used, upto 80 BFER's can be addressed. 
      </t>
      </section>
  </section>

  <section title="Appendix 2: Scaling considerations">
  <t>With this specification the typical scale a BIER domain would be less
  than 96 egress routers. On networks with larger scale the current proposal
  is to have multiple subdomains and to do ingress replication for traffic
  bound to various subdomains.
  </t>
  </section>

  </middle>

  <!-- *****BACK MATTER ***** -->

  <back>
    <references title="Normative References">
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
      <!--SRv6
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8689.xml"?>
	-->
      <!--BIER-->
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8279.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8296.xml"?>
    </references>

    <references title="Informative References">
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8689.xml"?>
      <!--pvt IPv6 -->
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml"?>
    </references>
  </back>
</rfc>

