[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 05

Network Working Group                                              Z. Li
Internet-Draft                                       Huawei Technologies
Intended status: Standards Track                                   L. Ou
Expires: January 7, 2016                                          Y. Luo
                                                  China Telcom Co., Ltd.
                                                               S. Zhuang
                                                                   N. Wu
                                                     Huawei Technologies
                                                           July 06, 2015


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

Abstract

   This document describes a mechanism to use BGP Flowspec address
   family [RFC5575] as routing-policy distribution protocol.  This
   mechanism is called BGP FlowSpec Extensions for Routing Policy
   Distribution (BGP FS RPD).

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 http://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 7, 2016.








Li, et al.               Expires January 7, 2016                [Page 1]


Internet-Draft                 BGP FS RPD                      July 2015


Copyright Notice

   Copyright (c) 2015 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
   (http://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
     1.1.  Routing Policies  . . . . . . . . . . . . . . . . . . . .   3
     1.2.  BGP FlowSpec  . . . . . . . . . . . . . . . . . . . . . .   4
     1.3.  BGP FlowSpec Extensions for Routing Policy Distribution .   4
   2.  Definitions and Acronyms  . . . . . . . . . . . . . . . . . .   5
   3.  Protocol Extensions . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  FlowSpec Traffic Actions for Routing Policy Distribution    5
     3.2.  BGP Policy Attribute  . . . . . . . . . . . . . . . . . .   6
       3.2.1.  Match Fields Format . . . . . . . . . . . . . . . . .   6
       3.2.2.  Action Fields Format  . . . . . . . . . . . . . . . .   8
     3.3.  Capability Negotiation  . . . . . . . . . . . . . . . . .   9
   4.  Applications  . . . . . . . . . . . . . . . . . . . . . . . .   9
     4.1.  Outbound Traffic Control  . . . . . . . . . . . . . . . .   9
     4.2.  Inbound Traffic Control . . . . . . . . . . . . . . . . .  12
   5.  Additional Contributors . . . . . . . . . . . . . . . . . . .  14
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   On a traditional IP network, devices calculate their respective paths
   in a dynamic and distributed manner.  The entire network is divided
   into multiple autonomous systems (ASs), and an Interior Gateway
   Protocol (IGP) runs on the devices within each AS.  The IGP enables
   devices within an AS to obtain the intra-AS network topology and use
   the same algorithm to calculate routes.  Devices in different ASs use
   Border Gateway Protocol (BGP) to exchange routes.  If a link or
   device fails, the IP network layer triggers route convergence to



Li, et al.               Expires January 7, 2016                [Page 2]


Internet-Draft                 BGP FS RPD                      July 2015


   protect data traffic.  However, if you want to manually optimize
   traffic paths on a traditional IP network, you will encounter the
   following difficulties:

   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.

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

   Hence, an automatic mechanism for setting up routing policies is
   desirable which can simplify the complexity of routing policies
   configuration.

1.1.  Routing Policies

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



Li, et al.               Expires January 7, 2016                [Page 3]


Internet-Draft                 BGP FS RPD                      July 2015


   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.

1.2.  BGP FlowSpec

   BGP FlowSpec is defined in [RFC 5575].  This RFC describes a new NLRI
   that allows to convey flow specifications and traffic Action/Rules
   associated (rate-limiting, redirect, remark ...).  BGP Flow
   specifications are encoded within the MP_REACH_NLRI and
   MP_UNREACH_NLRI attributes.  Rules (Actions associated) are encoded
   in Extended Community attribute.  The BGP Flow Specification function
   allows BGP Flow Specification routes that carry traffic policies to
   be transmitted to BGP Flow Specification peers to control attack
   traffic.

   BGP FlowSpec 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.  The
   typical application of BGP Flow-spec is to automate the distribution
   of traffic filter lists to routers for DDOS mitigation.

1.3.  BGP FlowSpec Extensions for Routing Policy Distribution

   BGP FlowSpec address family [RFC5575] is used to install Flow based
   filters to filter unwanted data traffic.  It is based on the
   forwarding plane, serves forwarding.  BGP FlowSpec feature allows you
   to rapidly deploy and propagate filtering and policing functionality
   among a large number of BGP peer routers, it can easily and
   automatically push the filter update to all the BGP peer routers that
   support BGP FlowSpec address family, it is a powerful tool.

   Routing Policy is based on the control plane, serves routing
   protocols and routing tables.  Routing Policy is also a powerful
   tool.  Currently, Routing Policy can only be configured device by
   device.

   This document describes a mechanism to use BGP Flowspec address
   family [RFC5575] as routing-policy distribution protocol.  This
   mechanism is called BGP FlowSpec Extensions for Routing Policy
   Distribution (BGP FS RPD).




Li, et al.               Expires January 7, 2016                [Page 4]


Internet-Draft                 BGP FS RPD                      July 2015


   BGP FS RPD introduce a new BGP path attribute called BGP Policy
   Attribute, it defines the matching criteria and actions for routing
   policies in the BGP Policy Attribute.

   BGP FS RPD uses the Destination Prefix component in the BGP FS NLRI
   to define a target prefix.  When a device receives a BGP FS RPD
   route, it will use the target prefix containing in the BGP FS NLRI to
   choose the matching routes, in most case, a prefix will have one more
   matching routes.

   When the matching routes are selected, the routing policies carrying
   in the BGP FS RPD route wiil be applied to them.

2.  Definitions and Acronyms

   BGP Flow Specification route: BGP Flow Specification routes are
   defined in RFC 5575.  Each BGP Flow Specification route contains BGP
   Network Layer Reachability Information (NLRI) and Extended Community
   Attributes, which carry traffic filtering rules and actions to be
   taken on filtered traffic.

   BGP Flow Specification peer relationship: A BGP Flow Specification
   peer relationship is established between the device that generates
   BGP Flow Specification routes and each network ingress that will
   transmit the BGP Flow Specification routes.  After receiving the BGP
   Flow Specification routes, the peer delivers preferred BGP Flow
   Specification routes to the forwarding plane.  The routes are then
   converted into traffic policies that control attack traffic.

   ACL:Access Control List

   BGP: Border Gateway Protocol

   FS: Flow Specification

   PBR:Policy-Based Routing

   RPD: Routing Policy Distribution

   VPN: Virtual Private Network

3.  Protocol Extensions

3.1.  FlowSpec 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)



Li, et al.               Expires January 7, 2016                [Page 5]


Internet-Draft                 BGP FS RPD                      July 2015


   and Sample (bit 46) defines in [RFC5575], this document defines Route
   Policy Distribution Flag(Bit 45).

   The Flow Specification Traffic Actions for Routing Policy
   Distribution:

                       40  41  42  43  44  45  46  47
                     +---+---+---+---+---+---+---+---+
                     | reserved          | R | S | T |
                     +---+---+---+---+---+---+---+---+
                     Figure 1: FlowSpec Traffic-action

   Route Policy Distribution Flag(Bit 45): When this bit is set, the
   corresponding filtering rules will be used as Route Policy.

3.2.  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:

                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |                               |
                     |   Match fields (Variable)     |
                     |                               |
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |                               |
                     |   Action fields (Variable)    |
                     |                               |
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Figure 2: 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.

3.2.1.  Match Fields Format

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









Li, et al.               Expires January 7, 2016                [Page 6]


Internet-Draft                 BGP FS RPD                      July 2015


                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |   Match Type (2 octets)       |
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     | Number of Sub-TLVs (2 octets) |
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |                               |
                     |   Sub-TLVs (Variable)         |
                     |                               |
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Figure 3: Match Fields Format

   Match Type:

   0: 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 do with this route.

   1: 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 do with this route.

   Number of Sub-TLVs: The number of Sub-TLVs contain in Match fields.

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

                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |       Type (2 octets)         |
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |       Length (2 octets)       |
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |                               |
                     |       Values (Variable)       |
                     |                               |
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Figure 4: Sub-TLVs 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 January 7, 2016                [Page 7]


Internet-Draft                 BGP FS RPD                      July 2015


   Supported format of the TLVs can be:

   Type 1: IPv4 Neighbor

   Type 2: IPv6 Neighbor

   Type 3: ASN List

   ...

   To be added in later versions.

3.2.2.  Action Fields Format

   Action fields define the action being applied to the targeted route.

                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |   Action Type (2 octets)      |
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |   Action Length (2 octets)    |
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |                               |
                     |   Action Values (Variable)    |
                     |                               |
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Figure 5: 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 1: Route-Preference

   Type 2: Route-Prepend-AS

   ...

   To be added in later versions.






Li, et al.               Expires January 7, 2016                [Page 8]


Internet-Draft                 BGP FS RPD                      July 2015


3.3.  Capability Negotiation

   It is necessary to negotiate the capability to support BGP FlowSpec
   Extensions for Route Policy Distribution (RPD).  The BGP FS 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)                          |
           +--------------------------------------------------+
           Figure 6: BGP FS 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 Route Policies via BGP FLowSpec from its peer (value 1),
   (b) would like to send Route Policies via BGP FLowSpec to its peer
   (value 2), or (c) both (value 3) for the <AFI, SAFI>.

4.  Applications

4.1.  Outbound Traffic Control

   Figure 7 shows the multiple transit providers scenario.  For Network
   1, it has n entries/exits that respectively connect to transit
   network N1, N2 and Nn.  And between Network 1 and each transit
   network, there is one or more links.  Different link has different
   cost/price, bandwidth, delay/loss attributes.

   For this multiple extry/exit scenario, it has the following
   requirements:

   o Choose the proper extry/exit based on link price and/or service
   type;





Li, et al.               Expires January 7, 2016                [Page 9]


Internet-Draft                 BGP FS RPD                      July 2015


   o Dynamically adjust the extry/exit based on link load and/or link
   price;

                               /----\   |------------|
                              |  N1 |---|            |
                          L1 / \----/   |            |
       ----------------     /   /       |            |
    ///                \\\ /   /        |            |
   /             ------   /\  /L3       |            |
  |              |IGW1|--+ | /          |            |
  | ------------ ------   \|/           |            |
  | |Policy    |          /\            |            |
  | |Controller|         / |\           |            | Route-Advertising
  | ------------        /  | \L2        |            |     <-------
  |              ------/   |  \ /----\  |            |
  |    Network 1 |IGW2|----+---|  N2 |--|    ...     |------| Prefix1
  |              ------ L4 |    \----/  |            |
  | -----                  |            |            |
  | |PE1|         ...      |      ...   |            |
  | -----        ------    |            |            |
  |              |IGWn|--+ |            |            |
  |              ------   \|            |            |
   |                      |\            |            |
    \\\                ///  \           |            |
       ----------------      \ /----\   |            |
                              |  Nn |---|            |
                               \----/   |------------|
  -----> Traffic to Prefix1
  PE1 acts as an Ingress Router
  EBGP peering:
  L1: IGW1 with N1; L2: IGW1 with N2; L3: IGW2 with N1; L4: IGW2 with N2

  Figure 7: Inbound Route Control / Outbound Traffic Control

   Outbound traffic control adjusts the transmission paths of outbound
   traffic from the ISP network to ensure that the traffic is evenly
   shared among links between IGWs and Transit Providers networks and
   the bandwidth usage of each link is below the specified threshold.

   In outbound traffic control 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:





Li, et al.               Expires January 7, 2016               [Page 10]


Internet-Draft                 BGP FS RPD                      July 2015


   To ensure even traffic sharing, the outbound traffic destined for
   Prefix1 needs to be scheduled to link IGW2 -> N1 for transmission.

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

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

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

   3) BGP Policy Attribute:

   o Match Type: 1, Permit

   o IPv4 Neighbor Sub-TLV: Local BGP Speaker IGW2, Remote BGP Peer N1

   o Action Type: Route-Preference

   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 Route Policy Distribution 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, the prefix Prefix1 has two more routes:

         Prefix    Next-Hop   Local BGP Speaker   Remote BGP Peer
         Prefix1   N1         IGW2                N1
         Prefix1   N2         IGW2                N2
         ...

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

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

   So IGW2 chooses the BGP route received from N1 (rather than N2) as
   the best route and the outbound traffic destined for Prefix1 can be
   scheduled to link IGW2 -> N1 for transmission.




Li, et al.               Expires January 7, 2016               [Page 11]


Internet-Draft                 BGP FS RPD                      July 2015


4.2.  Inbound Traffic Control

   Inbound traffic control adjusts the transmission paths of traffic
   bound for the IP core network to ensure that the traffic is evenly
   shared among links between Transit Networks and IGWs and the
   bandwidth usage of each link is below the specified threshold.

                              /----\   |------------|
                             |  N1 |---|            |
                         L1 / \----/   |            |
      ----------------     /   /       |            |
   ///                \\\ /   /        |            |
  /             ------   /\  /L3       |            |
 |              |IGW1|--+ | /          |            |
 | ------------ ------   \|/           |            |
 | |Policy    |          /\            |            |
 | |Controller|         / |\           |            | Traffic to Prefix2
 | ------------        /  | \L2        |            |     <-------
 |              ------/   |  \ /----\  |            |
 |    Network 1 |IGW2|----+---|  N2 |--|    ...     |------| Client
 | -----        ------ L4 |    \----/  |            |
 | |PE1|                  |            |            |
 | -----         ...      |      ...   |            |
 | Prefix2      ------    |            |            |
 |              |IGWn|--+ |            |            |
 |              ------   \|            |            |
  |                      |\            |            |
   \\\                ///  \           |            |
      ----------------      \ /----\   |            |
                             | Nn  |---|            |
                              \----/   |------------|
  -----> Route-Advertising

 Figure 8: Outbound Route Control / Inbound Traffic Control

   For example:

   To ensure even traffic sharing, the traffic destined for Prefix2
   needs to be scheduled to link N1 -> IGW2 for transmission.

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

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

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



Li, et al.               Expires January 7, 2016               [Page 12]


Internet-Draft                 BGP FS RPD                      July 2015


   3) BGP Policy Attribute:

   o Match Type: 2, Deny

   o IPv4 Neighbor Sub-TLV: Local BGP Speaker IGW2, Remote BGP Peer N1

   o Action Type: Route-Prepend-AS

   o Action Value: Prepend-AS times is 5

   IGW1 processes the received BGP FS RPD route as follows:

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

   2) IGW1 identifies the Route Policy Distribution 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 Prefix2 to choose the matching routes,
   in this case, IGW1 will choose the current best route of Prefix2;

   4) IGW1 gets the matching criteria from the BGP Policy Attribute:
   Local BGP Speaker IGW2, Remote BGP Peer N1;

   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 Peer N1, at the
   same time the Match Type is "Deny" mode, so IGW1 sends the best route
   of Prefix2 to N1 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 Prefix2 from the Destination Prefix
   component in the BGP FS NLRI of the BGP FS RPD route;

   2) IGW2 identifies the Route Policy Distribution 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, IGW2 will choose the current best route of Prefix2;




Li, et al.               Expires January 7, 2016               [Page 13]


Internet-Draft                 BGP FS RPD                      July 2015


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

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

   IGW2 checks the matching criteria and finds that it hits the matching
   criteria: Local BGP Speaker IGW2, Remote BGP Peer N1, but the Match
   Type is "Deny" mode, so IGW2 sends the best route of Prefix2 to N1,
   without performing the Action instructions from the BGP FS RPD route.

   In like manner, the other IGWs will perform the same Action
   instructions as IGW1.

   Afterwards, client will choose the route to Prefix2 that it passes
   IGW2 and N1.  So the traffic destined for Prefix2 has been be
   scheduled to link N1 -> IGW2 for transmission.

5.  Additional Contributors

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

6.  IANA Considerations

   TBD.

7.  Security Considerations

   TBD.

8.  Acknowledgements

   The authors would like to thank xxx for their contributions to this
   work.

9.  References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760, January
              2007.



Li, et al.               Expires January 7, 2016               [Page 14]


Internet-Draft                 BGP FS RPD                      July 2015


   [RFC5492]  Scudder, J. and R. Chandra, "Capabilities Advertisement
              with BGP-4", RFC 5492, February 2009.

   [RFC5575]  Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
              and D. McPherson, "Dissemination of Flow Specification
              Rules", RFC 5575, August 2009.

Authors' Addresses

   Zhenbin Li
   Huawei Technologies
   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


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

   Email: zhuangshunwan@huawei.com








Li, et al.               Expires January 7, 2016               [Page 15]


Internet-Draft                 BGP FS RPD                      July 2015


   Nan Wu
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: eric.wu@huawei.com












































Li, et al.               Expires January 7, 2016               [Page 16]


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