[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

Network Working Group                                              Z. Li
Internet-Draft                                                    Huawei
Intended status: Standards Track                                   L. Ou
Expires: September 11, 2019                                       Y. Luo
                                                  China Telcom Co., Ltd.
                                                                   S. Lu
                                                                 Tencent
                                                                 H. Chen
                                                               S. Zhuang
                                                                 H. Wang
                                                                  Huawei
                                                          March 10, 2019


          BGP Extensions for Routing Policy Distribution (RPD)
                      draft-li-idr-flowspec-rpd-04

Abstract

   It is hard to adjust traffic and optimize traffic paths on a
   traditional IP network from time to time through manual
   configurations.  It is desirable to have an automatic mechanism for
   setting up routing policies, which adjust traffic and optimize
   traffic paths automatically.  This document describes BGP Extensions
   for Routing Policy Distribution (BGP RPD) to support this.

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 September 11, 2019.



Li, et al.             Expires September 11, 2019               [Page 1]


Internet-Draft                   BGP RPD                      March 2019


Copyright Notice

   Copyright (c) 2019 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 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Problem Statements  . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Inbound Traffic Control . . . . . . . . . . . . . . . . .   4
     3.2.  Outbound Traffic Control  . . . . . . . . . . . . . . . .   4
   4.  Protocol Extensions . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Extensions to BGP Floespec  . . . . . . . . . . . . . . .   5
       4.1.1.  Traffic Actions for Routing Policy Distribution . . .   6
     4.2.  Using a New AFI and SAFI  . . . . . . . . . . . . . . . .   6
     4.3.  BGP Wide Community  . . . . . . . . . . . . . . . . . . .   7
       4.3.1.  New Wide Community Atoms  . . . . . . . . . . . . . .   7
       4.3.2.  Application Examples  . . . . . . . . . . . . . . . .  12
     4.4.  Capability Negotiation  . . . . . . . . . . . . . . . . .  20
   5.  Consideration . . . . . . . . . . . . . . . . . . . . . . . .  20
     5.1.  Route-Policy  . . . . . . . . . . . . . . . . . . . . . .  20
   6.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  21
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  22
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  22
     10.2.  Informative References . . . . . . . . . . . . . . . . .  23
   Appendix A.  BGP Policy Attribute . . . . . . . . . . . . . . . .  23
     A.1.  Match Fields  . . . . . . . . . . . . . . . . . . . . . .  23
     A.2.  Action Fields . . . . . . . . . . . . . . . . . . . . . .  29
     A.3.  Application Examples  . . . . . . . . . . . . . . . . . .  31
       A.3.1.  Change Attributes . . . . . . . . . . . . . . . . . .  31
       A.3.2.  Inbound Traffic Control . . . . . . . . . . . . . . .  32
       A.3.3.  Outbound Traffic Control  . . . . . . . . . . . . . .  34
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  35




Li, et al.             Expires September 11, 2019               [Page 2]


Internet-Draft                   BGP RPD                      March 2019


1.  Introduction

   It is difficult to optimize traffic paths on a traditional IP network
   because of:

   o  Heavy configuration and error prone.  Traffic can only be adjusted
      device by device.  All routers that the traffic traverses need to
      be configured.  The configuration workload is heavy.  The
      operation is not only time consuming but also prone to
      misconfiguration for Service Providers.

   o  Complex.  The routing policies used to control network routes are
      complex, posing difficulties to subsequent maintenance, high
      maintenance skills are required.

   It is desirable to have an automatic mechanism for setting up routing
   policies, which can simplify the routing policies configuration.
   This document describes extensions to BGP for Routing Policy
   Distribution to resolve these issues.

2.  Terminology

   The following terminology is used in this document.

   o  ACL:Access Control List

   o  BGP: Border Gateway Protocol

   o  FS: Flow Specification

   o  PBR:Policy-Based Routing

   o  RPD: Routing Policy Distribution

   o  VPN: Virtual Private Network

3.  Problem Statements

   It is obvious that providers have the requirements to adjust their
   business traffic from time to time because:

   o  Business development or network failure introduces link congestion
      and overload.

   o  Network transmission quality is decreased as the result of delay,
      loss and they need to adjust traffic to other paths.





Li, et al.             Expires September 11, 2019               [Page 3]


Internet-Draft                   BGP RPD                      March 2019


   o  To control OPEX and CPEX, prefer the transit provider with lower
      price.

3.1.  Inbound Traffic Control

   In the scenario below, for the reasons above, the provider of AS100
   saying P may wish the inbound traffic from AS200 enters AS100 through
   link L3 instead of the others.  Since P doesn't have any
   administration over AS200, so there is no way for P to modify the
   route selection criteria directly.

                  Traffic from PE1 to Prefix1
             ----------------------------------->

   +-----------------+            +-------------------------+
   |     +---------+ |        L1  | +----+      +----------+|
   |     |Speaker1 | +------------+ |IGW1|      |policy    ||
   |     +---------+ |**      L2**| +----+      |controller||
   |                 |  **    **  |             +----------+|
   | +---+           |    ****    |                         |
   | |PE1|           |    ****    |                         |
   | +---+           |  **    **  |                         |
   |     +---------+ |**      L3**| +----+                  |
   |     |Speaker2 | +------------+ |IGW2|      AS100       |
   |     +---------+ |        L4  | +----+                  |
   |                 |            |                         |
   |    AS200        |            |                         |
   |                 |            |  ...                    |
   |                 |            |                         |
   |     +---------+ |            | +----+      +-------+   |
   |     |Speakern | |            | |IGWn|      |Prefix1|   |
   |     +---------+ |            | +----+      +-------+   |
   +-----------------+            +-------------------------+

               Prefix1 advertised from AS100 to AS200
             <----------------------------------------

                    Inbound Traffic Control case

3.2.  Outbound Traffic Control

   In the scenario below, the provider of AS100 saying P prefers link L3
   for the traffic to the destination Prefix2 among multiple exits and
   links.  This preference can be dynamic and changed frequently because
   of the reasons above.  So the provider P expects an efficient and
   convenient solution.





Li, et al.             Expires September 11, 2019               [Page 4]


Internet-Draft                   BGP RPD                      March 2019


                  Traffic from PE2 to Prefix2
             ----------------------------------->
   +-------------------------+            +-----------------+
   |+----------+      +----+ |L1          | +---------+     |
   ||policy    |      |IGW1| +------------+ |Speaker1 |     |
   ||controller|      +----+ |**        **| +---------+     |
   |+----------+             |L2**    **  |        +-------+|
   |                         |    ****    |        |Prefix2||
   |                         |    ****    |        +-------+|
   |                         |L3**    **  |                 |
   |      AS100       +----+ |**        **| +---------+     |
   |                  |IGW2| +------------+ |Speaker2 |     |
   |                  +----+ |L4          | +---------+     |
   |                         |            |                 |
   |+---+                    |            |    AS200        |
   ||PE2|              ...   |            |                 |
   |+---+                    |            |                 |
   |                  +----+ |            | +---------+     |
   |                  |IGWn| |            | |Speakern |     |
   |                  +----+ |            | +---------+     |
   +-------------------------+            +-----------------+

               Prefix2 advertised from AS200 to AS100
             <----------------------------------------

                     Outbound Traffic Control case

4.  Protocol Extensions

   Two solutions are proposed.  One extends BGP Floespec.  The other
   uses a new AFI and SAFI.  These solutions use the same BGP Wide
   Community for encoding a routing policy.

4.1.  Extensions to BGP Floespec

   BGP FlowSpec [RFC5575] leverages the BGP control plane to simplify
   the distribution of filter rules.  New filter rules can be injected
   to all BGP peers simultaneously without changing router
   configuration.  Its typical application is for DDOS mitigation.

   This document extends BGP Flowspec as a routing policy distribution
   protocol (BGP RPD for short).  It can be as powerful as the device-
   based routing policy while still has the efficiency and convenience
   of BGP Flowspec.







Li, et al.             Expires September 11, 2019               [Page 5]


Internet-Draft                   BGP RPD                      March 2019


4.1.1.  Traffic Actions for Routing Policy Distribution

   The traffic-action extended community consists of 6 bytes of which
   only the 2 least significant bits of the 6th byte (from left to
   right) are currently defined in [RFC5575]: Terminal Action (bit 47)
   and Sample (bit 46).  This document defines Routing Policy
   Distribution (RPD, or R for short) Flag (Bit 45).  The 6th byte with
   this newly defined flag is illustrated below:

                       40  41  42  43  44  45  46  47
                     +---+---+---+---+---+---+---+---+
                     | reserved          | R | S | T |
                     +---+---+---+---+---+---+---+---+

                     Traffic-action with RPD (R) flag

   RPD (R) Flag (Bit 45): When this bit is set, the BGP Wide Community
   will be used as a Routing Policy.

4.2.  Using a New AFI and SAFI

   A new AFI and SAFI are defined: the Routing Policy AFI whose
   codepoint TBD1 is to be assigned by IANA, and SAFI whose codepoint
   TBD2 is to be assigned by IANA.

   The AFI and SAFI pair uses a new NLRI, which is defined as follows:

    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
   +-+-+-+-+-+-+-+-+
   |  NLRI Length  |
   +-+-+-+-+-+-+-+-+
   |  Policy Type  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Distinguisher (4 octets)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Peer IP (4/16 octets)                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where:

     NLRI Length:  1 octet represents the length of NLRI.

     Policy Type:  1 octet indicates the type of a policy.  1 is for
      export policy. 2 is for import policy.

     Distinguisher:  4 octet value uniquely identifies the policy in the
      peer.



Li, et al.             Expires September 11, 2019               [Page 6]


Internet-Draft                   BGP RPD                      March 2019


     Peer IP:  4/16 octet value indicates an IPv4/IPv6 peer.

   The NLRI containing the Routing Policy is carried in a BGP UPDATE
   message, which MUST contain the BGP mandatory attributes and MAY also
   contain some BGP optional attributes.

   When receiving a BGP UPDATE message, a BGP speaker processes it only
   if the peer IP address in the NLRI is the IP address of the BGP
   speaker or 0.

   The content of the Routing Policy is encoded in a BGP Wide Community.

4.3.  BGP Wide Community

   The BGP wide community is defined in
   [I-D.ietf-idr-wide-bgp-communities].  It can be used to facilitate
   the delivery of new network services, and be extended easily for
   distributing different kinds of routing policies.

4.3.1.  New Wide Community Atoms

   A wide community Atom is a TLV (or sub-TLV), which may be included in
   a BGP wide community container (or BGP wide community for short)
   containing some BGP Wide Community TLVs.  Three BGP Wide Community
   TLVs are defined in [I-D.ietf-idr-wide-bgp-communities], which are
   BGP Wide Community Target(s) TLV, Exclude Target(s) TLV, and
   Parameter(s) TLV.  Each of these TLVs comprises a series of Atoms,
   each of which is a TLV (or sub-TLV).  A new wide community Atom is
   defined for BGP Wide Community Target(s) TLV and a few new Atoms are
   defined for BGP Wide Community Parameter(s) TLV.  For your reference,
   the format of the TLV is illustrated 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
   +-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |             Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Value (variable)                      ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Format of Wide Community Atom TLV

   A RouteAttr Atom TLV (or RouteAttr TLV/sub-TLV for short) is defined
   and may be included in a Target TLV.  It has the following format.







Li, et al.             Expires September 11, 2019               [Page 7]


Internet-Draft                   BGP RPD                      March 2019


    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 (TBD1)  |        Length (variable)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          sub-TLVs                             ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Format of RouteAttr Atom TLV

   The Type for RouteAttr is TBD1 (suggested value 48) to be assigned by
   IANA.  In RouteAttr TLV, three sub-TLVs are defined: IP Prefix, AS-
   Path and Community sub-TLV.

   An IP prefix sub-TLV gives matching criteria on IPv4 prefixes.  Its
   format is illustrated 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type (TBD2)  |         Length (N x 8)        |M-Type | Flags |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          IPv4 Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Mask      |     GeMask    |     LeMask    |M-Type | Flags |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~       . . .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          IPv4 Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Mask      |     GeMask    |     LeMask    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Format of IPv4 Prefix sub-TLV

   Type:  TBD2 (suggested value 1) for IPv4 Prefix is to be assigned by
      IANA.

   Length:  N x 8, where N is the number of tuples <M-Type, Flags, IPv4
      Address, Mask, GeMask, LeMask>.

   M-Type:  4 bits for match types, four of which are defined:

      M-Type = 0:  Exact match.

      M-Type = 1:  Match prefix greater and equal to the given maskes.

      M-Type = 2:  Match prefix less and equal to the given maskes.



Li, et al.             Expires September 11, 2019               [Page 8]


Internet-Draft                   BGP RPD                      March 2019


      M-Type = 3:  Match prefix within the range of the given maskes.

   Flags:  4 bits.  No flags are currently defined.

   IPv4 Address:  4 octets for an IPv4 address.

   Mask:  1 octet for the mask length.

   GeMask:  1 octet for match range, must be less than Mask or be 0.

   LeMask:  1 octet for match range, must be greater than Mask or be 0.

   For example, tuple <M-Type=0, Flags=0, IPv4 Address = 1.1.0.0, Mask =
   22, GeMask = 0, LeMask = 0> represents an exact IP prefix match for
   1.1.0.0/22.

   <M-Type=1, Flags=0, IPv4 Address = 16.1.0.0, Mask = 24, GeMask = 24,
   LeMask = 0> represents match IP prefix 1.1.0.0/24 greater-equal 24.

   <M-Type=2, Flags=0, IPv4 Address = 17.1.0.0, Mask = 24, GeMask = 0,
   LeMask = 26> represents match IP prefix 17.1.0.0/24 less-equal 26.

   <M-Type=3, Flags=0, IPv4 Address = 18.1.0.0, Mask = 24, GeMask = 24,
   LeMask = 32> represents match IP prefix 18.1.0.0/24 greater-equal to
   24 and less-equal 32.

   Similarly, an IPv6 Prefix sub-TLV represents match criteria on IPv6
   prefixes.  Its format is illustrated 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type(TBD3)  |         Length (N x 20)       |M-Type | Flags |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     IPv6 Address (16 octets)                  ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Mask      |     GeMask    |     LeMask    |M-Type | Flags |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~       . . .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      IPv6 Address (16 octets                  ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Mask      |     GeMask    |     LeMask    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Format of IPv6 Prefix sub-TLV





Li, et al.             Expires September 11, 2019               [Page 9]


Internet-Draft                   BGP RPD                      March 2019


   An AS-Path sub-TLV represents a match criteria in a regular
   expression string.  Its format is illustrated 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type (TBD4)  |      Length (Variable)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    AS-Path Regex String                       |
   :                                                               :
   |                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Format of AS Path sub-TLV

   Type:  TBD4 (suggested value 2) for AS-Path is to be assigned by
      IANA.

   Length:  Variable, maximum is 1024.

   AS-Path Regex String:  AS-Path regular expression string.

   A community sub-TLV represents a list of communities to be matched
   all.  Its format is illustrated 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type (TBD5)  |        Length (N x 4 + 1)       |    Flags    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Community 1 Value                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                              . . .                            ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Community N Value                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Format of Community sub-TLV

   Type:  TBD5 (suggested value 3) for Community is to be assigned by
      IANA.

   Length:  N x 4 + 1, where N is the number of communities.

   Flags:  1 octet.  No flags are currently defined.

   In Parameter(s) TLV, two action sub-TLVs are defined: MED change sub-
   TLV and AS-Path change sub-TLV.  When the community in the container



Li, et al.             Expires September 11, 2019              [Page 10]


Internet-Draft                   BGP RPD                      March 2019


   is MATCH AND SET ATTR, the Parameter(s) TLV includes some of these
   sub-TLVs.  When the community is MATCH AND NOT ADVERTISE, the
   Parameter(s) TLV's value is empty.

   A MED change sub-TLV indicates an action to change the MED.  Its
   format is illustrated 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type (TBD6)  |          Length (5)           |      OP       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Value                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Format of MED Change sub-TLV

   Type:  TBD6 (suggested value 1) for MED Change is to be assigned by
      IANA.

   Length:  5.

   OP:  1 octet.  Three are defined:

      OP = 0:  assign the Value to the existing MED.

      OP = 1:  add the Value to the existing MED.  If the sum is greater
         than the maximum value for MED, assign the maximum value to
         MED.

      OP = 2:  subtract the Value from the existing MED.  If the
         existing MED minus the Value is less than 0, assign 0 to MED.

   Value:  4 octets.

   An AS-Path change sub-TLV indicates an action to change the AS-Path.
   Its format is illustrated below:














Li, et al.             Expires September 11, 2019              [Page 11]


Internet-Draft                   BGP RPD                      March 2019


    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 (TBD7)  |        Length (n x 5)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             AS1                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Count1     |
   +-+-+-+-+-+-+-+-+
   ~       . . .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ASn                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Countn     |
   +-+-+-+-+-+-+-+-+

                         Format of AS-Path Change sub-TLV

   Type:  TBD7 (suggested value 2) for AS-Path Change is to be assigned
      by IANA.

   Length:  n x 5.

   ASi:  4 octet.  An AS number.

   Counti:  1 octet.  ASi repeats Counti times.

   The sequence of AS numbers are added to the existing AS Path.

4.3.2.  Application Examples

4.3.2.1.  Change Attributes

   Multiple attributes of a route may be changed when it matches given
   criteria.  In the example below, the policy has the following
   matching criteria:

   o  match 20.20.15.0/20 to 20.20.15.0/24

   o  match as-path 6553601 6553601

   The actions to be applied are add 12345 to the existing MED and add
   AS sequence 123456, 6553602, 6553602, 6553602, 6553602 to the end of
   existing AS Path.  These actions are listed as follows:

   o  apply MED = MED + 12345

   o  apply add as-path 123456, 6553602, 6553602, 6553602, 6553602



Li, et al.             Expires September 11, 2019              [Page 12]


Internet-Draft                   BGP RPD                      March 2019


   The corresponding BGP Wide Community Encoding for these is
   illustrated below.

















































Li, et al.             Expires September 11, 2019              [Page 13]


Internet-Draft                   BGP RPD                      March 2019


    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        |Flags      |0|1|  Reserved(0)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Length:                    71 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Community: Change Attributes                            TBD11 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Source AS                                              64496  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Context AS                                             64496  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Target TLV: 1 |   Length:                 18  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PrefxRange:TBD3|   Length:                  6  | Flags (0)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | MaskLen: 20   | LeMaskLen: 24 |IPv4 Prefix:           20.20.  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |.15            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AS Path: TBD5 |   Length:                  6  | OP:        1  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AS                        6553601                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Count      2  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |ExcTargetTLV: 2|   Length:                   0 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Param TLV:    3|   Length:                  32 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |ChangeMED: TBD8|   Length:                   5 | OP:        2  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Value:                                                  12345 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |AddASPath: TBD7|   Length:                  11 | OP:        1  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AS                        123456                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Count      1  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AS                        6553602                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Count      4  |
   +-+-+-+-+-+-+-+-+

        Example BGP Wide Community Encoding for Change Attributes




Li, et al.             Expires September 11, 2019              [Page 14]


Internet-Draft                   BGP RPD                      March 2019


4.3.2.2.  Inbound Traffic Control

   As required in the case, traffic from PE1 to Prefix1 need to enter
   through L3, so IGWs except IGW2 should prepend ASN list to Prefix1
   when populating to AS100.  As shown in figure below, community
   "PREPEND N TIMES BY AS" and "Exclude Target(s) TLV" are be used.

   The encoding example using BGP Wide Community:

    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        |Flags      |0|1|  Reserved(0)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Length:                    36 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Community: PREPEND N TIMES BY AS                           17 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Source AS                                                 100 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Context AS                                                100 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |ExcTargetTLV: 2|   Length:                  11 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |IPv4Sess: TBD1 |   Length:                   8 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Local Address/Speaker                                   #IGW2 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Remote Address/Speaker                              #Speaker1 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Param TLV:  3 |   Length:                   7 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Integer:   4 |   Length:                   4 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Prepend #                                                   5 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Example encoding for Inbound Traffic Control case

   "PREPEND N TIMES BY AS" Wide Community has been defined in
   [I-D.ietf-idr-registered-wide-bgp-communities].

   The traffic destined for Prefix1 needs to be scheduled to link
   Speaker1 -> IGW2 for transmission.

   The Policy Controller constructs a BGP RPD route and pushes it to all
   the IGW routers, the route carries:




Li, et al.             Expires September 11, 2019              [Page 15]


Internet-Draft                   BGP RPD                      March 2019


   1.  Prefix1 in the Destination Prefix component of the BGP-FS NLRI;

   2.  Flow Specification Traffic Action Extended Community with the
       Routing Policy Distribution (R) Flag (Bit 45) set.  When this bit
       is set, the corresponding filtering rules will be used as Routing
       Policies.

   3.  NO_ADVERTISE Community [RFC1997]

   4.  Wide BGP Community Attribute:

   PREPEND N TIMES BY AS:
          Type: 0x0001                S = src AS #
          F = 0x80                    C = 0x00000000
          H = 0                       T = none
          L = 36 octets               E = Type_TBD (BGP IPv4 session)
          R = 17                      P = Type_4 (0x05)

   Where "BGP IPv4 session" Atom TLV contains:
   The BGP session IPv4 local address: Local BGP Speaker IGW2
   The BGP session IPv4 peer address: Remote BGP Peer Speaker1

   IGW1 processes the received BGP-FS RPD route as follows:

   1.  IGW1 gets the target prefix Prefix1 from the Destination Prefix
       component in the BGP FS NLRI of the BGP FS RPD route;

   2.  IGW1 identifies the Routing Policy Distribution (R) Flag carrying
       in the Flow Specification Traffic Action Extended Community, then
       IGW1 knows that the corresponding filtering rules will be used as
       Routing Policies.

   3.  IGW1 uses the target prefix Prefix1 to choose the matching
       routes, in this case, IGW1 will choose the current best route of
       Prefix1;

   4.  IGW1 gets the action type from the Wide BGP Community Attribute:
       PREPEND N TIMES BY AS;

   5.  IGW1 gets the matching criteria from the Wide BGP Community
       Attribute: Exclude the BGP IPv4 session: <Local BGP Speaker IGW2,
       Remote BGP Speaker1>;

   6.  IGW1 gets the parameter for "PREPEND N TIMES BY AS" from the Wide
       BGP Community Attribute: 5 times;

   IGW1 checks the matching criteria and finds that it doesn't hits the
   exclude matching criteria: Local BGP Speaker IGW2, Remote BGP



Li, et al.             Expires September 11, 2019              [Page 16]


Internet-Draft                   BGP RPD                      March 2019


   Speaker1, so IGW1 sends the best route of Prefix1 to Speaker1 and
   Speaker2 with performing the Action instructions from the BGP-FS RPD
   route: Prepend Local AS 5 times.

   IGW2 processes the received BGP FS RPD route as follows:

   1.  IGW2 gets the target prefix Prefix1 from the Destination Prefix
       component in the BGP-FS NLRI of the BGP FS RPD route;

   2.  IGW2 identifies the Routing Policy Distribution (R) Flag carrying
       in the Flow Specification Traffic Action Extended Community, then
       IGW2 knows that the corresponding filtering rules will be used as
       Routing Policies.

   3.  IGW2 uses the target prefix Prefix1 to choose the matching
       routes, in this case, IGW2 will choose the current best route of
       Prefix1;

   4.  IGW2 gets the action type from the Wide BGP Community Attribute:
       PREPEND N TIMES BY AS;

   5.  IGW2 gets the matching criteria from the BGP Policy Attribute:
       Exclude the BGP IPv4 session: <Local BGP Speaker IGW2, Remote BGP
       Speaker1>;

   6.  IGW2 gets the parameter for "PREPEND N TIMES BY AS" from the Wide
       BGP Community Attribute: 5 times;

   IGW2 checks the matching criteria and finds that there is a speaker
   which hits the exclude matching criteria: Local BGP Speaker IGW2,
   Remote BGP Peer Speaker1, so IGW2 sends the best route of Prefix1 to
   Speaker1 without performing the Action instructions from the BGP-FS
   RPD route, at the same time, IGW2 sends the best route of Prefix1 to
   Speaker2 with performing the Action instructions from the BGP-FS RPD
   route: Prepend Local AS 5 times.

   In the similar manner, other IGWs will perform the same Action
   instructions as IGW1.  Then the traffic destined for Prefix1 has been
   be scheduled to link L3 for transmission.

4.3.2.3.  Outbound Traffic Control

   As required in the case, traffic from PE2 to Prefix2 need to exit
   through L3, so IGWs should prefer the route from IGW2 to Speaker1.
   As shown in figure below, community "LOCAL PREFERENCE" and "Target(s)
   TLV" are be used.

   The encoding example using BGP Wide Community:



Li, et al.             Expires September 11, 2019              [Page 17]


Internet-Draft                   BGP RPD                      March 2019


    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        |Flags      |0|1|  Reserved(0)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Length:                    36 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Community: LOCAL PREFERENCE                                20 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Source AS                                                 100 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Context AS                                                100 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | TargetTLV:  1 |   Length:                  11 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  IPv4Sess:TBD1|   Length:                   8 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Local Address/Speaker                                   #IGW2 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Remote Address/Speaker                              #Speaker1 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Param TLV:  3 |   Length:                   7 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Integer:   4 |   Length:                   4 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Increment #                                               100 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Example encoding for Outbound Traffic Control case

   "LOCAL PREFERENCE" Wide Community has been defined in
   [I-D.ietf-idr-registered-wide-bgp-communities].

   In this scenario, if the bandwidth usage of a link exceeds the
   specified threshold, the Policy Controller automatically identifies
   which traffic needs to be scheduled and the Policy Controller
   automatically calculates traffic control paths based on network
   topology and traffic information.

   For example, the outbound traffic destined for Prefix2 needs to be
   scheduled to link IGW2 -> Speaker1 for transmission.

   The Policy Controller sends a BGP-FS RPD route to IGW2, the route
   carries:

   1.  Prefix2 in the Destination Prefix component of the BGP-FS NLRI;





Li, et al.             Expires September 11, 2019              [Page 18]


Internet-Draft                   BGP RPD                      March 2019


   2.  Flow Specification Traffic Action Extended Community with the RPD
       (R) Flag (Bit 45) set.  When this bit is set, the corresponding
       filtering rules will be used as Routing Policies.

   3.  NO_ADVERTISE Community [RFC1997]

   4.  Wide BGP Community Attribute:

   LOCAL PREFERENCE:
          Type: 0x0001                S = src AS #
          F = 0x80                    C = 0x00000000
          H = 0                       T = Type_TBD (BGP IPv4 session)
          L = 36 octets               E = none
          R = 20                      P = Type_4 (0x64)

   Where "BGP IPv4 session" Atom TLV contains:
   The BGP session IPv4 local address: Local BGP Speaker IGW2
   The BGP session IPv4 peer address: Remote BGP Peer Speaker1

   IGW2 processes the received BGP FS RPD route as follows:

   1.  IGW2 gets the target prefix Prefix2 from the Destination Prefix
       component in the BGP-FS NLRI of the BGP FS RPD route;

   2.  IGW2 identifies the Routing Policy Distribution (R) Flag carrying
       in the Flow Specification Traffic Action Extended Community, then
       IGW2 knows that the corresponding filtering rules will be used as
       Routing Policies.

   3.  IGW2 uses the target prefix Prefix2 to choose the matching
       routes, in this case, the prefix Prefix2 has two more routes:

         Prefix    Next-Hop   Local BGP Speaker   Remote BGP Peer
         --------------------------------------------------------
         Prefix2   Speaker1         IGW2                Speaker1
         Prefix2   Speaker2         IGW2                Speaker2
         ...

   4.  IGW2 gets the action type from the Wide BGP Community Attribute:
       LOCAL PREFERENCE;

   5.  IGW2 gets the matching criteria from the Wide BGP Community
       Attribute: Local BGP Speaker IGW2, Remote BGP Peer Speaker1;

   6.  IGW2 gets the parameter for "LOCAL PREFERENCE" from the Wide BGP
       Community Attribute: increment 100;





Li, et al.             Expires September 11, 2019              [Page 19]


Internet-Draft                   BGP RPD                      March 2019


   So IGW2 chooses the BGP route received from Speaker1 instead of
   Speaker2 as the best route and the outbound traffic destined for
   Prefix2 can be scheduled to link L3 for transmission.

4.4.  Capability Negotiation

   It is necessary to negotiate the capability to support BGP Extensions
   for Routing Policy Distribution (RPD).  The BGP RPD Capability is a
   new BGP capability [RFC5492].  The Capability Code for this
   capability is to be specified by the IANA.  The Capability Length
   field of this capability is variable.  The Capability Value field
   consists of one or more of the following tuples:

           +--------------------------------------------------+
           |  Address Family Identifier (2 octets)            |
           +--------------------------------------------------+
           |  Subsequent Address Family Identifier (1 octet)  |
           +--------------------------------------------------+
           |  Send/Receive (1 octet)                          |
           +--------------------------------------------------+

                          BGP RPD Capability

   The meaning and use of the fields are as follows:

   Address Family Identifier (AFI): This field is the same as the one
   used in [RFC4760].

   Subsequent Address Family Identifier (SAFI): This field is the same
   as the one used in [RFC4760].

   Send/Receive: This field indicates whether the sender is (a) willing
   to receive Routing Policies from its peer (value 1), (b) would like
   to send Routing Policies to its peer (value 2), or (c) both (value 3)
   for the <AFI, SAFI>.

5.  Consideration

5.1.  Route-Policy

   Routing policies are used to filter routes and control how routes are
   received and advertised.  If route attributes, such as reachability,
   are changed, the path along which network traffic passes changes
   accordingly.

   When advertising, receiving, and importing routes, the router
   implements certain policies based on actual networking requirements




Li, et al.             Expires September 11, 2019              [Page 20]


Internet-Draft                   BGP RPD                      March 2019


   to filter routes and change the attributes of the routes.  Routing
   policies serve the following purposes:

   o  Control route advertising: Only routes that match the rules
      specified in a policy are advertised.

   o  Control route receiving: Only the required and valid routes are
      received.  This reduces the size of the routing table and improves
      network security.

   o  Filter and control imported routes: A routing protocol may import
      routes discovered by other routing protocols.  Only routes that
      satisfy certain conditions are imported to meet the requirements
      of the protocol.

   o  Modify attributes of specified routes Attributes of the routes:
      that are filtered by a routing policy are modified to meet the
      requirements of the local device.

   o  Configure fast reroute (FRR): If a backup next hop and a backup
      outbound interface are configured for the routes that match a
      routing policy, IP FRR, VPN FRR, and IP+VPN FRR can be
      implemented.

   Routing policies are implemented using the following procedures:

   1.  Define rules: Define features of routes to which routing policies
       are applied.  Users define a set of matching rules based on
       different attributes of routes, such as the destination address
       and the address of the router that advertises the routes.

   2.  Implement the rules: Apply the matching rules to routing policies
       for advertising, receiving, and importing routes.

6.  Contributors

   The following people have substantially contributed to the definition
   of the BGP-FS RPD and to the editing of this document:

   Peng Zhou
   Huawei
   Email: Jewpon.zhou@huawei.com

7.  IANA Considerations

   TBD.





Li, et al.             Expires September 11, 2019              [Page 21]


Internet-Draft                   BGP RPD                      March 2019


8.  Security Considerations

   TBD.

9.  Acknowledgements

   The authors would like to thank Acee Lindem, Jeff Haas, Jie Dong,
   Haibo Wang, Lucy Yong, Qiandeng Liang, Zhenqiang Li for their
   comments to this work.

10.  References

10.1.  Normative References

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

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <https://www.rfc-editor.org/info/rfc4271>.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              DOI 10.17487/RFC4760, January 2007,
              <https://www.rfc-editor.org/info/rfc4760>.

   [RFC5492]  Scudder, J. and R. Chandra, "Capabilities Advertisement
              with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
              2009, <https://www.rfc-editor.org/info/rfc5492>.

   [RFC5575]  Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
              and D. McPherson, "Dissemination of Flow Specification
              Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
              <https://www.rfc-editor.org/info/rfc5575>.




Li, et al.             Expires September 11, 2019              [Page 22]


Internet-Draft                   BGP RPD                      March 2019


10.2.  Informative References

   [I-D.ietf-idr-registered-wide-bgp-communities]
              Raszuk, R. and J. Haas, "Registered Wide BGP Community
              Values", draft-ietf-idr-registered-wide-bgp-communities-02
              (work in progress), May 2016.

Appendix A.  BGP Policy Attribute

   This document defines and uses a new BGP attribute called the "BGP
   Policy attribute".  This is an optional BGP attribute.  The format of
   this attribute is defined as follows:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Attr Flag   |Attr Type(TBD) |     Attr Length   ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                      Match fields (Variable)                  ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                      Action fields (Variable)                 ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Format of BGP Policy Attribute

   Match fields: Match Fields define the matching criteria for the BGP
   Policy Attribute.

   Action fields: Action fields define the action being applied to the
   target route.

A.1.  Match Fields

   Match Fields define the matching criteria for the BGP Policy
   Attribute.  It has the following format:












Li, et al.             Expires September 11, 2019              [Page 23]


Internet-Draft                   BGP RPD                      March 2019


      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Match Type (2 octets)       |         Length (2 octets)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                         Sub-TLVs (Variable)                   ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                             Match Fields Format

   Match Type:

   1: Permit, specifies the permit mode of a match rule.  If a route
   matches the matching criteria of the BGP Policy Attribute, the
   actions defined by the Action fields of the BGP Policy Attribute are
   performed.  If a route does not match the matching criteria for the
   BGP Policy Attribute, then nothing needs to be done with this route.

   2: Deny, specifies the deny mode of a match rule.  In the deny mode,
   If a route does not match the matching criteria of the BGP Policy
   Attribute, the actions defined by the Action fields of the BGP Policy
   Attribute are performed.  If a route matches the matching criteria of
   the BGP Policy Attribute, then nothing needs to be done with this
   route.

   Length: The total length of the Sub-TLVs in the Match fields.

   The contents of Match fields are encoded as Sub-TLVs, where each Sub-
   TLV has the following format:

      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 (2 octets)         |         Length (2 octets)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                          Values (Variable)                    ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                  Sub-TLV Format

   Type: The Type field contains a value of 1-65534.  The values 0 and
   65535 are reserved for future use.

   Length: The Length field represents the total length of a given TLV's
   value field in octets.

   Values: The Value field contains the TLV value.




Li, et al.             Expires September 11, 2019              [Page 24]


Internet-Draft                   BGP RPD                      March 2019


   The following TLVs are defined:

   Type TBD1: BGP IPv4 Session (or IPv4 Session for short), whose TLV
   contains the IPv4 local address/speaker and remote address/speaker of
   a BGP session.  Its TLV (or Sub-TLV) format is illustrated 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Type (TBD1)        |         Length (8)            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Local IPv4 Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Remote IPv4 Address                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Format of IPv4 Session TLV

   Type TBD2: BGP IPv6 Session (or IPv6 Session for short), whose TLV
   contains the IPv6 local address/speaker and remote address/speaker of
   a BGP session.  Its TLV (or Sub-TLV) format is illustrated 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Type (TBD2)        |          Length (32)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                  Local IPv6 Address (16 Bytes)                ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                  Remote IPv6 Address (16 Bytes)               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Format of IPv6 Session TLV

   Type TBD3: IPv4 Prefix Range, which represents a range of IPv4
   prefixes.  Its format is illustrated below:















Li, et al.             Expires September 11, 2019              [Page 25]


Internet-Draft                   BGP RPD                      March 2019


      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 (TBD3)        |      Length (Variable)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Flags      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          IPv4 Address                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   MaskLen     |   LeMaskLen   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~       . . .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          IPv4 Address                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   MaskLen     |   LeMaskLen   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Format of IPv4 Prefix Range TLV

   The IPv4 Prefix Range TLV (or Sub-TLV) contains a number of triple
   <IPv4 Address, MaskLen, LeMaskLen>s.  Each triple <IPv4 Address,
   MaskLen, LeMaskLen> represents an IPv4 prefix range from IPv4-
   Address/MaskLen to IPv4-Address/LeMaskLen.  For example, triple
   <10.10.0.0, 16, 16> represents prefixes 10.10.0.0/16 (i.e., from
   10.10.0.0/16 to 10.10.0.0/16).  Triple <20.20.15.0, 20, 24>
   represents prefixes from 20.20.15.0/20 to 20.20.15.0/24.

   The encoding of IPv4 Prefix Range may be optimized to the following
   compact format:

      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 (TBD3)        |      Length (Variable)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Flags      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   MaskLen     |   LeMaskLen   |          IPv4 Prefix          ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~       . . .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   MaskLen     |   LeMaskLen   |          IPv4 Prefix          ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Compact Format of IPv4 Prefix Range TLV





Li, et al.             Expires September 11, 2019              [Page 26]


Internet-Draft                   BGP RPD                      March 2019


   It contains a number of triple <MaskLen, LeMaskLen, IPv4 Prefix>s.
   Each triple <MaskLen, LeMaskLen, IPv4 Prefix> represents an IPv4
   prefix range from IPv4-Prefix/MaskLen to IPv4-Prefix/LeMaskLen.
   LeMaskLen is the length of the prefix.  For example, triple <16, 16,
   10.10.0.0> represents prefixes 10.10.0.0/16 (i.e., from 10.10.0.0/16
   to 10.10.0.0/16).  Triple <20, 24, 20.20.15.0> represents prefixes
   from 20.20.15.0/20 to 20.20.15.0/24.

   Similarly, Type TBD4: IPv6 Prefix Range represents a range of IPv6
   prefixes.  Its format is illustrated 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Type (TBD4)        |      Length (Variable)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Flags      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                     IPv6 Address (16 Bytes)                   ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   MaskLen     |   LeMaskLen   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~       . . .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                     IPv6 Address (16 Bytes)                   ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   MaskLen     |   LeMaskLen   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Format of IPv6 Prefix Range TLV

   The encoding of IPv6 Prefix Range may be optimized to the following
   compact format:


















Li, et al.             Expires September 11, 2019              [Page 27]


Internet-Draft                   BGP RPD                      March 2019


      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 (TBD4)        |      Length (Variable)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Flags      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   MaskLen     |   LeMaskLen   |          IPv6 Prefix          ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~       . . .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   MaskLen     |   LeMaskLen   |          IPv6 Prefix          ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Compact Format of IPv6 Prefix Range TLV

   Type TBD5: AS Path, which represents a sequence of AS numbers.  For
   an AS number occurs multiple times in a row in a path, it is
   represented by the AS number and a count indicating the times that
   the AS number occurs.  Its format is illustrated 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Type (TBD5)        |      Length (Variable)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Flags      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             AS1                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Count1     |
     +-+-+-+-+-+-+-+-+
     ~       . . .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             ASn                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Countn     |
     +-+-+-+-+-+-+-+-+

                                Format of AS Path TLV

   For example, AS Path "123456, 6553603, 6553603, 6553603" is
   represented by AS1 = 123456, Count1 = 1, AS2 = 6553603, and Count2 =
   3.

   Type TBD6: Communities, which represents a list of communities
   values.  Its format is illustrated below:




Li, et al.             Expires September 11, 2019              [Page 28]


Internet-Draft                   BGP RPD                      March 2019


       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 (TBD6)        |      Length (Variable)        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Flags      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Community 1 Value                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                              . . .                            ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Community n Value                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Format of Communities TLV

A.2.  Action Fields

   Action fields define the action being applied to the targeted route.
   It has the following format.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Action Type (2 octets)      |         Length (2 octets)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                         Action Values (Variable)              ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            Action Fields Format

   Action Type: The Action Type field contains a value of 1-65534.  The
   values 0 and 65535 are reserved for future use.

   Action Length: The Action Length field represents the total length of
   the Action Values in octets.

   Action Values: The Action Values field contain parameters of the
   action.

   Supported format of the TLVs can be:

   Type TBD7: Add AS Path, which indicates to add the sequence of AS
   numbers represented in the TLV to AS Path.  Its TLV (or Sub-TLV)
   format is illustrated below:






Li, et al.             Expires September 11, 2019              [Page 29]


Internet-Draft                   BGP RPD                      March 2019


      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 (TBD7)        |      Length (Variable)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      OP       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             AS1                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Count1     |
     +-+-+-+-+-+-+-+-+
     ~       . . .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             ASn                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Countn     |
     +-+-+-+-+-+-+-+-+

                                Format of Add AS Path TLV

   When OP = 1, the sequence of AS numbers are added in the end of the
   existing AS Path.  When OP = 2, the sequence of AS numbers are added
   in the front of the existing AS Path.

   Type TBD8: Change Med, which indicates to change the Med according to
   OP.  Its TLV (or Sub-TLV) format is illustrated 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Type (TBD8)        |          Length (5)           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      OP       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Value                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                              Format of Change Med TLV

   When OP = 1, assign the Value to the existing Med.  When OP = 2, add
   the Value to the existing Med.  If the sum of them is greater than
   the maximum value for Med, assign the maximum value to Med.  When OP
   = 3, subtract the Value from the existing Med.  If the existing Med
   minus the Value is less than 0, assign 0 to Med.

   Type TBD9: Deny, which indicates Deny action.  Its TLV (or Sub-TLV)
   format is illustrated below:




Li, et al.             Expires September 11, 2019              [Page 30]


Internet-Draft                   BGP RPD                      March 2019


      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 (TBD9)          |          Length (0)           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                Format of Atom Deny

A.3.  Application Examples

A.3.1.  Change Attributes

   Multiple attributes of a route may be changed when it matches given
   matching criteria.  In the example below, the policy has the
   following matching criteria:

   o  match 20.20.15.0/20 to 20.20.15.0/24

   o  match as-path 6553601 6553601

   The actions to be applied are add 12345 to the existing MED and add
   AS sequence 123456, 6553602, 6553602 to the end of existing AS Path.
   These actions are listed as follows:

   o  apply MED = MED + 12345

   o  apply add as-path 123456, 6553602, 6553602

   The corresponding BGP Policy Attribute Encoding for these is
   illustrated below.





















Li, et al.             Expires September 11, 2019              [Page 31]


Internet-Draft                   BGP RPD                      March 2019


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | MatchType:                 1  |   Length:                 20  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PrefxRange:TBD3                |   Length:                  6  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Flags (0)     |  MaskLen:  20 | LeMaskLen: 24 |IPv4 Prefix:20.|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |20.15                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AS Path: TBD5                 |   Length:                  6  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OP:        1  | AS                        6553601             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AS-Contiue    | Count      2  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |ActionType:                 3  |   Length:                  24 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Change MED: TBD8               |   Length:                   5 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OP:        2  | Value:                                  12345 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Value-Contiue  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Add AS Path: TBD7              |   Length:                  11 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OP:        1  | AS                        123456              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AS-Contiue    | Count      1  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AS                        6553602                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Count      2  |
   +-+-+-+-+-+-+-+-+

      Example BGP Policy Attribute Encoding for Change Attributes

A.3.2.  Inbound Traffic Control

   The traffic destined for Prefix1 needs to be scheduled to link
   Speaker1 -> IGW2 for transmission.

   The Policy Controller constructs a BGP-FS RPD route and pushes it to
   all the IGW routers, the route carries:

   1.  Prefix1 in the Destination Prefix component of the BGP-FS NLRI;




Li, et al.             Expires September 11, 2019              [Page 32]


Internet-Draft                   BGP RPD                      March 2019


   2.  Flow Specification Traffic Action Extended Community with the
       Routing Policy Distribution (R) Flag (Bit 45) set.  When this bit
       is set, the corresponding filtering rules will be used as Routing
       Policies.

   3.  NO_ADVERTISE Community [RFC1997]

   4.  BGP Policy Attribute:

       *  Match Type: 2, Deny

       *  IPv4 Session Sub-TLV: Local BGP Speaker IGW2, Remote BGP Peer
          Speaker1

       *  Action Type: Route-Prepend-AS

       *  Action Value: Prepend-AS times is 5

   IGW1 processes the received BGP-FS RPD route as follows:

   1.  IGW1 gets the target prefix Prefix1 from the Destination Prefix
       component in the BGP FS NLRI of the BGP FS RPD route;

   2.  IGW1 identifies the Routing Policy Distribution (R) Flag carrying
       in the Flow Specification Traffic Action Extended Community, then
       IGW1 knows that the corresponding filtering rules will be used as
       Routing Policies.

   3.  IGW1 uses the target prefix Prefix1 to choose the matching
       routes, in this case, IGW1 will choose the current best route of
       Prefix1;

   4.  IGW1 gets the matching criteria from the BGP Policy Attribute:
       Local BGP Speaker IGW2, Remote BGP Speaker1;

   5.  IGW1 gets the action from the BGP Policy Attribute: Route-
       Prepend-AS, 5 times;

   IGW1 checks the matching criteria and finds that it doesn't hits the
   matching criteria: Local BGP Speaker IGW2, Remote BGP Speaker1, at
   the same time the Match Type is "Deny" mode, so IGW1 sends the best
   route of Prefix1 to Speaker1 and Speaker2 with performing the Action
   instructions from the BGP-FS RPD route: Prepend Local AS 5 times.

   IGW2 processes the received BGP FS RPD route as follows:

   1.  IGW2 gets the target prefix Prefix1 from the Destination Prefix
       component in the BGP-FS NLRI of the BGP FS RPD route;



Li, et al.             Expires September 11, 2019              [Page 33]


Internet-Draft                   BGP RPD                      March 2019


   2.  IGW2 identifies the Routing Policy Distribution (R) Flag carrying
       in the Flow Specification Traffic Action Extended Community, then
       IGW2 knows that the corresponding filtering rules will be used as
       Routing Policies.

   3.  IGW2 uses the target prefix Prefix1 to choose the matching
       routes, in this case, IGW2 will choose the current best route of
       Prefix1;

   4.  IGW2 gets the matching criteria from the BGP Policy Attribute:
       Local BGP Speaker IGW2, Remote BGP Speaker1;

   5.  IGW2 gets the action from the BGP Policy Attribute: Route-
       Prepend-AS, 5 times;

   IGW2 checks the matching criteria and finds that there is a speaker
   which hits the matching criteria: Local BGP Speaker IGW2, Remote BGP
   Peer Speaker1, but the Match Type is "Deny" mode, so IGW2 sends the
   best route of Prefix1 to Speaker1, without performing the Action
   instructions from the BGP-FS RPD route.  At the same time, IGW2 sends
   the best route of Prefix1 to Speaker2 with performing the Action
   instructions from the BGP-FS RPD route: Prepend Local AS 5 times.

   In the similar manner, other IGWs will perform the same Action
   instructions as IGW1.  Then the traffic destined for Prefix1 has been
   be scheduled to link L3 for transmission.

A.3.3.  Outbound Traffic Control

   In this scenario, if the bandwidth usage of a link exceeds the
   specified threshold, the Policy Controller automatically identifies
   which traffic needs to be scheduled and the Policy Controller
   automatically calculates traffic control paths based on network
   topology and traffic information.

   For example, the outbound traffic destined for Prefix2 needs to be
   scheduled to link IGW2 -> Speaker1 for transmission.

   The Policy Controller sends a BGP-FS RPD route to IGW2, the route
   carries:

   1.  Prefix2 in the Destination Prefix component of the BGP-FS NLRI;

   2.  Flow Specification Traffic Action Extended Community with the
       Routing Policy Distribution (R) Flag (Bit 45) set.  When this bit
       is set, the corresponding filtering rules will be used as Routing
       Policies.




Li, et al.             Expires September 11, 2019              [Page 34]


Internet-Draft                   BGP RPD                      March 2019


   3.  NO_ADVERTISE Community [RFC1997]

   4.  BGP Policy Attribute:

       *  Match Type: 1, Permit

       *  IPv4 Session Sub-TLV: Local BGP Speaker IGW2, Remote BGP Peer
          Speaker1

       *  Action Type: Route-Preference

       *  Action Value: none

   IGW2 processes the received BGP FS RPD route as follows:

   1.  IGW2 gets the target prefix Prefix2 from the Destination Prefix
       component in the BGP-FS NLRI of the BGP FS RPD route;

   2.  IGW2 identifies the Routing Policy Distribution (R) Flag carrying
       in the Flow Specification Traffic Action Extended Community, then
       IGW2 knows that the corresponding filtering rules will be used as
       Routing Policies.

   3.  IGW2 uses the target prefix Prefix2 to choose the matching
       routes, in this case, the prefix Prefix2 has two more routes:

         Prefix    Next-Hop   Local BGP Speaker   Remote BGP Peer
         Prefix2   Speaker1         IGW2                Speaker1
         Prefix2   Speaker2         IGW2                Speaker2
         ...

   4.  IGW2 gets the matching criteria from the BGP Policy Attribute:
       Local BGP Speaker IGW2, Remote BGP Peer Speaker1;

   5.  IGW2 gets the action from the BGP Policy Attribute: Route-
       Preference;

   So IGW2 chooses the BGP route received from Speaker1 instead of
   Speaker2 as the best route and the outbound traffic destined for
   Prefix2 can be scheduled to link L3 for transmission.

Authors' Addresses









Li, et al.             Expires September 11, 2019              [Page 35]


Internet-Draft                   BGP RPD                      March 2019


   Zhenbin Li
   Huawei
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: lizhenbin@huawei.com


   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


   Sujian Lu
   Tencent
   Tengyun Building,Tower A ,No. 397 Tianlin Road
   Shanghai, Xuhui District  200233
   China

   Email: jasonlu@tencent.com


   Huaimo Chen
   Huawei
   Boston, MA
   USA

   Email: Huaimo.chen@huawei.com









Li, et al.             Expires September 11, 2019              [Page 36]


Internet-Draft                   BGP RPD                      March 2019


   Shunwan Zhuang
   Huawei
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: zhuangshunwan@huawei.com


   Haibo Wang
   Huawei
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: rainsword.wang@huawei.com



































Li, et al.             Expires September 11, 2019              [Page 37]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/