Internet DRAFT - draft-xu-grow-bmp-route-policy-attr-trace
draft-xu-grow-bmp-route-policy-attr-trace
Network Working Group F. Xu
Internet-Draft Tencent
Intended status: Standards Track T. Graf
Expires: 22 April 2024 Swisscom
Y. Gu
S. Zhuang
Z. Li
Huawei
20 October 2023
BGP Route Policy and Attribute Trace Using BMP
draft-xu-grow-bmp-route-policy-attr-trace-08
Abstract
The generation of BGP adj-rib-in, local-rib or adj-rib-out comes from
BGP route exchange and route policy processing. BGP Monitoring
Protocol (BMP) provides the monitoring of BGP adj-rib-in [RFC7854],
BGP local-rib [RFC9069] and BGP adj-rib-out [RFC8671]. By monitoring
these BGP RIB's the full state of the network is visible, but how
route-policies affect the route propagation or changes BGP attributes
is still not. This document describes a method of using BMP to
record the trace data on how BGP routes are (not) changed under the
process of route policies.
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 22 April 2024.
Xu, et al. Expires 22 April 2024 [Page 1]
Internet-Draft Route Policy-Attribute Trace October 2023
Copyright Notice
Copyright (c) 2023 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. BGP Route Policy and Attribute Trace Overview . . . . . . 3
1.2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Extension of BMP for Route Policy and Attribute Trace . . . . 4
2.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Per Peer Header . . . . . . . . . . . . . . . . . . . . . 4
2.3. Route Policy and Attribute Trace Message . . . . . . . . 4
2.3.1. VRF/Table TLV . . . . . . . . . . . . . . . . . . . . 7
2.3.2. Policy TLV . . . . . . . . . . . . . . . . . . . . . 8
2.3.3. Pre Policy Attribute TLV . . . . . . . . . . . . . . 12
2.3.4. Post Policy Attribute TLV . . . . . . . . . . . . . . 12
2.3.5. String TLV . . . . . . . . . . . . . . . . . . . . . 13
3. Implementation Considerations . . . . . . . . . . . . . . . . 14
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Normative References . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
The typical processing procedure after receiving a BGP Update Message
at a routing device is as follows: 1. Adding the pre-policy routes
into the pre-policy adj-rib-in (if any); 2. Filtering the pre-policy
routes through inbound route policies; 3. Selecting the BGP best
routes from the post-policy routes; 4. Adding the selected routes
into the BGP local-rib; 5-a. Adding the BGP best routes from local-
rib to the core routing table manager for selection; 5-b. Filtering
the routes from BGP local-rib through outbound route policies w.r.t.
per peer or peer groups; 6. Sending the BGP adj-rib-out to the
target peer or peer groups. Details may vary by vendors. The BGP
Monitoring Protocol (BMP) can be utilized to monitor BGP routes in
Xu, et al. Expires 22 April 2024 [Page 2]
Internet-Draft Route Policy-Attribute Trace October 2023
forms of adj-rib-in, local-rib and adj-rib-out. However, the
complete procedure from inbound to outbound policy processing,
including other policies, e.g., route redistribution, route selection
and so on, is currently unobserved. For example, there are 10 policy
items (or nodes) configured under one outbound route policy per a
specific peer. By collecting the local-rib and adj-rib-out through
BMP, the operator finds that the outbound policy didn't work as
expected. However, it's hard to distinguish which one of the 10
policy items/nodes is responsible for the failure.
1.1. BGP Route Policy and Attribute Trace Overview
This document describes a method that records and reports how each
policy item/node processes the routes (e.g., changes the route
attribute). Each policy item/node processing is called an event
thereafter in this document. Compared with conventional BGP rib
entry, which consists of prefix/mask, route attributes, e.g., next
hop, MED, local preference, AS path, and so on, the event record
discussed in this document includes extra information, such as event
index, timestamp, policy information, and so on. For example, if a
route is processed by 5 policy items/nodes, there can be 5 event
records for the same prefix/mask. Each event is numbered in order of
time (e.g., the time of policy execution). The policy information
includes the policy name and item/node ID/name so that the server/
controller can map to the exact policy either directly from the
device or from the configurations collected at the server side.
This document defines a new BMP message type to carry the recorded
policy and route data. More detailed message format is defined in
Section 2. The message is called the BMP Route Policy and Attribute
Trace Message thereafter in this document.
1.2. Use cases
There are cases that a new policy is configured incorrectly, e.g.,
setting an incorrect community value, or policy placed in incorrect
order among other policies. These may result in incorrect route
attribute modification, best route selection mistake, or route
distribution mistake. With the correlated record of policy and
route, the server/controller is able to identify the unexpected route
change and its responsible policy. Considering the fact that the BGP
route policy impacts not only the route processing within the
individual device but also the route distribution to its peers, the
route trace data of a single device is always analyzed in correlation
with such data collected from its peer devices.
Xu, et al. Expires 22 April 2024 [Page 3]
Internet-Draft Route Policy-Attribute Trace October 2023
Apart from the policy validation application, the route trace data
can also be analyzed to discover the route propagation path within
the network. With the route's inbound and outbound event records
collect from each related device, the server is able to find the
propagation path hop by hop. The identified path is helpful for
operators to better understand its network, and thus benefiting both
network troubleshooting and network planning.
2. Extension of BMP for Route Policy and Attribute Trace
2.1. Common Header
This document defines a new BMP message type to carry the Route
Policy and Attribute Trace data.
* Type = TBD: Route Policy and Attribute Trace Message
The new defined message type is indicated in the Message Type field
of the BMP common header.
2.2. Per Peer Header
The Route Policy and Attribute Trace Message is not per peer based,
thus it does not require the Per Peer Header.
2.3. Route Policy and Attribute Trace Message
The Route Policy and Attribute Trace Message format is defined as
follows:
Xu, et al. Expires 22 April 2024 [Page 4]
Internet-Draft Route Policy-Attribute Trace October 2023
+---------------------------------------------------------------+
|V| Reserved |
+---------------------------------------------------------------+
| Route Distinguisher |
+---------------------------------------------------------------+
| Prefix length |
+---------------------------------------------------------------+
| Prefix |
+---------------------------------------------------------------+
| Route Origin |
+---------------------------------------------------------------+
| Event count |
+---------------------------------------------------------------+
| Total event length |
+---------------------------------------------------------------+
| 1st Event |
+---------------------------------------------------------------+
| 2nd Event |
+---------------------------------------------------------------+
~ ~
+ ...... +
~ ~
+---------------------------------------------------------------+
| Last Event |
+---------------------------------------------------------------+
Figure 1: Route Policy and Attribute Trace Message format
* Flags (1 Byte): The V flag indicates that the Peer address is an
IPv6 address. For IPv4 peers, this is set to 0.
* Route Distinguisher (8 Bytes): indicates the route distinguisher
(RD) related to the route.
* Prefix Length (1 Byte): indicates the length of the prefix.
* Prefix (16 Bytes): indicates the monitored prefix, with mask
defined by Prefix Length field. It is 4 bytes long if an IPv4
address is carried in this field (with the 12 most significant
bytes zero-filled) and 16 bytes long if an IPv6 address is carried
in this field.
* Route Origin (4 Bytes): indicates the BGP router ID where this
route is learned from. If the route is locally generated, this
field is zero filled.
* Event Count (1 Byte): indicates the total number of policy
processing event recorded in this message.
Xu, et al. Expires 22 April 2024 [Page 5]
Internet-Draft Route Policy-Attribute Trace October 2023
* Total event length (2 Bytes): indicates the total length of the
following fields including all events, where the total number is
indicated by the Event Count field.
* 1 ~ Last event: indicates each event, stacked one by one in order
of time. The event format is further defined as follows.
+---------------------------------------------------------------+
| Single event length |
+---------------------------------------------------------------+
| Event index |
+---------------------------------------------------------------+
| Timestamp(seconds) |
+---------------------------------------------------------------+
| Timestamp(microseconds) |
+---------------------------------------------------------------+
| Path Identifier |
+---------------------------------------------------------------+
| AFI |
+---------------------------------------------------------------+
| SAFI |
+---------------------------------------------------------------+
| VRF/Table TLV |
+---------------------------------------------------------------+
| Policy TLV |
+---------------------------------------------------------------+
| Pre Policy Attribute TLV |
+---------------------------------------------------------------+
| Post Policy Attribute TLV |
+---------------------------------------------------------------+
| String TLV |
+---------------------------------------------------------------+
Figure 2: Event format
* Single event length (2 Bytes): indicates the total length of a
single policy process event, including the following fields that
belong to this event.
* Event index (1 Byte): indicates the sequence number of this event,
staring from 1 and increases by 1 for each event recorded in
order.
* Timestamp (8 Bytes): indicates the time when the policy of this
event starts execution, expressed in seconds and microseconds
since midnight (zero hour), January 1, 1970 (UTC).
Xu, et al. Expires 22 April 2024 [Page 6]
Internet-Draft Route Policy-Attribute Trace October 2023
* Path Identifier (4 Bytes): used to distinguish multiple BGP paths
for the same prefix. If there's no path ID, this field is zero
filled.
* AFI (2 Bytes)/SAFI (1 Byte): indicates the AFI/SAFI of the route.
* VRF/Table TLV (Variable): indicates the VRFinformation of the
route. The format of the VRF/Table TLV is further defined in
Figure 3. The VRF/Table ID TLV is optional. At most one VRF/
Table TLV can be included in each Route Policy and Attribute Trace
Message.
* Policy TLV (Variable): indicates the ID of the route policy of
this event, which is user specific or vendor specific, which can
be used for mapping to the actual policy content. The policy
content data retrieval is out of the scope of this document. The
format of the Policy ID TLV is further defined in Figure 4. The
Policy ID TLV is optional. At most one Policy TLV can be included
in each Route Policy and Attribute Trace Message.
* Pre Policy Attribute TLV (Variable): include the BGP route
attributes before the policy is executed. The format of the Pre-
policy Attribute TLV is further defined in Figure 4. The Pre-
policy Attribute TLV is optional. At most one Pre Policy
Attribute TLV can be included in each Route Policy and Attribute
Trace Message.
* Post Policy Attribute TLV (Variable): include the BGP route
attributes after the policy is executed. The format of the Post-
policy Attribute TLV is further defined in Figure 5. The Post-
policy Attribute TLV is optional. At most one Post Policy
Attribute TLV can be included in each Route Policy and Attribute
Trace Message.
* String TLV (Variable): leaves for future extension. The String
TLV is optional. One or more String TLVs can be included in each
Route Policy and Attribute Trace Message.
2.3.1. VRF/Table TLV
Xu, et al. Expires 22 April 2024 [Page 7]
Internet-Draft Route Policy-Attribute Trace October 2023
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 |
+-------------------------------+-------------------------------+
| VRF/Table ID |
+---------------------------------------------------------------+
~ VRF/Table Name ~
| |
+---------------------------------------------------------------+
Figure 3: VRF/Table TLV
* Type = TBD1 (2 Bytes): VRF/Table TLV.
* Length (2 Bytes): indicates the total length of the VRF/Table ID
field and the VRF/Table Name field.
* VRF/Table ID (4 Bytes): indicates the VRF or table ID of this
route.
* VRF/Table name (Variable): indicates the VRF or table name of this
route in the format of ASCII string. The string size MUST be
within the range of 1 to 255 bytes.
2.3.2. Policy TLV
Xu, et al. Expires 22 April 2024 [Page 8]
Internet-Draft Route Policy-Attribute Trace October 2023
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 |
+---------------+-------------------------------+---------------+
|M|P|D| Res. | Policy Count | Policy Class. |
+---------------+---------------+---------------+---------------+
~ Peer Address ~
+ +
+---------------------------------------------------------------+
| Peer Router ID |
+---------------------------------------------------------------+
| Peer AS |
+---------------------------------------------------------------+
~ ~
+ 1st Policy +---------------+
| |C|R| Res. |
+---------------------------------------------------------------+
~ . ~
+ . +
~ . ~
+---------------------------------------------------------------+
~ ~
+ Last Policy +---------------+
| |C|R| Res. |
+---------------------------------------------------------------+
Figure 4: Policy TLV
* Type = TBD2 (2 Bytes): Policy TLV.
* Length (2 Bytes): indicates the length of the Policy Value field
that follows it. The Policy value field includes the reserved
Flag Byte, Policy Count field, Policy Classification field, Peer
Router ID field, Peer AS field, and each Policy field.
Xu, et al. Expires 22 April 2024 [Page 9]
Internet-Draft Route Policy-Attribute Trace October 2023
* Flag Byte (1 Byte): the M bit (the left most bit) indicates if the
route in this event is matched (once or multiple times) or not by
any policies. "0" means no match and "1" means else wise. When
the M bit is set to "0", the Post Policy Attribute TLV SHALL not
be included in the Message. The P bit (the second left bit)
indicates if the matched result is Permit or Deny. "0" means Deny,
and "1" means Permit. When the M bit is set to "0", any value of
the P bit SHOULD be ignored. When the P bit is set to "0", the
Post Policy Attribute TLV SHALL not be included in the Message.
The D bit (the third left bit) indicates if there exists any
difference between the pre-policy attributes and the post policy
attributes. "0" means no difference, and "1" means difference
exists. When the D bit is set to "0", the Post Policy Attribute
TLV SHALL not be included in the Message.
* Policy Count (1 Byte): indicates the number of policies carried in
this event.
* Policy Classification (1 Byte): indicates the category of the
policy. Currently 8 policy categories are defined: "00000000"
indicates the Inbound policy; "00000001" indicates the Outbound
policy; "00000010" indicating the Multi-protocol Redistribute
policy (including routes import from other protocols, like ISIS/
OSPF and static routes), "00000011" indicates the Cross-VRF
Redistribute policy (route import between VRF and global table and
between VRFs); "00000100" indicates VRF Import policy (e.g., an
IPv4 route within a VRF transformed from a VPNv4 route),
"00000101" indicates VRF Export policy (e.g., a VPNv4 route
transformed from an IPv4 route within an VRF); "00000110"
indicates the Network policy (BGP network installment and
advertisement), "00000111" indicates the Aggregation policy;
"00001000" indicating the Route Withdraw (triggered by BGP Update
or local actions, e.g., route aggregation). Specifications
regarding each category can be included in the String TLV. For
the route update, i.e., route creation and withdrawal, that is not
processed by any route policy, the Policy Category field is set
per the route update point. In addition, the Policy ID field in
the Policy ID TLV SHOULD be set to 0.
Xu, et al. Expires 22 April 2024 [Page 10]
Internet-Draft Route Policy-Attribute Trace October 2023
+---------------------------------------+
| Value |Policy Classification |
+---------------------------------------+
| 00000000 | Inbound policy |
| 00000001 | Outbound policy |
| 00000010 | Multi-protocol Redistribute|
| 00000011 | Cross-VRF Redistribute |
| 00000100 | VRF import |
00000101 | VRF export |
| 00000110 | Network |
| 00000111 | Aggregation |
| 00001000 | Route Withdraw |
+----------+----------------------------+
Table 1: Policy Classification
* Peer Address: The remote IP address associated with the TCP
session over which the encapsulated PDU was received. It is 4
bytes long if an IPv4 address is carried in this field (with the
12 most significant bytes zero-filled) and 16 bytes long if an
IPv6 address is carried in this field.
* Peer Router ID (4 Bytes): indicates the BGP Router ID where this
policy is configured under. This field is used in combination
with the Policy Classification field. If the Policy
Classification field is set to "00000000", meaning Inbound policy,
then this field is set to the BGP router ID where the route is
received from; if the Policy Classification field is set to
"00000001", meaning Outbound policy, then this field is set to the
BGP router ID where the route is distributed to; If the Policy
Direction field is set to any other values, then this field is set
to all zeros.
* Peer AS (4 Bytes): indicates the AS number of the BGP Peer that
defined the Peer ID field.
* 1st ~ Last Policy (Variable): indicates the Policy name and the
Item ID of each policy match.
* Flag Byte (1 Byte): the C bit (left most bit) indicates if the
next subsequent policy has chaining relationship to the current
policy. "1" means it's chaining relationship and "0" means else
wise. For the flag byte following the Last Policy field, the C
bit SHALL be set to "0". The R bit (second left bit) indicates if
the next subsequent policy has recursion to the current policy.
"1" means it's recursion and "0" means else wise. For the flag
byte following the Last Policy field, the R bit SHALL be set to
"0".
Xu, et al. Expires 22 April 2024 [Page 11]
Internet-Draft Route Policy-Attribute Trace October 2023
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
+-------------------------------+-------------------------------+
| Policy Name Length | Policy Item ID Length |
+-------------------------------+-------------------------------+
~ Policy Name ~
+ +
+---------------------------------------------------------------+
~ Policy Item ID ~
+ +
+---------------------------------------------------------------+
Figure 5: Policy field format
The Policy field consists of the Policy Name (Variable) and the
Policy Item ID (Variable). The Policy Name and Policy Item ID fields
are in the format of ASCII string. The length of Policy Name is
indicated by the Policy Name Length (2 Bytes) field. The length of
Policy Item ID is indicated by the Policy Item ID Length (2 Bytes)
field.
2.3.3. Pre Policy Attribute TLV
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 |
+-------------------------------+-------------------------------+
~ Pre Policy Attribute sub TLVs ~
+ +
+---------------------------------------------------------------+
Figure 6: Pre Policy Attribute TLV
* Type = TBD3 (2 Bytes): Pre Policy Attribute TLV.
* Pre Policy Attribute length (2 Bytes): indicates the total length
of the following Pre Policy Attribute sub TLVs.
* Pre Policy Attribute sub TLVs (Variable): include the BGP route
attributes before the policy is executed.
2.3.4. Post Policy Attribute TLV
Xu, et al. Expires 22 April 2024 [Page 12]
Internet-Draft Route Policy-Attribute Trace October 2023
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 |
+-------------------------------+-------------------------------+
~ Post Policy Attribute sub TLVs ~
+ +
+---------------------------------------------------------------+
Figure 7: Post Policy Attribute TLV
* Type = TBD4 (2 Bytes): Post Policy Attribute TLV.
* Post Policy Attribute length (2 Bytes): indicates the total length
of the following Post Policy Attribute sub TLVs.
* Post Policy Attribute sub TLVs (Variable): include the BGP route
attributes after the policy is executed.
2.3.5. String TLV
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 |
+-------------------------------+-------------------------------+
~ Value ~
+ +
+---------------------------------------------------------------+
Figure 8: String TLV
* Type = TBD5 (2 Bytes): String TLV.
* Length (2 Bytes): indicates the length of the following value
field.
* Value (Variable): the textual expression of user-specific
information in ASCII format.
An example of using the String TLV is expressing the route policy
xpath information instead of using the Policy TLV.
Xu, et al. Expires 22 April 2024 [Page 13]
Internet-Draft Route Policy-Attribute Trace October 2023
3. Implementation Considerations
Considering the data amount of monitoring the route and policy trace
of all routes from all BMP clients, users MAY trigger the monitoring
at any user-specific time. Users MAY configure locally at the BMP
client to monitor only user-specific routes or all the routes. In
addition, users MAY configure locally at the BMP client whether to
report the TLVs that are optional according to their own
requirements, i.e., the Pre Policy Attribute TLV, Post Policy
Attribute TLV, Policy ID TLV, and String TLV.
Successive recored events from one device MAY be encapsulated in one
Route Policy and Attribute Trace Message or multiple Route Policy and
Attribute Trace Messages per the user configuration.
4. Acknowledgments
TBD.
5. IANA Considerations
This document defines the following new BMP Message type
(Section 2.1).
* Type = TBD: Route Policy and Attribute Trace Message.
This document defines the following new TLV types for the Route
Policy and Attribute Trace Message (Section 2.3).
* Type = TBD1 (2 Bytes): VRF/Table TLV.
* Type = TBD2 (2 Bytes): Policy TLV.
* Type = TBD3 (2 Bytes): Pre Policy Attribute TLV.
* Type = TBD4 (2 Bytes): Post Policy Attribute TLV.
* Type = TBD5 (2 Bytes): String TLV.
6. Security Considerations
TBD.
7. Normative References
Xu, et al. Expires 22 April 2024 [Page 14]
Internet-Draft Route Policy-Attribute Trace October 2023
[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>.
[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>.
[RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP
Monitoring Protocol (BMP)", RFC 7854,
DOI 10.17487/RFC7854, June 2016,
<https://www.rfc-editor.org/info/rfc7854>.
[RFC8671] Evens, T., Bayraktar, S., Lucente, P., Mi, P., and S.
Zhuang, "Support for Adj-RIB-Out in the BGP Monitoring
Protocol (BMP)", RFC 8671, DOI 10.17487/RFC8671, November
2019, <https://www.rfc-editor.org/info/rfc8671>.
[RFC9069] Evens, T., Bayraktar, S., Bhardwaj, M., and P. Lucente,
"Support for Local RIB in the BGP Monitoring Protocol
(BMP)", RFC 9069, DOI 10.17487/RFC9069, February 2022,
<https://www.rfc-editor.org/info/rfc9069>.
Authors' Addresses
Feng Xu
Tencent
Guangzhou
China
Email: oliverxu@tencent.com
Thomas Graf
Swisscom
Binzring 17
CH-8045 Zürich
Switzerland
Email: thomas.graf@swisscom.com
Xu, et al. Expires 22 April 2024 [Page 15]
Internet-Draft Route Policy-Attribute Trace October 2023
Yunan Gu
Huawei
Huawei Bld., No.156 Beiqing Rd.
Beijing
100095
China
Email: guyunan@huawei.com
Shunwan Zhuang
Huawei
Huawei Bld., No.156 Beiqing Rd.
Beijing
100095
China
Email: zhuangshunwan@huawei.com
Zhenbin Li
Huawei
Huawei Bld., No.156 Beiqing Rd.
Beijing
100095
China
Email: lizhenbin@huawei.com
Xu, et al. Expires 22 April 2024 [Page 16]
