idnits 2.17.1 draft-ietf-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 8, 2010) is 4950 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 266, but no explicit reference was found in the text == Unused Reference: 'RFC4760' is defined on line 269, 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 8, 2010 5 Intended status: Informational 6 Expires: March 12, 2011 8 MRT BGP routing information export format with geo-location extensions 9 draft-ietf-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 12, 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] datum decimal degrees 118 format stored as a single precision float in the 32 bits allocated to 119 the Latitude and Longitude. 121 0 1 2 3 122 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 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Collector BGP ID | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Collector Latitude | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Collector Longitude | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | View Name Length | View Name (variable) | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Peer Count | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 The format of the peer entries is shown below. The PEER_INDEX_TABLE 136 record contains Peer Count peer entries. 138 0 1 2 3 139 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 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Peer Type | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Peer BGP ID | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Peer IP address (variable) | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Peer AS (variable) | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Peer Latitude | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Peer Longitude | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 The Peer Type, Peer BGP ID, Peer IP, Peer AS, Peer Latitude, and Peer 155 Longitude fields are repeated as indicated by the Peer Count field. 156 The position of the Peer in the PEER_INDEX_TABLE is used as an index 157 in the subsequent TABLE_DUMP_V2+GEO MRT records. The index number 158 begins with 0. 160 The Peer Latitude and Peer Longitude are the geographical coordinates 161 of the collector in WGS84 [WGS 84] datum decimal degrees format 162 stored as a single precision float in the 32 bits allocated to the 163 Latitude and Longitude. 165 The Peer Type field remains as defined in the TABLE_DUMP_V2 MRT 166 format [I-D.ietf-grow-mrt]. 168 The records which follow the PEER_INDEX_TABLE record constitute the 169 RIB entries and their formats remain unchanged from TABLE_DUMP_V2+ 170 GEO. 172 That is the common format for the RIB_IPV4_UNICAST, 173 RIB_IPV4_MULTICAST, RIB_IPV6_UNICAST, and RIB_IPV6_MULTICAST remains 174 as defined for TABLE_DUMP_V2 and the header is shown below for 175 informational purposes only. 177 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Sequence number | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Prefix Length | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Prefix (variable) | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Entry Count | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 Similarly the the RIB_GENERIC format is unchanged and is shown here: 191 0 1 2 3 192 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 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Sequence number | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Address Family Identifier |Subsequent AFI | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Network Layer Reachability Information (variable) | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Entry Count | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 The RIB entries that follow the RIB entry headers are also unchanged 204 from MRT [I-D.ietf-grow-mrt]: 206 0 1 2 3 207 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 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Peer Index | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Originated Time | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Attribute Length | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | BGP Attributes... (variable) 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 5. Implementation Note 220 In implementation of the formats above where a Collector has an 221 assigned Latitude and Longitude but a Peer does not. It is currently 222 recommended that the Collector's coordinates are replicated in the 223 Peer's Latitude and Longitude. The inquiring researcher can then 224 make the decision on the interpretation of the routes 'as seen' at 225 those coordinates, or disregard any geographical information for the 226 peer based on the comparison of the Collector and Peer coordinates. 228 The TABLE_DUMP_v2+GEO format MUST not be used if the Collector's 229 Latitude and Longitude have not been defined. 231 6. Acknowledgements 233 Thanks to Andrew Clark, Ernest Foo, Dave Meyer, Larry Bluck, and 234 Jeffrey Haas for reviewing this document. 236 This document describes a small portion of the research towards the 237 author's PhD. 239 7. IANA Considerations 241 This section requests the Internet Assigned Numbers Authority (IANA) 242 register the Type code values (as FCFS as defined in the "MRT format" 243 [I-D.ietf-grow-mrt] and Subtype code values related to the 244 TABLE_DUMP_v2+GEO type as an entry in the MRT namespaces, in 245 accordance with BCP 26, RFC 5226 [RFC5226]. 247 8. Security Considerations 249 This extension to the "MRT format" [I-D.ietf-grow-mrt] defines fields 250 that are of a descriptive nature and provide information that is 251 useful in the analysis of routing systems. As such, the author 252 believes that they do not constitute an additional security risk. 254 9. References 256 9.1. Normative References 258 [I-D.ietf-grow-mrt] 259 Blunk, L., Karir, M., and C. Labovitz, "MRT routing 260 information export format", draft-ietf-grow-mrt-11 (work 261 in progress), March 2010. 263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", BCP 14, RFC 2119, March 1997. 266 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 267 Protocol 4 (BGP-4)", RFC 4271, January 2006. 269 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 270 "Multiprotocol Extensions for BGP-4", RFC 4760, 271 January 2007. 273 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 274 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 275 May 2008. 277 9.2. Informative References 279 [MRT PROG GUIDE] 280 Labovitz, C., "MRT Programmer's Guide", November 1999, 281 . 283 [WGS 84] Geodesy and Geophysics Department, DoD., "World Geodetic 284 System 1984", January 2000, . 287 Author's Address 289 Terry Manderson 290 ICANN 292 Email: terry.manderson@icann.org