[Search] [txt|html|xml|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                             J. Xie
Internet-Draft                                                   F. Duan
Intended status: Informational                       Huawei Technologies
Expires: 26 April 2022                                   23 October 2021


   BIER Deployment and Operation: Challenges and Solution Approaches
                    draft-xie-mboned-bier-deploy-00

Abstract

   As a new multicast architecture, BIER [RFC8279] has been an IETF
   standard for years.  It has been evaluated in some networks for some
   scenarios.  Some challenges related to its deployment, operation,
   maintenance, and extensibility are raised.  This document reviews and
   describes the challenges related to its deployment, and try to figure
   out the potential solution approches.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 26 April 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Xie & Duan                Expires 26 April 2022                 [Page 1]


Internet-Draft         BIER Deployment Challenges           October 2021


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Challenges for Inter-domain Deployment  . . . . . . . . . . .   2
     2.1.  Protocol ambiguity for BIER advertisement in BGP  . . . .   2
     2.2.  Multi-hop BFR-NBR Support as an Inherent Requirement  . .   4
     2.3.  Anycast BIER-Label for Redundant ASBR deployment  . . . .   5
     2.4.  Overlapped BFR-id Assignment in Different Domains . . . .   7
     2.5.  Summary of Challenges in Inter-domain Deployment  . . . .  10
   3.  Challenges for Brownfield Deployment  . . . . . . . . . . . .  11
     3.1.  Adding Bypass tunnel for Intermediate Nodes . . . . . . .  11
     3.2.  Removing (Popping) BIER Header for Edge Nodes . . . . . .  12
     3.3.  Summary of Challenges in Brownfield Deployment  . . . . .  13
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   As a new multicast architecture, BIER [RFC8279] has been an IETF
   standard for years.  It has been evaluated in some networks for some
   scenarios.  Some challenges related to its deployment, operation,
   maintenance, and extensibility are raised.  This document reviews and
   describes the challenges related to its deployment, and try to figure
   out the potential solution approches.


2.  Challenges for Inter-domain Deployment


2.1.  Protocol ambiguity for BIER advertisement in BGP

   The following figure demonstrates an inter-domain network where a
   single BIER sub-domainis deployed across the whole BIER domain
   (multiple domains of an administrative entity, e.g., a Service
   Provider's network), and where MVPN service(s) deployed on the Edge
   PE1x/PE2x/PE3x.



Xie & Duan                Expires 26 April 2022                 [Page 2]


Internet-Draft         BIER Deployment Challenges           October 2021


                                             +---------------------+
                                             |  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
            |                                | +-----+    +------+ |
            |                                +---------------------+
            |                                                 |
            |<------------------ BIER Domain ---------------->|
            |<---------------- BIER Sub-Domain X------------->|
            |<------------------ MVPN services--------------->|

    BR = Border Router
    SRC = Multicast Source
    RCV = Multicast Receiver

                Figure 1: BIER Inter Domain Deployment

   In this figure, router BR2 needs to receive BIER information
   advertisement from PE2x and other routers in Metro 2 by IGP (e.g.,
   IS-IS or OSPF), and re-advertise these BIER information to BR1 using
   eBGP.  This means that, BR2 needs to use mixed protocols for BIER
   information advertisement in a single sub-domain.

   Such kind of mixed underlay-protocols usage for a single BIER sub-
   domain could also happen in intra-domain case.
   [I-D.ietf-bier-prefix-redistribute] describes such a case where an
   Area-Border-Router(ABR) uses different IGP protocols in different
   interfaces, and these interfaces are belonging to a single BIER sub-
   domain.

   However, BIER architecture [RFC8279] requires that only one routing
   underlay could be used for a single Sub-domain.







Xie & Duan                Expires 26 April 2022                 [Page 3]


Internet-Draft         BIER Deployment Challenges           October 2021


   Draft [I-D.ietf-bier-prefix-redistribute] defines a new TLV structure
   named BIER proxy range sub-TLV for mixed protocols, including BGP to
   use.  However, it does not clearly specify how to use this TLV in
   BGP, e.g, what BGP attribute to carry this TLV, and what AFI/SAFI
   used for the advertisement.

   Draft [I-D.ietf-bier-idr-extensions] defines a new BGP Path named
   BIER Path in section 3, with a sub-TLV named BIER MPLS Encapsulation
   sub-TLV in the same section, but lacks description what SAFI/AFI used
   to carry the BIER Path attribute explicitly.

   This situlation leads to the challenge of BIER deployment in Inter-
   domain network as illustrated above.  This document suggests
   clarifications are made in the above document by IETF.  For example,
   it may be considered to use BGP SAFI-1/2 routes to carry BIER Path,
   and use BIER Path to carry the BIER proxy range sub-TLV for inter-
   domain advertisement.


2.2.  Multi-hop BFR-NBR Support as an Inherent Requirement

   In above figure, router BR2 re-advertise BIER information to BR1
   using eBGP.  Accordingly, BR1 needs to receive the BIER information
   advertisement from BR2 using eBGP, and re-advertise these BIER
   information to PE1x, either through IGP or iBGP.

   A common practice for inter-domain routing is to seperate the routing
   procedure into two layers, 1st layer is BGP routing to determine non-
   direct BGP next-hop, 2nd layer is IGP routing to determine direct IGP
   next-hop based on the BGP/non-direct next-hop.  For BIER inter-domain
   deployment as illustrated in the above figure, the preferred solution
   is to use iBGP on BR1 to re-advertise the BIER information to PE1x,
   and PE1x set BR1 (the BGP/non-direct nexthop) as the non-direct BFR-
   NBR to BFERs in Metro-2 and Metro-3.  In another word, non-direct
   BFR-NBR support is an inherent requirement for BIER inter-domain
   deployment.

   Unfortunately the BIER architecture [RFC8279] is built on L2 and the
   non-direct BFR-NBR or Multi-hop BFR-NBR support is optional.  This
   means that, every time a Non-direct BFR-NBR is used, another layer of
   "bypass tunnel" needs to be used on the top of the BIER header for
   multi-hop BFR-NBR reaching.  The function seems fine, but there are
   implications to the operation and maintenance aspects.








Xie & Duan                Expires 26 April 2022                 [Page 4]


Internet-Draft         BIER Deployment Challenges           October 2021


   Firstly a policy should be configured to select what type(s) of
   tunnel are preferred.  Some network operator may prefer to use "MPLS
   LSP" as the "bypass tunnel", and then there are multiple options "LDP
   LSP", "RSVP-TE LSP", "SR-MPLS LSP" for the selection.  Some network
   operator may prefer to use IP, GRE, or UDP tunnel.

   Secondly the protocols and identifiers bound to these "bypass tunnel"
   have to be taken into the BIER routing and forwarding information.
   Different tunnel type means different tunnel identifier in control
   plane for operation and maintenance.  For example, LDP tunnel means
   FEC object [RFC5036], RSVP-TE tunnel means Session Object [RFC3209],
   SR tunnel means SRGB block and the index object [RFC8660], and
   IP/UDP/GRE tunnel means the IP Endpoint/UDP port/GRE key object.
   Accordingly, network administrators need to debug these protocols and
   the various identifiers additionally in operation and
   troubleshooting.

2.3.  Anycast BIER-Label for Redundant ASBR deployment


   The following figure demonstrates an inter-domain network (of an
   administrative entity, e.g., a Service Provider's network), where
   redundant ASBRs is deployed.




























Xie & Duan                Expires 26 April 2022                 [Page 5]


Internet-Draft         BIER Deployment Challenges           October 2021


                                             +---------------------+
                                             |  Metro 2 (AS 65002) |
                                             | +-----+    +------+ |
                                     +---------| BR2a|    | PE2x |---RCV
                                    /        | +-----+    +------+ |
                                   /         | +-----+             |
                                  /  +---------| BR2b|             |
                                 /  /        | +-----+             |
                                /  /         +---------------------+
       +---------------------+ /  /             Bfr-id 1 to 256
       | Backbone (AS 65001) |/  /
       | +------+    +-----+ /  /
   SRC---| PE1x |    | BR1a| | /
       | +------+    +-----+ \/
       |             +-----+ /\
       |             | BR1b| | \
       |             +-----+ |  \
       +---------------------\   \               Bfr-id 257 to 512
            |                 \   \          +---------------------+
            |                  \   \         |  Metro 3 (AS 65003) |
            |                   \   \        | +-----+    +------+ |
            |                    \   +---------| BR3a|    | PE3x |---RCV
            |                     \          | +-----+    +------+ |
            |                      \         | +-----+             |
            |                       +----------| BR3b|             |
            |                                | +-----+             |
            |                                +---------------------+
            |                                                 |
            |<------------------ BIER Domain ---------------->|
            |<---------------- BIER Sub-Domain X------------->|
            |<------------------ MVPN services--------------->|

    BR = Border Router
    SRC = Multicast Source
    RCV = Multicast Receiver

           Figure 2: BIER Inter Domain Deployment Redundant

   In this figure, a common practice is to use anycast mechanism for
   service protection.  For example, BR1a and BR1b share a same
   identifier called anycast ID, where the anycast ID could be an IP
   address or an SRGB label [RFC8402].  Take unicast IP address as an
   example, PE1x send a BIER packet to Metro-2 or Metro-3 through the
   backbone border using the anycast IP address without awareness of the
   two nodes and its state.

   Usually such an anycast ID is a per node-pair allocation policy.




Xie & Duan                Expires 26 April 2022                 [Page 6]


Internet-Draft         BIER Deployment Challenges           October 2021


   In BIER-MPLS [RFC8296] design, the first 4 octets of BIER header is
   an MPLS label with the S bit set to 1 to indicate the bottom of the
   MPLS label stack.  It applies to a per-SD/BSL/SI allocation policy
   and thus defined as "locally significant" in section 2.1.1.1 of
   [RFC8296].

   If BR1a and BR1b want to deploy anycast mechanism for service
   protection, then SRGB label need to be used for BIER-MPLS label
   allocation on a Per-SD/BSL/SI base.  It is needed to use manual
   configuration on each node due to the shortage of SRGB label for
   automatic allocation.

   In addition, the BR1a and BR1b need to have the same (at least
   overlapped) SRGB label space to ensure the anycast BIER-MPLS value is
   absolutely equal.  Basically it does not require the SRGB label space
   to be absolutely equal in Segment Routing architecture [RFC8402], but
   in anycast Label case, it needs the absolute equivalence.  If BR1a
   and BR1b have different SRGB label space, the deployment of anycast
   BIER-MPLS scheme is still challengeable.

   Note that, Non-MPLS BIER encapsulation uses a different L2 protocol
   indication (typically Ethertype 0xAB37) to indicate the BIER header
   following the L2 header.  In such case, the first 4 octets of the
   BIER header is not an MPLS label encoding.  The 20-bit BIFT-id field
   of BIER header is wide enough for automaticlly mapping from SD/BSL/SI
   by using the method in [I-D.ietf-bier-non-mpls-bift-encoding].


2.4.  Overlapped BFR-id Assignment in Different Domains

   Intra-domain usually needs to consider a router to be added without
   much impact to existing routers.  Given this, the BFR-id assignment
   in Intra-domain scenario need to reserve some BFR-id space (holes) in
   the earlier range.

   Following is quoted from RFC8279 section 2 verbatim.

      The procedure for assigning a particular BFR-id to a particular
      BFR is outside the scope of this document.  However, it is
      RECOMMENDED that the BFR-ids for each sub-domain be assigned
      "densely" from the numbering space, as this will result in a more
      efficient encoding (see Section 3).  That is, if there are 256 or
      fewer BFERs, it is RECOMMENDED to assign all the BFR-ids from the
      range [1,256].  If there are more than 256 BFERs but less than
      512, it is RECOMMENDED to assign all the BFR-ids from the range
      [1,512], with as few "holes" as possible in the earlier range.
      However, in some deployments, it may be advantageous to depart
      from this recommendation; this is discussed further in Section 3.



Xie & Duan                Expires 26 April 2022                 [Page 7]


Internet-Draft         BIER Deployment Challenges           October 2021


   Following is quoted from RFC8279 section 3 verbatim.

      In order to minimize the number of copies that must be made of a
      given multicast packet, it is RECOMMENDED that the BFR-ids used in
      a given sub-domain be assigned "densely" (see Section 2) from the
      numbering space.  This will minimize the number of SIs that have
      to be used in that sub-domain.  However, depending upon the
      details of a particular deployment, other assignment methods may
      be more advantageous.  Suppose, for example, that in a certain
      deployment, every multicast flow is intended either for the "east
      coast" or for the "west coast", but not for both coasts.  In such
      a deployment, it would be advantageous to assign BFR-ids so that
      all the "west coast" BFR-ids fall into the same SI-subset and so
      that all the "east coast" BFR-ids fall into the same SI-subset.

   The BFR-id assignment recommendation above can be summarized as a
   hierarchical rule: A whole set/block (1-256 are a set for example) is
   assigned to a network-region (east coast or west coast) of a network,
   where some "holes" in the block are reserved to allow nodes adding in
   the future without crossing the border of a set.

   Inter-domain allows a domain to be added without much impact to
   existing domains.  It adds another level of constraints when
   considering the BFR-id assignment.  Extending the hierarchical rule,
   an overlapped BFR-id assignment scheme may be considered.  The
   following figure illustrates the scheme:


                                             +---------------------+
                                             |  Metro 2 (AS 65002) |
                                             | +-----+    +------+ |
                                       +-------| BR2 |    | PE2x |---RCV
                                     /       | +-----+    +------+ |
                                   /         +---------------------+
       +---------------------+   /             Bfr-id 1 to 1024
       | Backbone (AS 65001) | /
       | +------+    +-----+ /
   SRC---| PE1x |    | BR1 | |
       | +------+    +-----+ \
       +---------------------+ \                Bfr-id 1 to 1024
          Bfr-id 1 to 1024       \           +---------------------+
                                   \         |  Metro 3 (AS 65003) |
                                     \       | +-----+    +------+ |
                                       +-------| BR3 |    | PE3x |---RCV
                                             | +-----+    +------+ |
                                             +---------------------+

                Figure 3: Overlapped BFR-id Assignment



Xie & Duan                Expires 26 April 2022                 [Page 8]


Internet-Draft         BIER Deployment Challenges           October 2021


   In this scheme, each domain (Backbone, Metro-2, Metro-3) has a bigger
   BFR-id space (1 to 1024 for example), and within each domain, the
   hierarchical rule is further used to assign block of BFR-id (1 to 256
   for example) to a network-region, and holes in the block are reserved
   for each network-region to expend its nodes in the future.

   When a packet is transmitted from PE1x to PE2x, PE1x forwards it
   through a multi-hop crossing-domain tunnel from PE1x to BR2, and BR2
   does the rest BIER forwarding inside the domain.  Again, the multi-
   hop BFR-NBR support is an Inherent Requirement in this scheme.

   This scheme will provide a clear BFR-id assignment for inter-domain
   deployment, and extends the multicast deployment to beyond the 256
   set limitation by using the combination of Ingress-Replication and
   BIER.  Note the multiple Set is a combination of Ingress-Replication
   and BIER too.  Below is an example of such extensibility:



             R1a    R1b          R2a   R2b        R3a   R3b
          +---+-----+---+   +---+-----+---+   +---+-----+---+
          | (AS 65001)  |   | (AS 65002)  |   | (AS 65003)  |
       S1-+             |   |             |   |             |
     (src)|  (bfr-id    |   |  (bfr-id    |   |  (bfr-id    |
          | (1 to 1024) |   | (1 to 1024) |   | (1 to 1024) |
          +-------------+   +-------------+   +-------------+

          +-------------+     +--------+      +-------------+
     R90a-+ (AS 65090)  |    /           \    | (AS 65004)  +-R4a
          |             |   |   backbone  |   |             |
          |  (bfr-id    |   |(inter-conn) |   |  (bfr-id    |
     R90b-+ (1 to 1024) |    \           /    | (1 to 1024) +-R4b
          +-------------+      +-------+      +-------------+

          +-------------+   +-------------+   +-------------+
          | (AS 65089)  |   | (AS .....)  |   | (AS 65005)  |
          |             |   |             |   |             |
          |  (bfr-id    |   |  (bfr-id    |   |  (bfr-id    |
          | (1 to 1024) |   | (1 to 1024) |   | (1 to 1024) |
          +---+-----+---+   +---+-----+---+   +---+-----+---+
             R89a  R89b         Rna   Rnb         R5a   R5b


                  Figure 4: Overlapped BFR-id Assignment 2

   In this example, AS 65001, 65002, 65003, ..., 65090 each has an
   initial BFR-id scope 1 to 1024, totally 90K BFERs could be supported.
   Source PE S1 could send packet to R1a/R1b, R2a/R2b, R3a/R3b, ...,



Xie & Duan                Expires 26 April 2022                 [Page 9]


Internet-Draft         BIER Deployment Challenges           October 2021


   R90a/R90b using Ingress-Replication (e.g., to each domain) and BIER
   BitString encapsulation (e.g., to multiple nodes in a domain).  When
   the inter-connected ASs is increased to AS 65091, it could continue
   its extension linerly and the limitation is the replication
   capability on S1 (which could be hundreds or thousands on modern
   routers).

   However, BIER is usually deployed with Overlay service and procedure
   like MVPN [RFC8556].  Such service depends on the packet to have the
   "Source" information for Reverse-Path-Forwarding (RPF) check to
   ensure the packet is coming from the correct Upstream-Multicast-Hop
   (UMH, [RFC6513]).  In BIER architecture, the "Source" information in
   the packet is the "BFIR-id" field within the Context of BIER Sub-
   domain-id.  The BIER Sub-domain-id is further mapped from the BIFT-id
   field.  The BFIR-id (in the context of Sub-domain-id) need to be
   uniquely bound to an IP address of the BFIR node.  This makes the
   above assignment scheme unavailable due to the overlapped BFR-id
   assignment amoung multiple domains.  Note all the BFR-id demonstrated
   in the above diagram is in a single Sub-domain-id.

   The root cause of the challenge in this case is the use of BFR-id in
   both the "destinations" and "source" of a packet.  If these two
   things are separated, and the unique IP address of the BFIR node is
   used in the BIER encoding, this problem will be solved.

2.5.  Summary of Challenges in Inter-domain Deployment

   These are some of the challenges for BIER deployment in Inter-domain
   environment.  This section also reviews the BIER architecture for
   each challenge to try to figure out the gap that may need to consider
   in the future work.

      Challenge-1:

      Description: Protocol ambiguity for BIER advertisement in BGP.

      Gap: BIER architecture does not support multiple/mixed routing-
      underlay protocols for a single sub-domain.  BGP protocol
      extension for inter-domain BIER deployment is still unclear.

      Challenge-2:

      Description: Multi-hop BFR-NBR Support as an Inherent Requirement.

      Gap: BIER architecture is built on L2 and Multi-hop BFR-NBR
      support is optional.

      Challenge-3:



Xie & Duan                Expires 26 April 2022                [Page 10]


Internet-Draft         BIER Deployment Challenges           October 2021


      Description: Anycast BIER-Label for Redundant ASBR deployment.

      Gap: The locally-significant per-SD/BSL/SI BIER-label is opposite
      to the per-Node Anycast ID assignment.

      Challenge-4:

      Description: Overlapped BFR-id Assignment in Different Domains.

      Gap: BFR-id is coupled for both "destinations" and "source" in
      BIER architecture.  It makes BFR-id assignment constrained and
      lacking of extensibility.


3.  Challenges for Brownfield Deployment


3.1.  Adding Bypass tunnel for Intermediate Nodes

   Bypass tunnel is a mechanism in BIER for deployment in brownfield
   network where an intermediate router does not support BIER
   forwarding.  This is the same as Multi-hop BFR-NBR as previously
   described.  The function could be implemented by additional
   encapsulation of a "bypass tunnel" of any type.  The impact is in the
   "operation and maintenance" aspects, as shown in previously in this
   document.  The improvements to minimize the impact is to select a
   "default" type of bypass tunnel and mandate it in a standard, thus
   different implementations could interop at the bottom.

   For BIER-MPLS, the preferred bypass tunnel is highly likely to be
   MPLS LSP.  But still need the further step to mandate an option as
   "default" from SR, LDP or RSVP-TE.

   For Non-MPLS BIER, the MPLS LSP and the functions built on it (like
   TI-LFA) is no longer available.  The preferred bypass tunnel is
   highly likely to be an IP based tunnel.  For IPv4, an IPv4+UDP tunnel
   may be preferred due to the lack of ECMP in IP itself.  For IPv6, an
   IPv6 tunnel may be preferred.

   Such diversity of options make it challengeable toward implementation
   and operation, including the selection between BIER-MPLS and Non-MPLS
   BIER first, and further interop test, deployment, troubleshooting and
   so on in each case.








Xie & Duan                Expires 26 April 2022                [Page 11]


Internet-Draft         BIER Deployment Challenges           October 2021


3.2.  Removing (Popping) BIER Header for Edge Nodes

   Another typical challenge in brownfield network is the Edge router(s)
   not supporting BIER forwarding.  Some networks may have many edge
   routers connected to a few core routers, and it is highly possible
   there are some of these edge routers not supporting BIER.  Using
   Penultimate Hop Pop (PHP) or Penultimate Segment Pop (PSP, [RFC8986])
   on the upstream node of an edge router can increase the deployability
   of BIER greatly.

   Draft [I-D.ietf-bier-php] defines a method for BIER PHP.  An edge
   router not supporting BIER forwarding acts as a Pseudo-BFER node.  It
   has a valid BFR-id assignment, and it signals other router in a BIER
   domain (typical an IGP domain using IS-IS or OSPF) a "PHP request".
   When an upstream router has a BIER packet with the bit corresponding
   to the BFR-id of this pseudo-BFER set to 1, the BIER header of the
   BIER packet is removed, and the packet is then unicast to this
   pseudo-BFER.

   However, as is pointed in the document, penultimate hop popping the
   BIER header ahead of the pseudo-BFER means that, the BFIR-id or the
   source identifier in the BIER header is also lost.  RPF function
   depending on the source identifier is no longer available.  Note
   that, RPF function is a basic function in multicast, to solve the
   problem in UMH [RFC6513] changing scenario, Source Redundancy
   [RFC9026] scenario and so on.

   Another problem is that, BIER header has a "proto" field to indicate
   the payload that follows the BIER header.  It is a "BIER specific"
   Next header indication.  When the BIER header is popped, the next
   header indication will have to scatter to the preceding header.
   E.g., if the preceding header is a link-level Ethernet header, each
   "BIER proto" value need to have a Ether-Type.  If the preceding
   header is a "bypass tunnel" of IP/GRE/UDP type, each "BIER Proto"
   value need to have an IP Proto/GRE Proto/UDP Port.  A typical case is
   the "Echo Request" currently defined in [I-D.ietf-bier-ping] as BIER
   payload (using BIER Proto 5).  Using the BIER PHP, the BIER ping/
   trace will no longer be available.  Note that, some other functions
   like the BFD bootstrap may depend on the BIER ping/trace, and will
   suffer the same as a consequence.

   A possible way for solving these problems in PHP deployment is to
   expend another layer over BIER header.  For example, an IP header is
   followed as a shim layer in the lifecycle of a BIER packet from BFIR
   to BFER.  Thus, when the BIER header is popped, the BFER could still
   get the "source identifier" from the IP header.  Accordingly, the
   BIER ping, BIER bfd also need to build the upper-layer body after the
   IP header.



Xie & Duan                Expires 26 April 2022                [Page 12]


Internet-Draft         BIER Deployment Challenges           October 2021


   An alternative way is to use use an additional layer of header when
   popping the BIER header.  For example, the upstream router A get the
   "source identifier" from the BIER packet, and encapsulate the BIER
   payload with an additional IP header whose IP source is the "source
   identifier" of the BFIR node.  Thus when the pseudo-BFER receives the
   packet without BIER header can still get the source identifier
   necessary for RPF function and the like.  Of course, the IP proto
   should be able to identify the BIER payload as mentioned above.



3.3.  Summary of Challenges in Brownfield Deployment

   These are some of the challenges for BIER deployment in Brown-field
   network.

      Challenge-5:

      Description: Adding Bypass tunnel on top of BIER header for
      Intermediate nodes.

      Gap: Select a "default" type of bypass tunnel to help the interop
      between different implementations.

      Challenge-6:

      Description: Removing (Popping) the BIER header for Edge nodes.

      Gap: Not losing basic functions like MVPN RPF/UMH, Source
      Redundancy, Ping/Trace when possible, using additional
      encapsulation either from BFIR or from the popping BFR node.

   It can be seen that, the BIER architecture [RFC8279] is built on L2
   and thus is dependent completely on additional mechanisms for
   brownfield deployment.  The mechanisms include: Some kind of routing
   mechanism (IP or LSP are both included in this terminology) is needed
   for multi-hop BIER neighboring.  Additional identifier of a BFIR node
   is needed for MVPN RPF and UMH-Redundancy functions, and additional
   Next Header identifier is needed for BIER payload indicating when
   popping BIER header.

4.  Security Considerations

   This document introduces no new security considerations beyond those
   already specified in [RFC8279], [RFC8296], [RFC8556].






Xie & Duan                Expires 26 April 2022                [Page 13]


Internet-Draft         BIER Deployment Challenges           October 2021


5.  IANA Considerations

   This document contains no actions for IANA.


6.  Acknowledgements

   Thanks Xuesong Geng for the review of this document.


7.  Normative References

   [I-D.ietf-bier-idr-extensions]
              Xu, X., Chen, M., Patel, K., Wijnands, I., and A.
              Przygienda, "BGP Extensions for BIER", Work in Progress,
              Internet-Draft, draft-ietf-bier-idr-extensions-07, 6
              September 2019, <https://www.ietf.org/archive/id/draft-
              ietf-bier-idr-extensions-07.txt>.

   [I-D.ietf-bier-non-mpls-bift-encoding]
              Wijnands, I., Mishra, M., Xu, X., and H. Bidgoli, "An
              Optional Encoding of the BIFT-id Field in the non-MPLS
              BIER Encapsulation", Work in Progress, Internet-Draft,
              draft-ietf-bier-non-mpls-bift-encoding-04, 30 May 2021,
              <https://www.ietf.org/archive/id/draft-ietf-bier-non-mpls-
              bift-encoding-04.txt>.

   [I-D.ietf-bier-php]
              Zhang, Z., "BIER Penultimate Hop Popping", Work in
              Progress, Internet-Draft, draft-ietf-bier-php-06, 24
              August 2020, <https://www.ietf.org/archive/id/draft-ietf-
              bier-php-06.txt>.

   [I-D.ietf-bier-ping]
              Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M.,
              and G. Mirsky, "BIER Ping and Trace", Work in Progress,
              Internet-Draft, draft-ietf-bier-ping-07, 11 May 2020,
              <https://www.ietf.org/archive/id/draft-ietf-bier-ping-
              07.txt>.

   [I-D.ietf-bier-prefix-redistribute]
              Zhang, Z., Wu, B., Zhang, Z., Wijnands, I., and Y. Liu,
              "BIER Prefix Redistribute", Work in Progress, Internet-
              Draft, draft-ietf-bier-prefix-redistribute-00, 4 August
              2020, <https://www.ietf.org/archive/id/draft-ietf-bier-
              prefix-redistribute-00.txt>.





Xie & Duan                Expires 26 April 2022                [Page 14]


Internet-Draft         BIER Deployment Challenges           October 2021


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
              <https://www.rfc-editor.org/info/rfc3209>.

   [RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
              "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
              October 2007, <https://www.rfc-editor.org/info/rfc5036>.

   [RFC6513]  Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
              BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
              2012, <https://www.rfc-editor.org/info/rfc6513>.

   [RFC6514]  Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
              Encodings and Procedures for Multicast in MPLS/BGP IP
              VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
              <https://www.rfc-editor.org/info/rfc6514>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8279]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
              Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
              Explicit Replication (BIER)", RFC 8279,
              DOI 10.17487/RFC8279, November 2017,
              <https://www.rfc-editor.org/info/rfc8279>.

   [RFC8296]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
              Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
              for Bit Index Explicit Replication (BIER) in MPLS and Non-
              MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
              2018, <https://www.rfc-editor.org/info/rfc8296>.

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

   [RFC8556]  Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S.,
              and A. Dolganow, "Multicast VPN Using Bit Index Explicit
              Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April
              2019, <https://www.rfc-editor.org/info/rfc8556>.



Xie & Duan                Expires 26 April 2022                [Page 15]


Internet-Draft         BIER Deployment Challenges           October 2021


   [RFC8660]  Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing with the MPLS Data Plane", RFC 8660,
              DOI 10.17487/RFC8660, December 2019,
              <https://www.rfc-editor.org/info/rfc8660>.

   [RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
              D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
              (SRv6) Network Programming", RFC 8986,
              DOI 10.17487/RFC8986, February 2021,
              <https://www.rfc-editor.org/info/rfc8986>.

   [RFC9026]  Morin, T., Ed., Kebler, R., Ed., and G. Mirsky, Ed.,
              "Multicast VPN Fast Upstream Failover", RFC 9026,
              DOI 10.17487/RFC9026, April 2021,
              <https://www.rfc-editor.org/info/rfc9026>.

Authors' Addresses

   Jingrong Xie
   Huawei Technologies

   Email: xiejingrong@huawei.com


   Fanghong Duan
   Huawei Technologies

   Email: duanfanghong@huawei.com






















Xie & Duan                Expires 26 April 2022                [Page 16]