idnits 2.17.1 draft-manderson-grow-geomrt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The TABLE_DUMP_v2+GEO format MUST not be used if the Collector's Latitude and Longitude have not been defined. -- The document date (June 21, 2010) is 5051 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1058' is defined on line 255, but no explicit reference was found in the text == Unused Reference: 'RFC1195' is defined on line 258, but no explicit reference was found in the text == Unused Reference: 'RFC2080' is defined on line 261, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 267, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 269, but no explicit reference was found in the text == Unused Reference: 'RFC4760' is defined on line 272, but no explicit reference was found in the text == Unused Reference: 'RFC5340' is defined on line 280, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-grow-mrt-11 ** Downref: Normative reference to an Historic RFC: RFC 1058 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Global Routing Operations Working T. Manderson 3 Group ICANN 4 Internet-Draft June 21, 2010 5 Intended status: Standards Track 6 Expires: December 23, 2010 8 MRT BGP routing information export format with geo-location Extensions 9 draft-manderson-grow-geomrt-00.txt 11 Abstract 13 This document extends the Border Gateway Protocol (BGP) MRT export 14 format for routing information with terrestrial coordinates. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on December 23, 2010. 33 Copyright Notice 35 Copyright (c) 2010 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 51 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Geo-location aware MRT Routing Information Type . . . . . . . 5 53 4. TABLE_DUMP_v2+GEO Type . . . . . . . . . . . . . . . . . . . . 6 54 5. Implementation Note . . . . . . . . . . . . . . . . . . . . . 9 55 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 57 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 58 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 59 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 60 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 63 1. Requirements notation 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in [RFC2119]. 69 2. Introduction 71 Research is underway that analyzes the network behavior of routing 72 protocol transactions from routing information base snapshots in 73 relation to geographical coordinates. Specifically the BGP routing 74 protocol is the subject of study and the analysis has been 75 significantly aided by the availability and extension of the "MRT 76 format" [I-D.ietf-grow-mrt] originally defined in the MRT 77 Programmer's Guide [MRT PROG GUIDE]. 79 This memo documents an extension to the "MRT format" 80 [I-D.ietf-grow-mrt] and introduces an additional definition of a MRT 81 Type field and related Subtype fields. 83 3. Geo-location aware MRT Routing Information Type 85 The following additional Type is defined for the TABLE_DUMP_v2+GEO 86 format, which extends the TABLE_DUMP_V2 type. 88 65 (TBA) TABLE_DUMP_v2+GEO 90 4. TABLE_DUMP_v2+GEO Type 92 The TABLE_DUMP_v2+GEO Type updates the TABLE_DUMP_v2 Type to include 93 Geo-location information in the form of WGS84 [WGS 84] formatted 94 coordinates. The following subtypes as used with the TABLE_DUMP_V2 95 Type, are used in the TABLE_DUMP_v2+GEO Type and their formats have 96 been augmented to include the WGS84 coordinates. 98 1 PEER_INDEX_TABLE 99 2 RIB_IPV4_UNICAST 100 3 RIB_IPV4_MULTICAST 101 4 RIB_IPV6_UNICAST 102 5 RIB_IPV6_MULTICAST 103 6 RIB_GENERIC 105 The extended PEER_INDEX_TABLE MRT record provides the BGP ID of the 106 collector, the latitude and longitude in WGS84 [WGS 84] format, an 107 optional view name, and a list of indexed peers. 109 The format and function of the Collector BGP ID, the View Name Length 110 and View Name, Peer Count are as defined by the TABLE_DUMP_V2 MRT 111 format [I-D.ietf-grow-mrt]. 113 The Collector Latitude and Collector Longitude are the geographical 114 coordinates of the collector in WGS84 [WGS 84] format. 116 0 1 2 3 117 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 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | Collector BGP ID | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | Collector Latitude | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Collector Longitude | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | View Name Length | View Name (variable) | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Peer Count | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 The format of the peer entries is shown below. The PEER_INDEX_TABLE 131 record contains Peer Count peer entries. 133 0 1 2 3 134 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 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Peer Type | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Peer BGP ID | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Peer IP address (variable) | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Peer AS (variable) | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Peer Latitude | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Peer Longitude | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 The Peer Type, Peer BGP ID, Peer IP, Peer AS, Peer Latitude, and Peer 150 Longitude fields are repeated as indicated by the Peer Count field. 151 The position of the Peer in the PEER_INDEX_TABLE is used as an index 152 in the subsequent TABLE_DUMP_V2+GEO MRT records. The index number 153 begins with 0. 155 The Peer Latitude and Peer Longitude are the geographical coordinates 156 of the peer in WGS84 [WGS 84] format. 158 The Peer Type field remains as defined in the TABLE_DUMP_V2 MRT 159 format [I-D.ietf-grow-mrt]. 161 The records which follow the PEER_INDEX_TABLE record constitute the 162 RIB entries and their formats remain unchanged from TABLE_DUMP_V2+ 163 GEO. 165 That is the common format for the RIB_IPV4_UNICAST, 166 RIB_IPV4_MULTICAST, RIB_IPV6_UNICAST, and RIB_IPV6_MULTICAST remains 167 as defined for TABLE_DUMP_V2 and the header is shown below for 168 informational purposes only. 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Sequence number | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Prefix Length | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Prefix (variable) | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Entry Count | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 Similarly the the RIB_GENERIC format is unchanged and is shown here: 184 0 1 2 3 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Sequence number | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Address Family Identifier |Subsequent AFI | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Network Layer Reachability Information (variable) | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Entry Count | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 The RIB entries that follow the RIB entry headers are also unchanged 197 from MRT [I-D.ietf-grow-mrt]: 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Peer Index | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Originated Time | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Attribute Length | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | BGP Attributes... (variable) 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 5. Implementation Note 213 In implementation of the formats above where a Collector has an 214 assigned Latitude and Longitude but a Peer does not. It is currently 215 recommended that the Collector's coordinates are replicated in the 216 Peer's Latitude and Longitude. The inquiring researcher can then 217 make the decision on the interpretation of the routes 'as seen' at 218 those coordinates, or disregard any geographical information for the 219 peer based on the comparison of the Collector and Peer coordinates. 221 The TABLE_DUMP_v2+GEO format MUST not be used if the Collector's 222 Latitude and Longitude have not been defined. 224 6. Acknowledgements 226 Thanks to Andrew Clark, Ernest Foo, and Dave Meyer for reviewing this 227 document. 229 This document describes a small portion of the research towards the 230 the author's PhD. 232 7. IANA Considerations 234 This section requests the Internet Assigned Numbers Authority (IANA) 235 register the Type code values and Subtype code values related to the 236 TABLE_DUMP_v2+GEO type in the MRT namespaces, in accordance with BCP 237 26, RFC 5226 [RFC5226]. 239 8. Security Considerations 241 This extension to the "MRT format" [I-D.ietf-grow-mrt] defines fields 242 that are of a descriptive nature and provide information that is 243 useful in the analysis of routing systems. As such, the author 244 believes that they do not constitute an additional security risk. 246 9. References 248 9.1. Normative References 250 [I-D.ietf-grow-mrt] 251 Blunk, L., Karir, M., and C. Labovitz, "MRT routing 252 information export format", draft-ietf-grow-mrt-11 (work 253 in progress), March 2010. 255 [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, 256 June 1988. 258 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 259 dual environments", RFC 1195, December 1990. 261 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 262 January 1997. 264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, March 1997. 267 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 269 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 270 Protocol 4 (BGP-4)", RFC 4271, January 2006. 272 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 273 "Multiprotocol Extensions for BGP-4", RFC 4760, 274 January 2007. 276 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 277 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 278 May 2008. 280 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 281 for IPv6", RFC 5340, July 2008. 283 9.2. Informative References 285 [MRT PROG GUIDE] 286 Labovitz, C., "MRT Programmer's Guide", November 1999, 287 . 289 [WGS 84] Geodesy and Geophysics Department, DoD., "World Geodetic 290 System 1984", January 2000, . 293 Author's Address 295 Terry Manderson 296 ICANN 298 Email: terry.manderson@icann.org