Internet DRAFT - draft-zzhang-bier-anycast

draft-zzhang-bier-anycast







BIER Working Group                                              Z. Zhang
Internet-Draft                                          Juniper Networks
Updates: 8279, 8401, 8444 (if approved)                      I. Wijnands
Intended status: Standards Track                                  Arrcus
Expires: 9 August 2024                                          Z. Zhang
                                                                     ZTE
                                                               M. Mishra
                                                           Cisco Systems
                                                                 H. Chen
                                                               Futurewei
                                                         6 February 2024


                           BIER with Anycast
                      draft-zzhang-bier-anycast-03

Abstract

   BIER architecture currently does not support anycast, in that each
   BIER Forwarding Router (BFR) has its own unique BFR-prefix and BFR-
   ID.  BIER signaling protocols also check if there are duplicate BFR-
   IDs advertised.  This document discusses and specifies anycast
   support with BIER.  It updates RFC 8279, RFC 8401 and RFC 8444.

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 9 August 2024.

Copyright Notice

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






Zhang, et al.             Expires 9 August 2024                 [Page 1]

Internet-Draft                BIER-anycast                 February 2024


   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 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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Specification . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   4.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   BIER architecture currently does not support anycast, in that each
   BIER Forwarding Router (BFR) has its own unique BFR-prefix and BFR-
   ID.  BIER signaling protocols [RFC8401] [RFC8444] require the
   checking for, and logging of duplicate BFR-IDs in advertisements, and
   require duplicate BFR-IDs be treated as zero, i.e., those BFRs
   advertising duplicate BFR-IDs will not be treated as BIER Forwarding
   Ingress Routers (BFIR) or BIER Forwarding Egress Routers (BFER).

   However, anycast is widely used in networks and it is desired and
   feasiable to support anycast addresses as BFR-prefixes, especially
   for egress protection purposes.

   In a simple egress protection scenario, a flow overlay node N1
   connects to BFER1 and BFER2 that advertise the same anycast BFR-
   prefix with the same BFR-ID.  For traffic that node N1 needs to
   receive, a BFIR can set the bit corresponding to the BFR-ID in the
   BitString.  Either BFER1 or BFER2 will receive the traffic and
   deliver to N1 after removing the BIER header.  If it is desired for
   BFER1 to be the primary while BFER2 to be the backup, then BFER2 can
   advertise with a higher cost.

                            +-----+
   +----+                   |BFER1|_________+--+
   |BFIR|                   +-----+        /|N1|
   +----+                   +-----+_______/ +--+
                            |BFER2|
                            +-----+





Zhang, et al.             Expires 9 August 2024                 [Page 2]

Internet-Draft                BIER-anycast                 February 2024


   In a more complicated scenario, a flow overlay node N1 may connect to
   BFER1 and BFER2, while another node N2 may connect to BFER2 and
   BFER3.  In this case, BFER1 and BFER2 need to advertise an anycast
   BFR-prefix1 while BFER2 and BFER3 need to advertise another anycast
   BFR-prefix2.

                            +-----+
                            |BFER1|_________+--+
                            +-----+        /|N1|
    +----+                  +-----+_______/ +--+
    |BFIR|                  |BFER2|_________+--+
    +----+                  +-----+        /|N2|
                            +-----+_______/ +--+
                            |BFER3|
                            +-----+

   In this scenario, BFER2 advertises two anycast BFR-prefixes and two
   corresponding BFR-IDs.  Its BIFTs will have two entries for
   decapsulation with local forwarding.  A packet arriving on BFER2 may
   have both bits set (for the two BFR-IDs corresponding to the two
   anycast BFR-prefixes), or two copies of the same packet may arrive on
   BFER2 (each with a different bit of the two bits being set).  In both
   cases, the flow overlay needs to make sure that N1 receives a copy
   corresponding to one bit while N2 receives a copy corresponding to
   the other bit.  Flow overlay procedures that may be used/needed for
   various protection scenarios will be specified in a separate
   document.

   Since each unique BFR-prefix needs a unique BFR-ID that takes one bit
   position in the BitString, a network designer should minimize the
   number of anycast BFR-prefixes.  Limiting egress protection to the
   first scenario where flow overlay nodes are uniformly connected is
   recommended.

   In both example scenarios above, there is no need for the BFERs to
   advertise a non-anycast BFR-prefixes.  Of course, there may be
   scenarios where both anycast and non-anycast BFR-prefixes are
   advertised by a BFER.













Zhang, et al.             Expires 9 August 2024                 [Page 3]

Internet-Draft                BIER-anycast                 February 2024


   All BFRs need to allow a non-zero BFR-ID advertised with the same
   BFR-prefix from different BFRs.  An operator needs to ensure that all
   BFRs allow it when the anycast functionality is needed.  At the
   protocol level, there is no need to signal a BFR's capability of
   allowing this.  Signaling the capability will not help backward
   compatiblity, but existence of BFRs not supporting the enhanced
   detection procedure will not cause issues other than that the BFERs
   with anycast BFR-IDs may not receive traffic.  The operator needs to
   upgrade those BFRs if the anycast functionaly is desired, and the
   required error reporting from those BFRs can help the operator
   identify the problem.

2.  Specification

   This document updates [RFC8279], [RFC8401], [RFC8444],
   [I-D.ietf-bier-ospfv3-extensions],
   [I-D.ietf-bier-lsr-non-mpls-extensions] and
   [I-D.ietf-bier-idr-extensions] to allow BFERs advertise anycast
   addresses as BFR-prefixes.

   When a BIER signaling protocol checks for and logs duplicated BFR-IDs
   in routing advertisements, only the same BFR-ID advertised with
   different BFR-prefixes is considered as duplicate.  The same BFR-
   prefix MAY be advertised by different BFRs, but they MUST all
   advertise the same BFR-ID.

   It is RECOMMENDED that only BFERs advertises anycast BFR-prefixes.  A
   transit BFR (with BFR-ID 0) SHOULD NOT advertise anycast BFR-
   prefixes, though otherwise the only consequence is additional useless
   advertisement.

   A BFER MAY advertise one non-anycast BFR-prefix and MAY advertise one
   or more anycast BFR-prefixes.  Multiple BFERs MAY advertise the same
   anycast BFR-prefix.  The same anycast BIER-prefix MUST be advertised
   with the same non-zero BFR-ID.

   Each BFR-prefix in a BIER sub-domain MUST have a unique BFR-ID if it
   is not zero.

   A BFER may be a BFIR at the same time.  If a BFIR advertises one or
   more anycast BFR-prefixes, it MUST uses the BFD-ID associated with
   its non-anycast BFR-prefix in the BIER header that it imposes, unless
   it is ok to associate the packet with any of the BFIRs having the
   same anycast BFR-prefix whose BFR-ID is used in the BIER header.







Zhang, et al.             Expires 9 August 2024                 [Page 4]

Internet-Draft                BIER-anycast                 February 2024


3.  Security Considerations

   This document does not introduce any new security concerns besides
   what has been discussed in [RFC8279] or what is associated with
   anycast.

4.  Normative References

   [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-
              10, 13 June 2023, <https://datatracker.ietf.org/doc/html/
              draft-ietf-bier-idr-extensions-10>.

   [I-D.ietf-bier-lsr-non-mpls-extensions]
              Dhanaraj, S., Yan, G., Wijnands, I., Psenak, P., Zhang, Z.
              J., and J. Xie, "LSR Extensions for BIER non-MPLS
              Encapsulation", Work in Progress, Internet-Draft, draft-
              ietf-bier-lsr-non-mpls-extensions-02, 27 January 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-bier-
              lsr-non-mpls-extensions-02>.

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

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





Zhang, et al.             Expires 9 August 2024                 [Page 5]

Internet-Draft                BIER-anycast                 February 2024


Authors' Addresses

   Zhaohui (Jeffrey) Zhang
   Juniper Networks
   Email: zzhang@juniper.net


   IJsbrand Wijnands
   Arrcus
   Email: ice@braindump.be


   Zheng Zhang
   ZTE
   Email: zhang.zhen@zte.com.cn


   Mankamana Mishra
   Cisco Systems
   Email: mankamis@cisco.com


   Huaimo Chen
   Futurewei
   Email: Huaimo.chen@futurewei.com


























Zhang, et al.             Expires 9 August 2024                 [Page 6]