Global Routing Operations Working T. Manderson Group ICANN Internet-DraftSeptember 8,December 14, 2010 Intended status: Informational Expires:March 12,June 17, 2011 MRT BGP routing information export format with geo-location extensionsdraft-ietf-grow-geomrt-00.txtdraft-ietf-grow-geomrt-01.txt Abstract This document extends the Border Gateway Protocol (BGP) MRT export format for routing information to include terrestrial coordinates. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months 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." This Internet-Draft will expire onMarch 12,June 17, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Geo-location aware MRT Routing InformationType .Subtype . . . . . . 54. TABLE_DUMP_v2+GEO Type . . . . . . .3.1. GEO_PEER_TABLE . . . . . . . . . . . . .6 5. Implementation Note . . . . .. . . . . . . . .. . . . . . . 9 6.5 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .10 7.7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . .11 8.8 6. Security Considerations . . . . . . . . . . . . . . . . . . .12 9.9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . .13 9.1.10 7.1. Normative References . . . . . . . . . . . . . . . . . . .13 9.2.10 7.2. Informative References . . . . . . . . . . . . . . . . . .1310 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .1411 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Introduction Research is underway that analyzes the network behavior of routing protocol transactions from routing information base snapshots in relation to geographical coordinates. Specifically the BGP routing protocol is the subject of study and the analysis has been significantly aided by the availability and extension of the "MRT format" [I-D.ietf-grow-mrt] originally defined in the MRT Programmer's Guide [MRT PROG GUIDE]. This memo documents an extension to the "MRT format" [I-D.ietf-grow-mrt] and introduces an additional definition of a MRTType field and relatedSubtypefields.field. 3. Geo-location aware MRT Routing InformationTypeSubtype ThefollowingadditionalTypeSubtype is defined for theTABLE_DUMP_v2+GEOTABLE_DUMP_v format, which extends the TABLE_DUMP_V2 type.[TYPE NUMBER] TABLE_DUMP_v2+GEO The TYPE NUMBER, an FCFS entry from the future IANA MRT registry is yet to be assigned. 4. TABLE_DUMP_v2+GEO Type3.1. GEO_PEER_TABLE TheTABLE_DUMP_v2+GEO TypeGEO_PEER_TABLE Subtype updates the TABLE_DUMP_v2TypeTypes to include Geo-location information in the form of WGS84 [WGS 84] formatted coordinates. ThefollowingMRT subtypes would be asused with the TABLE_DUMP_V2 Type, are used in the TABLE_DUMP_v2+GEO Type and their formats have been augmented to include the WGS84 coordinates.follows. 1 PEER_INDEX_TABLE 2 RIB_IPV4_UNICAST 3 RIB_IPV4_MULTICAST 4 RIB_IPV6_UNICAST 5 RIB_IPV6_MULTICAST 6 RIB_GENERIC 7 GEO_PEER_TABLE Theextended PEER_INDEX_TABLEGEO_PEER_TABLE MRT record provides the BGP ID of the collector,theIts latitude and longitude in WGS84 [WGS 84] format,an optional view name,and a list of indexed peers. The format and function of the Collector BGP ID,the View Name Length and View Name,Peer Count are as defined by the TABLE_DUMP_V2 MRTformatPEER_INDEX_TABLE format. [I-D.ietf-grow-mrt]. The Collector Latitude and Collector Longitude are the geographical coordinates of the collector in WGS84 [WGS 84] datum decimal degrees format stored as a single precision float in the 32 bits allocated to the Collector Latitude and Collector Longitude. The latitude and longitude may be a Not A Number (NAN) for situations where the geo- location of the collector is considered private. The Collector Latitude and Collector Longitude MUST NOT be a mix of WGS84 [WGS 84] datum coordinate and NAN values. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Collector BGP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Collector Latitude | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Collector Longitude | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |View Name Length | View Name (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Peer Count |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Peer entries (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the peer entries is shown below. The Peer Type and the Peer BGP ID is as defined in the TABLE_DUMP_V2 MRT [I-D.ietf-grow-mrt] PEER_INDEX_TABLErecord containsformat. The order of the PeerCount peer entries.entries in GEO_PEER_TABLE MUST match the order and number as existing in the PEER_INDEX_TABLE. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer BGP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PeerIP address (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer AS (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PeerLatitude | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer Longitude | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The PeerType, Peer BGP ID, Peer IP, Peer AS, Peer Latitude, and Peer Longitude fields are repeated as indicated by the Peer Count field. The position of the Peer in the PEER_INDEX_TABLE is used as an index in the subsequent TABLE_DUMP_V2+GEO MRT records. The index number begins with 0. The PeerLatitude and Peer Longitude are the geographical coordinates of thecollectorpeer in WGS84 [WGS 84] datum decimal degrees format stored as a single precision float in the 32 bits allocated to the Peer Latitude andLongitude. ThePeerType field remains as defined in the TABLE_DUMP_V2 MRT format [I-D.ietf-grow-mrt].Longitude. Therecords which follow the PEER_INDEX_TABLE record constitute the RIB entrieslatitude andtheir formats remain unchanged from TABLE_DUMP_V2+ GEO. That is the common formatlongitude may be a Not A Number (NAN) for situations where theRIB_IPV4_UNICAST, RIB_IPV4_MULTICAST, RIB_IPV6_UNICAST, and RIB_IPV6_MULTICAST remains as defined for TABLE_DUMP_V2 andgeo-location of theheaderpeer isshown below for informational purposes only. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Entry Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Similarly the the RIB_GENERIC format is unchanged and is shown here: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family Identifier |Subsequent AFI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Layer Reachability Information (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Entry Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+considered private. TheRIB entries that follow the RIB entry headers are also unchanged from MRT [I-D.ietf-grow-mrt]: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originated Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BGP Attributes... (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5. Implementation Note In implementation of the formats above where a Collector has an assigned Latitude and Longitude but aPeerdoes not. It is currently recommended that the Collector's coordinates are replicated in the Peer'sLatitude andLongitude. The inquiring researcher can then make the decision on the interpretation of the routes 'as seen' at those coordinates, or disregard any geographical information for the peer based on the comparison of the Collector andPeercoordinates. The TABLE_DUMP_v2+GEO formatLongitude MUSTnotNOT beused if the Collector's Latitudea mix of WGS84 [WGS 84] datum coordinate andLongitude have not been defined. 6.NAN values for a single Peer. 4. Acknowledgements Thanks to Andrew Clark, Ernest Foo, Dave Meyer, Larry Bluck, Richard Barnes, and Jeffrey Haas for reviewing this document. This document describes a small portion of the research towards the author's PhD.7.5. IANA Considerations This section requests the Internet Assigned Numbers Authority (IANA) register theTypeadditional Subtype codevalues (as FCFS as definedvalue as: 7 GEO_PEER_TABLE in the "MRT format" [I-D.ietf-grow-mrt] and Subtype code values related to theTABLE_DUMP_v2+GEOTABLE_DUMP_v2 typeas an entryin the MRTnamespaces,namespace, in accordance with BCP 26, RFC 5226 [RFC5226].8.6. Security Considerations This extension to the "MRT format" [I-D.ietf-grow-mrt] defines fields that are of a descriptive nature and provide information that is useful in the analysis of routing systems. As such, the author believes that they do not constitute an additional security risk.9.It is recommended that the operators of the BGP collector and Peers consider their own privacy concerns before supplying geographical coordinates in MRT dumps. 7. References9.1.7.1. Normative References [I-D.ietf-grow-mrt] Blunk, L., Karir, M., and C. Labovitz, "MRT routing information export format",draft-ietf-grow-mrt-11draft-ietf-grow-mrt-13 (work in progress),MarchSeptember 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.9.2.7.2. Informative References [MRT PROG GUIDE] Labovitz, C., "MRT Programmer's Guide", November 1999, <http://www.merit.edu/networkresearch/mrtprogrammer.pdf>. [WGS 84] Geodesy and Geophysics Department, DoD., "World Geodetic System 1984", January 2000, <http://earth-info.nga.mil/ GandG/publications/tr8350.2/wgs84fin.pdf>. Author's Address Terry Manderson ICANN Email: terry.manderson@icann.org