| Internet-Draft | BGP RPD | January 2022 |
| Li, et al. | Expires 29 July 2022 | [Page] |
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.¶
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.¶
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 29 July 2022.¶
Copyright (c) 2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
It is difficult to optimize traffic paths in a traditional IP network because of the following:¶
It is desirable to have an automatic mechanism for setting up routing policies, which can simplify routing policy configuration and be fast. This document describes extensions to BGP for Routing Policy Distribution to resolve these issues.¶
The following terminology is used in this document.¶
Providers have the requirement to adjust their business traffic routing policies from time to time because of the following:¶
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.¶
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
<----------------------------------------
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.¶
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
<----------------------------------------
This document specifies a solution using a new AFI and SAFI with the BGP Wide Community for encoding a routing policy.¶
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:¶
Under RPD AFI/SAFI, the RPD routes are stored and ordered according to the keys (Policy type, Distinguisher, Peer IP). Under IPv4/IPv6 Unicast AFI/SAFI, there are IPv4/IPv6 unicast routes learned and various static policies configured. In addition, there are dynamic RPD policies from the RPD AFI/SAFI when RPD is enabled.¶
Before advertising an IPv4/IPv6 Unicast AFI/SAFI route, the configured policies are applied to it first, and then the RPD Export policies are applied.¶
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 as follows:¶
The content of the Routing Policy is encoded in a BGP Wide Community.¶
The BGP wide community attribute is defined in [I-D.ietf-idr-wide-bgp-communities]. This document specifies how two wide communities associate the routing policy NLRI to Routing Policy NLRI (section 4.1) to distribute routing policy to BGP peers. The wide communities which define routing policy are:¶
These wide communities are passed in the BGP wide community container in the wide community attribute. These communities support three of the optional TLVs: Target TLV, Exclude Target TLV, and Parameter 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 (RouteAttr), and two 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) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A RouteAttr Atom sub-TLV (or RouteAttr 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 (TBD3) | Length (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-sub-TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type for RouteAttr atom is TBD3. In RouteAttr sub-TLV, four sub-sub-TLVs are defined: IPv4 Prefix, IPv6 Prefix, AS-Path, and Community sub-sub-TLV.¶
An IP prefix sub-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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4-bit field specifying match type. The following four values are defined. IPaddress is the IP address in the sub-sub-TLV while IProute is the IP route being matched.¶
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 16.1.0.0/24 greater-equal 24 (i.e., route matches if route's first Mask=24 bits match 16.1.0 and 24 =< route's prefix length =< 32).¶
<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 (i.e., route matches if route's first Mask=24 bits match 17.1.0 and 24 =< route's prefix length <= 26).¶
<M-Type=3, Flags=0, IPv4 Address = 18.1.0.0, Mask = 24, GeMask = 24, LeMask = 30> represents match IP prefix 18.1.0.0/24 greater-equal 24 and less-equal 30 (i.e., route matches if route's first Mask=24 bits match 18.1.0 and 24 =< route's prefix length <= 30).¶
Similarly, an IPv6 Prefix sub-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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An AS-Path sub-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 | : : | ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A community sub-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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This document introduces 2 community values:¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 octet. Three are defined:¶
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 | +-+-+-+-+-+-+-+-+
The sequence of AS numbers are added to the existing AS Path.¶
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) | +--------------------------------------------------+
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.¶
This section presents a typical application scenario and some details about handling a related failure.¶
Figure 13 illustrates a typical scenario, where RPD is used by a controller with a Route Reflector (RR) to adjust traffic dynamically.¶
+--------------+
| Controller |
+-------+------+
\
\ RPD
.--\._.+--+ ___...__
__( \ '.---... ( )
/ RR o -------- A o) ---------- (o X AS2 )
(o E |\ ) _____//(___ ___)
( | \_______ B o) ____/ / '''
(o F \ ) ____/
( \_____ C o) ______/ ___...__
' AS1 _) \_____ ( )
'---._.-. ) \_______ (o Y AS3 )
'---' (___ ___)
'''
The controller connects the RR through a BGP session. There is a BGP session between the RR and each of routers A, B and C in AS1, which is shown in the figure. Other sessions in AS1 are not shown in the figure.¶
There is router X in AS2. There is a BGP session between X and each of routers A, B and C in AS1.¶
There is router Y in AS3. There is a BGP session between Y and router C in AS1.¶
The controller sends a RPD route to the RR. After receiving the RPD route from the controller, the RR reflects the RPD route to routers A, B and C. After receiving the RPD route from the RR, routers A, B and C extract the routing policy from the RPD route. If the peer IP in the NLRI of the RPD route is 0, then apply the routing policy to all the remote peers of routers A, B and C. If the peer IP in the NLRI of the RPD route is non-zero, then the IP address indicates a remote peer of routers A, B and C and such routing policy is applied to the specific remote peer. The IPv4/IPv6 unicast routes towards router X in AS2 and router Y in AS3 will be adjusted based on the routing policy sent by the controller via a RPD route.¶
The controller uses the RT extend community to notify a router whether to receive a RPD policy. For example, if there is not any adjustment on router B, the controller sends RPD routes with the RTs for A and C. B will not receive the routes.¶
The process of adjusting traffic in a network is a close loop. The loop starts from the controller with some traffic expectations on a set of routes. The controller obtains the information about traffic flows for the related routes. It analyzes the traffic and checks whether the current traffic flows meet the expectations. If the expectations are not met, the controller adjusts the traffic. And then the loop goes to the starter of the loop (The controller obtains the information about traffic ...).¶
This section describes some details about handling a failure related to a RPD route being applied.¶
A RPD route is not a configuration. When it is sent to a router from a controller, no ack is needed from the router. The existing BGP mechanisms are re-used for delivering a RPD route. After the route is delivered to a router, it will be successful. This is guaranteed by the BGP protocols.¶
If there is a failure for the router to install the route locally, this failure is a bug of the router. The bug needs to be fixed.¶
For the errors mentioned in [RFC7606], they are handled according to [RFC7606]. These errors are bugs, which need to be resolved.¶
When the controller fails while a RPD route is being applied such as on the way to the router, some existing mechanisms such BGP Graceful Restart (GR) [RFC4724] and BGP Long-lived Graceful Restart (LLGR) can be used to let the router keep the routes from the controller for some time.¶
With support of "Long-lived Graceful Restart Capability" [I-D.ietf-idr-long-lived-gr], the routes can be retained for a longer time after the controller fails.¶
After the controller recovers from its failure, the router will have all the routes (including the RPD route being applied) from the controller.¶
In the worst case, the controller fails and the RPD routes for adjusting the traffic are withdrawn. The traffic adjusted/redirected may take its old path. This should be acceptable.¶
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¶
Protocol extensions defined in this document do not affect BGP security other than as discussed in the Security Considerations section of [RFC8955].¶
The authors would like to thank Acee Lindem, Jeff Haas, Jie Dong, Lucy Yong, Qiandeng Liang, Zhenqiang Li, Robert Raszuk, Donald Eastlake, Ketan Talaulikar, and Jakob Heitz for their comments to this work.¶
IANA has assigned an AFI of value 16398 from the registry "Address Family Numbers" for Routing Policy.¶
IANA has assigned a SAFI of value 75 from the registry "Subsequent Address Family Identifiers (SAFI) Parameters" for Routing Policy.¶
IANA has assigned a Code Point of value 72 from the registry "Capability Codes" for Routing Policy Distribution.¶
IANA Should assign from the Registered Wide Community Values" the following values:¶
+---------------------+------------------------------+-------------+ | Community Value | Description | Reference | +---------------------+------------------------------+-------------+ | TBD1 | MATCH AND SET ATTR |This document| +---------------------+------------------------------+-------------+ | TBD2 | MATCH AND NOT ADVISE |This document| +---------------------+------------------------------+-------------+¶
IANA is requested to assign a code-point from the registry "BGP Community Container Atom Types" as follows:¶
+---------------------+------------------------------+-------------+ | Atom Code Point | Description | Reference | +---------------------+------------------------------+-------------+ | TBD3 (48 suggested) | RouteAttr Atom |This document| +---------------------+------------------------------+-------------+¶
IANA is requested to create a registry called "Route Attributes Sub-sub-TLV" under RouteAttr Atom Sub-TLV. The allocation policy of this registry is "First Come First Served (FCFS)".¶
The initial code points are as follows:¶
+-------------+-----------------------------------+-------------+ | Code Point | Description | Reference | +-------------+-----------------------------------+-------------+ | 0 | Reserved | | +-------------+-----------------------------------+-------------+ | 1 | IPv4 Prefix Sub-sub-TLV |This document| +-------------+-----------------------------------+-------------+ | 2 | AS-Path Sub-sub-TLV |This document| +-------------+-----------------------------------+-------------+ | 3 | Community Sub-sub-TLV |This document| +-------------+-----------------------------------+-------------+ | 4 | IPv6 Prefix Sub-sub-TLV |This document| +-------------+-----------------------------------+-------------+ | 5 - 255 | Available | | +-------------+-----------------------------------+-------------+¶
IANA is requested to create a registry called "Attribute Change Sub-TLV" under Parameter(s) TLV. The allocation policy of this registry is "First Come First Served (FCFS)".¶
Initial code points are as follows:¶
+-------------+-----------------------------------+-------------+ | Code Point | Description | Reference | +-------------+-----------------------------------+-------------+ | 0 | Reserved | | +-------------+-----------------------------------+-------------+ | 1 | MED Change Sub-TLV |This document| +-------------+-----------------------------------+-------------+ | 2 | AS-Path Change Sub-TLV |This document| +-------------+-----------------------------------+-------------+ | 3 - 255 | Available | | +-------------+-----------------------------------+-------------+¶