Tethering A BIER Router To A BIER Incapable Router
draft-ietf-bier-tether-06

BIER                                                            Z. Zhang
Internet-Draft                                          Juniper Networks
Intended status: Standards Track                               N. Warnke
Expires: 30 March 2025                                  Deutsche Telekom
                                                             I. Wijnands
                                                                  Arrcus
                                                              D. Awduche
                                                                 Verizon
                                                       26 September 2024

           Tethering A BIER Router To A BIER Incapable Router
                       draft-ietf-bier-tether-06

Abstract

   This document specifies optional enhancements to optimize the support
   of Bit Index Explicit Replication (BIER) incapable routers in a BIER
   domain by attaching (tethering) a BIER router to a BIER incapable
   router, including procedures and ISIS/OSPF/BGP signaling extensions.

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 30 March 2025.

Copyright Notice

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

   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

Zhang, et al.             Expires 30 March 2025                 [Page 1]
Internet-Draft                 bier-tether                September 2024

   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Additional Considerations . . . . . . . . . . . . . . . . . .   4
   4.  Specification . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  IGP Signaling and Calculation . . . . . . . . . . . . . .   6
     4.2.  BGP Signaling . . . . . . . . . . . . . . . . . . . . . .   9
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   6.  Operational Considerations  . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  10
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Terminology

   Familiarity with BIER {{!RFC8279}} architecture, protocols and
   procedures is assumed.  Some terminologies are listed below for
   convenience.

   BIER: Bit Indexed Explicit Replication

   BFR: BIER Forwarding Router

   BFER: BIER Forwarding Egress Router

   BFR-prefix: Each BFR is assigned a single "BFR-prefix" for each sub-
   domain to which it belongs.  It is recommended that the BFR-prefix be
   a loopback address of the BFR.

2.  Introduction

   Consider the scenario in Figure 1 where router X does not support
   BIER.  BFER1..n and BFR1..n are BIER capable - implied by their
   names.

Zhang, et al.             Expires 30 March 2025                 [Page 2]
Internet-Draft                 bier-tether                September 2024

                              ------ BFR2 ------- BFER2
                             /
      BFER1 ---  BFR1 ---- X ------- BFR3 ------- BFER3
                             .........
                             \
                              ------ BFRn ------- BFERn

             Figure 1: Deployment with a BIER incapable router

   For BFR1 to forward BIER traffic towards BFR2...BFRn, it needs to
   tunnel individual copies through X.  This degrades to "ingress"
   replication to those BFRs.  If X's connections to BFRs are long
   distance or bandwidth limited, and n is large, it becomes very
   inefficient.

   A solution to the inefficient tunneling is to attach (tether) a BFRx
   to X as depicted in Figure 2:

                              ------ BFR2 ------- BFER2
                             /
      BFER1 ---  BFR1 ---- X ------- BFR3 ------- BFER3
                          / \  .........
                         /   \
                      BFRx    ------ BFRn ------- BFERn

                          Figure 2: Tethered BFRx

   Instead of BFR1 tunneling to BFR2, ..., BFRn directly, BFR1 will
   tunnel BIER packets to BFRx, which will then tunnel to BFR2, ...,
   BFRn.  For the ingress replication from BFRx to BFR2..n to be
   acceptable, the bandwidth between BFRx and X needs to be adequate.
   That should not be a problem with local and fat pipes between them.

   For BFR1 to tunnel BIER packets to BFRx, the BFR1-BFRx tunnel needs
   to be announced in Interior Gateway Protocol (IGP) as a forwarding
   adjacency so that BFRx will appear on the Shortest Path First (SPF)
   tree.  This needs to happen in a BIER specific topology so that
   unicast traffic would not be tunneled to BFRx.  Obviously this is
   operationally cumbersome.

   Section 6.9 of the BIER architecture specification [RFC8279]
   delineates a methodology for tunneling BIER packets through incapable
   routers without the need to explicitly announce tunnels.
   Nonetheless, this method is inapplicable in the current context, as
   BFRx is not a node in the SPF tree rooted at BFR1

Zhang, et al.             Expires 30 March 2025                 [Page 3]
Internet-Draft                 bier-tether                September 2024

   This document specifies the tethering solution that addresses the
   above mentioned problems.  In the case of IGP, BFRx could advertise
   that it is X's helper and other BFRs will use BFRx (instead of X's
   children on the SPF tree) to replace X during its post-SPF processing
   as described in section 6.9 of the BIER architecture specification
   [RFC8279].  X does not need to be BIER-aware at all.  In the case of
   BGP, X does need to be "slightly BIER-aware" in the control plane, as
   described in Section 4.2.

3.  Additional Considerations

   While the scenario in Figure 2 has a direct connection between BFRx
   and X, other network configurations are possible.  As long as BIER
   packets can be tunneled to BFRx without requiring X to do BIER
   forwarding and BFRx will not send them back to X's upstream BFR, the
   tethering solution works.

   Additionally, the helper BFRx can be a transit helper, i.e., it has
   other connections (instead of being a stub helper that is only
   connected to X), as long as BFRx won't send BIER packets tunneled to
   it back to the tunnel ingress.  Figure 3 shows an example topology:

                                 ------ BFR2 ------- BFER2
                                /
         BFER1 ---  BFR1 ---- X ------- BFR3 ------- BFER3
                              |
                              |
                            BFRx ------ BFR4 ------- BFER4
                                \
                                 ------ BFR5 ------- BFER5

                      Figure 3: A Safe Transit Helper

   In the above example, BFR1 can tunnel one copy to BFRx, which will
   tunnel to BFR2/BFR3 and send natively to BFR4/BFR5 respectively.

   In the example of Figure 4, there is a connection between BFR1 and
   BFRx.  If the link metrics are all 1 on the three sides of
   BFR1-X-BFRx triangle, a loop won't happen but if the BFRx-X metric is
   3 while the other two sides of the triangle have metric 1 then BFRx
   will send BIER packets tunneled to it from BFR1 back to BFR1, causing
   a loop.

Zhang, et al.             Expires 30 March 2025                 [Page 4]
Internet-Draft                 bier-tether                September 2024

                              ------ BFR2 ------- BFER2
                             /
      BFER1 ---  BFR1 ---- X ------- BFR3 ------- BFER3
                   \      / \  .........
                    \    /   \
                      BFRx    ------ BFRn ------- BFERn

                   Figure 4: Potential looping situation

   This can easily be prevented if BFR1 does an SPF calculation with the
   helper BFRx as the root.  For any BFERn reached via X from BFR1, if
   BFRx's SPF path to BFERn includes BFR1 then BFR1 must not use the
   helper.  Instead, BFR1 must directly tunnel packets for BFERn to X's
   BFR (grand-)child on BFR1's SPF path to BFERn, per section 6.9 of
   [RFC8279].

   Notice that this SPF calculation on BFR1 with BFRx as the root is not
   different from the SPF done for a neighbor as part of Loop-Free
   Alternate (LFA) calculation.  In fact, BFR1 tunneling BIER packets to
   X's helper is not different from tunneling unicast packets to a TI-
   LFA backup.

   Also notice that, instead of a dedicated helper BFRx, any one or
   multiple ones of BFR2..n can also be the helper (as long as the
   connection between that BFR and X has enough bandwidth for
   replication to multiple helpers through X).  To allow multiple
   helpers to help the same non-BFR, the "I am X's helper" advertisement
   carries a priority.  BFR1 will choose the helper advertising the
   highest priority among those satisfying the loop-free condition
   described above.  When there are multiple helpers advertising the
   same priority and satisfying the loop-free condition, any one or
   multiple ones could be used solely at the discretion of BFR1.
   However, if multiple ones are used, it means that multiple copies may
   be tunneled through X.

   The tethering solution works for the situation in Figure 5 as well,
   where a helper BFRxy helps two different non-BFRs X and Y.

Zhang, et al.             Expires 30 March 2025                 [Page 5]
Internet-Draft                 bier-tether                September 2024

                              ----- BFR2 ------- BFER2
                            /
                          X ------- BFR3 ------- BFER3
                        / | \
                      /    \  ----- BFR4 ------- BFER4
                    /       \
          BFER1 -- BFR1      BFRxy ------------- BFERxy
                    \       /
                      \    /  ----- BFR5 ------- BFER5
                        \ | /
                          Y ------- BFR6 ------- BFER6
                            \
                              ----- BFRn ------- BFERn

                  Figure 5: One Helper for multiple helped

4.  Specification

   The procedures in this document apply when a BFRx is tethered to a
   BIER incapable router X as X's helper for BIER forwarding.

   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.

4.1.  IGP Signaling and Calculation

   Suppose that the BIER domain uses BIER signaling extensions to ISIS
   [RFC8401] or OSPF [RFC8444] [draft-ietf-bier-ospfv3-extensions].  A
   helper node (BFRx) MUST advertise a BIER Helped Node sub-sub-TLVs in
   the BIER Info sub-TLV in the case of ISIS or a BIER Helped Node sub-
   TLV in the BIER sub-TLV in the case of OSPFv2/OSPFv3:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Type       |   Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | List of <System-ID, Priority> for the Helped Nodes (variable) ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 6: ISIS BIER Helped Node sub-sub-TLV

Zhang, et al.             Expires 30 March 2025                 [Page 6]
Internet-Draft                 bier-tether                September 2024

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Type       |   Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | List of <Router-ID, Priority> for the Helped Nodes (variable) ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 7: OSPF BIER Helped Node sub-TLV

   The Type is TBD1 in the case of ISIS, TBD2 in the case of OSPFv2, or
   TBD3 in the case of OSPFv3, to be assigned by IANA.

   In the case of ISIS, the Value field is a list of <6-octet ISIS
   System-ID, 1-octet Priority> tuples, one for each helped node.  The
   number of tuples is derived from the Length field of the sub-sub-TLV.

   In the case of OSPFv2 or OSPFv3, the Value field is a list of
   <4-octet OSPF Router-ID, 1-octet Priority> tuples, one for each
   helped node.  The number of tuples is derived from the Length field
   of the sub-TLV.

   When there are more than one helper nodes for a helped non-BFR node,
   the helper advertising a higher priority MUST be preferred.  If there
   are multiple helpers advertising the same priority, ECMP through
   those equal-priority helpers MAY be used.

   The post-SPF processing procedures in Section 6.9 of the BIER
   architecture specification [RFC8279] are modified as follows for BIER
   tethering purpose.  Note that, BFR-B refers to the calculating node
   in Section 6.9 of [RFC8279].

   (1)  BFR-B looks in turn at each of its child nodes on the BIER-SPF
        tree.

   (2)  If one of the child nodes, say X, does not support BIER, BFR-B
        removes X from the tree.  The child nodes of X that has just
        been removed are then re-parented on the tree, so that BFR-B now
        becomes their parent.  Each child of X that is re-parented, say
        Cx, maintains an ordered list of nodes and X is added to the
        tail of that list.  It is possible that X itself may be a re-
        parented child and has a non-empty list already.  In that case,
        X's list is copied to Cx, and X is added to the tail of the
        list.

Zhang, et al.             Expires 30 March 2025                 [Page 7]
Internet-Draft                 bier-tether                September 2024

   (3)  BFR-B then continues to look at each of its child nodes,
        including any nodes that have been re-parented to BFR-B as a
        result of the previous step.

   At the end of the above iterations, BFR-B's children on the BIER-SPF
   tree will all be BFRs.  Some of them may be non-adjacent (not
   directly connected to BFR-B) and BFR-B could just tunnel to them as
   described in Section 6.9 of [RFC8279], i.e., without the tethering
   benefit.

   A non-adjacent child has a non-empty list built in Step 2, which is a
   list of BIER-incapable nodes between BFR-B and the child.  That list
   is used for the tethering purposes as follows.

   For each non-adjacent child (with a non-empty list), the following
   additional procedures are performed:

   *  Starting with the first node in the ordered list of incapable
      nodes, say N1, check if there is one or more helper nodes for N1.
      If not, go to the next node in the list.

   *  Order all the helper nodes of N1 in descending order based on the
      numeric values of priority and BIER prefix.  Starting with the
      first one, say H1, check if BFR-B could use H1 as an LFA next hop
      to reach the child.  If yes, tunneling to H1 (which is a helper to
      a node upstream of the child) instead of to the child itself can
      be used and the procedure stops for the child unless there is
      another helper in the list with the same priority (in which case
      ECMP could be used).  Otherwise, go to the next helper in order
      and repeat.

   *  If none of the helper nodes of N1 can be used, go to the next node
      in the list of incapable nodes and repeat.

   If the above procedure finishes without finding any usable helper,
   then direct tunneling to the child has to be used.  The problem
   posited in Section 2 is not solved for this child, but nothing is
   lost and forwarding continues as if there were no helpers available.

   Notice that only the building and use of the list for the non-
   adjacent children are the extensions to the original Section 6.9
   procedures.

Zhang, et al.             Expires 30 March 2025                 [Page 8]
Internet-Draft                 bier-tether                September 2024

4.2.  BGP Signaling

   Suppose that the BIER domain uses BGP signaling
   [I-D.ietf-bier-idr-extensions] instead of IGP.  BFR1..n advertise
   BFR-prefixes that are reachable through them, with BIER Path
   Attributes (BPA) attached.  There are two situations regarding X's
   involvement:

   (1)  X does not participate in BGP peering at all

   (2)  X re-advertises the BFR-prefixes but it does not update the BPA.

   In either case, the BFR1..n will tunnel BIER packets directly to each
   other.  This may not be desired as explained earlier.

   To make BFR1 tunnel one copy to BFRx which then tunnel to BFR2...n,
   the following MUST be done in the case of BGP (no new signaling is
   needed):

   *  Configure BGP sessions between X and BFR1..n and BFRx.

   *  BFRx advertises its own BFR-prefix with BPA to X, and sets the
      BIER Nexthop to itself.

   *  When X re-advertises BFR-prefixes to its helper BFRx, it does not
      change the BPA.  This allows BFRx to tunnel BIER packets to
      BFR1..n.

   *  When X re-advertises BFR-prefixes to BFR1..n, it replaces the BPA
      with the one attached to BFRx's BFR-prefix.  Notice that if X
      supported BIER forwarding, it'd re-advertise the BFR-prefixes with
      its own BPA so that BFR1..n would send BIER traffic to itself.
      Since X does not BIER forwarding, using BFRx's BPA instead allows
      BFR1..n to tunnel BFRx.

5.  Security Considerations

   This specification does not introduce additional security concerns
   beyond those already discussed in BIER architecture and OSPF/ISIS/BGP
   extensions for BIER signaling.

6.  Operational Considerations

   Section 2 explains the motivation and benefits of BIER tethering.
   Configuring a BIER helper is simple and other BFRs can automatically
   tunnel relevant BIER packets to the helper nodes.  Tethering a stub
   helper to a helped node is most straightforward (Figure 2).  Other
   deployment scenarios are also possible and discussed in Section 3.

Zhang, et al.             Expires 30 March 2025                 [Page 9]
Internet-Draft                 bier-tether                September 2024

7.  IANA Considerations

   This document requests a new sub-sub-TLV type value from the "Sub-
   sub-TLVs for BIER Info Sub-TLV" registry in the "IS-IS TLV
   Codepoints" registry:

        Type    Name
        ----    ----
        TBD1    BIER Helped Node

   This document requests a new sub-TLV type value from the OSPFv2
   Extended Prefix TLV Sub-TLV registry:

        Type    Name
        ----    ----
        TBD2    BIER Helped Node

   This document also requests a new sub-TLV type value from the OSPFv3
   Extended-LSA Sub-TLVs registry:

        Type    Name
        ----    ----
        TBD3    BIER Helped Node

8.  Contributors

   The following also contributed to this document.

      Zheng(Sandy) Zhang
      ZTE Corporation

      EMail: zzhang_ietf@hotmail.com

      Hooman Bidgoli
      Nokia
      EMail: hooman.bidgoli@nokia.com

9.  Acknowledgements

   The author wants to thank Eric Rosen and Antonie Przygienda for their
   review, comments and suggestions.

10.  Normative References

Zhang, et al.             Expires 30 March 2025                [Page 10]
Internet-Draft                 bier-tether                September 2024

   [I-D.ietf-bier-idr-extensions]
              Xu, X., Chen, M., Patel, K., Wijnands, I., Przygienda, T.,
              and Z. J. Zhang, "BGP Extensions for BIER", Work in
              Progress, Internet-Draft, draft-ietf-bier-idr-extensions-
              11, 3 June 2024, <https://datatracker.ietf.org/doc/html/
              draft-ietf-bier-idr-extensions-11>.

   [I-D.ietf-bier-ospfv3-extensions]
              Psenak, P., Nainar, N. K., and I. Wijnands, "OSPFv3
              Extensions for BIER", Work in Progress, Internet-Draft,
              draft-ietf-bier-ospfv3-extensions-07, 1 December 2022,
              <https://datatracker.ietf.org/doc/html/draft-ietf-bier-
              ospfv3-extensions-07>.

   [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>.

   [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>.

   [RFC8401]  Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z.
              Zhang, "Bit Index Explicit Replication (BIER) Support via
              IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018,
              <https://www.rfc-editor.org/info/rfc8401>.

   [RFC8444]  Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A.,
              Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2
              Extensions for Bit Index Explicit Replication (BIER)",
              RFC 8444, DOI 10.17487/RFC8444, November 2018,
              <https://www.rfc-editor.org/info/rfc8444>.

Authors' Addresses

   Zhaohui Zhang
   Juniper Networks
   Email: zzhang@juniper.net

Zhang, et al.             Expires 30 March 2025                [Page 11]
Internet-Draft                 bier-tether                September 2024

   Nils Warnke
   Deutsche Telekom
   Email: Nils.Warnke@telekom.de

   IJsbrand Wijnands
   Arrcus
   Email: ice@braindump.be

   Daniel Awduche
   Verizon
   Email: daniel.awduche@verizon.com

Zhang, et al.             Expires 30 March 2025                [Page 12]