rfc9069v1.txt		rfc9069.txt
	Internet Engineering Task Force (IETF) T. Evens		Internet Engineering Task Force (IETF) T. Evens
	Request for Comments: 9069 S. Bayraktar		Request for Comments: 9069 S. Bayraktar
	Updates: 7854 M. Bhardwaj		Updates: 7854 M. Bhardwaj
	Category: Standards Track Cisco Systems		Category: Standards Track Cisco Systems
	ISSN: 2070-1721 P. Lucente		ISSN: 2070-1721 P. Lucente
	NTT Communications		NTT Communications
	October 2021		February 2022
	Support for Local RIB in the BGP Monitoring Protocol (BMP)		Support for Local RIB in the BGP Monitoring Protocol (BMP)
	Abstract		Abstract
	The BGP Monitoring Protocol (BMP) defines access to local Routing		The BGP Monitoring Protocol (BMP) defines access to local Routing
	Information Bases (RIBs). This document updates BMP (RFC 7854) by		Information Bases (RIBs). This document updates BMP (RFC 7854) by
	adding access to the Local Routing Information Base (Loc-RIB), as		adding access to the Local Routing Information Base (Loc-RIB), as
	defined in RFC 4271. The Loc-RIB contains the routes that have been		defined in RFC 4271. The Loc-RIB contains the routes that have been
	selected by the local BGP speaker's Decision Process.		selected by the local BGP speaker's Decision Process.
	skipping to change at line 36 ¶		skipping to change at line 36 ¶
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on		Internet Engineering Steering Group (IESG). Further information on
	Internet Standards is available in Section 2 of RFC 7841.		Internet Standards is available in Section 2 of RFC 7841.
	Information about the current status of this document, any errata,		Information about the current status of this document, any errata,
	and how to provide feedback on it may be obtained at		and how to provide feedback on it may be obtained at
	https://www.rfc-editor.org/info/rfc9069.		https://www.rfc-editor.org/info/rfc9069.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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
	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 Revised BSD License text as described in Section 4.e of the
	the Trust Legal Provisions and are provided without warranty as		Trust Legal Provisions and are provided without warranty as described
	described in the Simplified BSD License.		in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction		1. Introduction
	1.1. Alternative Method to Monitor Loc-RIB		1.1. Alternative Method to Monitor Loc-RIB
	2. Terminology		2. Terminology
	3. Definitions		3. Definitions
	4. Per-Peer Header		4. Per-Peer Header
	4.1. Peer Type		4.1. Peer Type
	4.2. Peer Flags		4.2. Peer Flags
	skipping to change at line 80 ¶		skipping to change at line 80 ¶
	6.1.1. Multiple Loc-RIB Peers		6.1.1. Multiple Loc-RIB Peers
	6.1.2. Filtering Loc-RIB to BMP Receivers		6.1.2. Filtering Loc-RIB to BMP Receivers
	6.1.3. Changes to Existing BMP Sessions		6.1.3. Changes to Existing BMP Sessions
	7. Security Considerations		7. Security Considerations
	8. IANA Considerations		8. IANA Considerations
	8.1. BMP Peer Type		8.1. BMP Peer Type
	8.2. BMP Loc-RIB Instance Peer Flags		8.2. BMP Loc-RIB Instance Peer Flags
	8.3. Peer Up Information TLV		8.3. Peer Up Information TLV
	8.4. Peer Down Reason Code		8.4. Peer Down Reason Code
	8.5. Deprecated Entries		8.5. Deprecated Entries
	9. Normative References		9. References
	10. Informative References		9.1. Normative References
			9.2. Informative References
	Acknowledgements		Acknowledgements
	Authors' Addresses		Authors' Addresses
	1. Introduction		1. Introduction
	This document defines a mechanism to monitor the BGP Loc-RIB state of		This document defines a mechanism to monitor the BGP Loc-RIB state of
	remote BGP instances without the need to establish BGP peering		remote BGP instances without the need to establish BGP peering
	sessions. BMP [RFC7854] does not define a method to send the BGP		sessions. BMP [RFC7854] does not define a method to send the BGP
	instance Loc-RIB. It does define locally originated routes in		instance Loc-RIB. It does define locally originated routes in
	Section 8.2 of [RFC7854], but these routes are defined as the routes		Section 8.2 of [RFC7854], but these routes are defined as the routes
	that originated into BGP. For example, as described by Section 9.4		that originated into BGP (e.g., Section 9.4 of [RFC4271]). Loc-RIB
	of [RFC4271]. Loc-RIB includes all selected received routes from BGP		includes all selected received routes from BGP peers in addition to
	peers in addition to locally originated routes.		locally originated routes.
	Figure 1 shows the flow of received routes from one or more BGP peers		Figure 1 shows the flow of received routes from one or more BGP peers
	into the Loc-RIB.		into the Loc-RIB.
	+------------------+ +------------------+		+------------------+ +------------------+
	| Peer-A | | Peer-B |		| Peer-A | | Peer-B |
	/-- | | ---- | | --\		/-- | | ---- | | --\
	| | Adj-RIB-In (Pre) | | Adj-RIB-In (Pre) | |		| | Adj-RIB-In (Pre) | | Adj-RIB-In (Pre) | |
	| +------------------+ +------------------+ |		| +------------------+ +------------------+ |
	| | | |		| | | |
	skipping to change at line 234 ¶		skipping to change at line 235 ¶
	when peering may not have even been required in the first place.		when peering may not have even been required in the first place.
	For example, virtual routing and forwarding (VRF) tables with no		For example, virtual routing and forwarding (VRF) tables with no
	peers, redistributed BGP-LS with no peers, and segment routing		peers, redistributed BGP-LS with no peers, and segment routing
	egress peer engineering where no peers have link-state address		egress peer engineering where no peers have link-state address
	family enabled are all situations with no preexisting BGP peers.		family enabled are all situations with no preexisting BGP peers.
	Many complexities are introduced when using a received Adj-RIB-In to		Many complexities are introduced when using a received Adj-RIB-In to
	infer a router Loc-RIB:		infer a router Loc-RIB:
	* Adj-RIB-Out received as Adj-RIB-In from another router may have a		* Adj-RIB-Out received as Adj-RIB-In from another router may have a
	policy applied that filters, generates aggregates, suppresses more		policy applied that generates aggregates, suppresses more specific
	specific prefixes, manipulates attributes, or filters routes. Not		prefixes, manipulates attributes, or filters routes. Not only
	only does this invalidate the Loc-RIB view, it adds complexity		does this invalidate the Loc-RIB view, it adds complexity when
	when multiple BMP routers may have peering sessions to the same		multiple BMP routers may have peering sessions to the same router.
	router. The BMP receiver user is left with the error-prone task		The BMP receiver user is left with the error-prone task of
	of identifying which peering session is the best representative of		identifying which peering session is the best representative of
	the Loc-RIB.		the Loc-RIB.
	* BGP peering is designed to work between administrative domains and		* BGP peering is designed to work between administrative domains and
	therefore does not need to include internal system-level		therefore does not need to include internal system-level
	information of each peering router (e.g., the system name or		information of each peering router (e.g., the system name or
	version information). In order to derive the Loc-RIB of a router,		version information). In order to derive the Loc-RIB of a router,
	the router name or other system information is needed. The BMP		the router name or other system information is needed. The BMP
	receiver and user are forced to do some type of correlation using		receiver and user are forced to do some type of correlation using
	whatever information is available in the peering session (e.g.,		whatever information is available in the peering session (e.g.,
	peering addresses, autonomous system numbers, and BGP		peering addresses, autonomous system numbers, and BGP
	skipping to change at line 312 ¶		skipping to change at line 313 ¶
	Section 4.2 of [RFC7854] defines a Local Instance Peer type, which is		Section 4.2 of [RFC7854] defines a Local Instance Peer type, which is
	for the case of non-RD peers that have an instance identifier.		for the case of non-RD peers that have an instance identifier.
	This document defines the following new peer type:		This document defines the following new peer type:
	* Peer Type = 3: Loc-RIB Instance Peer		* Peer Type = 3: Loc-RIB Instance Peer
	4.2. Peer Flags		4.2. Peer Flags
	If locally sourced routes are communicated using BMP, they MUST be		If locally sourced routes are communicated using BMP, they MUST be
	conveyed using the Loc-RIB instance peer type.		conveyed using the Loc-RIB Instance Peer Type.
	The per-peer header flags for the Loc-RIB Instance Peer type are		The per-peer header flags for the Loc-RIB Instance Peer Type are
	defined as follows:		defined as follows:
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|F| | | | | | | |		|F| | | | | | | |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	* The F flag indicates that the Loc-RIB is filtered. This MUST be		* The F flag indicates that the Loc-RIB is filtered. This MUST be
	set when a filter is applied to Loc-RIB routes sent to the BMP		set when a filter is applied to Loc-RIB routes sent to the BMP
	collector.		collector.
	skipping to change at line 356 ¶		skipping to change at line 357 ¶
	Peer Type: Set to 3 to indicate Loc-RIB Instance Peer.		Peer Type: Set to 3 to indicate Loc-RIB Instance Peer.
	Peer Distinguisher: Zero-filled if the Loc-RIB represents the global		Peer Distinguisher: Zero-filled if the Loc-RIB represents the global
	instance. Otherwise, set to the route distinguisher or unique		instance. Otherwise, set to the route distinguisher or unique
	locally defined value of the particular instance to which the Loc-		locally defined value of the particular instance to which the Loc-
	RIB belongs.		RIB belongs.
	Peer Address: Zero-filled. The remote peer address is not		Peer Address: Zero-filled. The remote peer address is not
	applicable. The V flag is not applicable with the Loc-RIB		applicable. The V flag is not applicable with the Loc-RIB
	Instance peer type considering addresses are zero-filled.		Instance Peer Type considering addresses are zero-filled.
	Peer Autonomous System (AS): Set to the primary router BGP		Peer Autonomous System (AS): Set to the primary router BGP
	autonomous system number (ASN).		autonomous system number (ASN).
	Peer BGP ID: Set to the BGP instance global or RD (e.g., VRF)		Peer BGP ID: Set the ID to the router-id of the VRF instance if VRF
	specific router ID (Section 1.1 of [RFC7854]).		is used; otherwise, set to the global instance router-id.
	Timestamp: The time when the encapsulated routes were installed in		Timestamp: The time when the encapsulated routes were installed in
	the Loc-RIB, expressed in seconds and microseconds since midnight		the Loc-RIB, expressed in seconds and microseconds since midnight
	(zero hour), January 1, 1970 (UTC). If zero, the time is		(zero hour), January 1, 1970 (UTC). If zero, the time is
	unavailable. Precision of the timestamp is implementation		unavailable. Precision of the timestamp is implementation
	dependent.		dependent.
	5.2. Peer Up Notification		5.2. Peer Up Notification
	Peer Up notifications follow Section 4.10 of [RFC7854] with the		Peer Up notifications follow Section 4.10 of [RFC7854] with the
	following clarifications:		following clarifications:
	Local Address: Zero-filled; the local address is not applicable.		Local Address: Zero-filled; the local address is not applicable.
	Local Port: Set to 0; the local port is not applicable.		Local Port: Set to 0; the local port is not applicable.
	Remote Port: Set to 0; the remote port is not applicable.		Remote Port: Set to 0; the remote port is not applicable.
	Sent OPEN Message: This is a fabricated BGP OPEN message.		Sent OPEN Message: This is a fabricated BGP OPEN message.
	Capabilities MUST include the 4-octet ASN and all necessary		Capabilities MUST include the 4-octet ASN and all necessary
	capabilities to represent the Loc-RIB route monitoring messages.		capabilities to represent the Loc-RIB Route Monitoring messages.
	Only include capabilities if they will be used for Loc-RIB		Only include capabilities if they will be used for Loc-RIB
	monitoring messages. For example, if ADD-PATH is enabled for IPv6		monitoring messages. For example, if ADD-PATH is enabled for IPv6
	and Loc-RIB contains additional paths, the ADD-PATH capability		and Loc-RIB contains additional paths, the ADD-PATH capability
	should be included for IPv6. In the case of ADD-PATH, the		should be included for IPv6. In the case of ADD-PATH, the
	capability intent of advertise, receive, or both can be ignored		capability intent of advertise, receive, or both can be ignored
	since the presence of the capability indicates enough that		since the presence of the capability indicates enough that
	additional paths will be used for IPv6.		additional paths will be used for IPv6.
	Received OPEN Message: Repeat of the same sent OPEN message. The		Received OPEN Message: Repeat of the same sent OPEN message. The
	duplication allows the BMP receiver to parse the expected received		duplication allows the BMP receiver to parse the expected received
	skipping to change at line 453 ¶		skipping to change at line 454 ¶
	5.4. Route Monitoring		5.4. Route Monitoring
	Route Monitoring messages are used for initial synchronization of the		Route Monitoring messages are used for initial synchronization of the
	Loc-RIB. They are also used to convey incremental Loc-RIB changes.		Loc-RIB. They are also used to convey incremental Loc-RIB changes.
	As described in Section 4.6 of [RFC7854], "Following the common BMP		As described in Section 4.6 of [RFC7854], "Following the common BMP
	header and per-peer header is a BGP Update PDU."		header and per-peer header is a BGP Update PDU."
	5.4.1. ASN Encoding		5.4.1. ASN Encoding
	Loc-RIB route monitor messages MUST use a 4-byte ASN encoding as		Loc-RIB Route Monitoring messages MUST use a 4-byte ASN encoding as
	indicated in the Peer Up sent OPEN message (Section 5.2) capability.		indicated in the Peer Up sent OPEN message (Section 5.2) capability.
	5.4.2. Granularity		5.4.2. Granularity
	State compression and throttling SHOULD be used by a BMP sender to		State compression and throttling SHOULD be used by a BMP sender to
	reduce the amount of route monitoring messages that are transmitted		reduce the amount of Route Monitoring messages that are transmitted
	to BMP receivers. With state compression, only the final resultant		to BMP receivers. With state compression, only the final resultant
	updates are sent.		updates are sent.
	For example, prefix 192.0.2.0/24 is updated in the Loc-RIB 5 times		For example, prefix 192.0.2.0/24 is updated in the Loc-RIB 5 times
	within 1 second. State compression of BMP route monitor messages		within 1 second. State compression of BMP Route Monitoring messages
	results in only the final change being transmitted. The other 4		results in only the final change being transmitted. The other 4
	changes are suppressed because they fall within the compression		changes are suppressed because they fall within the compression
	interval. If no compression was being used, all 5 updates would have		interval. If no compression was being used, all 5 updates would have
	been transmitted.		been transmitted.
	A BMP receiver should expect that Loc-RIB route monitoring		A BMP receiver should expect that the granularity of Loc-RIB Route
	granularity can be different by BMP sender implementation.		Monitoring can vary depending on the BMP sender implementation.
	5.5. Route Mirroring		5.5. Route Mirroring
	Section 4.7 of [RFC7854] defines Route Mirroring for verbatim		Section 4.7 of [RFC7854] defines Route Mirroring for verbatim
	duplication of messages received. This is not applicable to Loc-RIB		duplication of messages received. This is not applicable to Loc-RIB
	as PDUs are originated by the router. Any received Route Mirroring		as PDUs are originated by the router. Any received Route Mirroring
	messages SHOULD be ignored.		messages SHOULD be ignored.
	5.6. Statistics Report		5.6. Statistics Report
	skipping to change at line 569 ¶		skipping to change at line 570 ¶
	+-----------+-----------------------+		+-----------+-----------------------+
	Table 1: BMP Peer Type		Table 1: BMP Peer Type
	8.2. BMP Loc-RIB Instance Peer Flags		8.2. BMP Loc-RIB Instance Peer Flags
	IANA has renamed "BMP Peer Flags" to "BMP Peer Flags for Peer Types 0		IANA has renamed "BMP Peer Flags" to "BMP Peer Flags for Peer Types 0
	through 2" and created a new registry named "BMP Peer Flags for Loc-		through 2" and created a new registry named "BMP Peer Flags for Loc-
	RIB Instance Peer Type 3".		RIB Instance Peer Type 3".
	This document defines peer flags that are being specific to the Loc-		This document defines peer flags that are specific to the Loc-RIB
	RIB instance peer type. IANA has registered the following in the		Instance Peer Type. IANA has registered the following in the "BMP
	"BMP Peer Flags for Loc-RIB Instance Peer Type 3" registry:		Peer Flags for Loc-RIB Instance Peer Type 3" registry:
	+======+=============+		+======+=============+
	| Flag | Description |		| Flag | Description |
	+======+=============+		+======+=============+
	| 0 | F flag |		| 0 | F flag |
	+------+-------------+		+------+-------------+
	Table 2: Loc-RIB		Table 2: Loc-RIB
	Instance Peer Type		Instance Peer Type
	As noted in Section 4.2, the F flag indicates that the Loc-RIB is		As noted in Section 4.2, the F flag indicates that the Loc-RIB is
	filtered. This indicates that the Loc-RIB does not represent the		filtered. This indicates that the Loc-RIB does not represent the
	complete routing table.		complete routing table.
	Flags 0 through 3 and 5 through 7 are unassigned. The registration		Flags 1 through 7 are unassigned. The registration procedure for the
	procedure for the registry is Standards Action.		registry is Standards Action.
	8.3. Peer Up Information TLV		8.3. Peer Up Information TLV
	IANA has renamed the "BMP Initiation Message TLVs" registry to "BMP		IANA has renamed the "BMP Initiation Message TLVs" registry to "BMP
	Initiation and Peer Up Information TLVs". Section 4.4 of [RFC7854]		Initiation and Peer Up Information TLVs". Section 4.4 of [RFC7854]
	indicates that both Initiation and Peer Up share the same information		indicates that both Initiation and Peer Up share the same information
	TLVs. This document defines the following new BMP Peer Up		TLVs. This document defines the following new BMP Peer Up
	Information TLV type (Section 5.2.1):		Information TLV type (Section 5.2.1):
	+======+================+		+======+================+
	skipping to change at line 629 ¶		skipping to change at line 630 ¶
	| 6 | Local system closed, TLV data follows |		| 6 | Local system closed, TLV data follows |
	+------+---------------------------------------+		+------+---------------------------------------+
	Table 4: BMP Peer Down Reason Code		Table 4: BMP Peer Down Reason Code
	8.5. Deprecated Entries		8.5. Deprecated Entries
	Per this document, IANA has marked the F Flag entry in the "BMP Peer		Per this document, IANA has marked the F Flag entry in the "BMP Peer
	Flags for Peer Types 0 through 2" registry as "deprecated".		Flags for Peer Types 0 through 2" registry as "deprecated".
	9. Normative References		9. References
			9.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,
	<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>.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", RFC 5226,
	DOI 10.17487/RFC5226, May 2008,
	<https://www.rfc-editor.org/info/rfc5226>.
	[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,
	<https://www.rfc-editor.org/info/rfc7854>.		<https://www.rfc-editor.org/info/rfc7854>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	10. Informative References		9.2. Informative References
	[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder,		[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder,
	"Advertisement of Multiple Paths in BGP", RFC 7911,		"Advertisement of Multiple Paths in BGP", RFC 7911,
	DOI 10.17487/RFC7911, July 2016,		DOI 10.17487/RFC7911, July 2016,
	<https://www.rfc-editor.org/info/rfc7911>.		<https://www.rfc-editor.org/info/rfc7911>.
	Acknowledgements		Acknowledgements
	The authors would like to thank John Scudder, Jeff Haas, and Mukul		The authors would like to thank John Scudder, Jeff Haas, and Mukul
	Srivastava for their valuable input.		Srivastava for their valuable input.
End of changes. 20 change blocks.
	39 lines changed or deleted		37 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/