--- 1/draft-ietf-grow-mrt-02.txt 2006-06-29 22:12:38.000000000 +0200 +++ 2/draft-ietf-grow-mrt-03.txt 2006-06-29 22:12:38.000000000 +0200 @@ -1,20 +1,20 @@ Network Working Group L. Blunk Internet-Draft M. Karir -Expires: September 7, 2006 Merit Network +Expires: December 28, 2006 Merit Network C. Labovitz Arbor Networks - March 6, 2006 + June 26, 2006 MRT routing information export format - draft-ietf-grow-mrt-02.txt + draft-ietf-grow-mrt-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -25,31 +25,32 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on September 7, 2006. + This Internet-Draft will expire on December 28, 2006. Copyright Notice Copyright (C) The Internet Society (2006). 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 + Routing Toolkit (MRT) from whence the format takes it name. The MRT + format was initially defined in the MRT Programmer's Guide [9]. The format can be used to export routing protocol messages, state changes, and routing information base contents. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Basic MRT Format . . . . . . . . . . . . . . . . . . . . . . . 4 3. MRT Control Types . . . . . . . . . . . . . . . . . . . . . . 6 3.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. START Type . . . . . . . . . . . . . . . . . . . . . . . . 6 @@ -663,40 +664,40 @@ Authority (IANA) regarding registration of values related to the MRT specification, in accordance with BCP 26, RFC 2434 [8]. There are two name spaces in MRT that require registration: Type Codes and Subtype Codes. MRT is not intended as a general-purpose specification for protocol information export, and allocations should not be made for purposes unrelated to routing protocol information export. - The following terms are used here with the meanings defined in BCP - 26: "name space", "assigned value", "registration". - The following policies are used here with the meanings defined in BCP - 26: "First Come First Served", "Specification Required". + 26: "Specification Required", "IETF Consensus". 5.1. Type Codes Type Codes have a range from 0 to 65535, of which 0-64 have been - allocated. New Type Codes should be allocated starting at 65 with - Specification Required. + allocated. New Type Codes should be allocated starting at 65. Type + Codes 65 - 32767 are to be assigned by IETF Consensus. Type Codes + 32768 - 65535 are assigned based on Specification Required. 5.2. Subtype Codes Subtype Codes have a range from 0 to 65535. Subtype definitions are specific to a particular Type Code definition. New Subtype Code definition must reference an existing Type Code to which the Subtype belongs. As Subtype Codes are specific to Type Codes, new numbers must be unique for the particular Type Code to which the Subtype - applies with Specification Required for the Subtype code. + applies. Subtype Codes specific to the Type Codes 0 - 32767 are + assigned by IETF Consensus. Suptype Codes specific to Type Codes + 32768 - 65535 are assigned based on Specification Required. 6. Security Considerations The MRT Format utilizes a structure which can store routing protocol information data. The fields defined in the MRT specification are of a descriptive nature and provide information that is useful to facilitate the analysis of routing data. As such, the fields currently defined in the MRT specification do not in themselves create additional security risks, since the fields are not used to induce any particular behavior by the recipient application. @@ -723,21 +724,22 @@ environments", RFC 1195, December 1990. [7] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 7.2. Informative References - [9] "The MRT Programmers Manual", November 1999. + [9] "MRT Programmer's Guide", November 1999, + . Authors' Addresses Larry Blunk Merit Network Email: ljb@merit.edu Manish Karir Merit Network