Network Working Group                                            J. Dong
Internet-Draft                                       Huawei Technologies
Intended status: Standards Track                                   Z. Li
Expires: January 13, 2022                                   China Mobile
                                                                   L. Ou
                                                                  Y. Luo
                                                  China Telcom Co., Ltd.
                                                           July 12, 2021


     BGP FlowSpec Extensions for Large Scale Prefix based Steering
          draft-dong-idr-flowspec-scalable-prefix-steering-01

Abstract

   This document describes a mechanism to use BGP FlowSpec RFC5575 as a
   scalable way of distributing prefix based traffic steering policies.
   The necessary extensions to BGP are also specified.

Requirements Language

   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 RFC 2119 [RFC2119].

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 January 13, 2022.

Copyright Notice

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





Dong, et al.            Expires January 13, 2022                [Page 1]


Internet-DraftBGP-FS for Large Scale Prefix Based Steering     July 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.  Typical Scenario of Prefix based Traffic Steering . . . . . .   3
   3.  Proposed BGP Extensions . . . . . . . . . . . . . . . . . . .   4
     3.1.  New Wide Community Atom . . . . . . . . . . . . . . . . .   4
     3.2.  New Wide BGP Community  . . . . . . . . . . . . . . . . .   5
   4.  Operational Procedures  . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  Contributing Authors  . . . . . . . . . . . . . . . . . . . .   7
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Dynamic traffic steering becomes more and more popular in operator
   networks.  It is desirable that an automatic and scalable mechanism
   can be provided to dynamically deploy such policies to network
   devices.  BGP FlowSpec [RFC8955] provides a flexible mechanism to
   specify the matching rules and the corresponding actions for specific
   traffic.  Due to the flexibility of BGP FlowSpec, the number of
   flowspec filtering entries supported in hardware is usually limited,
   which is suitable for a small number of complicated traffic matching
   and manipulation policies.  In some operator networks, there are
   requirements of dynamically deploying a large amount of destination
   prefix based traffic steering policies, thus some scalable mechanism
   for large scale prefix based traffic steering policy is needed.

   One possible option is that the controller advertises the destination
   prefix based steering policy as normal IP routes directly to the
   network devices.  Although this seems straightforward, it is
   difficult to determine the interaction results of the steering routes
   and the existing routes in the devices, and may have unexpected
   impacts to the whole network.





Dong, et al.            Expires January 13, 2022                [Page 2]


Internet-DraftBGP-FS for Large Scale Prefix Based Steering     July 2021


   Another option is that the controller advertises the destination
   prefix based steering policy as BGP FlowSpec routes to the network
   devices.  Instead of installing these routes as the BGP FlowSpec
   filtering entries, the network devices are instructed by the
   controller to download the prefix based steering policies to their
   Forwarding Information Base (FIB), so that the number of prefix based
   steering policy supported is not limited by the number of BGP
   FlowSpec filtering entries.

   This document proposes to use the mechanism in the second option, and
   specifies the required extensions to BGP protocol.

2.  Typical Scenario of Prefix based Traffic Steering

   In ISP networks, usually there are multiple paths to a particular
   destination.  The path with better QoS characteristics such as
   latency, loss, jitter, etc., is preferred.  Since these QoS
   characteristics change from time to time, the decision of path
   selection also needs to be changed accordingly.

   Figure 1 shows a typical scenario of prefix based traffic steering in
   inter-domain ISP networks.  As shown in the figure, there are two
   transit nodes from AS-1 to the destination Prefix-1 in AS-4, saying
   transit node M in AS-2 and transit node N in AS-3.  In normal state,
   traffic from AS-1 to Prefix-1 goes through transit node M.  While
   transit node N would be preferred when performance degradation
   happens on transit node M.  In that case, traffic should be steered
   to go through transit node N instead.  According to the real time
   network performance condition, the traffic steering policy needs to
   be changed dynamically.  Thus the operator of AS-1 expects an
   efficient and convenient mechanism for steering the traffic to
   different transit nodes.



















Dong, et al.            Expires January 13, 2022                [Page 3]


Internet-DraftBGP-FS for Large Scale Prefix Based Steering     July 2021


       ********************************
       *                 +----------+ *
       *         AS-1    |  Policy  | *
       *                 |Controller| *      AS-2
       *                 +----------+ *
       *         +---+         +---+  *  +-----------+
       *        /| B |---------| C |-----| Transit M |\        AS-4
       *       / +---+\        +---+\ *  +-----------+ \\
       *      /    |   \\    /   |    \      /           \  +---------+
       *+---+/     |     \\//    |    * \  /              \_|         |
       *| A |      |     //\     |    *   X                _| Prefix-1|
       *+---+\     |   //   \\   |    * /   \             / |         |
       *      \    |  /       \  |    /       \          /  +---------+
       *       \ +---+         +---+/ *  +-----------+ //
       *        \| D |---------| E |-----| Transit N |/
       *         +---+         +---+  *  +-----------+
       *                              *
       *      ISP Network             *      AS-3
       *                              *
       ********************************
        Figure 1. Scenario of Prefix Based Traffic Steering

3.  Proposed BGP Extensions

   This section specifies the proposed extension to BGP protocol.

3.1.  New Wide Community Atom

   A new Wide Community Atoms TLV [I-D.ietf-idr-wide-bgp-communities]
   "Bit Flags List Atom" is defined.  This atom is an array of units of
   32 flags numbered from the most significant bit as bit zero.  The
   Length field for this TLV is always a multiple of four bytes,
   regardless of the number of bits carried, and no padding is required.
   Unassigned bits are considered as reserved and MUST be set to zero on
   transmission by the originator of this TLV.  Bits not contained in
   the TLV MUST be assumed to be set to zero.

      Type (TBA): Bit Flags List Atom

   One flag (bit 31) is defined in this document.  When this flag is set
   to 1, recursive route lookup SHOULD be performed in the local routing
   table identified by the address family of the received route with
   this TLV.  When this bit is set to 0, recursive route lookup SHOULD
   be performed in the global routing table.







Dong, et al.            Expires January 13, 2022                [Page 4]


Internet-DraftBGP-FS for Large Scale Prefix Based Steering     July 2021


    +-------+-------+--------------------------------------------------+
    |  Bit  | Value | Meaning                                          |
    +-------+-------+--------------------------------------------------+
    |   31  |   0   | recursive route lookup in global table           |
    |       |   1   | recursive route lookup in local table            |
    | other |   -   | MUST be zero when sent and ignored upon receipt. |
    +-------+-------+--------------------------------------------------+

   The assignment of other bits is managed by IANA.

3.2.  New Wide BGP Community

   A new Registered Wide BGP Community "Download to FIB" is defined.  It
   is used to instruct the receiving BGP speakers to download the BGP
   FlowSpec routes carrying this Wide Community into the FIB, instead of
   installing the FlowSpec routes into FlowSpec filtering entries.

   Download TO FIB:
          Type: 0x0001                S = src AS #
          F = 0x80                    C = 0x00000000
          H = 0                       T = none
          L = 22 octets               E = none
          R = TBA by IANA             P = Type_TBD (Flags 0x00000001)

   An example of the Download to FIB Wide BGP community generated by the
   policy controller in Figure 1 is as below:

      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Container Type 1 (1)      |1 0 0 0 0 0 0 0| Hop Count: 0  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Length: 22            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Community: Download TO FIB   (IANA assigned)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Source AS Number: A                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Context AS Number: 0                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Param TLV (3) |   Length:                   7 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Flags   (TBD) |   Length:                   4 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Flags                            |1|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Dong, et al.            Expires January 13, 2022                [Page 5]


Internet-DraftBGP-FS for Large Scale Prefix Based Steering     July 2021


4.  Operational Procedures

   In order to achieve dynamic prefix based traffic steering in the
   scenario of Figure 1, the controller of AS-1 constructs a BGP
   FlowSpec route which carries the following information:

   o  Prefix-1 as the Destination Prefix component of BGP FlowSpec NLRI.

   o  Traffic-Action Extended Community, with the Route Policy
      Distribution (RPD) [I-D.ietf-idr-rpd] Flag set.  This is to
      indicate that the corresponding FlowSpec filtering rules are used
      as routing policies.

   o  NO_ADVERTISE Community [RFC1997].  This indicates that the
      receiving BGP speaker MUST NOT advertise this BGP FlowSpec route
      to other BGP peers.

   o  "Redirect to IP" Extended Communities
      [I-D.ietf-idr-flowspec-redirect-ip], with the global administrator
      field set to the address of transit node N.

   o  "Download to FIB" Wide BGP Community to indicate that the
      receiving BGP speaker SHOULD download this BGP FlowSpec filtering
      rule to its FIB.

   The controller of AS-1 sends this BGP FlowSpec route to the ASBRs of
   AS-1, i.e. router C and E.

   On receipt of this BGP FlowSpec route from the controller, the
   routers processes the received BGP FlowSpec route as follows:

   o  Extracts the target prefix Prefix-1 from the Destination Prefix
      component in the BGP FlowSpec NLRI.

   o  Identifies that the RPD Flag in the Traffic-Action Extended
      Community is set, so the corresponding filtering rules will be
      used as Routing Policies.

   o  Parses the "Download to FIB" Wide BGP Community, and knows that
      this FlowSpec route SHOULD be downloaded into FIB entry, instead
      of being installed as FlowSpec filtering entry.  And according to
      the Flag Bit 31 in the Wide Community Parameters TLV, knows that
      the recursive route lookup should be performed in the global
      routing table.

   o  Extracts the redirect IP address from the "Redirect to IP"
      Extended Communities, which will be used for the recursive route
      lookup.



Dong, et al.            Expires January 13, 2022                [Page 6]


Internet-DraftBGP-FS for Large Scale Prefix Based Steering     July 2021


   After performing the recursive lookup in the designated routing
   table, the connected next hop is identified and this route is
   downloaded as a FIB entry into the forwarding plane.

5.  IANA Considerations

   IANA is requested to assign a new code point for the "Bit Flags List
   Atom" TLV from the "Wide BGP Communities Atom Types" registry.

   IANA is requested to assign a new code point for the "Download to
   FIB" Wide BGP Community from the "Registered Wide BGP Communities"
   registry.

6.  Security Considerations

   TBD

7.  Contributing Authors

   The following individuals gave significant contributions to this
   document:

   Peng Zhang
   China Telecom
   15335170018@189.cn

   Zhongchao Li
   China Telecom
   15301588336@189.cn

   Dong Shu
   China Telecom
   15301586130@189.cn

8.  Acknowledgements

   The authors would like to thank Shunwan Zhuang, Nan Wu and Haibo Wang
   for the valuable discussion on this work.

9.  Normative References

   [I-D.ietf-idr-flowspec-redirect-ip]
              Uttaro, J., Haas, J., Texier, M., Karch, A., Ray, S.,
              Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to
              IP Action", draft-ietf-idr-flowspec-redirect-ip-02 (work
              in progress), February 2015.





Dong, et al.            Expires January 13, 2022                [Page 7]


Internet-DraftBGP-FS for Large Scale Prefix Based Steering     July 2021


   [I-D.ietf-idr-rpd]
              Li, Z., Ou, L., Luo, Y., Lu, S., Mishra, G. S., Chen, H.,
              Zhuang, S., and H. Wang, "BGP Extensions for Routing
              Policy Distribution (RPD)", draft-ietf-idr-rpd-10 (work in
              progress), November 2020.

   [I-D.ietf-idr-wide-bgp-communities]
              Raszuk, R., Haas, J., Lange, A., Decraene, B., Amante, S.,
              and P. Jakma, "BGP Community Container Attribute", draft-
              ietf-idr-wide-bgp-communities-05 (work in progress), July
              2018.

   [RFC1997]  Chandra, R., Traina, P., and T. Li, "BGP Communities
              Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
              <https://www.rfc-editor.org/info/rfc1997>.

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

   [RFC8955]  Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
              Bacher, "Dissemination of Flow Specification Rules",
              RFC 8955, DOI 10.17487/RFC8955, December 2020,
              <https://www.rfc-editor.org/info/rfc8955>.

Authors' Addresses

   Jie Dong
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Rd.
   Beijing  100095
   China

   Email: jie.dong@huawei.com


   Zhenqiang Li
   China Mobile
   No.32 Xuanwumenxi Ave., Xicheng District
   Beijing  100032
   China

   Email: li_zhenqiang@hotmail.com







Dong, et al.            Expires January 13, 2022                [Page 8]


Internet-DraftBGP-FS for Large Scale Prefix Based Steering     July 2021


   Liang Ou
   China Telcom Co., Ltd.
   109 West Zhongshan Ave,Tianhe District
   Guangzhou  510630
   China

   Email: oul@gsta.com


   Yujia Luo
   China Telcom Co., Ltd.
   109 West Zhongshan Ave,Tianhe District
   Guangzhou  510630
   China

   Email: luoyuj@gsta.com



































Dong, et al.            Expires January 13, 2022                [Page 9]