draft-ietf-grow-mrt-add-paths-02.txt		draft-ietf-grow-mrt-add-paths-03.txt
	Global Routing Operations C. Petrie		Global Routing Operations C. Petrie
	Internet-Draft RIPE NCC		Internet-Draft RIPE NCC
	Intended status: Standards Track T. King		Intended status: Standards Track T. King
	Expires: July 12, 2017 DE-CIX		Expires: July 18, 2017 DE-CIX
	January 8, 2017		January 14, 2017
	Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format		Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format
	with BGP Additional Paths Extensions		with BGP Additional Paths Extensions
	draft-ietf-grow-mrt-add-paths-02		draft-ietf-grow-mrt-add-paths-03
	Abstract		Abstract
	This document updates the Multi-threaded Routing Toolkit (MRT) export		This document updates the Multi-threaded Routing Toolkit (MRT) export
	format for Border Gateway Protocol (BGP) routing information by		format for Border Gateway Protocol (BGP) routing information by
	extending it to support the Advertisement of Multiple Paths in BGP		extending it to support the Advertisement of Multiple Paths in BGP
	extensions.		extensions.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 http://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 July 12, 2017.		This Internet-Draft will expire on July 18, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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		(http://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. Requirements Language . . . . . . . . . . . . . . . . . . . . 2		2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 2
	3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. MRT Subtypes for Types BGP4MP/BGP4MP_ET . . . . . . . . . . . 3
	4. MRT Subtypes for Types BGP4MP/BGP4MP_ET . . . . . . . . . . . 3		4. MRT Subtypes for Type TABLE_DUMP_V2 . . . . . . . . . . . . . 3
	5. MRT Subtypes for Type TABLE_DUMP_V2 . . . . . . . . . . . . . 3		4.1. AFI/SAFI specific RIB Subtypes . . . . . . . . . . . . . 3
	5.1. AFI/SAFI specific RIB Subtypes . . . . . . . . . . . . . 4		4.2. RIB_GENERIC_ADDPATH Subtype . . . . . . . . . . . . . . . 4
	5.2. RIB_GENERIC_ADDPATH Subtype . . . . . . . . . . . . . . . 4		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		5.1. BGP4MP/BGP4MP_ET Subtype codes: . . . . . . . . . . . . . 4
	6.1. BGP4MP/BGP4MP_ET Subtype codes: . . . . . . . . . . . . . 5		5.2. TABLE_DUMP_V2 Subtype codes: . . . . . . . . . . . . . . 5
	6.2. TABLE_DUMP_V2 Subtype codes: . . . . . . . . . . . . . . 5		6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 5		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		7.1. Normative References . . . . . . . . . . . . . . . . . . 5
	8.1. Normative References . . . . . . . . . . . . . . . . . . 6		7.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	8.2. Informative References . . . . . . . . . . . . . . . . . 6		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
	8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	The MRT record format [RFC6396] was developed to provide researchers		The MRT record format [RFC6396] was developed to provide researchers
	and engineers a means to encapsulate, export, and archive routing		and engineers a means to encapsulate, export, and archive routing
	protocol transactions and routing information base snapshots.		protocol transactions and routing information base snapshots.
	The Advertisement of Multiple Paths in BGP [I-D.ietf-idr-add-paths]		The Advertisement of Multiple Paths in BGP [RFC7911] defines a BGP
	defines a BGP extension to allow the advertisement of multiple paths		extension to allow the advertisement of multiple paths for the same
	for the same address prefix without the new paths implicitly		address prefix without the new paths implicitly replacing any
	replacing any previous ones.		previous ones.
	This document contains an optional extension to the MRT format		This document contains an optional extension to the MRT format
	[RFC6396] and introduces additional definitions of MRT subtype fields		[RFC6396] and introduces additional definitions of MRT subtype fields
	to permit representation of multiple path advertisements		to permit representation of multiple path advertisements [RFC7911].
	[I-D.ietf-idr-add-paths].
	2. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].
	3. Rationale		2. Rationale
	MRT parsers are usually stateless. In order to parse BGP messages		MRT parsers are usually stateless. In order to parse BGP messages
	which contain data structures that depend on the capabilities		which contain data structures that depend on the capabilities
	negotiated during the BGP session setup, the so-called MRT subtypes		negotiated during the BGP session setup, the so-called MRT subtypes
	are utilized. The Advertisement of Multiple Path		are utilized. The Advertisement of Multiple Path [RFC7911] extension
	[I-D.ietf-idr-add-paths] extension for BGP alters the encoding of the		for BGP alters the encoding of the BGP NLRI format for withdraws and
	BGP NLRI format for withdraws and announcements. Therefore new		announcements. Therefore new BGP4MP/BGP4MP_ET subtypes as defined in
	BGP4MP/BGP4MP_ET subtypes as defined in [RFC6396] are required to		[RFC6396] are required to signal to a MRT parser how to parse the
	signal to a MRT parser how to parse the NLRI.		NLRI.
	In section 4.3 [RFC6396] of the MRT specification RIB subtypes are		In section 4.3 [RFC6396] of the MRT specification RIB subtypes are
	specified. Prefix length and prefix fields are encoded in the same		specified. Prefix length and prefix fields are encoded in the same
	manner as the BGP NLRI encoding. In order to support path identifier		manner as the BGP NLRI encoding. In order to support path identifier
	information as defined in [I-D.ietf-idr-add-paths] new subtypes need		information as defined in [RFC7911] new subtypes need to be added.
	to be added.
	The following two sections define the required subtypes.		The following two sections define the required subtypes.
	4. MRT Subtypes for Types BGP4MP/BGP4MP_ET		3. MRT Subtypes for Types BGP4MP/BGP4MP_ET
	This document defines the following new Subtypes:		This document defines the following new Subtypes:
	o BGP4MP_MESSAGE_ADDPATH		o BGP4MP_MESSAGE_ADDPATH
	o BGP4MP_MESSAGE_AS4_ADDPATH		o BGP4MP_MESSAGE_AS4_ADDPATH
	o BGP4MP_MESSAGE_LOCAL_ADDPATH		o BGP4MP_MESSAGE_LOCAL_ADDPATH
	o BGP4MP_MESSAGE_AS4_LOCAL_ADDPATH		o BGP4MP_MESSAGE_AS4_LOCAL_ADDPATH
	The fields of these message types are identical to the equivalent		The fields of these message types are identical to the equivalent
	non-additional-path versions specified in section 4.4 [RFC6396].		non-additional-path versions specified in section 4.4 [RFC6396].
	These enhancements continues to encapsulate the entire BGP message in		These enhancements continues to encapsulate the entire BGP message in
	the BGP message field.		the BGP message field.
	5. MRT Subtypes for Type TABLE_DUMP_V2		4. MRT Subtypes for Type TABLE_DUMP_V2
	This document defines the following new Subtypes:		This document defines the following new Subtypes:
	o RIB_IPV4_UNICAST_ADDPATH		o RIB_IPV4_UNICAST_ADDPATH
	o RIB_IPV4_MULTICAST_ADDPATH		o RIB_IPV4_MULTICAST_ADDPATH
	o RIB_IPV6_UNICAST_ADDPATH		o RIB_IPV6_UNICAST_ADDPATH
	o RIB_IPV6_MULTICAST_ADDPATH		o RIB_IPV6_MULTICAST_ADDPATH
	skipping to change at page 4, line 4 ¶		skipping to change at page 3, line 37 ¶
	This document defines the following new Subtypes:		This document defines the following new Subtypes:
	o RIB_IPV4_UNICAST_ADDPATH		o RIB_IPV4_UNICAST_ADDPATH
	o RIB_IPV4_MULTICAST_ADDPATH		o RIB_IPV4_MULTICAST_ADDPATH
	o RIB_IPV6_UNICAST_ADDPATH		o RIB_IPV6_UNICAST_ADDPATH
	o RIB_IPV6_MULTICAST_ADDPATH		o RIB_IPV6_MULTICAST_ADDPATH
	o RIB_GENERIC_ADDPATH		o RIB_GENERIC_ADDPATH
	The fields of these message types are identical to the equivalent		The fields of these message types are identical to the equivalent
	non-additional-path versions specified in section 4.3 [RFC6396].		non-additional-path versions specified in section 4.3 [RFC6396].
	However, for the specific case of the 4 AFI/SAFI specific RIB		However, for the specific case of the 4 AFI/SAFI specific RIB
	subtypes, the existing RIB Entries field is re-defined as detailed in		subtypes, the existing RIB Entries field is re-defined as detailed in
	the sections below.		the sections below.
	5.1. AFI/SAFI specific RIB Subtypes		4.1. AFI/SAFI specific RIB Subtypes
	In order to preserve the record compaction achieved by using the most		In order to preserve the record compaction achieved by using the most
	common subtypes, and allowing multiple RIB Entries to be stored in a		common subtypes, and allowing multiple RIB Entries to be stored in a
	single TABLE_DUMP_V2 record, the existing RIB Entries field is		single TABLE_DUMP_V2 record, the existing RIB Entries field is
	redefined for use within the new AFI/SAFI specific RIB Subtypes		redefined for use within the new AFI/SAFI specific RIB Subtypes
	defined by this document as follows:		defined by this document as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 4, line 42 ¶		skipping to change at page 4, line 29 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: RIB Entries for AFI/SAFI-specific RIB Subtypes with		Figure 1: RIB Entries for AFI/SAFI-specific RIB Subtypes with
	additional-paths support		additional-paths support
	This adds a field to the RIB Entries record, to store the path		This adds a field to the RIB Entries record, to store the path
	identifier, when used with the RIB_IPV4_UNICAST_ADDPATH,		identifier, when used with the RIB_IPV4_UNICAST_ADDPATH,
	RIB_IPV4_MULTICAST_ADDPATH, RIB_IPV6_UNICAST_ADDPATH and		RIB_IPV4_MULTICAST_ADDPATH, RIB_IPV6_UNICAST_ADDPATH and
	RIB_IPV6_MULTICAST_ADDPATH subtypes.		RIB_IPV6_MULTICAST_ADDPATH subtypes.
	5.2. RIB_GENERIC_ADDPATH Subtype		4.2. RIB_GENERIC_ADDPATH Subtype
	The fields of this subtype are identical to the equivalent non-		The fields of this subtype are identical to the equivalent non-
	additional-path versions specified in section 4.3.3 [RFC6396]. These		additional-path versions specified in section 4.3.3 [RFC6396]. These
	fields continue to encapsulate the raw and additional-path enabled		fields continue to encapsulate the raw and additional-path enabled
	AFI/SAFI/NLRI in the record, and the raw attributes in the RIB		AFI/SAFI/NLRI in the record, and the raw attributes in the RIB
	Entries.		Entries.
	For clarity, the RIB Entries in this subtype are not redefined.		For clarity, the RIB Entries in this subtype are not redefined.
	6. IANA Considerations		5. IANA Considerations
	This document requests that IANA assign the following subtype codes		This document requests that IANA assign the following subtype codes
	to the MRT name space [1]:		to the MRT name space [1]:
	6.1. BGP4MP/BGP4MP_ET Subtype codes:		5.1. BGP4MP/BGP4MP_ET Subtype codes:
	BGP4MP_MESSAGE_ADDPATH = 8 (Section 4)
	BGP4MP_MESSAGE_AS4_ADDPATH = 9 (Section 4)		BGP4MP_MESSAGE_ADDPATH = 8 (Section 3)
	BGP4MP_MESSAGE_LOCAL_ADDPATH = 10 (Section 4)		BGP4MP_MESSAGE_AS4_ADDPATH = 9 (Section 3)
	BGP4MP_MESSAGE_AS4_LOCAL_ADDPATH = 11 (Section 4)		BGP4MP_MESSAGE_LOCAL_ADDPATH = 10 (Section 3)
			BGP4MP_MESSAGE_AS4_LOCAL_ADDPATH = 11 (Section 3)
	The values provided above are suggested as they are used in		The values provided above are suggested as they are used in
	implementations.		implementations.
	6.2. TABLE_DUMP_V2 Subtype codes:		5.2. TABLE_DUMP_V2 Subtype codes:
	RIB_IPV4_UNICAST_ADDPATH = 8 (Section 5.1)		RIB_IPV4_UNICAST_ADDPATH = 8 (Section 4.1)
	RIB_IPV4_MULTICAST_ADDPATH = 9 (Section 5.1)		RIB_IPV4_MULTICAST_ADDPATH = 9 (Section 4.1)
	RIB_IPV6_UNICAST_ADDPATH = 10 (Section 5.1)		RIB_IPV6_UNICAST_ADDPATH = 10 (Section 4.1)
	RIB_IPV6_MULTICAST_ADDPATH = 11 (Section 5.1)		RIB_IPV6_MULTICAST_ADDPATH = 11 (Section 4.1)
	RIB_GENERIC_ADDPATH = 12 (Section 5.2)		RIB_GENERIC_ADDPATH = 12 (Section 4.2)
	The values provided above are suggested as they are used in		The values provided above are suggested as they are used in
	implementations.		implementations.
	7. Security Considerations		6. 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.
	However, the security considerations of [RFC6396] are equally		However, the security considerations of [RFC6396] are equally
	applicable to this document, and this document permits the export of		applicable to this document, and this document permits the export of
	more detailed routing data.		more detailed routing data.
	An organization that uses the MRT format to store their BGP routing		An organization that uses the MRT format to store their BGP routing
	information should be aware that supporting these extensions permits		information should be aware that supporting these extensions permits
	more detailed network path information to be stored, and should		more detailed network path information to be stored, and should
	consider the implications of this within their environment.		consider the implications of this within their environment.
	An organization that peers with public BGP collectors, and enables		An organization that peers with public BGP collectors, and enables
	the additional-paths capability on a peering session, should be aware		the additional-paths capability on a peering session, should be aware
	that it is exporting not only its best paths, but potentially other		that it is exporting not only its best paths, but potentially other
	paths within its networks. The BGP peer should consider any and all		paths within its networks. The BGP peer should consider any and all
	implications of exposing this additional data.		implications of exposing this additional data.
	8. References		7. References
	8.1. Normative References
	[I-D.ietf-idr-add-paths]
	Walton, D., Retana, A., Chen, E., and J. Scudder,
	"Advertisement of Multiple Paths in BGP", draft-ietf-idr-
	add-paths-15 (work in progress), May 2016.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		7.1. Normative References
	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.
	[RFC6396] Blunk, L., Karir, M., and C. Labovitz, "Multi-Threaded		[RFC6396] Blunk, L., Karir, M., and C. Labovitz, "Multi-Threaded
	Routing Toolkit (MRT) Routing Information Export Format",		Routing Toolkit (MRT) Routing Information Export Format",
	RFC 6396, DOI 10.17487/RFC6396, October 2011,		RFC 6396, DOI 10.17487/RFC6396, October 2011,
	<http://www.rfc-editor.org/info/rfc6396>.		<http://www.rfc-editor.org/info/rfc6396>.
	8.2. Informative References		[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder,
			"Advertisement of Multiple Paths in BGP", RFC 7911,
	[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,		DOI 10.17487/RFC7911, July 2016,
	DOI 10.17487/RFC2629, June 1999,		<http://www.rfc-editor.org/info/rfc7911>.
	<http://www.rfc-editor.org/info/rfc2629>.
	[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
	Text on Security Considerations", BCP 72, RFC 3552,
	DOI 10.17487/RFC3552, July 2003,
	<http://www.rfc-editor.org/info/rfc3552>.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	DOI 10.17487/RFC5226, May 2008,
	<http://www.rfc-editor.org/info/rfc5226>.
	8.3. URIs		7.2. URIs
	[1] https://www.iana.org/assignments/mrt/mrt.xhtml		[1] https://www.iana.org/assignments/mrt/mrt.xhtml
	Authors' Addresses		Authors' Addresses
	Colin Petrie		Colin Petrie
	RIPE NCC		RIPE NCC
	Stationsplein 11		Stationsplein 11
	Amsterdam 1012 AB		Amsterdam 1012 AB
	NL		NL
End of changes. 30 change blocks.
	85 lines changed or deleted		54 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/