draft-ietf-grow-mrt-10.txt		draft-ietf-grow-mrt-11.txt
	Network Working Group L. Blunk		Network Working Group L. Blunk
	Internet-Draft M. Karir		Internet-Draft M. Karir
	Intended status: Standards Track Merit Network		Intended status: Standards Track Merit Network
	Expires: January 14, 2010 C. Labovitz		Expires: September 9, 2010 C. Labovitz
	Arbor Networks		Arbor Networks
	July 13, 2009		March 8, 2010
	MRT routing information export format		MRT routing information export format
	draft-ietf-grow-mrt-10.txt		draft-ietf-grow-mrt-11.txt
			Abstract
			This document describes the MRT format for routing information
			export. This format was developed in concert with the Multi-threaded
			Routing Toolkit (MRT) from whence the format takes it name. The
			format can be used to export routing protocol messages, state
			changes, and routing information base contents.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 34		skipping to change at page 1, line 42
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on January 14, 2010.		This Internet-Draft will expire on September 9, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2010 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 in effect on the date of		Provisions Relating to IETF Documents
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
	Abstract		include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
	This document describes the MRT format for routing information		described in the BSD License.
	export. This format was developed in concert with the Multi-threaded
	Routing Toolkit (MRT) from whence the format takes it name. The
	format can be used to export routing protocol messages, state
	changes, and routing information base contents.
	Table of Contents		Table of Contents
	1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4		1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Basic MRT Format . . . . . . . . . . . . . . . . . . . . . . . 6		3. Basic MRT Format . . . . . . . . . . . . . . . . . . . . . . . 6
	4. MRT Informational Types . . . . . . . . . . . . . . . . . . . 8		4. MRT Informational Types . . . . . . . . . . . . . . . . . . . 8
	4.1. START Type . . . . . . . . . . . . . . . . . . . . . . . . 8		4.1. START Type . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.2. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . . . 8		4.2. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . . . 8
	5. MRT Routing Information Types . . . . . . . . . . . . . . . . 9		5. MRT Routing Information Types . . . . . . . . . . . . . . . . 9
	5.1. OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 9		5.1. OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.2. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 9		5.2. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 10
	5.3. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 11		5.3. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 11
	5.4. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 13		5.4. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 14
	5.4.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 14		5.4.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 14
	5.4.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 15		5.4.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 15
	5.4.3. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 15		5.4.3. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 16
	5.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 16		5.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 16
			5.4.5. BGP4MP_MESSAGE_LOCAL Subtype . . . . . . . . . . . . . 17
			5.4.6. BGP4MP_MESSAGE_AS4_LOCAL Subtype . . . . . . . . . . . 17
	5.5. BGP4MP_ET Type . . . . . . . . . . . . . . . . . . . . . . 17		5.5. BGP4MP_ET Type . . . . . . . . . . . . . . . . . . . . . . 17
	5.6. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 17		5.6. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 18
	5.7. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 17		5.7. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 18
	5.8. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 17		5.8. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 18
	5.9. OSPFv3_ET Type . . . . . . . . . . . . . . . . . . . . . . 18		5.9. OSPFv3_ET Type . . . . . . . . . . . . . . . . . . . . . . 19
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	6.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 19		6.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 20
	6.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 19		6.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 20
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 20		7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 21		8.1. Normative References . . . . . . . . . . . . . . . . . . . 22
	8.2. Informative References . . . . . . . . . . . . . . . . . . 21		8.2. Informative References . . . . . . . . . . . . . . . . . . 22
	Appendix A. Deprecated MRT types . . . . . . . . . . . . . . . . 22		Appendix A. Deprecated MRT types . . . . . . . . . . . . . . . . 23
	A.1. Deprecated MRT Informational Types . . . . . . . . . . . . 22		A.1. Deprecated MRT Informational Types . . . . . . . . . . . . 23
	A.1.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . 22		A.1.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . 23
	A.1.2. DIE Type . . . . . . . . . . . . . . . . . . . . . . . 22		A.1.2. DIE Type . . . . . . . . . . . . . . . . . . . . . . . 23
	A.1.3. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . 22		A.1.3. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . 23
	A.2. Deprecated MRT Routing Information Types . . . . . . . . . 22		A.2. Deprecated MRT Routing Information Types . . . . . . . . . 23
	A.2.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . 22		A.2.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . 23
	A.2.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . 25		A.2.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . 26
	A.2.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . 25		A.2.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . 26
	A.2.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . 25		A.2.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . 26
	A.2.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . 26		A.2.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . 27
	A.2.6. Deprecated BGP4MP Subtypes . . . . . . . . . . . . . . 26		A.2.6. Deprecated BGP4MP Subtypes . . . . . . . . . . . . . . 27
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
	1. Requirements notation		1. Requirements notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Introduction		2. Introduction
	Researchers and engineers often wish to analyze network behavior by		Researchers and engineers often wish to analyze network behavior by
	skipping to change at page 10, line 30		skipping to change at page 10, line 38
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer IP address (variable) |		| Peer IP address (variable) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer AS | Attribute Length |		| Peer AS | Attribute Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| BGP Attribute... (variable)		| BGP Attribute... (variable)
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The View field is normally 0 and is intended for cases where an		The View field is normally 0 and is intended for cases where an
	implementation may have multiple RIB views (such as a route server).		implementation may have multiple RIB views (such as a route server).
	The Sequence field is a simple incremental counter for each RIB		In cases where multiple RIB views are present, an implementation may
	entry. A typical RIB dump will exceed the 16-bit bounds of this		use the the view field to distinguish entries from each view. The
	counter and implementation should simply wrap back to zero and		Sequence field is a simple incremental counter for each RIB entry. A
	continue incrementing the counter in such cases.		typical RIB dump will exceed the 16-bit bounds of this counter and
			implementation should simply wrap back to zero and continue
			incrementing the counter in such cases.
	The Prefix field contains the IP address of a particular RIB entry.		The Prefix field contains the IP address of a particular RIB entry.
	The size of this field is dependent on the value of the Subtype for		The size of this field is dependent on the value of the Subtype for
	this message. For AFI_IPv4, this field is 4 octets, for AFI_IPv6, it		this message. For AFI_IPv4, this field is 4 octets, for AFI_IPv6, it
	is 16 octets in length. The Prefix Length field indicates the length		is 16 octets in length. The Prefix Length field indicates the length
	in bits of the prefix mask for the preceding Prefix field.		in bits of the prefix mask for the preceding Prefix field.
	The Status octet is not used in the TABLE_DUMP Type and SHOULD be set		The Status octet is not used in the TABLE_DUMP Type and SHOULD be set
	to 1.		to 1.
	skipping to change at page 11, line 12		skipping to change at page 11, line 22
	field and an IPv4 address, while a Subtype of AFI_IPv6 requires a 16		field and an IPv4 address, while a Subtype of AFI_IPv6 requires a 16
	octet field and an IPv6 address. The Peer AS field contains the AS		octet field and an IPv6 address. The Peer AS field contains the AS
	number of the peer.		number of the peer.
	Attribute length is the length of Attribute field and is 2-octets.		Attribute length is the length of Attribute field and is 2-octets.
	The Attribute field contains the attribute information for the RIB		The Attribute field contains the attribute information for the RIB
	entry.		entry.
	5.3. TABLE_DUMP_V2 Type		5.3. TABLE_DUMP_V2 Type
	The TABLE_DUMP_V2 Type updates the TABLE_DUMP Type to include 32BIT		The TABLE_DUMP_V2 Type updates the TABLE_DUMP Type to include 4-Byte
	ASN support and full support for BGP Multiprotocol extensions. It		ASN support and full support for BGP Multiprotocol extensions. It
	also improves upon the space efficiency of the TABLE_DUMP Type by		also improves upon the space efficiency of the TABLE_DUMP Type by
	employing an index table for peers and permitting a single MRT record		employing an index table for peers and permitting a single MRT record
	per NLRI entry. The following subtypes are used with the		per NLRI entry. The following subtypes are used with the
	TABLE_DUMP_V2 Type.		TABLE_DUMP_V2 Type.
	1 PEER_INDEX_TABLE		1 PEER_INDEX_TABLE
	2 RIB_IPV4_UNICAST		2 RIB_IPV4_UNICAST
	3 RIB_IPV4_MULTICAST		3 RIB_IPV4_MULTICAST
	4 RIB_IPV6_UNICAST		4 RIB_IPV6_UNICAST
	skipping to change at page 14, line 11		skipping to change at page 14, line 24
	This Type was initially defined in the Zebra software package for the		This Type was initially defined in the Zebra software package for the
	BGP protocol with multiprotocol extension support as defined by RFC		BGP protocol with multiprotocol extension support as defined by RFC
	4760 [RFC4760]. It supersedes the BGP, BGP4PLUS, BGP4PLUS_01 Types.		4760 [RFC4760]. It supersedes the BGP, BGP4PLUS, BGP4PLUS_01 Types.
	The BGP4MP Type has six Subtypes which are defined as follows:		The BGP4MP Type has six Subtypes which are defined as follows:
	0 BGP4MP_STATE_CHANGE		0 BGP4MP_STATE_CHANGE
	1 BGP4MP_MESSAGE		1 BGP4MP_MESSAGE
	4 BGP4MP_MESSAGE_AS4		4 BGP4MP_MESSAGE_AS4
	5 BGP4MP_STATE_CHANGE_AS4		5 BGP4MP_STATE_CHANGE_AS4
			6 BGP4MP_MESSAGE_LOCAL
			7 BGP4MP_MESSAGE_AS4_LOCAL
	5.4.1. BGP4MP_STATE_CHANGE Subtype		5.4.1. BGP4MP_STATE_CHANGE Subtype
	This record is used to encode state changes in the BGP finite state		This record is used to encode state changes in the BGP finite state
	machine. The BGP FSM states are encoded in the Old State and New		machine. The BGP FSM states are encoded in the Old State and New
	State fields to indicate the previous and current state. The format		State fields to indicate the previous and current state. In some
	is illustrated below:		cases, the Peer AS number may be undefined. In such cases, the value
			of this field may be set to zero. The format is illustrated below:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer AS number | Local AS number |		| Peer AS number | Local AS number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Interface Index | Address Family |		| Interface Index | Address Family |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer IP address (variable) |		| Peer IP address (variable) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 15, line 11		skipping to change at page 15, line 30
	be zero if unknown or unsupported. The Address Family indicates what		be zero if unknown or unsupported. The Address Family indicates what
	types of addresses are in the the address fields. At present, the		types of addresses are in the the address fields. At present, the
	following AFI Types are supported:		following AFI Types are supported:
	1 AFI_IPv4		1 AFI_IPv4
	2 AFI_IPv6		2 AFI_IPv6
	5.4.2. BGP4MP_MESSAGE Subtype		5.4.2. BGP4MP_MESSAGE Subtype
	This Subtype is used to encode BGP Messages. It can be used to		This Subtype is used to encode BGP Messages. It can be used to
	encode any Type of BGP message. In order to determine the BGP		encode any Type of BGP message. The entire BGP message is
	message Type, the entire BGP message is included in the BGP Message		encapsulated in the BGP Message field, including the 16-octet marker,
	field. This includes the 16-octet marker, the 2-octet length, and		the 2-octet length, and the 1-octet type fields. Note that the
	the 1-octet type fields. Note that the BGP4MP_MESSAGE Subtype does		BGP4MP_MESSAGE Subtype does not support 4-Byte AS numbers. Further,
	not support 32BIT AS numbers. The BGP4MP_MESSAGE_AS4 Subtype updates		the AS_PATH contained in these messages MUST only consist of 2-Byte
	the BGP4MP_MESSAGE Subtype in order to support 32BIT AS numbers. The		AS numbers. The BGP4MP_MESSAGE_AS4 Subtype updates the
			BGP4MP_MESSAGE Subtype in order to support 4-Byte AS numbers. The
	BGP4MP_MESSAGE fields are shown below:		BGP4MP_MESSAGE fields are shown below:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer AS number | Local AS number |		| Peer AS number | Local AS number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Interface Index | Address Family |		| Interface Index | Address Family |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer IP address (variable) |		| Peer IP address (variable) |
	skipping to change at page 15, line 50		skipping to change at page 16, line 22
	2 AFI_IPv6		2 AFI_IPv6
	Note that the Address Family value only applies to the IP addresses		Note that the Address Family value only applies to the IP addresses
	contained in the MRT header. The BGP4MP_MESSAGE Subtype is otherwise		contained in the MRT header. The BGP4MP_MESSAGE Subtype is otherwise
	transparent to the contents of the actual message which may contain		transparent to the contents of the actual message which may contain
	any valid AFI/SAFI values. Only one BGP message may be encoded in		any valid AFI/SAFI values. Only one BGP message may be encoded in
	the BGP4MP_MESSAGE Subtype.		the BGP4MP_MESSAGE Subtype.
	5.4.3. BGP4MP_MESSAGE_AS4 Subtype		5.4.3. BGP4MP_MESSAGE_AS4 Subtype
	This Subtype updates the BGP4MP_MESSAGE Subtype to support 32BIT		This Subtype updates the BGP4MP_MESSAGE Subtype to support 4-Byte
	Autonomous System numbers. The BGP4MP_MESSAGE_AS4 Subtype is		Autonomous System numbers. The BGP4MP_MESSAGE_AS4 Subtype is
	otherwise identical to the BGP4MP_MESSAGE Subtype. The		otherwise identical to the BGP4MP_MESSAGE Subtype. The AS_PATH in
			these messages MUST only consist of 4-Byte AS numbers. The
	BGP4MP_MESSAGE_AS4 fields are shown below:		BGP4MP_MESSAGE_AS4 fields are shown below:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer AS number |		| Peer AS number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Local AS number |		| Local AS number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Interface Index | Address Family |		| Interface Index | Address Family |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer IP address (variable) |		| Peer IP address (variable) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Local IP address (variable) |		| Local IP address (variable) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| BGP Message... (variable)		| BGP Message... (variable)
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	5.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype		5.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype
	This Subtype updates the BGP4MP_STATE_CHANGE Subtype to support 32BIT		This Subtype updates the BGP4MP_STATE_CHANGE Subtype to support
	Autonomous System numbers. As with the BGP4MP_STATE_CHANGE Subtype,		4-Byte Autonomous System numbers. As with the BGP4MP_STATE_CHANGE
	the BGP FSM states are encoded in the Old State and New State fields		Subtype, the BGP FSM states are encoded in the Old State and New
	to indicate the previous and current state. Aside from the extension		State fields to indicate the previous and current state. Aside from
	of the peer and local AS fields to 32 bits, this subtype is otherwise		the extension of the peer and local AS fields to 4-Bytes, this
	identical to the BGP4MP_STATE_CHANGE Subtype. The		subtype is otherwise identical to the BGP4MP_STATE_CHANGE Subtype.
	BGP4MP_STATE_CHANGE_AS4 fields are shown below:		The BGP4MP_STATE_CHANGE_AS4 fields are shown below:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer AS number |		| Peer AS number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Local AS number |		| Local AS number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Interface Index | Address Family |		| Interface Index | Address Family |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer IP address (variable) |		| Peer IP address (variable) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Local IP address (variable) |		| Local IP address (variable) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Old State | New State |		| Old State | New State |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			5.4.5. BGP4MP_MESSAGE_LOCAL Subtype
			Implementations of MRT have largely focused on collecting remotely
			generated BGP messages in a passive route collector role. However,
			for active BGP implementations, it can be useful to archive locally
			generated BGP messages in addition to remote messages. This subtype
			is added to indicated a locally generated BGP message. The fields
			remain identical to the BGP4MP_MESSAGE type including the Peer and
			Local IP and AS fields. The Local fields continue to refer to the
			local IP and AS number of the collector which generated the message
			and the Peer IP and AS fields refer to the receipient of the
			generated BGP messages.
			5.4.6. BGP4MP_MESSAGE_AS4_LOCAL Subtype
			As with the BGP4MP_MESSAGE_LOCAL type, this type indicate locally
			generated messages. The fields are identical to the
			BGP4MP_MESSAGE_AS4 message type.
	5.5. BGP4MP_ET Type		5.5. BGP4MP_ET Type
	This Type was initially defined in the Sprint Labs Python Routing		This Type was initially defined in the Sprint Labs Python Routing
	Toolkit (PyRT). It extends the MRT common header field to include a		Toolkit (PyRT). It extends the MRT common header field to include a
	32BIT microsecond timestamp field. The type and subtype field		32BIT microsecond timestamp field. The type and subtype field
	definitions remain as defined for the BGP4MP Type. The 32BIT		definitions remain as defined for the BGP4MP Type. The 32BIT
	microsecond timestamp immediately follows the length field in the MRT		microsecond timestamp immediately follows the length field in the MRT
	common header and precedes all other fields in the message. The		common header and precedes all other fields in the message. The
	32BIT microsecond field is included in the computation of the length		32BIT microsecond field is included in the computation of the length
	field value. The MRT common header modification is illustrated		field value. The MRT common header modification is illustrated
	skipping to change at page 19, line 19		skipping to change at page 20, line 19
	specification, in accordance with BCP 26, RFC 5226 [RFC5226].		specification, in accordance with BCP 26, RFC 5226 [RFC5226].
	There are two name spaces in MRT that require registration: Type		There are two name spaces in MRT that require registration: Type
	Codes and Subtype Codes.		Codes and Subtype Codes.
	MRT is not intended as a general-purpose specification for protocol		MRT is not intended as a general-purpose specification for protocol
	information export, and allocations should not be made for purposes		information export, and allocations should not be made for purposes
	unrelated to routing protocol information export.		unrelated to routing protocol information export.
	The following policies are used here with the meanings defined in BCP		The following policies are used here with the meanings defined in BCP
	26: "Specification Required", "IETF Consensus".		26: "Specification Required", "IETF Consensus", "Experimental Use",
			"First Come First Served".
	6.1. Type Codes		6.1. Type Codes
	Type Codes have a range from 0 to 65535, of which 0-64 have been		Type Codes have a range from 0 to 65535, of which 1-64 have been
	allocated. New Type Codes MUST be allocated starting at 65. Type		allocated. New Type Codes MUST be allocated starting at 65. Type
	Codes 65 - 32767 are to be assigned by IETF Consensus. Type Codes		Codes 65 - 511 are to be assigned by IETF Review. Type Codes 512 -
	32768 - 65535 are assigned based on Specification Required.		2047 are assigned based on Specification Required. Type Codes 2048 -
			64511 are available on a First Come First Served policy. Type Codes
			64512 - 65534 are available for Experimental Use. The Type Code
			Values of 0 and 65535 are reserved.
	6.2. Subtype Codes		6.2. Subtype Codes
	Subtype Codes have a range from 0 to 65535. Subtype definitions are		Subtype Codes have a range from 0 to 65535. Subtype definitions are
	specific to a particular Type Code definition. New Subtype Code		specific to a particular Type Code definition. New Subtype Code
	definition must reference an existing Type Code to which the Subtype		definition must reference an existing Type Code to which the Subtype
	belongs. As Subtype Codes are specific to Type Codes, new numbers		belongs. Subtype assignmnents to Type Codes 0 - 511 are to be
	must be unique for the particular Type Code to which the Subtype		assigned by IETF Review. Subtype assignments for the remaning Type
	applies. Subtype Codes specific to the Type Codes 0 - 32767 are		Codes follow the assignment rules for the Type Codes to which they
	assigned by IETF Consensus. Subtype Codes specific to Type Codes		belong.
	32768 - 65535 are assigned based on Specification Required.
	7. Security Considerations		7. Security Considerations
	The MRT Format utilizes a structure which can store routing protocol		The MRT Format utilizes a structure which can store routing protocol
	information data. The fields defined in the MRT specification are of		information data. The fields defined in the MRT specification are of
	a descriptive nature and provide information that is useful to		a descriptive nature and provide information that is useful to
	facilitate the analysis of routing data. As such, the fields		facilitate the analysis of routing data. As such, the fields
	currently defined in the MRT specification do not in themselves		currently defined in the MRT specification do not in themselves
	create additional security risks, since the fields are not used to		create additional security risks, since the fields are not used to
	induce any particular behavior by the recipient application.		induce any particular behavior by the recipient application.
	skipping to change at page 26, line 47		skipping to change at page 27, line 47
	The following two subtypes of the BGP4MP Type are considered to be		The following two subtypes of the BGP4MP Type are considered to be
	deprecated.		deprecated.
	2 BGP4MP_ENTRY		2 BGP4MP_ENTRY
	3 BGP4MP_SNAPSHOT		3 BGP4MP_SNAPSHOT
	A.2.6.1. BGP4MP_ENTRY Subtype		A.2.6.1. BGP4MP_ENTRY Subtype
	This Subtype is similar to the TABLE_DUMP Type and is used to record		This Subtype is similar to the TABLE_DUMP Type and is used to record
	RIB table entries. It extends the TABLE_DUMP Type to include true		RIB table entries. It extends the TABLE_DUMP Type to include true
	multiprotocol support. However, this Type does not support 32BIT AS		multiprotocol support. However, this Type does not support 4-Byte AS
	numbers and has not been widely implemented. This Type is deprecated		numbers and has not been widely implemented. This Type is deprecated
	in favor of the TABLE_DUMP_V2 which includes 32BIT AS number support		in favor of the TABLE_DUMP_V2 which includes 4-Byte AS number support
	and a more compact format.		and a more compact format.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer AS number | Local AS number |		| Peer AS number | Local AS number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Interface Index | Address Family |		| Interface Index | Address Family |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer IP address (variable) |		| Peer IP address (variable) |
End of changes. 26 change blocks.
	77 lines changed or deleted		112 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/