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/