draft-ietf-grow-bmp-adj-rib-out-02.txt   draft-ietf-grow-bmp-adj-rib-out-03.txt 
Global Routing Operations T. Evens Global Routing Operations T. Evens
Internet-Draft S. Bayraktar Internet-Draft S. Bayraktar
Updates: 7854 (if approved) Cisco Systems Updates: 7854 (if approved) Cisco Systems
Intended status: Standards Track P. Lucente Intended status: Standards Track P. Lucente
Expires: March 21, 2019 NTT Communications Expires: June 22, 2019 NTT Communications
P. Mi P. Mi
Tencent Tencent
S. Zhuang S. Zhuang
Huawei Huawei
September 17, 2018 December 19, 2018
Support for Adj-RIB-Out in BGP Monitoring Protocol (BMP) Support for Adj-RIB-Out in BGP Monitoring Protocol (BMP)
draft-ietf-grow-bmp-adj-rib-out-02 draft-ietf-grow-bmp-adj-rib-out-03
Abstract Abstract
The BGP Monitoring Protocol (BMP) defines access to only the Adj-RIB- The BGP Monitoring Protocol (BMP) defines access to only the Adj-RIB-
In Routing Information Bases (RIBs). This document updates the BGP In Routing Information Bases (RIBs). This document updates the BGP
Monitoring Protocol (BMP) RFC 7854 by adding access to the Adj-RIB- Monitoring Protocol (BMP) RFC 7854 by adding access to the Adj-RIB-
Out RIBs. It adds a new flag to the peer header to distinguish Adj- Out RIBs. It adds a new flag to the peer header to distinguish Adj-
RIB-In and Adj-RIB-Out. RIB-In and Adj-RIB-Out.
Status of This Memo Status of This Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 March 21, 2019. This Internet-Draft will expire on June 22, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 23 skipping to change at page 2, line 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Per-Peer Header . . . . . . . . . . . . . . . . . . . . . . . 4 4. Per-Peer Header . . . . . . . . . . . . . . . . . . . . . . . 4
5. Adj-RIB-Out . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Adj-RIB-Out . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Post-Policy . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. Post-Policy . . . . . . . . . . . . . . . . . . . . . . . 4
5.2. Pre-Policy . . . . . . . . . . . . . . . . . . . . . . . 4 5.2. Pre-Policy . . . . . . . . . . . . . . . . . . . . . . . 4
6. BMP Messages . . . . . . . . . . . . . . . . . . . . . . . . 5 6. BMP Messages . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Route Monitoring and Route Mirroring . . . . . . . . . . 5 6.1. Route Monitoring and Route Mirroring . . . . . . . . . . 5
6.2. Statistics Report . . . . . . . . . . . . . . . . . . . . 5 6.2. Statistics Report . . . . . . . . . . . . . . . . . . . . 5
6.3. Peer Down and Up Notifications . . . . . . . . . . . . . 5 6.3. Peer Down and Up Notifications . . . . . . . . . . . . . 6
6.3.1. Peer Up Information . . . . . . . . . . . . . . . . . 6 6.3.1. Peer Up Information . . . . . . . . . . . . . . . . . 6
7. Other Considerations . . . . . . . . . . . . . . . . . . . . 6 7. Other Considerations . . . . . . . . . . . . . . . . . . . . 6
7.1. Peer and Update Groups . . . . . . . . . . . . . . . . . 6 7.1. Peer and Update Groups . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9.1. BMP Peer Flags . . . . . . . . . . . . . . . . . . . . . 7 9.1. BMP Peer Flags . . . . . . . . . . . . . . . . . . . . . 7
9.2. BMP Statistics Types . . . . . . . . . . . . . . . . . . 7 9.2. BMP Statistics Types . . . . . . . . . . . . . . . . . . 7
9.3. Peer UP Information TLV . . . . . . . . . . . . . . . . . 8 9.3. Peer UP Information TLV . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
BGP Monitoring Protocol (BMP) defines monitoring of the received BGP Monitoring Protocol (BMP) defines monitoring of the received
(e.g. Adj-RIB-In) Routing Information Bases (RIBs) per peer. The (e.g. Adj-RIB-In) Routing Information Bases (RIBs) per peer. The
Adj-RIB-In pre-policy conveys to a BMP receiver all RIB data before Adj-RIB-In pre-policy conveys to a BMP receiver all RIB data before
any policy has been applied. The Adj-RIB-In post-policy conveys to a any policy has been applied. The Adj-RIB-In post-policy conveys to a
BMP receiver all RIB data after policy filters and/or modifications BMP receiver all RIB data after policy filters and/or modifications
have been applied. An example of pre-policy verses post-policy is have been applied. An example of pre-policy verses post-policy is
skipping to change at page 4, line 20 skipping to change at page 4, line 20
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|V|L|A|O| Resv | |V|L|A|O| Resv |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
o The O flag indicates Adj-RIB-In if set to 0 and Adj-RIB-Out if set o The O flag indicates Adj-RIB-In if set to 0 and Adj-RIB-Out if set
to 1. to 1.
The existing flags are defined in section 4.2 [RFC7854] and the The existing flags are defined in section 4.2 [RFC7854] and the
remaining bits are reserved for future use. They SHOULD be remaining bits are reserved for future use. They SHOULD be
transmitted as 0 and their values MUST be ignored on receipt. transmitted as 0 and their values MUST be ignored on receipt. The
following fields in Per-Peer Header are redefined:
o Peer Address: The remote IP address associated with the TCP
session over which the encapsulated PDU was sent.
o Peer AS: The Autonomous System number of the peer from which the
encapsulated PDU was sent.
o Peer BGP ID: The BGP Identifier of the peer from which the
encapsulated PDU was sent.
5. Adj-RIB-Out 5. Adj-RIB-Out
5.1. Post-Policy 5.1. Post-Policy
The primary use-case in monitoring Adj-RIB-Out is to monitor the The primary use-case in monitoring Adj-RIB-Out is to monitor the
updates transmitted to the BGP peer after outbound policy has been updates transmitted to the BGP peer after outbound policy has been
applied. These updates reflect the result after modifications and applied. These updates reflect the result after modifications and
filters have been applied (e.g. Adj-RIB-Out Post-Policy). Some filters have been applied (e.g. Adj-RIB-Out Post-Policy). Some
attributes are set when the BGP message is transmitted, such as next- attributes are set when the BGP message is transmitted, such as next-
skipping to change at page 4, line 45 skipping to change at page 5, line 6
The L flag MUST be set to 1 to indicate post-policy. The L flag MUST be set to 1 to indicate post-policy.
5.2. Pre-Policy 5.2. Pre-Policy
As with Adj-RIB-In policy validation, there are use-cases that pre- As with Adj-RIB-In policy validation, there are use-cases that pre-
policy Adj-RIB-Out is used to validate and audit outbound policies. policy Adj-RIB-Out is used to validate and audit outbound policies.
For example, a comparison between pre-policy and post-policy can be For example, a comparison between pre-policy and post-policy can be
used to validate the outbound policy. used to validate the outbound policy.
Depending on BGP peering session type (IBGP, IBGP route reflector Depending on BGP peering session type (IBGP, IBGP route reflector
client, EBGP) the candidate routes that make up the Pre-Policy Adj- client, EBGP, BGP confederations, Route Server Client) the candidate
RIB-Out do not contain all local-rib routes. Pre-Policy Adj-RIB-Out routes that make up the Pre-Policy Adj-RIB-Out do not contain all
conveys only routes that are available based on the peering type. local-rib routes. Pre-Policy Adj-RIB-Out conveys only routes that
Post-Policy represents the filtered/changed routes from the available are available based on the peering type. Post-Policy represents the
routes. filtered/changed routes from the available routes.
Some attributes are set only during transmission of the BGP message, Some attributes are set only during transmission of the BGP message,
e.g. Post-Policy. It is common that next-hop may be null, loopback, e.g. Post-Policy. It is common that next-hop may be null, loopback,
or similar during this phase. All mandatory attributes, such as or similar during this phase. All mandatory attributes, such as
next-hop, MUST be either ZERO or have an empty length if they are next-hop, MUST be either ZERO or have an empty length if they are
unknown at the Pre-Policy phase. The BMP receiver will treat zero or unknown at the Pre-Policy phase. The BMP receiver will treat zero or
empty mandatory attributes as self originated. empty mandatory attributes as self originated.
The L flag MUST be set to 0 to indicate pre-policy. The L flag MUST be set to 0 to indicate pre-policy.
skipping to change at page 5, line 31 skipping to change at page 5, line 41
6.2. Statistics Report 6.2. Statistics Report
Statistics report message has Stat Type field to indicate the Statistics report message has Stat Type field to indicate the
statistic carried in the Stat Data field. Statistics report messages statistic carried in the Stat Data field. Statistics report messages
are not specific to Adj-RIB-In or Adj-RIB-Out and MUST have the O are not specific to Adj-RIB-In or Adj-RIB-Out and MUST have the O
flag set to zero. The O flag SHOULD be ignored by the BMP receiver. flag set to zero. The O flag SHOULD be ignored by the BMP receiver.
The following new statistic types are added: The following new statistic types are added:
o Stat Type = TBD1: (64-bit Gauge) Number of routes in Adj-RIBs-Out o Stat Type = 14: (64-bit Gauge) Number of routes in Adj-RIBs-Out
Pre-Policy. Pre-Policy.
o Stat Type = TBD2: (64-bit Gauge) Number of routes in Adj-RIBs-Out o Stat Type = 15: (64-bit Gauge) Number of routes in Adj-RIBs-Out
Post-Policy. Post-Policy.
o Stat Type = TBD3: Number of routes in per-AFI/SAFI Adj-RIB-Out o Stat Type = 16: Number of routes in per-AFI/SAFI Adj-RIB-Out Pre-
Pre- Policy. The value is structured as: 2-byte Address Family Policy. The value is structured as: 2-byte Address Family
Identifier (AFI), 1-byte Subsequent Address Family Identifier Identifier (AFI), 1-byte Subsequent Address Family Identifier
(SAFI), followed by a 64-bit Gauge. (SAFI), followed by a 64-bit Gauge.
o Stat Type = TBD4: Number of routes in per-AFI/SAFI Adj-RIB-Out o Stat Type = 17: Number of routes in per-AFI/SAFI Adj-RIB-Out Post-
Post-Policy. The value is structured as: 2-byte Address Family Policy. The value is structured as: 2-byte Address Family
Identifier (AFI), 1-byte Subsequent Address Family Identifier Identifier (AFI), 1-byte Subsequent Address Family Identifier
(SAFI), followed by a 64-bit Gauge. (SAFI), followed by a 64-bit Gauge.
6.3. Peer Down and Up Notifications 6.3. Peer Down and Up Notifications
PEER UP and DOWN notifications convey BGP peering session state to PEER UP and DOWN notifications convey BGP peering session state to
BMP receivers. The state is independent of whether or not route BMP receivers. The state is independent of whether or not route
monitoring or route mirroring messages will be sent for Adj-RIB-In, monitoring or route mirroring messages will be sent for Adj-RIB-In,
Adj-RIB-Out, or both. BMP receiver implementations SHOULD ignore the Adj-RIB-Out, or both. BMP receiver implementations SHOULD ignore the
O flag in PEER UP and DOWN notifications. BMP receiver O flag in PEER UP and DOWN notifications. BMP receiver
implementations MUST use the per-peer header O flag in route implementations MUST use the per-peer header O flag in route
monitoring and mirroring messages in order to identify if the message monitoring and mirroring messages in order to identify if the message
is for Adj-RIB-In or Adj-RIB-Out. is for Adj-RIB-In or Adj-RIB-Out.
6.3.1. Peer Up Information 6.3.1. Peer Up Information
The following peer UP information TLV types are added: The following peer UP information TLV types are added:
o Type = TBD5: Admin Label. The Information field contains a free- o Type = 4: Admin Label. The Information field contains a free-form
form UTF-8 string whose length is given by the Information Length UTF-8 string whose length is given by the Information Length
field. The value is administratively assigned. There is no field. The value is administratively assigned. There is no
requirement to terminate the string with null or any other requirement to terminate the string with null or any other
character. character.
Multiple admin labels can be included in the Peer UP. When Multiple admin labels can be included in the Peer UP. When
multiple admin labels are included the BMP receiver MUST preserve multiple admin labels are included the BMP receiver MUST preserve
the order. the order.
The TLV is optional. The TLV is optional.
skipping to change at page 7, line 37 skipping to change at page 7, line 46
(Section 4): (Section 4):
o Flag 3 as O flag: The O flag indicates Adj-RIB-In if set to 0 and o Flag 3 as O flag: The O flag indicates Adj-RIB-In if set to 0 and
Adj-RIB-Out if set to 1. Adj-RIB-Out if set to 1.
9.2. BMP Statistics Types 9.2. BMP Statistics Types
This document defines four new statistic types for statistics This document defines four new statistic types for statistics
reporting (Section 6.2): reporting (Section 6.2):
o Stat Type = TBD1: (64-bit Gauge) Number of routes in Adj-RIBs-Out o Stat Type = 14: (64-bit Gauge) Number of routes in Adj-RIBs-Out
Pre-Policy. Pre-Policy.
o Stat Type = TBD2: (64-bit Gauge) Number of routes in Adj-RIBs-Out o Stat Type = 15: (64-bit Gauge) Number of routes in Adj-RIBs-Out
Post-Policy. Post-Policy.
o Stat Type = TBD3: Number of routes in per-AFI/SAFI Adj-RIB-Out o Stat Type = 16: Number of routes in per-AFI/SAFI Adj-RIB-Out Pre-
Pre- Policy. The value is structured as: 2-byte Address Family Policy. The value is structured as: 2-byte Address Family
Identifier (AFI), 1-byte Subsequent Address Family Identifier Identifier (AFI), 1-byte Subsequent Address Family Identifier
(SAFI), followed by a 64-bit Gauge. (SAFI), followed by a 64-bit Gauge.
o Stat Type = TBD4: Number of routes in per-AFI/SAFI Adj-RIB-Out o Stat Type = 17: Number of routes in per-AFI/SAFI Adj-RIB-Out Post-
Post-Policy. The value is structured as: 2-byte Address Family Policy. The value is structured as: 2-byte Address Family
Identifier (AFI), 1-byte Subsequent Address Family Identifier Identifier (AFI), 1-byte Subsequent Address Family Identifier
(SAFI), followed by a 64-bit Gauge. (SAFI), followed by a 64-bit Gauge.
9.3. Peer UP Information TLV 9.3. Peer UP Information TLV
This document defines the following new BMP PEER UP informational This document defines the following new BMP PEER UP informational
message TLV types (Section 6.3.1): message TLV types (Section 6.3.1):
o Type = TBD5: Admin Label. The Information field contains a free- o Type = 4: Admin Label. The Information field contains a free-form
form UTF-8 string whose length is given by the Information Length UTF-8 string whose length is given by the Information Length
field. The value is administratively given by the Information field. The value is administratively given by the Information
Length field. The value is administratively assigned. There is Length field. The value is administratively assigned. There is
no requirement to terminate the string with null or any other no requirement to terminate the string with null or any other
character. character.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
 End of changes. 18 change blocks. 
29 lines changed or deleted 39 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/