draft-ietf-grow-mrt-05.txt   draft-ietf-grow-mrt-06.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: May 19, 2008 C. Labovitz Expires: May 22, 2008 C. Labovitz
Arbor Networks Arbor Networks
November 16, 2007 November 19, 2007
MRT routing information export format MRT routing information export format
draft-ietf-grow-mrt-05.txt draft-ietf-grow-mrt-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 May 19, 2008. This Internet-Draft will expire on May 22, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes the MRT format for routing information This document describes the MRT format for routing information
export. This format was developed in concert with the Multi-threaded export. This format was developed in concert with the Multi-threaded
Routing Toolkit (MRT) from whence the format takes it name. The Routing Toolkit (MRT) from whence the format takes it name. The
format can be used to export routing protocol messages, state format can be used to export routing protocol messages, state
changes, and routing information base contents. 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 Control Types . . . . . . . . . . . . . . . . . . . . . . 8 4. MRT Informational Types . . . . . . . . . . . . . . . . . . . 8
4.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. START Type . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. START Type . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. DIE Type . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. DIE Type . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . . . 8 4.4. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . . . 8
4.5. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . . . 8 4.5. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . . . 9
5. MRT Routing Information Types . . . . . . . . . . . . . . . . 9 5. MRT Routing Information Types . . . . . . . . . . . . . . . . 10
5.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1.1. BGP_NULL Subtype . . . . . . . . . . . . . . . . . . . 9 5.1.1. BGP_NULL Subtype . . . . . . . . . . . . . . . . . . . 10
5.1.2. BGP_UPDATE Subtype . . . . . . . . . . . . . . . . . . 10 5.1.2. BGP_UPDATE Subtype . . . . . . . . . . . . . . . . . . 11
5.1.3. BGP_PREF_UPDATE Subtype . . . . . . . . . . . . . . . 10 5.1.3. BGP_PREF_UPDATE Subtype . . . . . . . . . . . . . . . 11
5.1.4. BGP_STATE_CHANGE Subtype . . . . . . . . . . . . . . . 10 5.1.4. BGP_STATE_CHANGE Subtype . . . . . . . . . . . . . . . 11
5.1.5. BGP_SYNC Subtype . . . . . . . . . . . . . . . . . . . 11 5.1.5. BGP_SYNC Subtype . . . . . . . . . . . . . . . . . . . 12
5.1.6. BGP_OPEN Subtype . . . . . . . . . . . . . . . . . . . 11 5.1.6. BGP_OPEN Subtype . . . . . . . . . . . . . . . . . . . 12
5.1.7. BGP_NOTIFY Subtype . . . . . . . . . . . . . . . . . . 11 5.1.7. BGP_NOTIFY Subtype . . . . . . . . . . . . . . . . . . 12
5.1.8. BGP_KEEPALIVE Subtype . . . . . . . . . . . . . . . . 11 5.1.8. BGP_KEEPALIVE Subtype . . . . . . . . . . . . . . . . 12
5.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . . . 12 5.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . . . 13
5.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . . . 12 5.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . . . 13
5.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . . . 12 5.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . . . 13
5.6. OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 13 5.6. OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 14
5.7. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 13 5.7. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 14
5.8. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 15 5.8. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 16
5.9. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 17 5.9. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 18
5.9.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 18 5.9.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 19
5.9.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 19 5.9.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 20
5.9.3. BGP4MP_ENTRY Subtype . . . . . . . . . . . . . . . . . 19 5.9.3. BGP4MP_ENTRY Subtype . . . . . . . . . . . . . . . . . 20
5.9.4. BGP4MP_SNAPSHOT Subtype . . . . . . . . . . . . . . . 20 5.9.4. BGP4MP_SNAPSHOT Subtype . . . . . . . . . . . . . . . 21
5.9.5. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 20 5.9.5. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 21
5.9.6. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 21 5.9.6. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 22
5.10. BGP4MP_ET . . . . . . . . . . . . . . . . . . . . . . . . 21 5.10. BGP4MP_ET . . . . . . . . . . . . . . . . . . . . . . . . 22
5.11. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 22 5.11. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 23
5.12. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 22 5.12. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 23
5.13. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 22 5.13. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 23
5.14. OSPFv3_ET Type . . . . . . . . . . . . . . . . . . . . . . 23 5.14. OSPFv3_ET Type . . . . . . . . . . . . . . . . . . . . . . 24
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
6.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 24 6.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 25
6.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 24 6.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.1. Normative References . . . . . . . . . . . . . . . . . . . 26 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27
8.2. Informative References . . . . . . . . . . . . . . . . . . 26 8.2. Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . . . . . 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 6, line 32 skipping to change at page 6, line 32
Header Field Descriptions: Header Field Descriptions:
Timestamp: Timestamp:
Time in seconds since 1 January 1970 00:00:00 UTC Time in seconds since 1 January 1970 00:00:00 UTC
Type: Type:
A 2-octet field that indicates the Type of information A 2-octet field that indicates the Type of information
contained in the message field. Types 1 through 5 are used for contained in the message field. Types 0 through 4 are
MRT control information while Types 6 and higher are used for informational messages pertaining to the state of an MRT
routing information. collector, while Types 5 and higher are used to convey routing
information.
Subtype: Subtype:
A 2-octet message Subtype field A 2-octet field that is used to further distinguish message
information within a particular message Type.
Length: Length:
A 4-octet message length field. The length does not include A 4-octet message length field. The length field contains the
the header. number of bytes within the message. The length field does not
include the length of the MRT common header.
Message: Message:
A variable length message. The contents of this field are A variable length message. The contents of this field are
context dependent on the Type and Subtype fields. context dependent upon the Type and Subtype fields.
4. MRT Control Types 4. MRT Informational Types
The MRT format defines five Control Type messages. These messages The MRT format defines five Informational Type messages. These
are OPTIONAL and MAY be used to communicate the state of the MRT messages are intended to signal the state of an MRT data collector
message source and it's peering sessions. The message field MAY and do not contain routing information. These messages are OPTIONAL
contain an OPTIONAL message string for diagnostic purposes. The and were largely intended for use when MRT messages are sent over a
message string encoding MUST follow the UTF-8 transformation format. network to a remote repository store. However, MRT message
The Subtype field is unused for these Types and SHOULD be set to 0. repository stores have traditionally resided on the same device as
the collector and these Informational Types have seen limited
implementation. Further, transport mechanisms for MRT messages are
considered to be outside the scope of this document.
The MRT Control Types are defined below: Two of these messages are considered potentially useful in
implementations with a local repository. In particular, the START
and I_AM_DEAD messages MAY be used to provide a time reference when a
data collector begins and ends the collection process.
0 NULL The message field MAY contain an OPTIONAL message string for
diagnostic purposes. The message string encoding MUST follow the
UTF-8 transformation format. The Subtype field is unused for these
Types and SHOULD be set to 0.
The MRT Informational Types are defined below:
0 NULL *DEPRECATED*
1 START 1 START
2 DIE 2 DIE *DEPRECATED*
3 I_AM_DEAD 3 I_AM_DEAD
4 PEER_DOWN 4 PEER_DOWN *DEPRECATED*
4.1. NULL Type 4.1. NULL Type
The NULL Type message causes no operation, A sender may wish to send The NULL Type message causes no operation and is deprecated.
these for synchronization or keep-alive purposes.
4.2. START Type 4.2. START Type
The START Type indicates a sender is about to begin sending MRT The START Type indicates a collector is about to begin generating MRT
messages messages.
4.3. DIE Type 4.3. DIE Type
A DIE Type signals that the receiver should shut down. The DIE Type signals a remote MRT repository it should stop accepting
messages. This Type is deprecated.
4.4. I_AM_DEAD Type 4.4. I_AM_DEAD Type
A I_AM_DEAD indicates that the sender is shutting down. An I_AM_DEAD MRT message indicates that a collector has shut down and
has stopped generating MRT messages.
4.5. PEER_DOWN Type 4.5. PEER_DOWN Type
A PEER_DOWN indicates when one of the sender's peers is down. In The PEER_DOWN message was intended to indicate that a collector had
practice, a sender will likely have multiple peers. The sender lost association with a BGP peer. However, the MRT format provides
SHOULD use the Message field to convey the IP address of the peer BGP state change message types which duplicate this functionality.
represented in UTF-8. This Type is deprecated.
5. MRT Routing Information Types 5. MRT Routing Information Types
The following Types are currently defined for the MRT format. Types The following Types are currently defined for the MRT format. Types
5-12 were defined in the initial MRT Toolkit package. The BGP4MP 5-12 were defined in the MRT Toolkit package. The BGP4MP Type,
Type, number 16, was initially defined in the Zebra routing software number 16, was initially defined in the Zebra routing software
package. The BGP4MP_ET, ISIS, and ISIS_ET Types were initially package. The BGP4MP_ET, ISIS, and ISIS_ET Types were initially
defined in the Sprint Labs Python Routing Toolkit (PyRT). defined in the Sprint Labs Python Routing Toolkit (PyRT).
5 BGP *DEPRECATED* 5 BGP *DEPRECATED*
6 RIP 6 RIP
7 IDRP *DEPRECATED* 7 IDRP *DEPRECATED*
8 RIPNG 8 RIPNG
9 BGP4PLUS *DEPRECATED* 9 BGP4PLUS *DEPRECATED*
10 BGP4PLUS_01 *DEPRECATED* 10 BGP4PLUS_01 *DEPRECATED*
11 OSPF 11 OSPF
skipping to change at page 9, line 43 skipping to change at page 10, line 43
[RFC4271]. The information in the message is dependent on the [RFC4271]. The information in the message is dependent on the
Subtype value. The BGP Type and all associated Subtypes are Subtype value. The BGP Type and all associated Subtypes are
considered to be DEPRECATED by the BGP4MP Type. considered to be DEPRECATED by the BGP4MP Type.
The following BGP Subtypes are defined for the MRT BGP Type. The following BGP Subtypes are defined for the MRT BGP Type.
0 BGP_NULL 0 BGP_NULL
1 BGP_UPDATE 1 BGP_UPDATE
2 BGP_PREF_UPDATE 2 BGP_PREF_UPDATE
3 BGP_STATE_CHANGE 3 BGP_STATE_CHANGE
4 BGP_SYNC 4 BGP_SYNC *DEPRECATED*
5 BGP_OPEN 5 BGP_OPEN
6 BGP_NOTIFY 6 BGP_NOTIFY
7 BGP_KEEPALIVE 7 BGP_KEEPALIVE
5.1.1. BGP_NULL Subtype 5.1.1. BGP_NULL Subtype
The BGP_NULL Subtype is a reserved Subtype. The BGP_NULL Subtype is a reserved Subtype.
5.1.2. BGP_UPDATE Subtype 5.1.2. BGP_UPDATE Subtype
skipping to change at page 11, line 7 skipping to change at page 12, line 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source AS number | | Source AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address | | Source IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old State | New State | | Old State | New State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.1.5. BGP_SYNC Subtype 5.1.5. BGP_SYNC Subtype
The BGP_SYNC Subtype is used to indicate a File Name where BGP Table The BGP_SYNC Subtype was intended to convey a system file name where
Dump messages should be recorded. The View # corresponds to the View BGP Table Dump messages should be recorded. The View # was to
# provided in the TABLE_DUMP Type messages. The following format correspond to the View # provided in the TABLE_DUMP Type messages.
This Type is considered to be deprecated. The following format
applies to this Subtype: applies to this Subtype:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View # | | View # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| File Name... (variable) | File Name... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 8 skipping to change at page 16, line 8
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.8. TABLE_DUMP_V2 Type 5.8. TABLE_DUMP_V2 Type
The TABLE_DUMP_V2 type updates the TABLE_DUMP type to include 32-bit The TABLE_DUMP_V2 Type updates the TABLE_DUMP Type to include 32-bit
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
5 RIB_IPV6_MULTICAST 5 RIB_IPV6_MULTICAST
6 RIB_GENERIC 6 RIB_GENERIC
An initial PEER_INDEX_TABLE MRT record provides the BGP ID of the An initial PEER_INDEX_TABLE MRT record provides the BGP ID of the
collector, an optional view name, and a list of indexed peers. collector, an optional view name, and a list of indexed peers.
skipping to change at page 18, line 10 skipping to change at page 19, line 10
5.9. BGP4MP Type 5.9. BGP4MP Type
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 four Subtypes which are defined as follows: The BGP4MP Type has four Subtypes which are defined as follows:
0 BGP4MP_STATE_CHANGE 0 BGP4MP_STATE_CHANGE
1 BGP4MP_MESSAGE 1 BGP4MP_MESSAGE
2 BGP4MP_ENTRY *DEPRECATED* 2 BGP4MP_ENTRY *DEPRECATED*
3 BGP4MP_SNAPSHOT 3 BGP4MP_SNAPSHOT *DEPRECATED*
4 BGP4MP_STATE_CHANGE_AS4 4 BGP4MP_STATE_CHANGE_AS4
5 BGP4MP_MESSAGE_AS4 5 BGP4MP_MESSAGE_AS4
5.9.1. BGP4MP_STATE_CHANGE Subtype 5.9.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. As with the BGP_STATE_CHANGE Subtype, the BGP FSM states machine. As with the BGP_STATE_CHANGE Subtype, the BGP FSM states
are encoded in the Old State and New State fields to indicate the are encoded in the Old State and New State fields to indicate the
previous and current state. The format is illustrated below: previous and current state. The format is illustrated below:
skipping to change at page 19, line 47 skipping to change at page 20, line 47
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.9.3. BGP4MP_ENTRY Subtype 5.9.3. 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 32-bit AS multiprotocol support. However, this Type does not support 32-bit 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 32-bit AS number support in favor of the TABLE_DUMP_V2 which includes 32-bit 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source AS number | Destination AS number | | Source AS number | Destination AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family | | Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 20, line 35 skipping to change at page 21, line 35
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix (variable) | | Address Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | | Attribute Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Attribute... (variable) | BGP Attribute... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.9.4. BGP4MP_SNAPSHOT Subtype 5.9.4. BGP4MP_SNAPSHOT Subtype
This Subtype is used to indicate a filename containing BGP4MP_ENTRY This Subtype was intended to convey a system file name where
records. It is similar to the BGP_SYNC message Subtype and shares BGP4MP_ENTRY messages should be recorded. It is similar to the
the same fields. BGP_SYNC message Subtype and is deprecated.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View # | | View # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| File Name... (variable) | File Name... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.9.5. BGP4MP_STATE_CHANGE_AS4 Subtype 5.9.5. BGP4MP_STATE_CHANGE_AS4 Subtype
 End of changes. 30 change blocks. 
87 lines changed or deleted 105 lines changed or added

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