<?xml version="1.0" encoding="US-ASCII"?>
<!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="std" docName="draft-geng-bier-ipv6-inter-domain-02"
     ipr="trust200902">
  <front>
    <title abbrev="Inter-domain-BIERv6">Inter-Domain Multicast Deployment
    using BIERv6</title>

    <author fullname="Liang Geng" initials="L." surname="Geng">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing 10053</city>

          <code/>

          <country/>
        </postal>

        <email>gengliang@chinamobile.com</email>
      </address>
    </author>

    <author fullname="Jingrong Xie" initials="J." surname="Xie">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <code/>

          <country/>
        </postal>

        <email>xiejingrong@huawei.com</email>
      </address>
    </author>

    <author fullname="Mike McBride" initials="M." surname="McBride">
      <organization>Futurewei</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <code/>

          <country/>
        </postal>

        <email>mmcbride7@gmail.com</email>
      </address>
    </author>

    <author fullname="Gang Yan" initials="G." surname="Yan">
      <organization>Huawei Technologies</organization>

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

        <email>yangang@huawei.com</email>
      </address>
    </author>

    <author fullname="Xuesong Geng" initials="X." surname="Geng">
      <organization>Huawei Technologies</organization>

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

        <email>gengxuesong@huawei.com</email>
      </address>
    </author>

    <date day="27" month="October" year="2020"/>

    <abstract>
      <t>Bit Index Explicit Replication IPv6 encapsulation (BIERv6) introduces
      an approach to use IPv6 extension header to carry BIER header with IPv6
      unicast address as destination address. It provides the ability to
      replicate a packet from one router to other routers in a different
      domain as well as routers in the same domain. This document introduces the
      techniques for multicast deployment across multiple domains using
      BIERv6, and demonstrate how BIERv6 is beneficial for such
      deployment.</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"/>
      and <xref target="RFC8174"/>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>Bit Index Explicit Replication [RFC8296] IPv6 encapsulation (BIERv6)
      described in <xref target="I-D.xie-bier-ipv6-encapsulation"/> introduces
      an approach to use IPv6 extension header to carry BIER header. One
      BIERv6 option, using IPv6 unicast address as destination address
      provides the ability to replicate a packet from one router to other
      routers in a different domain as well as routers in the same domain. This
      document introduces the techniques for multicast deployment across
      multiple domains using BIERv6, and demonstrates how BIERv6 is beneficial
      for such deployment.</t>
      <t>The word "domain" used in this document means a closely connected set of
      nodes or simply "IGP domain" or "autonomous system (AS)". The word "inter-domain" 
      used in this document means interconnected IGP domains or autonomous systems (ASes) 
      belonging to a single "BIERv6 domain" as defined in 
      <xref target="I-D.xie-bier-ipv6-encapsulation"/>. </t>
      <t>There is no concept of MVPN segmentation <xref target="RFC6513"/> in this document.
      Instead, It is a non-segmented MVPN or inter-domain stateless multicast deployment 
      in this document, and a single BIER Sub-domain throughout the "inter-domain" scope
      of the BIERv6 domain is assumed. </t>
    </section>

    <section title="Terminology">
      <t>Readers of this document are assumed to be familiar with the
      terminology and concepts of the documents listed as Normative
      References.</t>
    </section>

    <section title="Inter-domain Multicast Overview">
      <t>It is common to deploy multicast services across multiple
      domains.</t>

      <t>One typical scenario for this type of deployment is in a service-
      provider network for MVPN service as described in <xref
      target="I-D.ietf-bier-ipv6-requirements"/>. Service provider network
      tends to be very heterogeneous with full-mesh backbone network, and
      metro networks with fabric for dense area coverage or ring-shaped for
      sparse area coverage. The backbone network and metro networks are
      autonomous systems interconnected by border routers (BRs).
      Multicast-based delivery of video need to be set up from a source router
      on the backbone to each of the boundary routers of each metro
      network.</t>

      <t>This scenario may have some variant. For example, multicast source
      router is a Top of Rack (TOR) switch in a service provider data
      center(SPDC) connected to backbone with data center gateway(s) (DC-GW),
      and multicast receiver is the home broadband subscribers connected to
      boundary routers (e.g. BNG) of each metro network. Operators may want to
      set up multicast-based delivery from TOR to BNGs seamlessly without
      segmentation or stitching on DC-GW(s) or BR(s).</t>

      <t>It is described as hierachical multicast in this document.</t>

      <t>Another typical scenario for inter-domain multicast deployment is in
      peering network as described in <xref target="RFC8313"/> to set up
      multicast-based delivery of content across inter-domain peering
      points.</t>

      <t>This scenario may have some variant. For example, interconnected
      content delivery networks (CDNs) (described in <xref target="RFC6770"/>)
      owned by Network Service Providers (NSPs) or Enterprise Service
      Providers may need to deliver multicast from one to others.</t>

      <t>It is described as peering multicast in this document.</t>

      <t/>
    </section>

    <section title="Inter-domain Multicast Deployment using BIERv6">
      <t/>

      <section title="Hierarchical Multicast">
        <t>Following is an example of hierarchical deployment of
        multicast.</t>

        <t><figure align="left" anchor="hierachmcast"
            title="Inter-Domain Hierarchical Multicast">
            <artwork><![CDATA[
                                             +---------------------+
                                             |  Metro 2 (AS 65002) |
                                             | +-----+    +------+ |
                                       +-------| BR2 |    | PE2x |---RCV
                                     /       | +-----+    +------+ |
                                   /         +---------------------+
       +---------------------+   /             Bfr-id 1 to 256
       | Backbone (AS 65001) | /
       | +------+    +-----+ /
   SRC---| PE1x |    | BR1 | |
       | +------+    +-----+ \
       +---------------------+ \                Bfr-id 257 to 512
            |                    \           +---------------------+
            |                      \         |  Metro 3 (AS 65003) |
            |                        \       | +-----+    +------+ |
            |                          +-------| BR3 |    | PE3x |---RCV
            |                                | +-----+    +------+ |
            |                                +---------------------+
            |                                                 |
            |<----------------- BIERv6 Domain --------------->|

    BR = Border Router
    SRC = Multicast Source
    RCV = Multicast Receiver
  ]]></artwork>
          </figure></t>

        <t>Multicast source is connected to PE1x, and multicast receivers are
        connected to PE2x and PE3x.</t>

        <t>PE1x, PE2x, PE3x is located in Backbone (AS 65001), Metro 2 (AS
        65002), and Metro 3 (AS 65003) respectively, and BR1, BR2, BR3 is
        boarder of these three domains. They belong to a single administrative
        domain.</t>

        <t>IGP underlay for BIERv6 is deployed in Metro2, Metro3 respectively.
        The bfr-ids in Metro2 and Metro 3 should be divided rationally.</t>

        <t>PE1x, PE2x, PE3x uses 2001:DB8::E1, 2001:DB8::E2, 2001:DB8::E3 as 
        End.BIER IPv6 address respectively.</t>

        <t>BR1, BR2, BR3 uses 2001:DB8::B1, 2001:DB8::B2, 2001:DB8::B3 as 
        End.BIER IPv6 address respectively.</t>

        <t>All of them use the Non-MPLS static BSL-SD-SI BIFT encoding method
        described in <xref target="I-D.ietf-bier-non-mpls-bift-encoding"/> as
        the auto-generation method.</t>

        <t>On BR1, static configuration can be used to construct inter-domain
        BIERv6 forwarding table.</t>

        <t><figure>
            <artwork align="left"><![CDATA[
    bier sub-domain 6 ipv6-underlay
      bfr-prefix interface loopback0
      end-bier 2001:DB8::B1
      encapsulation ipv6 bsl 256 max-si 2
      static-bift
        nexthop end-bier 2001:DB8::B2 bfr-id 1 to 256
        nexthop end-bier 2001:DB8::B3 bfr-id 257 to 512
 ]]></artwork>
          </figure></t>

        <t>Accordingly, the following BIFTs will be constructed:</t>

        <t><figure>
            <artwork align="left"><![CDATA[
    BIFT correspond to SD<6>/BSL<256>/SI<0>
      (neighbor = 2001:DB8::B2, F-BM = ffff....ffff)
    BIFT correspond to SD<6>/BSL<256>/SI<1>
      (neighbor = 2001:DB8::B3, F-BM = ffff....ffff)
 ]]></artwork>
          </figure></t>

        <t>On PE1x, static configuration can be used to construct inter-domain
        BIERv6 forwarding table. Note that PE1x doesn't need to assign a valid 
        BFR-id uniquely among many.</t>

        <t><figure>
            <artwork align="left"><![CDATA[
    bier sub-domain 6 ipv6-underlay
      bfr-prefix interface loopback0
      end-bier 2001:DB8::E1
      encapsulation ipv6 bsl 256 max-si 2
      static-bift
        nexthop end-bier 2001:DB8::B1 bfr-id 1 to 512
 ]]></artwork>
          </figure></t>

        <t>Accordingly, the following BIFTs will be constructed:</t>

        <t><figure>
            <artwork align="left"><![CDATA[
    BIFT correspond to SD<6>/BSL<256>/SI<0>
      (neighbor = 2001:DB8::B1, F-BM = ffff....ffff)
    BIFT correspond to SD<6>/BSL<256>/SI<1>
      (neighbor = 2001:DB8::B1, F-BM = ffff....ffff)
 ]]></artwork>
          </figure></t>

        <t>Use of BGP as inter-domain underlay protocol to advertise the BIER
        information from BR2 or BR2 to BR1, or from BR1 to PE1x is outside the
        scope of this document.</t>

        <t>On each domain, two redundant border routers may be deployed, and
        anycase IPv6 address can be used on each pair of BRs as
        End.BIER IPv6 address.</t>

        <t>Inter-Domain BIER will converge normally when unicast converge and
        the BIFT will be reconstructed accordingly.</t>

        <t/>

        <t>For multicast overlay layer, there are no extensions needed. MVPN
        is deployed on PE1x, PE2x and PE3x using sub-domain 6 and bsl 256
        without segmentation on border router(s).</t>

        <t>Note: Use of the IPv6 address configured on PE1 to identify an MVPN
        instance can eliminate the need for BFR-id configuration on PE1x,
        which otherwise has to be configured from the space of a
        sub-domain.</t>

        <t/>
      </section>

      <section title="Peering Multicast">
        <t>Following is an example of peering deployment of multicast.</t>

        <t><figure align="left" anchor="peeringmcast"
            title="Inter-Domain Peering Multicast">
            <artwork><![CDATA[
                                             +---------------------+
                                             |    AD-2 (AS 65002)  |
                                   +---+     | +-----+    +------+ |
                                 /   I   \   | | BR2 |    | PE2x |---RCV
              (color 1)         (    N    )  | +-----+    +------+ |
            Bfr-id 1 to 256     (    T    )  +---------------------+
       +---------------------+  (    E    )       Bfr-id 1 to 512
       |    AD-1 (AS 65001)  |  (    R    )         (color 2)
       | +------+    +-----+ |  (    C    )  
   SRC---| PE1x |    | BR1 | |  (    O    )  
       | +------+    +-----+ |  (    N    )  
       | +------+            |  (    N    )  
   RCV---| PE1y |            |  (    E    )  
       | +------+            |  (    C    )         (color 3)
       +---------------------+  (    T    )       Bfr-id 1 to 256
                                (    I    )  +---------------------+
                                (    O    )  |    AD-3 (AS 65003)  |
                                 \   N   /   | +-----+    +------+ |
                                   +---+     | | BR3 |    | PE3x |---RCV
                                             | +-----+    +------+ |
                                             +---------------------+
    AD = Administrative Domain (independent autonomous system)
    BR = Border Router
    SRC = Multicast Source
    RCV = Multicast Receiver
      ]]></artwork>
          </figure></t>

        <t>Each Administrative Domain AD-1, AD-2 or AD-3 is configured a
        unique color. Color 1, 2, 3 are used in this example.</t>

        <t>For routing underlay layer, the ingress router uses IGP protocol
        (IS-IS as example in this document) for the domain it belongs to, and
        uses static configuration for the domain it doesn't belong to.</t>

        <t>Below is an example of routing underlay configuration on PE1x. 
        Note that PE1x doesn't need to assign a valid BFR-id per color.</t>

        <t><figure>
            <artwork align="left"><![CDATA[    # PE1x routing underlay layer configuration
    bier sub-domain 6 ipv6-underlay
      bfr-prefix interface loopback0
      end-bier 2001:DB8::E1
      encapsulation ipv6 bsl 256 max-si 1
      color 1 protocol isis
      color 2 static-bift
        nexthop end-bier 2001:DB8::B2 bfr-id 1 to 512
      color 3 static-bift
        nexthop end-bier 2001:DB8::B3 bfr-id 1 to 256
 ]]></artwork>
          </figure></t>

        <t>The following lists the BIFT that will be constructed on PE1x:</t>

        <t><figure>
            <artwork align="left"><![CDATA[
   BIFT corresponding  to SD<6>/BSL<256>/SI<0> for color 1 ;;Ref1
   BIFT corresponding  to SD<6>/BSL<256>/SI<0> for color 2 ;;Ref2
   BIFT corresponding  to SD<6>/BSL<256>/SI<1> for color 2 ;;Ref3
   BIFT corresponding  to SD<6>/BSL<256>/SI<0> for color 3 ;;Ref4
 ]]></artwork>
          </figure></t>

        <t>Ref1: BIFT constructed using IGP.</t>

        <t>Ref2: BIFT constructed using static configuration, with BR2 a
        multi-hop BFR neighbor of PE1x.</t>

        <t>Ref3: BIFT constructed using static configuration, with BR2 a
        multi-hop BFR neighbor of PE1x.</t>

        <t>Ref3: BIFT constructed using static configuration, with BR3 a
        multi-hop BFR neighbor of PE1x.</t>

        <t/>

        <t>For multicast overlay layer, the color extended community defined
        in [RFC5512] is carried in Leaf A-D route together with the PTA
        attribute.</t>

        <t>(1) PE in each domain gets the color it belongs to. This can be
        done by configuration on each PE in each domain.</t>

        <t>(2) PE carries a color attribute in BGP-MVPN Leaf A-D route when
        advertising to Ingress PE as response to explicit-tracking initiated
        by the Ingress PE. This can be done by configuration on MVPN
        deployment. Refer to <xref target="I-D.xie-bier-ipv6-mvpn"/> for other
        attributes needed to be used.</t>

        <t>(3) The Ingress PE gets the Leaf A-D route, learns the BFERs of a
        color (representing a domain) interested in a multicast flow, and
        constructs the overlay forwarding table. Below is an example of the
        overlay forwarding table on PE1x:</t>

        <t><figure>
            <artwork align="left"><![CDATA[
  (VRF<X>, S<S1>, G<G1>)
    (Color<1>, SD<6>, BSL<256>, SI<0>, BitString<0001>) ;;Ref1
    (Color<2>, SD<6>, BSL<256>, SI<0>, BitString<0001>) ;;Ref2
    (Color<2>, SD<6>, BSL<256>, SI<1>, BitString<0001>) ;;Ref3
    (Color<3>, SD<6>, BSL<256>, SI<0>, BitString<0001>) ;;Ref4
 ]]></artwork>
          </figure></t>

        <t>Ref1: packet will be replicated according to the
        BitString&lt;0001&gt; and the BIFT constructed using the IGP for
        SD&lt;6&gt;/BSL&lt;256&gt;/SI&lt;0&gt; for color 1.</t>

        <t>Ref2: packet will be replicated according to the
        BitString&lt;0001&gt; and the BIFT constructed using the static-bift
        configuration for SD&lt;6&gt;/BSL&lt;256&gt;/SI&lt;0&gt; for color
        2.</t>

        <t>Ref3: packet will be replicated according to the
        BitString&lt;0001&gt; and the BIFT constructed using the static-bift
        configuration for SD&lt;6&gt;/BSL&lt;256&gt;/SI&lt;1&gt; for color
        2.</t>

        <t>Ref3: packet will be replicated according to the
        BitString&lt;0001&gt; and the BIFT constructed using the static-bift
        configuration for SD&lt;6&gt;/BSL&lt;256&gt;/SI&lt;1&gt; for color
        3.</t>

        <t>Note: BFR-id configuration on PE1x is only necessary when PE1x will
        act as BFER, for example, there is multicast packet from PE2x to PE1x.
        The BFR-ids in color 1, 2, 3 is independent on each other.</t>
      </section>
    </section>

    <section title="Security Considerations">
      <t>Section 5.1 of <xref target="I-D.xie-bier-ipv6-encapsulation"/> 
      should be strictly deployed as a basic security mechanism for 
      BIERv6 deployment. </t>
      
      <t>In case the inter-domain "domains" are connected directly, 
      for example, they may be connected to the same physical infrastructure 
      (e.g., a Service Provider's network), then the "edge node" and 
      "external interface of each edge node" are both clear. </t>
      
      <t>In case the inter-domain "domains" are connected remotely by a
      secure connection, for example, they may be connected by a kind of VPN 
      connection, then the "external interface of each edge node" excludes the 
      interface of the Customer Edge (CE) router connecting (through VPN) to 
      the Provider Edge(PE) router. </t>

      <t>In case the inter-domain "domains" are connected remotely by an
      insecure connection, for example, they may be connected by an internet
      connection, then the "external interface of each edge node" includes the 
      interface of the Customer Edge (CE) router connecting (through internet) to 
      the Provider Edge(PE) router. </t>
      <t/>
    </section>

    <section title="IANA Considerations">
      <t>No IANA Allocation is required in this document.</t>

      <t/>
    </section>

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

      <t/>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.8279'?>

      <?rfc include='reference.RFC.5512'?>

      <?rfc include='reference.RFC.6770'?>
      <?rfc include='reference.RFC.6513'?>

      <?rfc include='reference.RFC.8313'?>

      <?rfc include='reference.I-D.ietf-bier-non-mpls-bift-encoding'?>

      <?rfc include='reference.I-D.ietf-bier-ipv6-requirements'?>

      <?rfc include='reference.I-D.xie-bier-ipv6-mvpn'?>

      <?rfc include='reference.I-D.xie-bier-ipv6-encapsulation'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.8174'?>
    </references>
  </back>
</rfc>
