BGP Extensions for Routing Policy Distribution (RPD)
draft-ietf-idr-rpd-07

Abstract

It is hard to adjust traffic and optimize traffic paths in a traditional IP network from time to time through manual configurations. It is desirable to have a mechanism for setting up routing policies, which adjusts traffic and optimizes 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

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 February 4, 2021.

Copyright Notice

Copyright (c) 2020 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
• 2. Terminology
• 3. Problem Statement
• 3.1. Inbound Traffic Control
• 3.2. Outbound Traffic Control
• 4. Protocol Extensions
• 4.1. Using a New AFI and SAFI
• 4.2. BGP Wide Community and Atoms
• 4.2.1. RouteAttr TLV/sub-TLV
• 4.2.2. Sub-TLVs of the Parameters TLV
• 4.3. Capability Negotiation
• 5. Routing Policy Considerations
• 6. Contributors
• 7. Security Considerations
• 8. Acknowledgements
• 9. IANA Considerations
• 9.1. Existing Assignments
• 9.2. Routing Policy Type Registry
• 9.3. RouteAttr Atom Type
• 9.4. Route Attributes Sub-TLV Registry
• 9.5. Attribute Change Sub-TLV Registry
• 10. References
• 10.1. Normative References
• 10.2. Informative References
• Authors' Addresses

1. Introduction

It is difficult to optimize traffic paths in a traditional IP network because of the following:

• Heavy and error prone configuration. 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.
• 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 routing policy 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.

• ACL: Access Control List
• BGP: Border Gateway Protocol [RFC4271]
• FS: Flow Specification
• NLRI: Network Layer Reachability Information [RFC4271]
• PBR: Policy-Based Routing
• RPD: Routing Policy Distribution
• VPN: Virtual Private Network

3. Problem Statement

Providers have the requirement to adjust their business traffic routing policies from time to time because of the following:

• Business development or network failure introduces link congestion and overload.
• Business changes or network additions produce unused resources such as idle links.
• Network transmission quality is decreased as the result of delay, loss and they need to adjust traffic to other paths.
• To control OPEX and CPEX, they may prefer the transit provider with lower price.

3.1. Inbound Traffic Control

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

Figure 1: Inbound Traffic Control case

In Figure 1, for the reasons above, the provider P of AS100 may wish the inbound traffic from AS200 to enter AS100 through link L3 instead of the others. Since P doesn't have any administrative control over AS200, there is no way for P to directly modify the route selection criteria inside AS200.

3.2. Outbound Traffic Control

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

Figure 2: Outbound Traffic Control case

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

4. Protocol Extensions

This document specifies a solution using a new AFI and SAFI with the BGP Wide Community for encoding a routing policy.

4.1. Using a New AFI and SAFI

A new AFI and SAFI are defined: the Routing Policy AFI whose codepoint 16398 has been assigned by IANA, and SAFI whose codepoint 75 has been 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. If the Length is anything other than 9 or 21, the NLRI is corrupt and the enclosing UPDATE message is ignored.

Policy Type:

1 octet indicates the type of a policy. 1 is for export policy. 2 is for import policy. If the Policy Type is any other value, the NLRI is corrupt and the enclosing UPDATE message is ignored.

Distinguisher:

4 octet value uniquely identifies the policy in the peer.

Peer IP:

4/16 octet value indicates an IPv4/IPv6 peer.

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

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

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

4.2. BGP Wide Community and Atoms

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.

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. The value of 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

4.2.1. RouteAttr TLV/sub-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.

 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. In RouteAttr TLV, four sub-TLVs are defined: IPv4 Prefix, IPv6 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  1      |         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:

1 for IPv4 Prefix.

Length:

N x 8, where N is the number of tuples <M-Type, Flags, IPv4 Address, Mask, GeMask, LeMask>. If Length is not a multiple of 8, the Atom is corrupt and the enclosing UPDATE message MUST be ignored.

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

M-Type = 2:

Match prefix less and equal to the given masks.

M-Type = 3:

Match prefix within the range of the given masks.

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

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  2      |      Length (Variable)        |  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    AS-Path Regex String                       |
:                                                               :
|                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Format of AS Path sub-TLV

Type:

2 for AS-Path.

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  3      |        Length (N x 4 + 1)       |    Flags    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Community 1 Value                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                              . . .                            ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Community N Value                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Format of Community sub-TLV

Type:

3 for Community.

Length:

N x 4 + 1, where N is the number of communities. If Length is not a multiple of 4 plus 1, the Atom is corrupt and the enclosing UPDATE MUST be ignored.

Flags:

1 octet. No flags are currently defined. These bits MUST be sent as zero and ignored on receipt.

4.2.2. Sub-TLVs of the Parameters TLV

For the 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 is MATCH AND SET ATTR, the Parameter(s) TLV can include 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  1      |          Length (5)           |      OP       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Value                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Format of MED Change sub-TLV

Type:

1 for MED Change.

Length:

5. If Length is any other value, the sub-TLV is corrupt and the enclosing UPDATE MUST be ignored.

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.

If OP is any other value, the sub-TLV is ignored.

Value:

4 octets.

An AS-Path change sub-TLV indicates an action to change the AS-Path. 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  2      |        Length (n x 5)         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             AS1                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Count1     |  
+-+-+-+-+-+-+-+-+
~       . . . 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             ASn                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Countn     |  
+-+-+-+-+-+-+-+-+

                      Format of AS-Path Change sub-TLV

Type:

2 for AS-Path Change.

Length:

n x 5. If Length is not a multiple of 5, the sub-TLV is corrupt and the enclosing UPDATE MUST be ignored.

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. 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 72 assigned 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>. If Send/Receive is any other value, that tuple is ignored but any other tuples present are still used.

5. Routing Policy Considerations

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:

• Control route advertising: Only routes that match the rules specified in a policy are advertised.
• Control route receiving: Only the required and valid routes are received. This reduces the size of the routing table and improves network security.
• 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.
• 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.
• 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

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

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

7. Security Considerations

Protocol extensions defined in this document do not affect BGP security other than as discussed in the Security Considerations section of [RFC5575].

8. Acknowledgements

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

9. IANA Considerations

9.1. Existing Assignments

IANA has assigned a new AFI of value 16398 from the registry "Address Family Numbers" for Routing Policy.

IANA has assigned a new SAFI of value 75 from the registry "Subsequent Address Family Identifiers (SAFI) Parameters" for Routing Policy.

IANA has assigned a new Code Point of value 72 from the registry "Capability Codes" for Routing Policy Distribution.

9.2. Routing Policy Type Registry

IANA is requested to create a new registry called "Routing Policy Type". The allocation policy of this registry is "First Come First Served (FCFS)".

   +-------------+-----------------------------------+-------------+
   | Code Point  | Description                       | Reference   |
   +-------------+-----------------------------------+-------------+
   |     0       |  Reserved                         |             |
   +-------------+-----------------------------------+-------------+
   |     1       | Export Policy                     |This document|
   +-------------+-----------------------------------+-------------+
   |     2       | Import Policy                     |This document|
   +-------------+-----------------------------------+-------------+
   |   3 - 255   |  Available                        |             |
   +-------------+-----------------------------------+-------------+

The initial code points are as follows:

9.3. RouteAttr Atom Type

   +---------------------+------------------------------+-------------+
   | TLV Code Point      | Description                  | Reference   |
   +---------------------+------------------------------+-------------+
   | TBD1 (48 suggested) | RouteAttr Atom               |This document|
   +---------------------+------------------------------+-------------+

IANA is requested to assign a code-point from the registry "BGP Community Container Atom Types" as follows:

9.4. Route Attributes Sub-TLV Registry

IANA is requested to create a new registry called "Route Attributes Sub-TLV" under RouteAttr Atom TLV. The allocation policy of this registry is "First Come First Served (FCFS)".

   +-------------+-----------------------------------+-------------+
   | Code Point  | Description                       | Reference   |
   +-------------+-----------------------------------+-------------+
   |      0      |  Reserved                         |             |
   +-------------+-----------------------------------+-------------+
   |      1      |  IPv4 Prefix Sub-TLV              |This document|
   +-------------+-----------------------------------+-------------+
   |      2      |  AS-Path Sub-TLV                  |This document|
   +-------------+-----------------------------------+-------------+
   |      3      |  Community Sub-TLV                |This document|
   +-------------+-----------------------------------+-------------+ 
   |      4      |  IPv6 Prefix Sub-TLV              |This document|
   +-------------+-----------------------------------+-------------+
   |   5 - 255   |  Available                        |             |
   +-------------+-----------------------------------+-------------+

The initial code points are as follows:

9.5. Attribute Change Sub-TLV Registry

IANA is requested to create a new registry called "Attribute Change Sub-TLV" under Parameter(s) TLV. The allocation policy of this registry is "First Come First Served (FCFS)".

   +-------------+-----------------------------------+-------------+
   | Code Point  | Description                       | Reference   |
   +-------------+-----------------------------------+-------------+
   |      0      |  Reserved                         |             |
   +-------------+-----------------------------------+-------------+
   |      1      |  MED Change Sub-TLV               |This document|
   +-------------+-----------------------------------+-------------+
   |      2      |  AS-Path Change Sub-TLV           |This document|
   +-------------+-----------------------------------+-------------+
   |   3 - 255   |  Available                        |             |
   +-------------+-----------------------------------+-------------+

Initial code points are as follows:

10. References

10.1. Normative References

10.2. Informative References

Authors' Addresses