draft-ietf-grow-bmp-adj-rib-out-00.txt   draft-ietf-grow-bmp-adj-rib-out-01.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: December 18, 2017 NTT Communications Expires: September 3, 2018 NTT Communications
P. Mi P. Mi
Tencent Tencent
S. Zhuang S. Zhuang
Huawei Huawei
June 16, 2017 March 2, 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-00 draft-ietf-grow-bmp-adj-rib-out-01
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
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://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 December 18, 2017. This Internet-Draft will expire on September 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
(http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Per-Peer Header . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 6. BMP Messages . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Route Monitoring and Route Mirroring . . . . . . . . . . 4 6.1. Route Monitoring and Route Mirroring . . . . . . . . . . 5
6.2. Statistics Report . . . . . . . . . . . . . . . . . . . . 4 6.2. Statistics Report . . . . . . . . . . . . . . . . . . . . 5
6.3. Peer Down and Up Notifications . . . . . . . . . . . . . 5 6.3. Peer Down and Up Notifications . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6.3.1. Peer Up Information . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Other Considerations . . . . . . . . . . . . . . . . . . . . 6
8.1. BMP Peer Flags . . . . . . . . . . . . . . . . . . . . . 5 7.1. Peer and Update Groups . . . . . . . . . . . . . . . . . 6
8.2. BMP Statistics Types . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 6 9.1. BMP Peer Flags . . . . . . . . . . . . . . . . . . . . . 7
9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.2. BMP Statistics Types . . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 9.3. Peer UP Information TLV . . . . . . . . . . . . . . . . . 8
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 8
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
when an inbound policy applies attribute modification or filters. when an inbound policy applies attribute modification or filters.
skipping to change at page 4, line 24 skipping to change at page 4, line 29
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.
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). The L filters have been applied (e.g. Adj-RIB-Out Post-Policy). Some
flag MUST be set to 1 in this case to indicate post-policy. attributes are set when the BGP message is transmitted, such as next-
hop. Adj-RIB-Out Post-Policy MUST convey what is actually
transmitted to the peer, next-hop and any attribute set during
transmission should also be set and transmitted to the BMP receiver.
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. The L flag MUST be set to 0 in used to validate the outbound policy.
this case to indicate pre-policy.
Depending on BGP peering session type (IBGP, IBGP route reflector
client, EBGP) the candidate routes that make up the Pre-Policy Adj-
RIB-Out do not contain all local-rib routes. Pre-Policy Adj-RIB-Out
conveys only routes that are available based on the peering type.
Post-Policy represents the filtered/changed routes from the available
routes.
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,
or similar during this phase. All mandatory attributes, such as
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
empty mandatory attributes as self originated.
The L flag MUST be set to 0 to indicate pre-policy.
6. BMP Messages 6. BMP Messages
Many BMP messages have a per-peer header but some are not applicable Many BMP messages have a per-peer header but some are not applicable
to Adj-RIB-In or Adj-RIB-Out monitoring. Unless otherwise defined, to Adj-RIB-In or Adj-RIB-Out monitoring. Unless otherwise defined,
the O flag should be set to 0 in the per-peer header in BMP messages. the O flag should be set to 0 in the per-peer header in BMP messages.
6.1. Route Monitoring and Route Mirroring 6.1. Route Monitoring and Route Mirroring
The O flag MUST be set accordingly to indicate if the route monitor The O flag MUST be set accordingly to indicate if the route monitor
skipping to change at page 5, line 34 skipping to change at page 6, line 10
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.
7. Security Considerations 6.3.1. Peer Up Information
The following peer UP information TLV types are added:
o Type = TBD: Admin Label. The Information field contains a free-
form UTF-8 string whose length is given by the Information Length
field. The value is administratively assigned. There is no
requirement to terminate the string with null or any other
character.
Multiple admin labels can be included in the Peer UP. When
multiple admin labels are included the BMP receiver MUST preserve
the order.
The TLV is optional.
7. Other Considerations
7.1. Peer and Update Groups
Peer and update groups are used to group updates shared by many
peers. This is a level of efficiency in the implementation, not a
true representation of what is conveyed to a peer in either Pre-
Policy or Post-Policy.
One of the use-cases to monitor Adj-RIB-Out Post-Policy is to
validate and continually ensure the egress updates match what is
expected. For example, wholesale peers should never have routes with
community X:Y sent to them. In this use-case, there maybe hundreds
of wholesale peers but a single peer could have represented the
group.
A single peer could be used to represent a group. From a BMP
perspective, this should be simple to include a group name in the
PEER UP, but it is more complex than that. BGP implementations have
evolved to provide comprehensive and structured policy grouping, such
as session, afi/safi, and template based group policy inheritances.
This level of structure and inheritance of polices does not provide a
simple peer group name or ID, such as wholesale peer.
Instead of requiring a group name to be used, a new administrative
label informational TLV (Section 6.3.1) is added to the Peer UP
message. These labels have administrative scope relevance. For
example, labels "type=wholesale" and "region=west" could be used to
monitor expected policies.
Configuration and assignment of labels to peers is BGP implementation
specific.
8. Security Considerations
It is not believed that this document adds any additional security It is not believed that this document adds any additional security
considerations. considerations.
8. IANA Considerations 9. IANA Considerations
This document requests that IANA assign the following new parameters This document requests that IANA assign the following new parameters
to the BMP parameters name space [1]. to the BMP parameters name space [1].
8.1. BMP Peer Flags 9.1. BMP Peer Flags
This document defines the following new per-peer header flags This document defines the following new per-peer header flags
(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.
8.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 = TBD: (64-bit Gauge) Number of routes in Adj-RIBs-Out o Stat Type = TBD: (64-bit Gauge) Number of routes in Adj-RIBs-Out
Pre-Policy. Pre-Policy.
o Stat Type = TBD: (64-bit Gauge) Number of routes in Adj-RIBs-Out o Stat Type = TBD: (64-bit Gauge) Number of routes in Adj-RIBs-Out
Post-Policy. Post-Policy.
o Stat Type = TBD: Number of routes in per-AFI/SAFI Adj-RIB-Out Pre- o Stat Type = TBD: Number of routes in per-AFI/SAFI Adj-RIB-Out 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 = TBD: Number of routes in per-AFI/SAFI Adj-RIB-Out o Stat Type = TBD: Number of routes in per-AFI/SAFI Adj-RIB-Out
Post-Policy. The value is structured as: 2-byte Address Family Post-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. References 9.3. Peer UP Information TLV
9.1. Normative References This document defines the following new BMP PEER UP informational
message TLV types (Section 6.3.1):
o Type = TBD: Admin Label. The Information field contains a free-
form UTF-8 string whose length is given by the Information Length
field. The value is administratively given by the Information
Length field. The value is administratively assigned. There is
no requirement to terminate the string with null or any other
character.
10. 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
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://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,
<http://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
[RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP
Monitoring Protocol (BMP)", RFC 7854, Monitoring Protocol (BMP)", RFC 7854,
DOI 10.17487/RFC7854, June 2016, DOI 10.17487/RFC7854, June 2016,
<http://www.rfc-editor.org/info/rfc7854>. <https://www.rfc-editor.org/info/rfc7854>.
9.2. URIs 10.2. URIs
[1] https://www.iana.org/assignments/bmp-parameters/bmp- [1] https://www.iana.org/assignments/bmp-parameters/bmp-
parameters.xhtml parameters.xhtml
Acknowledgements Acknowledgements
The authors would like to thank John Scudder for his valuable input. The authors would like to thank John Scudder for his valuable input.
Contributors Contributors
 End of changes. 22 change blocks. 
35 lines changed or deleted 121 lines changed or added

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