< draft-xu-grow-bmp-route-policy-attr-trace-00.txt   draft-xu-grow-bmp-route-policy-attr-trace-01.txt >
Network Working Group F. Xu Network Working Group F. Xu
Internet-Draft Tencent Internet-Draft Tencent
Intended status: Standards Track Y. Gu Intended status: Standards Track Y. Gu
Expires: September 10, 2019 S. Zhuang Expires: January 8, 2020 S. Zhuang
Z. Li Z. Li
Huawei Huawei
March 9, 2019 July 7, 2019
BGP Route Policy and Attribute Trace Using BMP BGP Route Policy and Attribute Trace Using BMP
draft-xu-grow-bmp-route-policy-attr-trace-00 draft-xu-grow-bmp-route-policy-attr-trace-01
Abstract Abstract
The generation of BGP adj-rib-in, local-rib or adj-rib-out comes from The generation of BGP adj-rib-in, local-rib or adj-rib-out comes from
BGP protocol communication, and route policy processing. BGP BGP protocol communication, and route policy processing. BGP
Monitoring Protocol (BMP) provides the monitoring of BGP adj-rib-in Monitoring Protocol (BMP) provides the monitoring of BGP adj-rib-in
[RFC7854], BGP local-rib [I-D.ietf-grow-bmp-local-rib] and BGP adj- [RFC7854], BGP local-rib [I-D.ietf-grow-bmp-local-rib] and BGP adj-
rib-out [I-D.ietf-grow-bmp-adj-rib-out]. However, there lacks rib-out [I-D.ietf-grow-bmp-adj-rib-out]. However, there lacks
monitoring of how BGP routes are transformed from adj-rib-in into monitoring of how BGP routes are transformed from adj-rib-in into
local-rib and then adj-rib-out (i.e., the BGP route policy processing local-rib and then adj-rib-out (i.e., the BGP route policy processing
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2019. This Internet-Draft will expire on January 8, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. BGP Route Policy and Attribute Trace Overview . . . . . . 3 1.1. BGP Route Policy and Attribute Trace Overview . . . . . . 3
1.2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Extension of BMP for Route Policy and Attribute Trace . . . . 4 2. Extension of BMP for Route Policy and Attribute Trace . . . . 4
2.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Per Peer Header . . . . . . . . . . . . . . . . . . . . . 4 2.2. Per Peer Header . . . . . . . . . . . . . . . . . . . . . 4
2.3. Route Policy and Attribute Trace Message . . . . . . . . 4 2.3. Route Policy and Attribute Trace Message . . . . . . . . 4
3. Implementation Example . . . . . . . . . . . . . . . . . . . 7 2.3.1. VRF/Table Name TLV . . . . . . . . . . . . . . . . . 8
4. Implementation Considerations . . . . . . . . . . . . . . . . 10 2.3.2. Pre Policy Attribute TLV . . . . . . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 2.3.3. Post Policy Attribute TLV . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 2.3.4. Policy ID TLV . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 2.3.5. Optional TLV . . . . . . . . . . . . . . . . . . . . 11
8. Normative References . . . . . . . . . . . . . . . . . . . . 11 3. Implementation Considerations . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 4. Implementation Example . . . . . . . . . . . . . . . . . . . 12
4.1. Route Distribution Tracking . . . . . . . . . . . . . . . 12
4.2. Route Leak Detection . . . . . . . . . . . . . . . . . . 16
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. Normative References . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The typical processing procedure after receiving a BGP Update Message The typical processing procedure after receiving a BGP Update Message
at a routing device is as follows: 1. Adding the pre-policy routes 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 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 through inbound route policies; 3. Selecting the BGP best
routes from the post-policy routes; 4. Adding the selected routes 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- 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 rib to the core routing table manager for selection; 5-b. Filtering
skipping to change at page 3, line 44 skipping to change at page 4, line 4
There are cases that a new policy is configured incorrectly, e.g., There are cases that a new policy is configured incorrectly, e.g.,
setting an incorrect community value, or policy placed in incorrect setting an incorrect community value, or policy placed in incorrect
order among other policies. These may result in incorrect route order among other policies. These may result in incorrect route
attribute modification, best route selection mistake, or route attribute modification, best route selection mistake, or route
distribution mistake. With the correlated record of policy and distribution mistake. With the correlated record of policy and
route, the server/controller is able to identify the unexpected route route, the server/controller is able to identify the unexpected route
change and its responsible policy. Considering the fact that the BGP change and its responsible policy. Considering the fact that the BGP
route policy impacts not only the route processing within the route policy impacts not only the route processing within the
individual device but also the route distribution to its peers, the individual device but also the route distribution to its peers, the
route trace data of a signle device is always analyzed in correlation route trace data of a single device is always analyzed in correlation
with such data collected from its peer devices. with such data collected from its peer devices.
Apart from the policy validation application, the route trace data Apart from the policy validation application, the route trace data
can also be analyzed to discover the route propagation path within can also be analyzed to discover the route propagation path within
the network. With the route's inbound and outbound event records the network. With the route's inbound and outbound event records
collecte from each related device, the server is able to find the collect from each related device, the server is able to find the
propagation path hop by hop. The identified path is helpful for propagation path hop by hop. The identified path is helpful for
oeprators to better understand its network, and thus benefitting both operators to better understand its network, and thus benefitting both
network troubleshooting and network planning. network troubleshooting and network planning.
2. Extension of BMP for Route Policy and Attribute Trace 2. Extension of BMP for Route Policy and Attribute Trace
2.1. Common Header 2.1. Common Header
This document defines a new BMP message type to carry the Route This document defines a new BMP message type to carry the Route
Policy and Attribute Trace data. Policy and Attribute Trace data.
o Type = TBD: Route Policy and Attribute Trace Message o Type = TBD: Route Policy and Attribute Trace Message
skipping to change at page 4, line 29 skipping to change at page 5, line 5
2.2. Per Peer Header 2.2. Per Peer Header
The Route Policy and Attribute Trace Message is not per peer based, The Route Policy and Attribute Trace Message is not per peer based,
thus it does not require the Per Peer Header. thus it does not require the Per Peer Header.
2.3. Route Policy and Attribute Trace Message 2.3. Route Policy and Attribute Trace Message
The Route Policy and Attribute Trace Message format is defined as The Route Policy and Attribute Trace Message format is defined as
follows: follows:
+---------------------------------------------------------------+
| Route Distinguisher |
+---------------------------------------------------------------+
| Prefix length |
+---------------------------------------------------------------+
| Prefix |
+---------------------------------------------------------------+
| Previous Hop Length |
+---------------------------------------------------------------+
| Previous Hop |
+---------------------------------------------------------------+
| Event count |
+---------------------------------------------------------------+
| Total event length |
+---------------------------------------------------------------+
| 1st Event |
+---------------------------------------------------------------+
| 2nd Event |
+---------------------------------------------------------------+
~ ~
+ ...... +
~ ~
+---------------------------------------------------------------+
| Last Event |
+---------------------------------------------------------------+
Figure 1: Route Policy and Attribute Trace Message format
o Route Distinguisher (8 Bytes): indicates the route distinguisher
(RD) related to the route.
o Prefix Length (1 Byte): indicates the length of the prefix.
o Prefix (Variable): indicates the monitored prefix, with the length
defined by Prefix Length field.
o Previous Hop Length (1 Byte): indicates the length of the
following Previous Hop field. If the BGP peer ID of previous hop
is IPv4, it is set to 4, and if the BGP peer ID of the previous
hop is an IPv6, it is set to 16.
o Previous Hop (Variable): indicates the BGP peer ID where this
route is learnt from. If the route is locally generated, then
field is zero filled.
o Event Count (1 Byte): indicates the total number of policy
processing event recorded in this message.
o Total event length (2 Byte): indicates the total length of the
following fields including all events, where the total number is
indicated by the Event Count field.
o 1 ~ Last event: indicates each event, stacked one by one in order
of time. The event format is further defined as follows.
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Prefix length | | Single event length |
+---------------------------------------------------------------+
| Prefix |
+---------------------------------------------------------------+
| Route Distinguisher |
+---------------------------------------------------------------+
| Previous Hop |
+---------------------------------------------------------------+
| Event count |
+---------------------------------------------------------------+
| Total event length |
+---------------------------------------------------------------+
| Single event length (1st event) |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Event index | | Event index |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Timestamp(seconds) | | Timestamp(seconds) |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Timestamp(microseconds) | | Timestamp(microseconds) |
+--------------------------------+------------------------------+ +---------------------------------------------------------------+
| Policy ID | Policy distinguisher | | Policy Classification |
+--------------------------------+------------------------------+ +---------------------------------------------------------------+
| Peer ID | | Peer ID |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Peer AS | | Peer AS |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Peer VRF/Table name | | Path Identifier |
+--------------------------------+------------------------------+
| Peer AFI | Peer SAFI |
+--------------------------------+------------------------------+
| Total attribute length |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Attribute TLVs | | Peer AFI |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
~ ~ | Peer SAFI |
+ +
~ ~
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Single event length (Last event) | | VRF/Table Name TLV |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
~ ~ | Pre Policy Attribute TLV |
+ +
~ ~
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Attribute TLVs | | Post Policy Attribute TLV |
+---------------------------------------------------------------+
| Policy ID TLV |
+---------------------------------------------------------------+
| Optional TLV |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 2: Route Policy and Attribute Trace Message format Figure 2: Event format
o Prefix Length (1 Byte): indicates the length of the prefix.
o Prefix (Variable): indicates the monitored prefix, with the length
defined by Prefix Length field.
o Route Distinguisher (8 Bytes): If the route is an IPv4 route, this
field is zero- filled. If the peer is a VPNv4 route, it is set to
the route distinguisher (RD) of the route.
o Previous Hop (4 Bytes): indicates the BGP peer ID where this route
is learnt from. If the route is locally generated, then field is
set to the local BGP router ID (global or VRF specific).
o Event Count (1 Byte): indicates the total number of policy
processing event recorded in this message.
o Total event lenght (1 Byte): indicates the total length of the
following fields including all events, where the total number is
indicated by the Event Count field.
o Single event lenght (1 Byte): indicates the total length of a o Single event length (2 Byte): indicates the total length of a
single policy process event, including the following fields that single policy process event, including the following fields that
belong to this event. belong to this event.
o Event index (1 Byte): indicates the sequence number of this event, o Event index (1 Byte): indicates the sequence number of this event,
staring from 1 and increases by 1 for each event recorded in staring from 1 and increases by 1 for each event recorded in
order. order.
o Timestamp (4 Bytes): indicates the time when the policy of this o Timestamp (8 Bytes): indicates the time when the policy of this
event starts excution, expressed in seconds and microseconds since event starts execution, expressed in seconds and microseconds
midnight (zero hour), January 1, 1970 (UTC). since midnight (zero hour), January 1, 1970 (UTC).
o Policy ID (Variable): indicates the ID of the route policy of this
event, which is user specific or vendor specific. It consists of
the Route Policy Name and the Route Policy Item/Node ID. The
Policy name and Item/Node ID is in the format of ASCII string, the
length of both fields are indicated by the Policy length and Item/
Node length fields, respectively
o
+-------------------+--------------------+
| Policy length | Policy name |
+----------------------------------------+
| Item/node length| Item/Node ID |
+----------------------------------------+
o Policy Distinguisher (4 Bits): indicates the category of the
policy. Currently 3 policy categories are defined: "0000"
indicating the inbound policy, "0001" indicating the outbound
policy, "0010" indicating the redistribution policy. More
categories to be defined.
o Peer ID (4 Bytes): indicates the BGP Peer ID where this policy is o Peer ID (4 Bytes): indicates the BGP Peer ID where this policy is
configured under. This field is used in combination with the configured under. This field is used in combination with the
Policy Direction field. If the Policy Direction field is set to Policy Direction field. If the Policy Direction field is set to
"0000", meaning inbound policy, then this field is set to the BGP "0000", meaning Inbound policy, then this field is set to the BGP
Peer ID where the route is received from; if the Policy Direction Peer ID where the route is received from; if the Policy Direction
field is set to "0001", meaning outbound policy, then this field field is set to "0001", meaning Outbound policy, then this field
is set to the BGP Peer ID where the route is distributed to; If is set to the BGP Peer ID where the route is distributed to; If
the Policy Direction field is set to "0010", meaning the Policy Direction field is set to "0010", "0010","0100" meaning
redistribution policy, then this field is set to the local BGP Redistribution/Network/Aggregation policy, then this field is set
router ID (global or VRF specific). to all zeros.
o Peer AS (4 Bytes): indicates the AS number of the BGP Peer that o Peer AS (4 Bytes): indicates the AS number of the BGP Peer that
defined the Peer ID field. defined the Peer ID field.
o Policy Classification (1 Byte): indicates the category of the
policy. Currently 5 policy categories are defined: "0000"
indicating the Inbound policy, "0001" indicating the Outbound
policy, "0010" indicating the Redistribution policy (e.g., route
import from other sources, like ISIS/OSPF), "0011" indicates the
Route Leak policy (route leaking from the global routing table to
a VRF or from a VRF to the global routing table, or between VRFs),
"0100" indicates the Network policy (BGP network installment and
advertisement), "0101" indicating the Aggregation policy. More
categories can be defined.
o
+--------------------------------+
| Value |Policy Classification|
+--------------------------------+
| 00000000 | Inbound policy |
| 00000001 | Outbound policy |
| 00000010 | Redistribution |
| 00000011 | Route Leak |
| 00000100 | Network |
| 00000101 | Aggregation |
+----------+---------------------+
Table 1: Policy Classification
o 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.
o Peer AFI (2 Bytes)/Peer SAFI (1 Byte): indicates the AFI/SAFI of
the route. The AFI/SAFI information varies for the same route
under different policy processing event. For example, an IPv4
Unicast route is received from a CE router at the PE router
through eBGP, an RD is attached to this IPv4 Unicast route and
making it a VPNv4 route, and then this VPNv4 route is distributed
to the RR. During this process, the AFI/SAFI information changes
from IPv4 Unicast (1/1) to VPNv4 (1/128) at the inbound policy and
outbound policy.
o VRF/Table Name TLV (Variable): indicates the VRF name or table
name of the route. The format of the VRF/Table Name TLV is
further defined in Figure 3. The VRF/Table Name TLV is non-
optional.
o Pre-policy Attribute TLV (Variable): include the BGP route
atttributes 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.
o Post-policy Attribute TLV (Variable): include the BGP route
atttributes 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.
o Policy ID 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 6. The
Policy ID TLV is optional.
o Optional TLV (Variable): leaves for future extension. The
Optioanl TLV is optional.
2.3.1. VRF/Table Name TLV
+-------------------------------+-------------------------------+
| Type = TBD1 | VRF/Table name length |
+-------------------------------+-------------------------------+
| VRF/Table name |
+---------------------------------------------------------------+
Figure 3: VRF/Table name TLV
o Type = TBD1 (2 Byte): indicates the type of VRF/Table name TLV.
o VRF/Table name length (2 Byte): indicates the length of the VRF/
Table name field.
o VRF/Table name (Variable): indicates the VRF or table name of this o VRF/Table name (Variable): indicates the VRF or table name of this
route in the format of ASCII string. The string size MUST be route in the format of ASCII string. The string size MUST be
within the range of 1 to 255 bytes. The VRF/Table name within the range of 1 to 255 bytes. The VRF/Table name varies for
information varies for the same route under different policy the same route under different events. For example, an IPv4
processing event. For example, an IPv4 route is received from a Unicast route is received from a CE router at the PE router
CE router at the PE router through iGBP, an RD is attached to this through iBGP, an RD is attached to this IPv4 route (under VRF A)
IPv4 route (under VRF name A) and making it a VPNv4 route, and and making it a VPNv4 route, and then this VPNv4 route (under the
then this VPNv4 route (under the Global routing table) is Global routing table) is distributed to the RR. During the whole
distributed to the RR. During this process, the VRF/Table name process, the VRF/Table name changes from VRF A to the Global
information changes from VRF A to the Global routing Table name at routing Table name at the inbound event and outbound event.
the inbound and outbound policy process.
o AFI/SAFI (2 Bytes): indicates the AFI/SAFI of the route. The AFI/ 2.3.2. Pre Policy Attribute TLV
SAFI information varies for the same route under different policy
processing event. For example, an IPv4 route is received from a
CE router at the PE router through iGBP, an RD is attached to this
IPv4 route and making it a VPNv4 route, and then this VPNv4 route
is distributed to the RR. During this process, the AFI
information changes from IPv4 to VPNv4 at the inbound and outbound
policy process.
o Total attribute length (2 Bytes): indicates the total length of +-------------------------------+-------------------------------+
the following route attribute TLVs. | Type = TBD2 | Pre Policy Attr. length |
+-------------------------------+-------------------------------+
| Pre Policy Attribute sub TLVs |
+---------------------------------------------------------------+
o Attribute TLVs: include atttributes that are currently carried in Figure 4: Pre Policy Attribute TLV
BGP Update messages (e.g., Community, Ext-community, Next Hop, AS
path, MED...) and those that are not (to be defined).
3. Implementation Example o Type = TBD2 (2 Byte): indicates the type of Pre Policy Attribute
TLV.
o Pre Policy Attribute length (2 Byte): indicates the total length
of the following Pre Policy Attribute sub TLVs.
o Pre Policy Attribute sub TLVs (Variable): include the BGP route
attributes before the policy is executed.
2.3.3. Post Policy Attribute TLV
+-------------------------------+-------------------------------+
| Type = TBD3 | Post Policy Attr. length |
+-------------------------------+-------------------------------+
| Post Policy Attribute sub TLVs |
+---------------------------------------------------------------+
Figure 5: Post Policy Attribute TLV
o Type = TBD3 (2 Byte): indicates the type of Pre Policy Attribute
TLV.
o Pre Policy Attribute length (2 Byte): indicates the total length
of the following Pre Policy Attribute sub TLVs.
o Pre Policy Attribute sub TLVs (Variable): include the BGP route
attributes before the policy is executed.
2.3.4. Policy ID TLV
The Route Policy and Attribute Trace Message is not per peer based,
thus it does not require the Per Peer Header.
+------------------------+---------------------------+
| Type = TBD4 | Policy ID length |
+----------------------------------------------------+
|M| Res. | Policy Count |
+----------------------------------------------------+
| 1st Policy |C|R| Res. |
+----------------------------------------------------+
~ | ~
+ ... | ... +
~ | ~
+----------------------------------------------------+
| Last Policy |C|R| Res. |
+----------------------------------------------------+
Figure 6: Policy ID TLV
Considering the chaining and recursion of polices and policy items,
the Policy ID TLV is defined as follows.
o Type = TBD4 (2 Byte): indicates the type of Policy ID TLV.
o Policy ID length (2 Byte): indicates the length of the Policy ID
value field that follows it. The Policy ID value field includes
the Reserved bits, the Flag bits, Policy Count field, and Policy
field.
o Flag bit M (1 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 elsewise. The remaining 7 bits are
reserved for future extension.
o Policy Count (1 Byte): indicates the number of policies (in the
format of Policy name + Item ID) carried in this event.
o 1st ~ Last Policy (Variable): indicates the Policy name and the
Item ID of each policy match.
o Flag bit C (1 bit): indicates if the next subsequent policy has
chaining relationship to the current policy. "1" means it's
chaining relationship and "0" means elsewise. For the flag byte
following the Last Policy field, the C bit SHALL be set to "0".
o Flag bit R (1 bit): indicates if the next subsequent policy has
recursioning relationship to the current policy. "1" means it's
recursioning relationship and "0" means elsewise. For the flag
byte following the Last Policy field, the R bit SHALL be set to
"0".
+----------------------------------------+
| Policy Name length |
+----------------------------------------+
| Policy Name |
+----------------------------------------+
| Item ID length |
+----------------------------------------+
| Item ID |
+----------------------------------------+
Figure 7: Policy field format
The Policy ID field consists of the Route Policy Name and the Route
Policy Item ID. The Policy name and Item ID are in the format of
ASCII string, the length of both fields are indicated by the Policy
Name length (2 Bytes) and Item length (1 Byte) fields, respectively.
2.3.5. Optional TLV
+-------------------------------+-------------------------------+
| Type = TBD5 | Length |
+-------------------------------+-------------------------------+
| Value |
+---------------------------------------------------------------+
Figure 8: Optional TLV
The Optional TLV remains to be defined. One or more Optional TLV
types can be defined. One or more Optional TLVs can be used.
One possible way of utilizing the Optional TLV is to define a string
Type TLV. The String Type TLV allows flexible textual expression of
user-specific information without requiring structural format. Some
examples:
o The Policy ID TLV is defined as optional, considering that users
may don't want detailed information about the policy but only the
result and/or the reasons. Using a string type TLV, one may
express "Route rejected due to inbound filtering". However, such
expression still requires the tracking of policy processing in
realtime, it's just another form of tracking representation to the
BMP server and the user.
o Another possible application is for route leak detection. One may
express the business relations as "P2C", "P2P" and so on, with the
inbound filtering event or the outbound filtering event. Detailed
usage is discussed in Section 4.2.
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 Optional 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. Implementation Example
4.1. Route Distribution Tracking
+----------+ +----------+
+------>+BMP server+<-------+ +------>+BMP server+<-------+
| +--+-------+ | | +--+-------+ |
+ ^ ^ | + ^ ^ |
Event 1,2,3 +-----+ | + Event 1,2,3 +-----+ | +
+ + + Event 9,10,11 + + + Event 9,10,11
| Event 4,5 Event 6,7,8 + | Event 4,5 Event 6,7,8 +
| + + | | + + |
| | | | | | | |
10.1.1.1/24 ****|****|**********|***********|***** 10.1.1.1/32 ****|****|**********|***********|*****
+---------> * | | | | AS0* +---------> * | | | | AS0*
+-----+ * | | +--+--+ | * +-----+ * | | +--+--+ | *
| CE1 ++eBGP+ * | +--------->+ RR +------+ | * | CE1 ++eBGP+ * | +--------->+ RR +------+ | *
+-----+ | * | | | ++----+ | | * +-----+ | * | | | ++----+ | | *
AS1 | * | | | ^ iBGP | | * AS1 | * | | | ^ iBGP | | *
| * | | ++----+ | 65000:10 | | * 10.1.1.1/24 | * | | ++----+ | 65000:10 | | * 10.1.1.1/32
10.1.1.1/24 +----------> PE2 +---+10.1.1.1/24| | * +-----------> 10.1.1.1/32 +----------> PE2 +---+10.1.1.1/32| | * +----------->
+---------> * | | +-----+ | | * +-----+ +---------> * | | +-----+ | | * +-----+
+-----+ * | | iBGP | | * +eBGP+>+ CE4 | +-----+ * | | iBGP | | * +eBGP+>+ CE4 |
| CE2 ++eBGP+ * | | iBGP 65000:10 + | * | +-----+ | CE2 ++eBGP+ * | | iBGP 65000:10 + | * | +-----+
+-----+ | * | +65000:10 10.1.1.1/24 | * | AS4 +-----+ | * | +65000:10 10.1.1.1/32 | * | AS4
AS2 | * | 10.1.1.1/24 + | * | AS2 | * | 10.1.1.1/32 + | * |
| * ++----+ +--v-++ * | | * ++----+ +--v-++ * |
+-----+ +-----> PE1 | | PE3 +------+ +-----+ +-----+ +-----> PE1 | | PE3 +------+ +-----+
| CE3 ++eBGP+-----> +---------------->+ +------+eBGP+>+ CE5 | | CE3 ++eBGP+-----> | | +------+eBGP+>+ CE5 |
+-----+ * +-----+ +-----+ * +-----+ +-----+ * +-----+ +-----+ * +-----+
10.1.1.1/24 * * 10.1.1.1/24 10.1.1.1/32 * * 10.1.1.1/32
+--------> ************************************** +-----------> +--------> ************************************** +----------->
AS3 AS5 AS3 AS5
Figure 3: Route Policy and Attribute Trace record implementation example Figure 9: Route Policy and Attribute Trace record implementation example
We take the network shown in Figure 2 as an example to show how to We take the network shown in Figure 9 as an example to show how to
use Route Policy and Attribute Trace Messages to recover the use Route Policy and Attribute Trace Messages to recover the
footprint of the route propagation. Notice that only basic events footprint of the route propagation. Notice that only basic events
required for footprint recovery are listed here. required for footprint recovery are illustrated here. Also notice
that the event index shown in Figure 9, 10, 11 are for illustration
purpose, and may not reflect the actual indexing.
Suppose a prefix 10.1.1.1/24 is sent from both CE2 and CE3 to PE1 Suppose a prefix 10.1.1.1/32 is sent from both CE2 and CE3 to PE1
through eBGP peering, PE1 processes the two Update messages with through eBGP peering, PE1 processes the two Update messages through
inbound policies. Such procedure is recorded as two events, namely inbound policies. Such procedure is recorded as two events, namely
Event 1 and Event 2. Then PE1 selects the route from CE2 as the best Event 1 and Event 2. Then PE1 selects the route from CE2 as the best
route, add it to VRF 1, and then distribute the VPNv4 route to RR. route, add it to VRF 1, and then distribute the VPNv4 route to RR.
The distribution procedure is recorded by PE1 as Event 3. As an The distribution procedure is recorded by PE1 as Event 3. As an
example, the Route Policy and Attribute Trace Message of Event 1, 2, example, the Route Policy and Attribute Trace Message of Event 1, 2,
3 is listed as follows. Only fields related to footprint recovery 3 is listed as follows. Only fields related to footprint recovery
are listed in the message shown below. Specifically, the Previous are listed in the message shown below. Specifically, the Previous
Hop information is carried in Event 3 when outbounding the route, Hop information is carried in Event 3 when outbounding the route,
indicating that the outbounded route is learnt from CE2. The same indicating that the outbounded route is learnt from CE2. The same
prefix is sent from CE1 to PE2, added to VRF 1 and then distributed prefix is sent from CE1 to PE2, added to VRF 1 and then distributed
to RR in the form of VPNv4 route. Two events, Event 4 (inbound) and to RR in the form of VPNv4 route. Two events, Event 4 (inbound) and
Event 5 (outbound) are recorded by PE2. Now for RR, prefix Event 5 (outbound) are recorded by PE2. Now for RR, prefix
10.1.1.1/24 is received from both PE1 and PE2 in the form of VPNv4 10.1.1.1/32 is received from both PE1 and PE2 in the form of VPNv4
route. RR selects the route from CE2 as the best route, and route. RR selects the route from PE1 as the best route, and
distribute it to PE3. Three events, Event 6 (PE2 inbound), Event 7 distribute it to PE3. Three events, Event 6 (PE2 inbound), Event 7
(PE1 inbound), Event 8 (PE3 outbound) are recorded in this case. PE3 (PE1 inbound), Event 8 (PE3 outbound) are recorded in this case. PE3
receives the VPNv4 route from RR, adds it to VRF 1 and then receives the VPNv4 route from RR, adds it to VRF 1 and then
distribute the IPv4 route to CE4 and CE5, respectively. Here, three distribute the IPv4 route to CE4 and CE5, respectively. Here, three
events are recorded, Event 9 (RR inbound), Event 10 (CE4 outbound) events are recorded, Event 9 (RR inbound), Event 10 (CE4 outbound)
and Event 11 (CE5 outbound). and Event 11 (CE5 outbound).
+---------------------------------------------------------------+
| RD: 65000:10 |
+---------------------------------------------------------------+
| Prefix: 10.1.1.1/32 |
+---------------------------------------------------------------+
| Previous hop: CE2 |
+---------------------------------------------------------------+
| Event count: 2 |
+---------------------------------------------------------------+
| Event 1 |
+---------------------------------------------------------------+
| Timestamp 1 |
+---------------------------------------------------------------+
| Inbound policy |
+---------------------------------------------------------------+
| Peer ID: CE2 |
+---------------------------------------------------------------+
| Peer AS: AS2 |
+---------------------------------------------------------------+
| Path ID: 0 |
+---------------------------------------------------------------+
| AFI/SAFI: IPv4 Unicast |
+---------------------------------------------------------------+
| VRF/Table name: VRF 1 |
+---------------------------------------------------------------+
| Pre Policy Attributes |
+---------------------------------------------------------------+
| Post Policy Attributes |
+---------------------------------------------------------------+
| Policy ID: WC1, node 101 |
+---------------------------------------------------------------+
| Event 3 |
+---------------------------------------------------------------+
| Timestamp 3 |
+---------------------------------------------------------------+
| Outbound policy |
+---------------------------------------------------------------+
| Peer ID: RR |
+---------------------------------------------------------------+
| Peer AS: AS0 |
+---------------------------------------------------------------+
| Path ID: 0 |
+---------------------------------------------------------------+
| AFI/SAFI: VPNv4 |
+---------------------------------------------------------------+
| VRF/Table name: Global/Default |
+---------------------------------------------------------------+
| Pre Policy Attributes |
+---------------------------------------------------------------+
| Post Policy Attributes |
+---------------------------------------------------------------+
| Policy ID: RR1, node 200 |
+---------------------------------------------------------------+
Figure 10: Event 1,3 data view
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| RD: 65000:10 | | RD: 65000:10 |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Prefix: 10.1.1.1/24 | | Prefix: 10.1.1.1/32 |
+---------------------------------------------------------------+
| Event 1 |
+---------------------------------------------------------------+
| Timestamp 1 |
+--------------------------------+------------------------------+
| Policy ID: WC1, node 101 | Inbound policy |
+--------------------------------+------------------------------+
| Peer ID: CE1 |
+---------------------------------------------------------------+
| Peer AS: AS1 |
+---------------------------------------------------------------+
| VRF/Table name: VRF 1 |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| AFI: IPv4 | | Previous hop: CE3 |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Previous Hop: CE1 | | Event count: 1 |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Event 2 | | Event 2 |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Timestamp 2 | | Timestamp 2 |
+--------------------------------+------------------------------+
| Policy ID: WC1, node 102 | Inbound policy |
+--------------------------------+------------------------------+
| Peer ID: CE2 |
+---------------------------------------------------------------+
| Peer AS: AS2 |
+---------------------------------------------------------------+
| VRF/Table name: VRF 1 |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| AFI: IPv4 | | Inbound policy |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Previous Hop: CE2 | | Peer ID: CE3 |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Event 3 | | Peer AS: AS3 |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Timestamp 3 | | Path ID: 0 |
+--------------------------------+------------------------------+
| Policy ID: RR1, node 103 | Outbound policy |
+--------------------------------+------------------------------+
| Peer ID: RR |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Peer AS: AS0 | | AFI/SAFI: IPv4 Unicast |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| VRF/Table name: VRF 1 | | VRF/Table name: VRF 1 |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| AFI: VPNv4 | | Pre Policy Attributes |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Previous Hop: CE1 | | Post Policy Attributes |
+---------------------------------------------------------------+
| Policy ID: WC1, node 102 |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 4: Event 1,2,3 data partial view Figure 11: Event 2 data view
The BMP server can use the collected events to recover the route The BMP server can use the collected events to recover the route
footprint. The key information required from recovery is the footprint. The key information required from recovery is the
Timestamp of each event, and the Previous Hop of the route. The Timestamp of each event, and the Previous Hop of the route. The
Timestamp allows the server to identify the order of each event, Timestamp allows the server to identify the order of each event,
while the Previous Hop information, combined with the outbound peer while the Previous Hop information, combined with the outbound peer
information, allows the server to recover the route propagation hop information, allows the server to recover the route propagation hop
by hop. by hop.
4. Implementation Considerations 4.2. Route Leak Detection
Considering the data amount of monitoring the route and policy trace Reusing Figure 9, the Optional TLV of the RoFT Message can be
of all routes from all BMP clients, the Route Policy and Attribute utilized to carry user-specific strings. We present a route leak
Trace monitoring MAY be triggered by user at any user-specific time, detection example here.
and MAY be applied to user-specific routes as well as all routes.
Successive recored events from one device MAY be encapsulated in one Suppose, a route leak happens (10.1.1.1/32: AS2 --> AS0 --> AS4).
Route Policy and Attribute Trace Message or multiple Route Policy and The Bussiness relationships between ASes are shown in Table 2.
Attribute Trace Messages per the user configuration.
+----------------+--------------+
| Neighbor ASes | Bussiness |
| | Relationship |
+-------------------------------+
| AS 1 : AS 0 | P2C |
+-------------------------------+
| AS 2 : AS 0 | P2C |
+-------------------------------+
| AS 3 : AS 0 | P2C |
+-------------------------------+
| AS 0 : AS 4 | C2P |
+-------------------------------+
| AS 0 : AS 5 | P2C |
+----------------+--------------+
Table 2: Bussiness Relationship
To detect the route leak, the BMP server analyzes the events with
bussiness relationship information reported from the ingress device
and egress device of AS0 (regarding a specific route)). In this
example, regarding 10.1.1.1/32, data from PC1 and PE3 are analized.
The bussiness relationship can be expressed in strings, such as "P2C"
or "P2P". At PE1, when 10.1.1.1/32 is received from CE2 and going
through the inbound policy, PE1 uses the Optional TLV (more
specifically the String Type TLV) to carry the text "Bussiness
Relationship: P2C" in the Inound Policy event. On the other hand, at
PE3, when 10.1.1.1/32 goes through the outbound policy and then sent
to CE4, PE3 adds the "Bussiness Relationship: P2C", using the
Optional TLV, in the Outbound Policy event. More specifically, the
format of the above mentioned two events are listed in Figure 12
(Event 1) and Figure 13 (Event 10), respecitvely.
+---------------------------------------------------------------+
| RD: 65000:10 |
+---------------------------------------------------------------+
| Prefix: 10.1.1.1/32 |
+---------------------------------------------------------------+
| Previous hop: CE2 |
+---------------------------------------------------------------+
| Event count: 1 |
+---------------------------------------------------------------+
| Event 1 |
+---------------------------------------------------------------+
| Timestamp 1 |
+---------------------------------------------------------------+
| Inbound policy |
+---------------------------------------------------------------+
| Peer ID: CE2 |
+---------------------------------------------------------------+
| Peer AS: AS2 |
+---------------------------------------------------------------+
| Path ID: 0 |
+---------------------------------------------------------------+
| AFI/SAFI: IPv4 Unicast |
+---------------------------------------------------------------+
| VRF/Table name: VRF 1 |
+---------------------------------------------------------------+
| Pre Policy Attributes |
+---------------------------------------------------------------+
| Post Policy Attributes |
+---------------------------------------------------------------+
| Policy ID: WC1, node 101 |
+---------------------------------------------------------------+
| Optional TLV: "Bussiness Relationship: P2C" |
+---------------------------------------------------------------+
Figure 12: Event 1 data view
+---------------------------------------------------------------+
| RD: 65000:10 |
+---------------------------------------------------------------+
| Prefix: 10.1.1.1/32 |
+---------------------------------------------------------------+
| Previous hop: RR |
+---------------------------------------------------------------+
| Event count: 1 |
+---------------------------------------------------------------+
| Event 10 |
+---------------------------------------------------------------+
| Timestamp 10 |
+---------------------------------------------------------------+
| Outbound policy |
+---------------------------------------------------------------+
| Peer ID: CE4 |
+---------------------------------------------------------------+
| Peer AS: AS4 |
+---------------------------------------------------------------+
| Path ID: 0 |
+---------------------------------------------------------------+
| AFI/SAFI: IPv4 Unicast |
+---------------------------------------------------------------+
| VRF/Table name: VRF 3 |
+---------------------------------------------------------------+
| Pre Policy Attributes |
+---------------------------------------------------------------+
| Post Policy Attributes |
+---------------------------------------------------------------+
| Policy ID: OB1, node 300 |
+---------------------------------------------------------------+
| Optional TLV: "Bussiness Relationship: C2P" |
+---------------------------------------------------------------+
Figure 13: Event 10 data view
The BMP server can use the two Optional TLVs from Event 1 and Event
10 to detect the route leak. What's more, the repsonsible
configurations are directly shown in the two events, i.e., the
Inbound policy at PE1: "Policy ID: WC1, node 101", the Outbound
policy at PE3: "Policy ID: OB1, node 300". No need to correlate with
other data sources, the user can detect the leak and figure out the
root cause.
5. Acknowledgements 5. Acknowledgements
TBD. TBD.
6. IANA Considerations 6. IANA Considerations
TBD. TBD.
7. Security Considerations 7. Security Considerations
TBD. TBD.
8. Normative References 8. Normative References
[I-D.ietf-grow-bmp-adj-rib-out] [I-D.ietf-grow-bmp-adj-rib-out]
Evens, T., Bayraktar, S., Lucente, P., Mi, K., and S. Evens, T., Bayraktar, S., Lucente, P., Mi, K., and S.
Zhuang, "Support for Adj-RIB-Out in BGP Monitoring Zhuang, "Support for Adj-RIB-Out in BGP Monitoring
Protocol (BMP)", draft-ietf-grow-bmp-adj-rib-out-03 (work Protocol (BMP)", draft-ietf-grow-bmp-adj-rib-out-06 (work
in progress), December 2018. in progress), June 2019.
[I-D.ietf-grow-bmp-local-rib] [I-D.ietf-grow-bmp-local-rib]
Evens, T., Bayraktar, S., Bhardwaj, M., and P. Lucente, Evens, T., Bayraktar, S., Bhardwaj, M., and P. Lucente,
"Support for Local RIB in BGP Monitoring Protocol (BMP)", "Support for Local RIB in BGP Monitoring Protocol (BMP)",
draft-ietf-grow-bmp-local-rib-02 (work in progress), draft-ietf-grow-bmp-local-rib-04 (work in progress), June
September 2018. 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
 End of changes. 56 change blocks. 
179 lines changed or deleted 550 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/