idnits 2.17.1 draft-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 (September 7, 2010) is 4978 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TYPE NUMBER' is mentioned on line 88, but not defined == Unused Reference: 'RFC4271' is defined on line 262, but no explicit reference was found in the text == Unused Reference: 'RFC4760' is defined on line 265, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-grow-mrt-11 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 6 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 September 7, 2010 5 Intended status: Informational 6 Expires: March 11, 2011 8 MRT BGP routing information export format with geo-location extensions 9 draft-grow-geomrt-00.txt 11 Abstract 13 This document extends the Border Gateway Protocol (BGP) MRT export 14 format for routing information to include 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 March 11, 2011. 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 [TYPE NUMBER] TABLE_DUMP_v2+GEO 90 The TYPE NUMBER, an FCFS entry from the future IANA MRT registry is 91 yet to be assigned. 93 4. TABLE_DUMP_v2+GEO Type 95 The TABLE_DUMP_v2+GEO Type updates the TABLE_DUMP_v2 Type to include 96 Geo-location information in the form of WGS84 [WGS 84] formatted 97 coordinates. The following subtypes as used with the TABLE_DUMP_V2 98 Type, are used in the TABLE_DUMP_v2+GEO Type and their formats have 99 been augmented to include the WGS84 coordinates. 101 1 PEER_INDEX_TABLE 102 2 RIB_IPV4_UNICAST 103 3 RIB_IPV4_MULTICAST 104 4 RIB_IPV6_UNICAST 105 5 RIB_IPV6_MULTICAST 106 6 RIB_GENERIC 108 The extended PEER_INDEX_TABLE MRT record provides the BGP ID of the 109 collector, the latitude and longitude in WGS84 [WGS 84] format, an 110 optional view name, and a list of indexed peers. 112 The format and function of the Collector BGP ID, the View Name Length 113 and View Name, Peer Count are as defined by the TABLE_DUMP_V2 MRT 114 format [I-D.ietf-grow-mrt]. 116 The Collector Latitude and Collector Longitude are the geographical 117 coordinates of the collector in WGS84 [WGS 84] format. 119 0 1 2 3 120 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 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Collector BGP ID | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Collector Latitude | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Collector Longitude | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | View Name Length | View Name (variable) | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Peer Count | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 The format of the peer entries is shown below. The PEER_INDEX_TABLE 134 record contains Peer Count peer entries. 136 0 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Peer Type | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Peer BGP ID | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Peer IP address (variable) | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Peer AS (variable) | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Peer Latitude | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Peer Longitude | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 The Peer Type, Peer BGP ID, Peer IP, Peer AS, Peer Latitude, and Peer 153 Longitude fields are repeated as indicated by the Peer Count field. 154 The position of the Peer in the PEER_INDEX_TABLE is used as an index 155 in the subsequent TABLE_DUMP_V2+GEO MRT records. The index number 156 begins with 0. 158 The Peer Latitude and Peer Longitude are the geographical coordinates 159 of the peer in WGS84 [WGS 84] format. 161 The Peer Type field remains as defined in the TABLE_DUMP_V2 MRT 162 format [I-D.ietf-grow-mrt]. 164 The records which follow the PEER_INDEX_TABLE record constitute the 165 RIB entries and their formats remain unchanged from TABLE_DUMP_V2+ 166 GEO. 168 That is the common format for the RIB_IPV4_UNICAST, 169 RIB_IPV4_MULTICAST, RIB_IPV6_UNICAST, and RIB_IPV6_MULTICAST remains 170 as defined for TABLE_DUMP_V2 and the header is shown below for 171 informational purposes only. 173 0 1 2 3 174 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 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Sequence number | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Prefix Length | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Prefix (variable) | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Entry Count | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Similarly the the RIB_GENERIC format is unchanged and is shown here: 187 0 1 2 3 188 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 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Sequence number | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Address Family Identifier |Subsequent AFI | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Network Layer Reachability Information (variable) | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Entry Count | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 The RIB entries that follow the RIB entry headers are also unchanged 200 from MRT [I-D.ietf-grow-mrt]: 202 0 1 2 3 203 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 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Peer Index | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Originated Time | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Attribute Length | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | BGP Attributes... (variable) 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 5. Implementation Note 216 In implementation of the formats above where a Collector has an 217 assigned Latitude and Longitude but a Peer does not. It is currently 218 recommended that the Collector's coordinates are replicated in the 219 Peer's Latitude and Longitude. The inquiring researcher can then 220 make the decision on the interpretation of the routes 'as seen' at 221 those coordinates, or disregard any geographical information for the 222 peer based on the comparison of the Collector and Peer coordinates. 224 The TABLE_DUMP_v2+GEO format MUST not be used if the Collector's 225 Latitude and Longitude have not been defined. 227 6. Acknowledgements 229 Thanks to Andrew Clark, Ernest Foo, Dave Meyer, Larry Bluck, and 230 Jeffrey Haas for reviewing this document. 232 This document describes a small portion of the research towards the 233 the author's PhD. 235 7. IANA Considerations 237 This section requests the Internet Assigned Numbers Authority (IANA) 238 register the Type code values (as FCFS as defined in the "MRT format" 239 [I-D.ietf-grow-mrt] and Subtype code values related to the 240 TABLE_DUMP_v2+GEO type as an entry in the MRT namespaces, in 241 accordance with BCP 26, RFC 5226 [RFC5226]. 243 8. Security Considerations 245 This extension to the "MRT format" [I-D.ietf-grow-mrt] defines fields 246 that are of a descriptive nature and provide information that is 247 useful in the analysis of routing systems. As such, the author 248 believes that they do not constitute an additional security risk. 250 9. References 252 9.1. Normative References 254 [I-D.ietf-grow-mrt] 255 Blunk, L., Karir, M., and C. Labovitz, "MRT routing 256 information export format", draft-ietf-grow-mrt-11 (work 257 in progress), March 2010. 259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 260 Requirement Levels", BCP 14, RFC 2119, March 1997. 262 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 263 Protocol 4 (BGP-4)", RFC 4271, January 2006. 265 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 266 "Multiprotocol Extensions for BGP-4", RFC 4760, 267 January 2007. 269 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 270 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 271 May 2008. 273 9.2. Informative References 275 [MRT PROG GUIDE] 276 Labovitz, C., "MRT Programmer's Guide", November 1999, 277 . 279 [WGS 84] Geodesy and Geophysics Department, DoD., "World Geodetic 280 System 1984", January 2000, . 283 Author's Address 285 Terry Manderson 286 ICANN 288 Email: terry.manderson@icann.org